Tasks
● Ensure that there is no BGP configuration on R1 - R8.
● Configure R2 in BGP AS 200.
● Configure BGP on all other R1 - R8 routers using AS 100.
● Configure iBGP peerings from R1 to all other devices in AS 100.
● Configure EBGP peerings between R7 and R9, between R8 and R10 using their directly connected links.
R9 and R10 are in AS 54 and are preconfigured to peer with R7 and R8.
● Configure EBGP peerings between R2 and R3, between R2 and R5.
● Advertise Loopback0 prefixes of R1 - R8 into BGP.
● Do not advertise the links between R7 and R9, between R8 and R10 into EIGRP.
● Use the next-hop-self command where necessary to ensure full IPv4 connectivity to the prefixes coming from AS 54.
● Ensure full reachability to Loopback0 prefixes from R1 - R8, and to all prefixes learned from AS 54 from R1 - R8 when sourcing traffic from the Loopback0 interfaces.
Configurations
R1:
en
conf t
router bgp 100
network 170.1.1.1 mask 255.255.255.255
neighbor 177.1.0.3 remote-as 100
neighbor 177.1.0.5 remote-as 100
neighbor 177.1.58.8 remote-as 100
neighbor 177.1.67.7 remote-as 100
neighbor 177.1.146.4 remote-as 100
neighbor 177.1.146.6 remote-as 100
neighbor 177.1.0.3 route-reflector-client
neighbor 177.1.0.5 route-reflector-client
neighbor 177.1.58.8 route-reflector-client
neighbor 177.1.67.7 route-reflector-client
neighbor 177.1.146.4 route-reflector-client
neighbor 177.1.146.6 route-reflector-client
end
R2:
en
conf t
router bgp 200
network 170.1.2.2 mask 255.255.255.255
neighbor 177.1.23.3 remote-as 100
neighbor 177.1.0.5 remote-as 100
end
R3:
en
conf t
router bgp 100
network 170.1.3.3 mask 255.255.255.255
neighbor 177.1.0.1 remote-as 100
neighbor 177.1.23.2 remote-as 200
end
R4:
en
conf t
router bgp 100
network 170.1.4.4 mask 255.255.255.255
neighbor 177.1.146.1 remote-as 100
end
R5:
en
conf t
router bgp 100
network 170.1.5.5 mask 255.255.255.255
neighbor 177.1.0.1 remote-as 100
neighbor 177.1.0.2 remote-as 200
end
R6:
en
conf t
router bgp 100
network 170.1.6.6 mask 255.255.255.255
neighbor 177.1.146.1 remote-as 100
end
R7:
en
conf t
router bgp 100
network 170.1.7.7 mask 255.255.255.255
neighbor 177.1.146.1 remote-as 100
neighbor 177.1.146.1 next-hop-self
neighbor 177.1.79.9 remote-as 54
end
R8:
en
conf t
router bgp 100
network 170.1.8.8 mask 255.255.255.255
neighbor 177.1.0.1 remote-as 100
neighbor 177.1.0.1 next-hop-self
neighbor 177.1.108.10 remote-as 54
end
Verifications
Recall from the IP Routing section how the route recursion process works. When the longest match route is found for the destination in question, the next-hop value of the prefix is checked. If the longest match to the next-hop value is a connected route, the outgoing interface is known, the Layer 2 address is found (depending on the media), and the frame is built for transmission. If the next-hop value is not via a connected interface, additional routing lookups (“recursive” lookups) must be performed until an outgoing interface is found.
With IGP routing, this process is usually transparent, because in the vast majority of cases routes are always learned from directly connected neighbors. For example, if an OSPF route is learned from neighbor A via interface X, it is safe to assume that interface X will be used to reach that destination. However, with BGP, a disconnect can occur between the neighbor from which prefixes are learned (the control plane) and the actual path that packets take toward the prefix (the forwarding/data plane). The main reason for this is that in many cases, BGP neighbors are not directly connected, but instead exchange BGP control plane information over additional hops in the network. This process can occur because IGP information provides reachability to establish the TCP transport inherent to the BGP control plane.
To ensure that this disconnect does not adversely affect the actual forwarding of traffic, the BGP process internally performs the route recursion process for all prefixes toward performing Bestpath selection. If route recursion is not successful (such as if the final outgoing interface cannot be found), the prefix cannot be considered for Bestpath selection. This implies that the prefix cannot be installed in the IP routing table, nor can it be advertised to any other BGP peers. In this particular example, this problem can be illustrated in AS 100 by the routes that are learned from AS 54 after disabling next-hop-self on R7:
R7(config)#router bgp 100
R7(config-router)#no neighbor 177.1.146.1 next-hop-self
R1#show ip bgp 112.0.0.0
R7 and R8 both learn the prefix 112.0.0.0/8 from their EBGP peers in AS 54 and pass the route on to R1. Because the route is being advertised to an iBGP neighbor, the next-hop value is not normally updated. Recall that the next-hop value is only updated by default when prefixes are advertised to true EBGP peers, not iBGP peers or confederation EBGP peers. However, because the next-hop value is just another attribute of the prefix, like AS-Path or Community, it can be arbitrarily changed as the prefix is advertised or received.
In the above output we can see that on R1 the prefix learned from R8 has a next hop value of 177.1.58.8, whereas the prefix from R7 has a next-hop value of 177.1.79.9. Normally, R8 would be reporting the next-hop value of 177.1.108.10 to R1, which is the next-hop it learned from R10, but the neighbor 177.1.146.1 next-hop-self command has been applied under R8’s BGP process. This means that when a prefix is learned from an EBGP neighbor, and then advertised to the neighbor 177.1.146.1, the next-hop value is set to whatever local address is used for the peering toward 177.1.146.1. Because R7 does not have this option applied, the default next-hop that R9 reports (177.1.79.9) is retained as the next-hop attribute.
The final result of this is that R1 cannot use the route via R7 for Bestpath selection because the next-hop value is listed as “inaccessible.” Inaccessible simply means that R1 does not have a route to the next-hop, which implies that successful route recursion cannot occur. Note that the links between R7 & R9 and R8 & R10 are not advertised into IGP. This is further reinforced by the output below:
R1#show ip route 177.1.79.9
Essentially, there are only two solutions for the problem presented. Either R1 must learn a route to the next-hop 177.1.79.9 via either static or dynamic routing, or the next-hop attribute must be changed to something R1 already has a route to. By configuring the next-hop-self option on R7 in addition to R8, the latter solution is used:
R7(config)#router bgp 100
R7(config-router)#neighbor 177.1.146.1 next-hop-self
R1#show ip bgp
When R7 updates the next-hop value toward R1, R1 can use both prefixes via R7 and R9 for Bestpath selection. According to the output below, we can see that the prefix via R7 wins because of the lower metric to next-hop (3072 vs. 3328):
R1#show ip bgp 112.0.0.0
