Day 3 — eBGP vs iBGP: Session Roles, Propagation Rules and Forwarding Implications
Learning objective
Explain how eBGP and iBGP serve different roles, predict how routes propagate between them, and diagnose the classic case where an iBGP-learned route stops at another iBGP speaker.
 |
| eBGP vs iBGP |
1. Opening — “BGP is BGP” is true only at the protocol layer
BGP uses the same protocol machinery whether two peers belong to the same autonomous system or different autonomous systems, but the routing semantics are not identical.
That distinction matters because a design can contain perfectly healthy BGP sessions while still failing to distribute routes where the operator expects them to go.
A common example is an enterprise with an Internet edge router, an internal route-distribution router, and another internal router. The edge learns an Internet prefix over eBGP and sends it to an iBGP peer. The engineer then expects that peer to pass the route to a second iBGP peer. It does not. The sessions are all Established. No ACL is blocking TCP. The route is valid. Yet propagation stops.
The reason is one of the most important iBGP rules in the protocol: a route learned from an internal BGP peer is not normally advertised to another internal BGP peer. This rule prevents loops inside an AS because the AS_PATH is not modified for ordinary iBGP propagation in the same way it is across eBGP boundaries.
Understanding this single rule leads directly to later topics such as iBGP full mesh, route reflectors, confederations and Add-Path.
2. Concept and standards behaviour
2.1 External BGP
An eBGP session is a BGP peering relationship between speakers in different autonomous systems.
Typical uses include:
- enterprise-to-ISP peering;
- ISP-to-customer peering;
- ISP-to-ISP transit;
- settlement-free peering;
- Internet exchange bilateral sessions;
- inter-AS MPLS or service-provider designs;
- and some data-centre underlays that intentionally use distinct ASNs per leaf or pod.
When a route crosses an ordinary eBGP boundary, the sending AS contributes to the AS path. That makes the AS_PATH a visible history of inter-AS traversal and provides loop prevention when a receiving AS sees its own ASN in the path.
2.2 Internal BGP
iBGP is BGP between speakers in the same autonomous system.
Its job is usually not to create a new interdomain boundary. Instead, it distributes BGP reachability and policy information inside the AS so multiple routers can make consistent decisions about external routes or BGP-carried services.
Examples include:
- distributing Internet routes between enterprise edge routers;
- carrying service-provider customer routes through a backbone;
- carrying VPNv4/VPNv6 routes between provider-edge routers;
- carrying EVPN routes in a data-centre fabric;
- and distributing routes among route-reflector clients.
2.3 Why iBGP does not simply re-advertise iBGP-learned routes
In ordinary iBGP, a route learned from one iBGP peer is not advertised to another iBGP peer.
The operational consequence is the classic full-mesh requirement: if every iBGP speaker must directly exchange ordinary iBGP-learned routes with every other speaker, all speakers need direct iBGP peerings unless the architecture uses route reflection or confederations.
For n iBGP speakers, a full mesh requires:
n(n-1)/2sessions.
This scales poorly as n grows, which is why route reflectors become a major design topic later in the series.
2.4 AS_PATH behavior
The inter-AS boundary and the AS path are tightly related.
At a high level:
- ordinary eBGP propagation adds the local ASN to the AS path;
- ordinary iBGP propagation inside the same AS does not add another copy of the local ASN for each internal hop.
If iBGP speakers were allowed to freely pass iBGP routes to one another without additional loop-control machinery, AS_PATH alone would not reveal those internal hops. The no-iBGP-to-iBGP propagation rule is therefore fundamental to loop prevention in classic iBGP.
2.5 Next-hop implications
Another important difference is next-hop handling.
When an external route is passed into iBGP, the internal routers must be able to resolve the BGP next hop. Depending on the topology and configuration, the original external next hop may not be reachable from internal routers.
A common Cisco design tool is next-hop-self, which causes the advertising iBGP speaker to make itself the next hop for the routes sent to a peer.
This lab uses next-hop-self deliberately so that the propagation lesson is not obscured by an unrelated next-hop reachability failure. Day 9 will treat NEXT_HOP in depth.
2.6 eBGP and iBGP are not “Internet BGP” and “private BGP”
The names describe the relationship between autonomous systems, not whether a route is public or private.
An internal BGP session may carry public Internet routes. An eBGP session may operate entirely inside a private data centre using private ASNs. The session classification comes from ASN relationship and design, not from whether the prefixes are globally routable.
3. Scenario — RETICUX Lab FND-003
AS 64512 has one Internet edge and two internal BGP speakers. The external provider is AS 64513.
Topology
 |
| Autonomous System Numbers |
AS 64512
iBGP iBGP
+--------+ 192.0.2.0/30 +-------+ 192.0.2.4/30 +-------+
| EDGE-A |--------------| CORE1 |---------------| CORE2 |
+--------+ +-------+ +-------+
|
| eBGP 203.0.113.0/30
|
+--------+
| ISP-A |
|AS64513 |
+--------+
|
198.51.100.0/24Interfaces
- EDGE-A Gi0/0:
203.0.113.1/30 - ISP-A Gi0/0:
203.0.113.2/30 - EDGE-A Gi0/1:
192.0.2.1/30 - CORE1 Gi0/0:
192.0.2.2/30 - CORE1 Gi0/1:
192.0.2.5/30 - CORE2 Gi0/0:
192.0.2.6/30 - ISP-A Loopback10:
198.51.100.1/24
BGP peerings
- ISP-A ↔ EDGE-A: eBGP, AS 64513 ↔ AS 64512
- EDGE-A ↔ CORE1: iBGP, both AS 64512
- CORE1 ↔ CORE2: iBGP, both AS 64512
Expected behavior
- ISP-A originates
198.51.100.0/24. - EDGE-A learns it over eBGP.
- EDGE-A advertises it to CORE1 over iBGP.
- CORE1 does not advertise that iBGP-learned route to CORE2 under classic iBGP rules.
This is the intended fault-demonstration state, not a platform bug.
4. Prerequisites
- Four IOS XE virtual routers.
- Basic IPv4 connectivity on all point-to-point links.
- No route-reflector configuration.
- No confederation configuration.
- No IGP is required for this small directly connected demonstration.
next-hop-selfis configured from EDGE-A toward CORE1 so CORE1 can resolve the external route through EDGE-A.
5. Baseline configuration
ISP-A — AS 64513
hostname ISP-A
!
interface GigabitEthernet0/0
ip address 203.0.113.2 255.255.255.252
no shutdown
!
interface Loopback10
ip address 198.51.100.1 255.255.255.0
!
router bgp 64513
bgp log-neighbor-changes
neighbor 203.0.113.1 remote-as 64512
address-family ipv4
network 198.51.100.0 mask 255.255.255.0
neighbor 203.0.113.1 activate
exit-address-familyEDGE-A — AS 64512
hostname EDGE-A
!
interface GigabitEthernet0/0
ip address 203.0.113.1 255.255.255.252
no shutdown
!
interface GigabitEthernet0/1
ip address 192.0.2.1 255.255.255.252
no shutdown
!
router bgp 64512
bgp log-neighbor-changes
neighbor 203.0.113.2 remote-as 64513
neighbor 192.0.2.2 remote-as 64512
address-family ipv4
neighbor 203.0.113.2 activate
neighbor 192.0.2.2 activate
neighbor 192.0.2.2 next-hop-self
exit-address-familyCORE1 — AS 64512
hostname CORE1
!
interface GigabitEthernet0/0
ip address 192.0.2.2 255.255.255.252
no shutdown
!
interface GigabitEthernet0/1
ip address 192.0.2.5 255.255.255.252
no shutdown
!
router bgp 64512
bgp log-neighbor-changes
neighbor 192.0.2.1 remote-as 64512
neighbor 192.0.2.6 remote-as 64512
address-family ipv4
neighbor 192.0.2.1 activate
neighbor 192.0.2.6 activate
exit-address-familyCORE2 — AS 64512
hostname CORE2
!
interface GigabitEthernet0/0
ip address 192.0.2.6 255.255.255.252
no shutdown
!
router bgp 64512
bgp log-neighbor-changes
neighbor 192.0.2.5 remote-as 64512
address-family ipv4
neighbor 192.0.2.5 activate
exit-address-family6. Verification before modification
On EDGE-A
show ip bgp summary
show ip bgp 198.51.100.0 255.255.255.0Expected relevant evidence:
- ISP-A is an external peer.
- CORE1 is an internal peer.
198.51.100.0/24is learned from AS 64513.
On CORE1
show ip bgp summary
show ip bgp 198.51.100.0 255.255.255.0
show ip route 198.51.100.0 255.255.255.0Expected:
- the route is present in BGP;
- the path still reflects external origin AS 64513;
- the next hop is EDGE-A because
next-hop-selfwas applied.
On CORE2
show ip bgp summary
show ip bgp 198.51.100.0 255.255.255.0Expected:
- the iBGP session to CORE1 is Established;
- the external prefix is absent.
This is the key observation: session success does not imply route propagation is permitted by BGP rules.
7. Controlled modification — add the missing full-mesh session
Classic iBGP can solve the problem by peering CORE2 directly with EDGE-A, but because they are not directly connected in this topology, transport reachability would first need to be provided. For a focused lab, add a loopback on each internal BGP speaker and static routes or an IGP, then build a direct logical iBGP session between EDGE-A and CORE2.
For this day, the conceptual correction is:
EDGE-A <---------------- iBGP ----------------> CORE2rather than expecting CORE1 to relay EDGE-A’s iBGP route.
In production networks with many routers, adding every pairwise session becomes operationally expensive. That is precisely why route reflectors exist; they will be covered in their own module rather than smuggled into this foundational lab.
8. Fault injection
Illustrative lab — not a real incident.
Lab name
FND-003-IBGP-NONTRANSIT
Fault
The operator assumes CORE1 will act as a BGP transit point between two ordinary iBGP sessions.
Symptoms
- All three relevant BGP sessions can be Established.
- CORE1 has the route.
- CORE2 does not receive it.
- There is no TCP failure.
- There is no prefix-list or route-map denying it.
Expected forwarding impact
CORE2 has no BGP route to the provider prefix and cannot forward toward it unless another routing source supplies a route.
9. Troubleshooting
``text show ip bgp summary ``
``text show ip bgp 198.51.100.0 255.255.255.0 ``
``text show ip bgp neighbors 192.0.2.6 advertised-routes ``
``text show running-config | section router bgp ``
- Confirm all neighbor sessions.
- On CORE1, confirm the route exists.
- Confirm whether the route was learned via iBGP.
- On CORE1, inspect advertisements toward CORE2.
- Verify that no outbound route map or prefix list explains the absence.
- Recognize the protocol rule: an ordinary iBGP speaker does not re-advertise an iBGP-learned route to another ordinary iBGP peer.
- Correct the topology using full mesh, route reflection, or confederation according to scale and design requirements.
Do not repeatedly clear BGP sessions; the sessions are not the failed component.
10. Root cause and correction
Root cause
The iBGP topology is incomplete. CORE1 was incorrectly expected to relay an iBGP-learned route to CORE2.
Corrective design options
- Small topology: Build full-mesh iBGP so CORE2 peers directly with EDGE-A.
- Scaled topology: Introduce route reflectors.
- Alternative architecture: Use confederations where justified.
The later scaling module will compare these approaches in detail.
11. Post-fix verification
After adding a valid direct or reflected control-plane path, verify on CORE2:
show ip bgp summary
show ip bgp 198.51.100.0 255.255.255.0
show ip route 198.51.100.0 255.255.255.0Then perform a traffic test toward 198.51.100.1 using an appropriate source address whose return path is known.
The complete forwarding test must verify both directions; learning a destination route on CORE2 alone does not guarantee the provider has a return route to CORE2’s source.
12. Rollback
If the added full-mesh peering is only for the lab, remove it and restore the original topology after preserving outputs:
show ip bgp summary
show ip bgp 198.51.100.0 255.255.255.0
show ip bgp neighbors
show loggingIn production, remove or alter iBGP topology only with independent management access and a documented rollback sequence, because losing internal BGP distribution can affect many external prefixes at once.
13. Production lessons
Architecture lesson
A chain of iBGP sessions is not equivalent to a chain of IGP adjacencies. Classic iBGP is not a hop-by-hop route-relay protocol.
Scale lesson
Full mesh is simple to reason about but scales as n(n-1)/2 sessions, which quickly motivates route-reflector architectures.
Forwarding lesson
Internal routers must also be able to resolve the BGP next hop. Route propagation and next-hop reachability are separate checks.
Troubleshooting lesson
When a route disappears between two healthy iBGP sessions, inspect where the route was learned before blaming filters or transport.
Security lesson
Do not treat eBGP as automatically untrusted and iBGP as automatically trusted. Both require deliberate policy and access controls appropriate to their role.
14. Knowledge check
Q1
CORE1 learns a route from EDGE-A over iBGP and has another ordinary iBGP session with CORE2. No route-reflector function is configured. Should CORE1 advertise that route to CORE2?
Answer: No. Classic iBGP does not normally advertise an iBGP-learned route to another iBGP peer.
Q2
Why does classic iBGP need full mesh or an alternative scaling mechanism?
Answer: Because iBGP-learned routes are not simply relayed between ordinary iBGP peers, so every speaker that needs direct exchange must peer with the others unless route reflection or confederations change the propagation architecture.
Q3
An eBGP route reaches an internal router but is not installed because the next hop is unreachable. Is that primarily a session-type problem or a next-hop reachability problem?
Answer: A next-hop reachability problem. The route can be successfully carried over iBGP yet still fail RIB installation or forwarding if the next hop cannot be resolved.
15. Sources
- RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)*.
- Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x: Configuring Internal BGP Features*.
- Cisco — *IP Routing Configuration Guide: Connecting to a Service Provider Using External BGP*.
- Cisco — *BGP Command Reference: show ip bgp neighbors*.
Accessed: 2026-08-11.