Use Of The 'Next-Hop-Self' Command For BGP Routing
A difference between bgp and other routing protocols is that when bgp announces a network to a peer, it sends the next hop address to reach that network, which is always the next hop beyond the router itself.
All other routing protocols simply announce a network and the peer sends traffic for that network to the router making the announcement – that is, the peer router implying that the announcement router is the next hop. The announcing router says "I have a route to this network", and the peer router sends traffic to that network by creating a route table entry like this:
Ip route [network] via [router IP address announcing the network]
However in bgp, the announcing router says "I have a route to this network, and here is the next hop that I use to reach it". The bgp peer router then adds the NEXT HOP to it's routing table, like this:
Ip route [network] via [IP address I have been told is the next hop]
Which is just fine where the announcing router also is announcing a path to the next hop address, or the peer router has a valid route path to the next hop address.
The problems next hop cause in eBGP are well known, and standard practice is to add next-hop-self for all eBGP peers.
However the addition of the next hop information can cause a network to become blackholed in iBGP in some cases, as this example shows:
1. A subnet is announced by two IGP's, in this case iBGP and EIGRP.
2. iBGP announces the subnet to peers with the next-hop parameter, which is the WAN address to reach the subnet. EIGRP announces the subnet to peers with the local router peer address as the next hop.
3. Edge routers exchange routing information via EIGRP, edge to core is via iBGP
4. The edge routers can reach the subnet via the next hop of the LAN ip address of the router announcing the subnet
5. The core routers are told that the next hop to the subnet is the WAN ip address
6. The core router though may not necessarily have a valid, or correct path to the WAN IP address – this may be blocked by filter rules, passive interface rules, or propagated a different way by route policies
This effectively blackholes the traffic for that subnet.
7. By enabling the command next-hop-self on the edge router for its iBGP core peer, instead of sending the next hop it knows about as the path to the subnet, the router now sends its own IP address as the next hop
8. The core routers now send traffic for the subnet directly to the edge routers, since that is now the next hop for that subnet. This resolves the problem