BGP Next-Hop Reachability Through a Route Reflector
AS 65000 runs six PE routers. R1 and R2 are route reflectors in cluster 1.1.1.1. R3 through R6 are clients that peer only with R1 and R2. R3 has an eBGP session to customer AS 65100 over ge-0/0/2 (198.51.100.0/30) and learns 203.0.113.0/24, which it advertises into iBGP. R6 receives the prefix from both reflectors but show route 203.0.113.0/24 hidden lists it as hidden with reason 'Next hop 198.51.100.1 is not reachable'. The IGP carries loopbacks and core /31s only; policy forbids redistributing customer prefixes into OSPF. R3's loopback is 10.0.0.3/32 and is reachable from R6. The customer /24 must be reachable from every PE, and operations does not want static routes on six routers. R1 and R2 are also iBGP peers of each other.
1. Explain precisely why R6 hides the route and give the preferred fix, including the exact place to apply it.
Read the worked answer
iBGP does not change the next hop when a router advertises an eBGP-learned route. R3 therefore advertises 203.0.113.0/24 with next hop 198.51.100.1, the customer-side address. The route reflectors re-advertise it unchanged, because a reflector preserves the next hop unless told otherwise. R6 can resolve 10.0.0.3, but it has no route to 198.51.100.1: that /30 is outside the IGP and policy forbids adding it. BGP still receives the path, but the route is unusable, so it is hidden for next-hop unreachability.
The preferred fix is next-hop-self on R3's iBGP sessions, that is, toward R1 and R2. R3 then advertises the prefix with next hop 10.0.0.3, which every PE can resolve through the IGP. The next hop identifies the ingress PE, which is also the correct forwarding point for traffic entering AS 65000.
Apply it on R3, not on the reflectors. Configuring next-hop-self on R1 and R2 would make every reflected route point at a reflector, which may pull traffic through a device that is not on the forwarding path and hides which PE actually owns each exit. Verify with show route 203.0.113.0/24 detail on R6 and show bgp neighbor on R3.
2. A junior engineer proposes adding a static route for 198.51.100.0/30 on R6 only. Evaluate that proposal and describe a verification sequence after the correct fix.
Read the worked answer
A static route on R6 would make this one prefix resolvable at this one router. It does not scale, it creates an inconsistent forwarding view across the PEs, and it will break when the customer link is re-addressed or moved. Worse, the static route does not guarantee that the rest of the fabric can reach the eBGP next hop for other customer prefixes learned from the same peer. The correct principle is to make the next hop an address the IGP already carries, which next-hop-self on the ingress PE achieves for all such prefixes at once.
After applying next-hop-self on R3:
- show bgp neighbor on R3 should show the iBGP sessions established and the new next-hop value in the advertised routes.
- show route 203.0.113.0/24 detail on R6 should show the route as active, with next hop 10.0.0.3 and a valid IGP resolution.
- show route forwarding-table matching 203.0.113.0/24 confirms the route is installed, not merely present in the RIB.
- Check R4 and R5 as well, since all clients must resolve the same next hop; a fix that only works on R6 is not a fix.