Resolving Next-Hop Issues

Resolving Next-Hop Issues
In Chapter 8, we discussed how a BGP speaker must know how to reach the next hop of a route
before that route can be used. In many cases, iBGP devices will not know how to reach the eBGP
speaker of a neighboring AS. The reason is that the remote eBGP speaker is not participating in
the IGP of the local AS. If this occurs, there is a way around it. The next-hop-self command
can be used to manipulate the NEXT_HOP attribute of a route.
In Figure 9.12, R2 and R3 are running an IGP for AS 200, and R2 is not including its direct
connection to R1 in the IGP. This would cause an issue. Any BGP routes from R1 that R3
learned would not be used by R3. The reason is that any route leaving AS 100 destined for
AS 200 would have its NEXT_HOP attribute set to R1, but R3 doesn’t know how to get to R1.
One way to overcome that would be to use the neighbor peer-address next-hop-self
command on R2, where the peer-address is the address used by R3 for the BGP session. What
would happen at this point is that any route being passed from R2 to R3 would have the NEXT_
HOP attribute set to R2. In this case, R3 would be able to use the routes from AS 100 because
it knows how to reach R2 and R2 knows how to reach R1.