What is External BGP (EBGP)?

External BGP (EBGP) is a BGP session between routers in different autonomous systems, most often used to exchange routes with an ISP, an MPLS carrier, or another organization’s network. VOS applies EBGP-specific defaults – TTL, route preference, and failover behavior – that differ from internal BGP peering within a single AS.

Key takeaways

• EBGP peers routers in different autonomous systems, unlike IBGP within one.
• VOS gives EBGP routes a default preference of 20, versus IBGP’s 200.
• Versa uses EBGP for DIA breakout, MPLS PE peering, and gateway HA.
• AS path checks and a 64-hop default TTL are standard VOS EBGP settings.
• Versa recommends EBGP for redundant, dynamically routed site-to-site tunnels.

On this page: Why it matters · How it works · Types · EBGP & Versa · FAQ

Why is EBGP important?

Every network that connects to the outside world – an ISP, an MPLS carrier, a cloud on-ramp, a partner organization – does so across an administrative boundary that BGP was built to cross. EBGP is the peering type that spans it: independently operated autonomous systems agreeing on what routes to exchange, and under what policy. IBGP only distributes routes among routers already inside one organization.

An EBGP session sits at the network edge, so a misconfigured peer can leak internal routes outward or accept bogus prefixes inward. That is why EBGP sessions carry their own defaults for TTL, filtering, and AS-path validation, and why getting EBGP right makes multi-homing, MPLS handoffs, and internet breakout reliable rather than fragile.

What is EBGP?

An EBGP session forms when two BGP speakers peer and their Local AS and Peer AS values differ – the test that separates EBGP from IBGP. The boundary changes route handling: advertising to an EBGP neighbor prepends the local AS number to the AS path, and a received route whose path already contains the local AS is rejected – the loop-prevention that keeps external peerings from looping.

VOS applies EBGP-specific defaults that differ from IBGP. TTL defaults to 64 hops for both, so multihop EBGP works without a separate enable step. EBGP Preference defaults to 20 – favored over IBGP’s default of 200 – and options such as Suppress Peer AS, Relax First AS Check, Next Hop Unchanged, and Fast External Failover exist specifically for the AS boundary.

Types of EBGP sessions

Single-hop EBGP peers directly connected neighbors – the common case for a WAN handoff to a provider’s edge router. Multihop EBGP peers non-adjacent neighbors; VOS’s default 64-hop TTL means this works without a separate toggle. EBGP and IBGP are also selected explicitly as a peer group type when configuring a BGP instance, since each carries different defaults.

A distinct pattern is EBGP ECMP for redundant tunnels: when a cloud security proxy supports BGP, Versa’s guidance is to build a separate Transport VR per tunnel, run EBGP on each, and install two equal-cost next hops so both tunnels load-balance actively instead of sitting active/standby. That pattern, run in pairs across an HA cross-connect, is how gateways keep redundant EBGP reachability when one device fails.

EBGP & Versa

VOS uses an internal EBGP connection between a tenant VRF and the transport WAN virtual router to control direct internet access (DIA): the VRF advertises a default route over EBGP, per the Consolidated SD-WAN Design Guide. Because EBGP’s default preference (20) beats IBGP’s (200), a local breakout route wins by default; to force centralized breakout, Configure BGP workflows raise the EBGP Preference above 200.

For MPLS underlay peering, a gateway runs EBGP to the provider’s PE router and a second, internal EBGP session between the MPLS-Transport-VR and Tenant-LAN-VR, using dedicated AS numbers so the AS-path check blocks any route leaking back through the underlay, per the Versa SD-WAN Design Guide. In active-active gateway HA, both devices run EBGP over a cross-connect cable, one carrying only a default route while IBGP distributes the full route set – the behavior behind Versa’s EBGP recommendation for redundant tunnels.

Frequently asked questions

What is the difference between EBGP and IBGP?

EBGP peers routers whose Local AS and Peer AS differ – it connects independently administered networks. IBGP peers routers that share the same AS, distributing externally learned routes across it. VOS applies separate defaults to each: EBGP sessions get a route preference of 20 and IBGP sessions get 200.

Does EBGP require directly connected neighbors?

No. VOS sets a default TTL of 64 hops for both EBGP and IBGP sessions, so EBGP multihop peering works without a separate enablement step, unlike some routing platforms that require multihop to be turned on explicitly for non-adjacent EBGP peers.

Why does VOS prefer EBGP routes over IBGP routes by default?

VOS assigns EBGP sessions a default route preference of 20, versus 200 for IBGP, so an externally learned route wins over an internally learned one when both exist. Operators raise the EBGP preference above 200 to force traffic through a centrally managed IBGP-learned path instead, such as a hub breakout.

How does Versa use EBGP for direct internet access?

A tenant VRF forms an internal EBGP session with the transport WAN virtual router and advertises a default route over it, with NAPT translating outbound traffic to the transport interface’s public address. EBGP preference tuning then decides whether local or centralized breakout wins when both are available.

Why does Versa recommend EBGP for site-to-site tunnel redundancy?

EBGP sessions can run over each leg of a redundant tunnel pair, letting VOS install two equal-cost next hops for active-active load balancing instead of active/standby failover. The same per-tunnel EBGP pattern, paired across an HA cross-connect, keeps MPLS or internet reachability up when one gateway device fails.

More on EBGP

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about EBGP, these are worth looking at next.