The above scenario came up in some BGP review I was doing recently for a certification renewal, and the core rules of BGP need to be remembered to answer the question that was posed. Both AS’s shown have full mesh iBPG peerings, and R4-R5 has dual eBGP peerings.
The question that was asked was:
If R8 generates a route and puts it into BGP (via the network statement), will R4 advertise it to R1 AND will it be visible in the R1 routing table IF R1 receives it ?
So to answer this we need to go back to our core BGP concepts – what will BGP speakers do with routes they receive, and what is required for a BGP route to be installed in the routing table ?
To look at the first part of what will happen to the route from R8 – we look to the BGP route rules:
1. BGP speakers will NOT advertise iBPG learnt routes to iBGP peers
2. BGP speakers WILL advertise eBGP learnt routes to iBGP and eBGP
peers
3. BGP speakers WILL advertise iBGP learnt routes to eBGP peers
From here we need to put this into the perspective of the scenario above.
The route starts on R8. From there is goes to R5 – so R5 now has a route that is has learnt from an iBGP peer.
Based on Point 1 – this route will NOT be advertised back to any of its AS 65512 peer.
Based on Point 3 – this route WILL be advertised to its eBGP peer R4.
So R4 now has an eBGP route from R5 (originated in AS 65512).
What does R4 do with the route ? Based on point 2 – this route will be advertised to all of the iBGP peers of R5 since its an eBGP route. This confirms that R1 WILL get the route in its BGP routing table. So that’s the first part of the question answered – YES R1 will get the route (at least to its BGP routing table).
The second part of the question is a bit harder to answer – as we don’t have access to the BGP config on R4. Why does that matter ? Because if the peering between R4 and R1 is just a standard iBGP peering with no options added, it will not allow the route to be added to the R1 routing table. Let’s review this!
The next-hop rules for BGP now apply to this question:
1. If a route comes in from an eBGP peer, its next-hop is changed to the IP of that eBGP peer
2. If a route comes in from an iBGP peer, its next-hop is unchanged
Here is a standard iBGP peering config from a Cisco IOS-XE router:
router bgp 111
bgp router-id 9.9.9.9
bgp log-neighbor-changes
neighbor 8.8.8.8 remote-as 111
neighbor 8.8.8.8 update-source Loopback0
!
address-family ipv4
neighbor 8.8.8.8 activate
exit-address-family
So R4 gets the route from R5 via eBGP and so changes the next-hop for the route to be R5 (as per point 1).
If the above is the config for both R4 and R1, then when R1 gets the route, the next hop of the route will point to R5 (as per point 2 – since the next-hop was not changed when the route was passed via iBGP from R4 – R1), which R1 will not know how to get to (unless its been advertised into AS65511 via another method).
So if R1 doesn’t have the route to the next-hop, as per BGP rules this BGP route cannot be installed in its routing table.
What would need to be added on R4 to fix this ? A simple way is to change the next hop for the eBGP routes advertised by R4 into its AS, with the following additional command:
address-family ipv4
neighbor 8.8.8.8 activate
neighbor 8.8.8.8 next-hop-self
exit-address-family
This changes the next-hop that all of the iBGP peers in AS65511 see for eBGP routes to be R4’s IP, which they of course all know, and this then allows the route to be added to their routing table.
So the answer to the second part of the question is – it depends! A much loved statement of IT consultants…