You want to change the next-hop attribute on routes while distributing them via iBGP so that the routes always point to a next-hop address that is inside your AS.
By default, the value of the next-hop attribute for an external route is the IP address of the external BGP router that announced this route to the AS. You can change this behavior so that the next-hop router is an internal router instead by using the next-hop-self command:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#router bgp 65500 Router1(config-router)#neighbor 192.168.1.6 remote-as 65500 Router1(config-router)#neighbor 192.168.1.6 next-hop-self Router1(config-router)#exit Router1(config)#end Router1#
The next-hop attribute for a route depends on which router announces it. When a router passes route information to a peer in a different AS (using eBGP), it will generally update the next-hop attribute with its own IP address. However, by default iBGP peers will not change this attribute. For internal routes, the next-hop attribute will be the IP address of the router that sourced the internal route into BGP.
The result is that all of the routers inside of an AS will see the same external device as the next-hop BGP router, even if that router is actually several physical hops away. The following output shows the BGP table of one of the routers in our AS before we specified the next-hop-self command. All of the next-hop addresses correspond to routers in other ASs:
Router2#show ip bgp BGP table version is 10, local router ID is 126.96.36.199 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i172.22.1.0/24 172.25.1.7 0 100 0 65510 ? * i172.24.0.0 172.22.1.3 0 100 0 ? * i172.25.0.0 172.22.1.3 0 100 0 i *>i172.25.2.0/30 172.25.1.7 0 100 0 65510 ? *>i172.20.0.0/14 172.20.1.2 100 0 65530 65501 ?
This can cause serious routing problems if this router doesn't know how to reach one of these next hop routers. And this is actually a distinct possibility because for all external routes, these next-hop IP addresses will be in a different AS. Unless you use static routes or take pains to ensure that the IGP distributes all of these addresses, the other iBGP routers will not have a route to the next hop.
As we mentioned in the Introduction to this chapter, the first thing that BGP checks when looking at BGP routes is whether the next hop router is reachable. Even if BGP didn't do this check, a route that has an unreachable next hop router clearly is not going to be very useful.
However, you can use the next-hop-self command to configure a router to insert its own IP address in the next-hop attribute when passing routes to another router via iBGP:
Router1(config)#router bgp 65500 Router1(config-router)#neighbor 192.168.1.6 remote-as 65500 Router1(config-router)#neighbor 192.168.1.6 next-hop-self
Then the next-hop of every route in the route table is guaranteed to be accessible:
Router2#show ip bgp BGP table version is 10, local router ID is 188.8.131.52 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i172.22.1.0/24 192.168.1.6 0 100 0 65510 ? * i172.24.0.0 192.168.1.6 0 100 0 ? * i172.25.0.0 192.168.1.6 0 100 0 i *>i172.25.2.0/30 192.168.1.6 0 100 0 65510 ? *>i172.20.0.0/14 192.168.1.6 100 0 65530 65501 ?
You can also configure this keyword for an eBGP peer, but it has no effect.
Note that you can also construct a route map to manually set the next-hop attribute to any IP address that you like. However, we don't recommend doing this, as it too easy to make a mistake and forward routes with unreachable next-hop routers.
Router Configuration and File Management
User Access and Privilege Levels
Handling Queuing and Congestion
Tunnels and VPNs
NTP and Time
Router Interfaces and Media
Simple Network Management Protocol
First Hop Redundancy Protocols
Appendix 1. External Software Packages
Appendix 2. IP Precedence, TOS, and DSCP Classifications