Hands-On Lab: Configuring iBGP and the Full-Mesh Requirement

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/24

Task 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 yet

R2# 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 R1

R3# 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 onward

R1(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 65010

R3# 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 it

Key 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.