Revisit the configuration of the iBGP routers
R2#sh run | s r b
router bgp 2
bgp log-neighbor-changes
neighbor 3.3.3.3 remote-as 2
neighbor 3.3.3.3 update-source Loopback2
neighbor 3.3.3.3 next-hop-self
neighbor 4.4.4.4 remote-as 2
neighbor 4.4.4.4 update-source Loopback2
neighbor 4.4.4.4 next-hop-self
neighbor 192.168.12.1 remote-as 1
R2#
R3#sh run | s r b
router bgp 2
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source Loopback3
neighbor 4.4.4.4 remote-as 2
neighbor 4.4.4.4 update-source Loopback3
R3#
R4#sh run | s r b
router bgp 2
bgp log-neighbor-changes
network 192.168.45.0
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source Loopback4
neighbor 2.2.2.2 next-hop-self
neighbor 3.3.3.3 remote-as 2
neighbor 3.3.3.3 update-source Loopback4
neighbor 3.3.3.3 next-hop-self
neighbor 192.168.45.5 remote-as 3
R4#
Full meshed iBGP
From the config R2 peers with R3 and R4. R3 peers with R2 and R4. R4 peers with R2 and R3, which logically looks like this.
This is known as full meshed (logically), each iBGP router needs to peer with every iBGP routers within the same Autonomous System (AS).
What if not fully meshed?
If iBGP routers are not fully meshed to one another will it work?
Before I removed the peering, let’s revisit the BGP routing table of R2, R3 and R4.
R2#sh ip route bgp | beg Gate
Gateway of last resort is not set
5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [200/0] via 4.4.4.4, 00:13:34
B 192.168.45.0/24 [200/0] via 4.4.4.4, 00:13:34
R2#
R3#sh ip route bgp | b Gate
Gateway of last resort is not set
5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [200/0] via 4.4.4.4, 00:21:45
B 192.168.12.0/24 [200/0] via 2.2.2.2, 00:03:47
B 192.168.45.0/24 [200/0] via 4.4.4.4, 00:21:45
R3#
R4#sh ip route bgp | b Gate
Gateway of last resort is not set
5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [20/0] via 192.168.45.5, 00:22:49
B 192.168.12.0/24 [200/0] via 2.2.2.2, 00:04:09
R4#
I removed the peering between R2 and R4.
R2(config)#router bgp 2
R2(config-router)#no neighbor 4.4.4.4
R2(config-router)#
R4(config)#router bgp 2
R4(config-router)#no neighbor 2.2.2.2
R4(config-router)#end
R4#
Let’s see the BGP tables on R2, R3 and R4.
R2#sh ip bgp | b Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/27 192.168.12.1 0 0 1 i
*> 192.168.12.0 0.0.0.0 0 32768 i
R2#
R3#sh ip bgp | b Net
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.0/27 2.2.2.2 0 100 0 1 i
*>i 5.5.5.5/32 4.4.4.4 0 100 0 3 i
*>i 192.168.12.0 2.2.2.2 0 100 0 i
*>i 192.168.45.0 4.4.4.4 0 100 0 i
R3#
R4#sh ip bgp | b Net
Network Next Hop Metric LocPrf Weight Path
*> 5.5.5.5/32 192.168.45.5 0 0 3 i
*> 192.168.45.0 0.0.0.0 0 32768 i
R4#
R2 has lost the update on how to go to 5.5.5.5/32 and 192.168.45.0/24.
R4 has lost the update on how to go to 1.1.1.0/27 and 192.168.12.0/24.
Only R3 which is peered to R2 and R4 has all the paths known, R3 however does not share what was learned from R4 to R2 and vice versa.
This is known as BGP split horizon; in iBGP an iBGP router does not share prefixes learned from one iBGP router with another iBGP router.
Between different ASes, eBGP does routing loop prevention by using AS_PATH attribute, an eBGP router drops the prefix if it sees its own AS number within the prefix update. In iBGP the AS is unchanged, hence the BGP split horizon is the mechanism to ensure there is no routing loop among iBGP routers.
cyruslab 