BGP Routing Issue and "Next-Hop-Self" Solution
In this section, we'll address a BGP routing issue involving the reachability of certain prefixes and explore the solution that involves the use of the "next-hop-self" command. This issue is based on real-world network configurations and is documented in Cisco's BGP troubleshooting guidelines.
Identifying the BGP Routing Issue
The outputs from the routers indicate that the loopback interfaces on R3 and R4 do not have reachability to the networks on R1. The show ip bgp output reveals that R3 and R4 have received BGP paths to those prefixes but have not marked them as the best paths.
To pinpoint the problem on R3, we use the show ip bgp 1.1.0.0 command, which exposes the fact that the path to this prefix is not marked as best. The reason is clear: the next-hop address is 12.1.1.1, but R3 has no route to reach this next-hop.
This may raise a question: why does an inaccessible next-hop prevent R3 from marking the path as the best? The answer lies in the fundamental difference between BGP and IGPs (Interior Gateway Protocols). IGPs focus on routing within an AS and are enabled to run directly on router interfaces. They discover the underlying network structure, and IGP routing entries include destination prefixes, next-hops, and outgoing interfaces for reaching those next-hops.
On the other hand, BGP is not enabled to run on interfaces or to discover the underlying network structure. It serves the purpose of advertising reachability information between ASes. BGP entries contain a destination prefix and a next-hop but lack the ability to fill in information on how to reach that next-hop.
The Role of Recursive Routing
When R2 advertises the same path to R3, it retains the original next-hop IP address received from R1: 12.1.1.1. As R3 lacks a route to this destination, BGP refrains from marking it as the best path. The same situation applies to R4 and all paths to the prefixes from R1.
R2 doesn't modify the next-hop IP address since R3 and R4 are iBGP (internal BGP) peers. By default, a router does not change the next-hop address when advertising a path to an internal peer. This behavior, however, poses challenges for remote internal neighbors trying to route to the external next-hop.
The Solution: "Next-Hop-Self"
To address this issue, the "next-hop-self" command comes to the rescue. This command allows R2 to override its default behavior and advertise itself as the next-hop for external prefixes to its internal peers on a peer-by-peer basis. This is a common and effective solution, as the internal peers already have routes to reach R2's address, evidenced by the successful BGP session establishment between them.
Implementing this solution involves modifying R2's BGP configuration. By using the neighbor neighbor-address next-hop-self command in BGP router configuration mode, R2 resets the next-hop address of eBGP-learned (external BGP) paths to its peering address used for its iBGP peering sessions with R3 and R4.
By doing this, R2 ensures that the next-hop information in the BGP table becomes accessible to the internal peers, resolving the routing issue.
This "next-hop-self" solution simplifies the routing process and enhances BGP's effectiveness in complex network scenarios.