eBGP vs iBGP: What's the Difference and When to Use Each

BGP is one protocol, but it behaves very differently depending on whether two peers are in the same autonomous system or different ones. External BGP (eBGP) connects different organizations across AS boundaries. Internal BGP (iBGP) distributes externally learned routes within your own AS. The rules governing each are different enough that treating them as the same thing will get you into trouble fast.

The Core Difference

The distinction is simple: if two BGP neighbors share the same AS number, the session is iBGP. If they have different AS numbers, it's eBGP. Everything else — TTL behavior, next-hop handling, AS-path modification, route advertisement rules — flows from this one distinction.

In our PingLabz BGP Lab:

• eBGP: R1-HQ (AS 65001) ↔ ISP-A-PE1 (AS 65010) — different ASes
• iBGP: R1-HQ (AS 65001) ↔ R2-HQ (AS 65001) — same AS

Behavioral Differences

TTL and Multihop

eBGP sets the IP TTL to 1 by default, meaning the peer must be directly connected. If you need to peer with an eBGP neighbor multiple hops away (common in IXP route server peering or multihop scenarios), you must configure:

R1-HQ(config)# router bgp 65001
R1-HQ(config-router)# neighbor 192.0.2.1 remote-as 64512
R1-HQ(config-router)# neighbor 192.0.2.1 ebgp-multihop 3

iBGP peers default to TTL 255, so multihop is not an issue. iBGP sessions typically peer between loopback addresses (reachable via OSPF or another IGP) rather than physical interface IPs. This provides resilience — if one physical link fails, the iBGP session stays up as long as there's any path between the loopbacks.

R1-HQ(config)# router bgp 65001
R1-HQ(config-router)# neighbor 2.2.2.2 remote-as 65001
R1-HQ(config-router)# neighbor 2.2.2.2 update-source Loopback0

The update-source Loopback0 is essential for loopback-based iBGP peering. Without it, BGP uses the outgoing interface IP as the source, which won't match the configured neighbor address on the remote side.

The Next-Hop Problem

When R1-HQ learns a prefix from ISP-A-PE1 (eBGP), the next-hop is set to 203.0.113.1 (the ISP's interface). When R1-HQ advertises that prefix to R2-HQ over iBGP, the next-hop is not changed — it stays as 203.0.113.1.

R2-HQ now has a BGP route with a next-hop it can't reach (it's not directly connected to the ISP). The route exists in the BGP table but never makes it into the routing table. This is the classic iBGP next-hop reachability problem.

The fix is next-hop-self, which we cover in BGP Next-Hop-Self: When and Why You Need It:

R1-HQ(config-router)# neighbor 2.2.2.2 next-hop-self

This tells R1-HQ to change the next-hop to its own loopback (1.1.1.1) when advertising to R2-HQ, making the route resolvable via the IGP.

The iBGP Split-Horizon Rule

This is the rule that catches everyone off guard: a route learned from one iBGP peer is NOT advertised to another iBGP peer. This is a loop prevention mechanism — since iBGP doesn't modify the AS-path, there's no way to detect loops through AS-path inspection alone.

The consequence: in an AS with more than two BGP speakers, you need either:

• Full mesh iBGP: Every BGP router peers with every other BGP router. Works fine for small networks (formula: n*(n-1)/2 sessions). At 10 routers, that's 45 sessions. At 50, it's 1,225 — unmanageable.
• Route reflectors: Designated routers that can re-advertise iBGP routes to other iBGP peers, using cluster-id and originator-id attributes for loop prevention. This is the standard solution — see BGP Route Reflectors: Eliminating the Full Mesh.
• Confederations: The AS is split into sub-ASes that use eBGP-like rules between them. Less common — see BGP Confederations: An Alternative to Route Reflectors.

Administrative Distance

Cisco assigns different administrative distances to eBGP and iBGP:

• eBGP: AD 20 — very trusted, preferred over IGP routes (OSPF = 110, EIGRP = 90)
• iBGP: AD 200 — less trusted than IGP routes

This means if you have an OSPF route and an iBGP route to the same prefix, the OSPF route wins. This is by design — iBGP routes are learned externally and may not reflect the optimal internal path. The IGP route (which represents the actual internal topology) should take precedence.

When to Use Each

• Use eBGP when connecting to external organizations: ISPs, peers at IXPs, cloud providers, partner networks. Also increasingly used in data center fabrics (eBGP between spine and leaf switches).
• Use iBGP when you need to carry externally learned BGP prefixes across your internal network — for example, when you have multiple border routers connecting to different ISPs and internal routers need to know about those external paths.

Many enterprise networks use eBGP with their ISPs but don't run iBGP at all — they simply redistribute a default route from BGP into their IGP. iBGP becomes necessary when you need internal routers to make path-selection decisions based on BGP attributes (local-pref, AS-path, MED) rather than just following a default route.

Verification

R1-HQ# show ip bgp neighbors 203.0.113.1 | include External
  External BGP neighbor may be up to 1 hop away.

R1-HQ# show ip bgp neighbors 10.1.1.2 | include Internal
  Internal BGP neighbor may be up to 255 hops away.

R1-HQ# show ip bgp 100.64.0.0/24
BGP routing table entry for 100.64.0.0/24, version 18
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  65010
    203.0.113.1 from 203.0.113.1 (203.0.113.1)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

Key Takeaways

• eBGP connects different ASes; iBGP distributes BGP routes within the same AS. The behavioral differences are significant.
• iBGP does not modify the next-hop by default — use next-hop-self to fix reachability issues.
• The iBGP split-horizon rule prevents iBGP-learned routes from being re-advertised to other iBGP peers. Solve with full mesh, route reflectors, or confederations.
• eBGP has AD 20 (preferred over IGPs); iBGP has AD 200 (less preferred). This is intentional — trust internal topology over external paths.
• iBGP sessions should peer between loopback addresses for resilience, using update-source Loopback0.