Lab Objective
Configure iBGP among three routers in the same autonomous system, deliberately configure only a partial mesh of peering relationships, observe a route failing to propagate to the router with no direct iBGP session, then complete the full mesh and verify propagation succeeds.
Lab Purpose
Unlike eBGP, covered in the previous lab, iBGP includes a built-in split-horizon-like rule: a router never re-advertises a route learned from one iBGP peer to another iBGP peer. This makes a full mesh of iBGP sessions a strict requirement within an AS, in contrast to IGPs like OSPF or EIGRP where a route learned from one neighbor is freely re-advertised to others.
Lab Topology
R1, R2, R3 all in AS 65010
R1 ---- R2 (iBGP session configured)
R2 ---- R3 (iBGP session configured)
R1 ---- R3 (NOT configured initially --
the deliberately incomplete link)
R1's LAN: 192.168.210.0/24Task 1: Configure Partial iBGP Mesh
Configure iBGP sessions between R1-R2 and R2-R3 only, leaving R1-R3 unconfigured.
Task 2: Advertise R1's Network
Advertise R1's LAN into BGP.
Task 3: Verify R2 Learns the Route
Confirm R2, directly peered with R1, learns the route via iBGP.
Task 4: Verify R3 Does NOT Learn the Route
Confirm R3, despite being peered with R2, never receives this route, since R2 will not re-advertise an iBGP-learned route to another iBGP peer.
Task 5: Complete the Full Mesh
Configure the missing R1-R3 iBGP session directly.
Task 6: Verify R3 Now Learns the Route
Confirm R3 receives the route once the full mesh is established.
Solution and Verification
R1(config)# router bgp 65010
R1(config-router)# neighbor 10.1.1.2 remote-as 65010
R1(config-router)# network 192.168.210.0 mask 255.255.255.0
R2(config)# router bgp 65010
R2(config-router)# neighbor 10.1.1.1 remote-as 65010
R2(config-router)# neighbor 10.2.2.2 remote-as 65010
R3(config)# router bgp 65010
R3(config-router)# neighbor 10.2.2.1 remote-as 65010
-- R1-R3 session deliberately not configured yetR2# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 192.168.210.0/24 10.1.1.1 0 100 0 i
-- R2 learned the route directly from R1R3# show ip bgp
-- (empty, or route absent -- R3 has no
-- entry for 192.168.210.0/24 at all)
R3# show ip bgp summary
Neighbor V AS MsgRcvd MsgSent State/PfxRcd
10.2.2.1 4 65010 8 8 0
-- The session with R2 is Established (0
-- prefixes received, not a down state),
-- confirming the session itself works fine
-- -- R2 is simply choosing not to forward
-- this particular iBGP-learned route onwardR1(config)# router bgp 65010
R1(config-router)# neighbor 10.3.3.2 remote-as 65010
R3(config)# router bgp 65010
R3(config-router)# neighbor 10.3.3.1 remote-as 65010R3# show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 192.168.210.0/24 10.1.1.1 0 100 0 i
-- R3 now learns the route directly from R1
-- over the newly completed direct session,
-- rather than relying on R2 to forward itKey Takeaway
iBGP's rule against re-advertising routes between iBGP peers exists specifically to prevent routing loops within an AS, since IGPs already handle loop prevention through their own metric-based mechanisms and BGP was not designed to duplicate that logic internally — the practical consequence is that every iBGP router within an AS must maintain a direct peering session with every other iBGP router, a full mesh that becomes operationally challenging at scale and is precisely the problem route reflectors, covered in a later lab, are designed to solve.