Course contents

Module 1: BGP FoundationsLesson 1.3 (3 of 3 in this module)3 of 43 in the BGP course

eBGP and iBGP

Why can a router learn a BGP route but still be unable to use it? Let's follow one provider route from R1 to R2 and check its next hop.

Advanced · 12 min read

You'll learn to compare eBGP and iBGP sessions, predict the next hop and AS path a route carries across each, and explain why iBGP needs a full mesh or a route reflector.

Why does the route stop at R2?

On the course network, R1 learns 203.0.113.0/24 from ISP A over eBGP and passes it to R2 over iBGP. R2 stores the announcement, but cannot use this path because it cannot reach the announced next hop. A user on the company LAN is trying to reach a service at 203.0.113.10. R2 must use another eligible route, if one exists, or discard the packet. Seeing the prefix in the BGP table is not enough.

Where the route stops
Where the route stopsA route learned by iBGP is not passed on to another iBGP neighbour.ISP Asends 203.0.113.0/24R1learns it over eBGPadvertises to R2 (iBGP)R2learns it over iBGPwill not pass it onR3 or othersnever see it unlessfull mesh or reflector

On small screens, swipe sideways or focus the diagram and use the arrow keys.

The rule that stops it is split horizon for iBGP, and it explains the symptom on R2.

External BGP (eBGP) is a session between routers in different autonomous systems. An autonomous system (AS) is a routing domain identified by an AS number. Internal BGP (iBGP) is a session between routers in the same AS. These names describe the AS relationship, not whether the cable is inside or outside a building.

R1 and R2 are in company AS 64500. ISP A is AS 64501. R1 learns the external prefix from ISP A and uses iBGP to tell R2 about it. A next hop is the IP address towards which a router must resolve a route before forwarding packets.

Know the addresses before following the route

Know the addresses before following the route
Know the addresses before following the routeConnection or identity; R1; Other end. Provider Ethernet link, 192.0.2.0/30: Gi0/0: 192.0.2.2 ISP A: 192.0.2.1 Internal Ethernet link, 10.0.12.0/30: Gi0/1: 10.0.12.1 R2 Gi0/1: 10.0.12.2 iBGP endpoints, each /32: Loopback0: 10.255.0.1 R2 Loopback0: 10.255.0.2 BGP router identifiers: 1.1.1.1 R2: 2.2.2.2Connection or identityR1Other endProvider Ethernet link,192.0.2.0/30Gi0/0: 192.0.2.2ISP A: 192.0.2.1Internal Ethernet link,10.0.12.0/30Gi0/1: 10.0.12.1R2 Gi0/1: 10.0.12.2iBGP endpoints, each/32Loopback0: 10.255.0.1R2 Loopback0: 10.255.0.2BGP router identifiers1.1.1.1R2: 2.2.2.2

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Read each row across: the left box names the item, the others describe it.

A loopback is a software interface. OSPF, our internal routing protocol, already carries the loopback /32 routes across the internal link. The iBGP session uses these stable endpoints. The router IDs are identifiers, not the addresses of that session. The company LAN is 198.51.100.0/24; the server-shaped symbol in the diagram represents that whole LAN.

What differs between eBGP and iBGP

What differs between eBGP and iBGP
What differs between eBGP and iBGPProperty; eBGP; iBGP. Neighbours are in: Different ASes (remote-as ≠ own AS) The same AS (remote-as = own AS) Administrative distance (Cisco): 20 200 Where the neighbour can be: On a directly connected subnet by default (packets use TTL 1) Anywhere IP routing can reach (default TTL 255) AS path when sending: Own AS added to the front Unchanged Next hop when sending: Normally the sending router's peering address; shared-subnet exceptions exist Unchanged for routes learned over eBGP, unless configured otherwise Passing routes on: Eligible selected routes are advertised subject to policy and loop checks An iBGP-learned route is not sent to another ordinary iBGP peer; route reflection is an exception Usually peers with: The directly connected interface address Loopback addresses, reached through the IGPPropertyeBGPiBGPNeighbours are inDifferent ASes (remote-as ≠ own AS)The same AS (remote-as = own AS)Administrative distance(Cisco)20200Where the neighbour canbeOn a directly connected subnet bydefault (packets use TTL 1)Anywhere IP routing can reach(default TTL 255)AS path when sendingOwn AS added to the frontUnchangedNext hop when sendingNormally the sending router's peeringaddress; shared-subnet exceptionsexistUnchanged for routes learned overeBGP, unless configured otherwisePassing routes onEligible selected routes areadvertised subject to policy and loopchecksAn iBGP-learned route is not sent toanother ordinary iBGP peer; routereflection is an exceptionUsually peers withThe directly connected interfaceaddressLoopback addresses, reached throughthe IGP

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Read each row across: the left box names the item, the others describe it.

Administrative distance is Cisco's local preference between routing sources for the same prefix. With these defaults, eBGP distance 20 is preferred to OSPF distance 110; iBGP distance 200 is less preferred than OSPF. This comparison applies to the same prefix and mask. It does not make an eBGP /16 override a more-specific OSPF /24 when forwarding to that /24.

eBGP and iBGP side by side
eBGP and iBGP side by sideeBGP connects different AS numbers and changes the next hop and AS path. iBGP connects routers in the same AS and keeps them.eBGPDifferent AS numbersUsually directly connectedPrepends own AS to the pathNext hop changes to senderiBGPSame AS numberOften peers on loopbacksAS path is not changedNext hop is kept by defaultand

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Same message types and attributes, different rules for what changes and what is passed on.

TTL (time to live) limits how many routers an IP packet can cross. It applies to the packets carrying the BGP session, not to every user packet using a BGP route. An IGP (interior gateway protocol), such as OSPF, provides internal reachability; static routes can also provide it.

The next hop does not change inside the AS

Who changes the next hop along the path
Who changes the next hop along the pathISP A advertises 203.0.113.0/24 to R1 with next hop 192.0.2.1, the ISP A side of the link. R1 passes it to R2 over iBGP without changing the next hop, so R2 still points at 192.0.2.1. R2 then advertises it to R3 over eBGP and sets the next hop to its own address 198.51.100.1.AS 64500ISP AAS 64501R1R2R3AS 64502eBGPiBGPeBGPR1 hears next hop192.0.2.1R2 hears next hop192.0.2.1 (unchanged)R3 hears next hop198.51.100.1Amber is the trap: an outside address that R2 may have no route to.

On small screens, swipe sideways or focus the diagram and use the arrow keys.

eBGP sets the next hop to the sender. iBGP leaves it alone. R2 must therefore be able to reach 192.0.2.1, which is outside its own AS, or it marks the route inaccessible. The usual fix is next-hop-self on R1.

ISP A advertises 203.0.113.0/24 with next hop 192.0.2.1. R1 can reach that address on its directly connected provider link. R2 knows R1's loopback but, at this stage, has no route to 192.0.2.1. Ordinary iBGP preserves the external next hop, so the announcement alone does not tell R2 how to reach it.

An established iBGP session does not guarantee that the next hop of every learned route is reachable.

192.0.2.0/30192.0.2.4/30Gi0/1 .1.2 Gi0/110.0.12.0/30Gi0/2Gi0/2InternetISP AAS 64501ISP BAS 64502R1RID 1.1.1.1R2RID 2.2.2.2Company LAN, AS 64500Subnet 198.51.100.0/24

Device key: ISP A, ISP B, R1, R2 (router) · Company LAN, AS 64500 (network / site)

Lines show the example’s network connections. Thick links: uplinks/WAN, as labelled. The coloured path and envelope follow the current step; its text identifies the sender, receiver and traffic type.

Reading the addresses

IP labels identify interfaces or destinations. Subnet labels identify networks; /n is the prefix length. A router ID (RID) identifies a routing process and need not be a reachable interface.

An IP address alone is not a URL. A web URL includes a scheme such as https://; an address on a router or printer does not imply a website.

  • ISP A: AS 64501
  • ISP B: AS 64502
  • R1: RID 1.1.1.1
  • R2: RID 2.2.2.2
  • Company LAN, AS 64500: Subnet 198.51.100.0/24
  1. 1. eBGP from ISP A: ISP A sets the next hop to its own address, 192.0.2.1, and the AS path to 64501.
  2. 2. iBGP to R2, unchanged: R1 passes the route on with the same next hop and AS path.
  3. 3. R2 can't use it: R2 has no route to 192.0.2.1, the subnet on R1's ISP link, so the BGP route is not valid for R2.
  4. 4. With next-hop-self on R1: R1 puts its own loopback in the next hop, which R2 reaches through OSPF, and the route is usable.
R1 passes ISP A's route to R2. next-hop-self changes the advertised forwarding next hop, while the destination prefix and AS path stay the same.
Example output written for this lesson, based on Cisco IOS documentation
R2#show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
   i  203.0.113.0      192.0.2.1                0    100      0 64501 i
 *>   198.51.100.0     0.0.0.0                  0         32768 i
The i in the left status columns marks an iBGP-learned route. The missing *means this path is not valid for selection: next hop 192.0.2.1 is unreachable. The missing >means it is not BGP's best path. The final i, after 64501, is a different field: the origin code. Here it says the prefix was originated using BGP's IGP-origin mechanism, commonly a network statement. The prefix is /24; this illustrative IOS output omits its classful mask.

There are two common fixes. The usual one is to make R1 advertise itself as the next hop to its iBGP neighbours:

router bgp 64500 neighbor 10.255.0.2 next-hop-self

R1. Routes sent to R2 now carry R1's update-source address (its loopback, 10.255.0.1) as the next hop. R2 reaches that through OSPF.

Example output written for this lesson, based on Cisco IOS documentation
R2#show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>i  203.0.113.0      10.255.0.1               0    100      0 64501 i
 *>   198.51.100.0     0.0.0.0                  0         32768 i
Now * marks a valid path and > marks BGP's best path. With no better competing routing source in this example, it is installed with distance 200. Confirm with show ip route 203.0.113.10; the BGP best marker alone does not prove installation. Another fix is to provide internal routes to the provider link, but that spreads provider addressing through the company network.

Why iBGP needs a full mesh

Why a full iBGP mesh does not scale
Why a full iBGP mesh does not scaleFour iBGP routers in a full mesh need six sessions. The number of sessions is n times n minus one, divided by two, so 10 routers need 45, 20 need 190 and 50 need 1225.4 routers, 6 sessionsR1R2R3R4Sessions = n (n - 1) / 24 routers66 routers1510 routers4520 routers19050 routers1225

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Every router must peer with every other router because iBGP does not pass on what it learned from another iBGP neighbour. The count grows with the square of the routers, which is what route reflectors and confederations remove.

eBGP loop prevention relies on the AS path, but iBGP doesn't change the AS path, so it can't catch a loop inside one AS. BGP prevents that with a simple rule: a route learned from an iBGP neighbour is not advertised to another iBGP neighbour. The consequence is that every BGP router in this ordinary iBGP design must have a session with every other BGP router that needs these routes. This requirement is a full mesh of BGP sessions, not a full mesh of physical cables.

RARBRCRD

Device key: RA, RB, RC, RD (router)

Lines show the example’s network connections. The coloured path and envelope follow the current step; its text identifies the sender, receiver and traffic type.

  1. 1. RA tells RB: RA learned a route over eBGP and sends it to its iBGP neighbour RB.
  2. 2. RB stops there: RB learned it over iBGP, so it doesn't pass it on to RD; RD needs its own session with RA.
  3. 3. The fix is a session to everyone: Four routers need 6 iBGP sessions: n × (n − 1) / 2.
Separate four-router illustration: lines are logical iBGP sessions. Four ordinary iBGP speakers need six sessions to exchange all their routes.

Sessions don't follow cables: an iBGP session runs over TCP between loopbacks, wherever the IGP can reach. Even so, 10 routers need 45 sessions and 50 need 1 225. Large networks replace the full mesh with route reflectors, which are allowed to pass iBGP routes on; Module 5 configures one.

Mistakes that come from mixing the two

Three common mixing mistakes
Three common mixing mistakesEach mistake has a different symptom.Symptom: route missingWrong remote-asPeer is eBGP when itshould be iBGP, or thereverseUnreachable next hopRoute is in the table butnot installed or not bestMissing iBGP sessionRoute stops at oneiBGP router

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Compare remote-as, next hop and the iBGP mesh before changing policy.
  • Expecting iBGP to change the next hop. It doesn't, so remote iBGP routers need next-hop-self or a route to the ISP link.
  • Peering eBGP between loopbacks with only the default connected-neighbour settings. Check routing, update-source and the connected-neighbour or multihop settings together.
  • Leaving out iBGP sessions between some routers and expecting routes to pass through them.
  • Being surprised that an iBGP route (200) loses to the same prefix in OSPF (110). That is by design.

Check the repair yourself

Use a Cisco IOS or IOS XE lab with the interfaces and loopbacks above, working OSPF loopback reachability, an established R1–ISP A session and an established R1–R2 iBGP session sourced from Loopback0. ISP A must already advertise the example prefix. These commands add a next-hop repair; they do not build those prerequisites.

show ip bgp 203.0.113.0 255.255.255.0 show ip route 192.0.2.1 show ip route 10.255.0.1

R2, privileged EXEC mode. Before the repair, compare the unreachable provider next hop with the reachable R1 loopback.

On R1, enter global configuration mode, open router bgp 64500 and apply the earlier neighbor 10.255.0.2 next-hop-self command. IOS variants using explicit address families place this command under address-family ipv4 unicast. Recheck R2 after the new advertisement arrives; avoid a disruptive hard session reset simply to test a route-policy change.

show ip bgp 203.0.113.0 255.255.255.0 show ip route 203.0.113.10

R2, after the change. Expect next hop 10.255.0.1 and a usable route. If it still fails, check the loopback route and the peer's update-source configuration before changing other settings.

The trade-off is management: a full mesh is straightforward for a few routers, but its session count grows quickly. Route reflectors reduce the count and add their own design rules. Technical references: RFC 4271 and Cisco's BGP troubleshooting guide. Examples are illustrative, not a claim of a physical-router test.

Test yourself on eBGP and iBGP

Predict · scenario 1

R2 learns 203.0.113.0/24 from R1 over iBGP. R1 learned it from ISP A (192.0.2.1). R1 has no next-hop-self. What next hop does R2 see?

Predict · scenario 2

What is the administrative distance of an iBGP route on Cisco IOS?

Predict · scenario 3

Five BGP routers in one AS, no route reflector. How many iBGP sessions are needed?

Predict · scenario 4

R1 and ISP A configure eBGP between their loopback addresses, with no other settings. The session never comes up. Why?

FAQ

If R1 already learns the routes from ISP A, why does R2 need iBGP?
So that R2 knows which destinations are better reached through ISP A, and can send that traffic to R1 instead of out of ISP B. Without iBGP, each router only knows its own provider's routes.
Why not redistribute BGP into OSPF instead of running iBGP?
BGP tables can be very large, and OSPF would carry them as external routes without the BGP attributes that policy depends on. iBGP keeps the attributes and leaves the IGP small: it only has to reach the iBGP neighbours and next hops.
What is BGP synchronization?
An old rule that an iBGP-learned route was not used until the same route was also learned from the IGP. It made sense when iBGP did not run on every router in the path. It is off by default since Cisco IOS 12.2(8)T and is almost never turned on today.