The BGP command next-hop-self simply does as it suggests. The next -hop
address of the origin of the prefix. To configure next-hop-self, use the following BGP configuration:
router bgp 200
neighbor 215.17.3.1 remote-as 210 neighbor 215.17.3.1 next-hop-self
!
Two common implementation examples are given in the following sections. The first deals with external connections, such as those to other networks or Internet
exchange points; the second deals with aggregation routers, in which customer links are terminated onto the ISP backbone.
External Connections
If a prefix is heard from an external network, the next hop is preserved throughout the IGP. However, setting next-hop-self on the border router that is distributing the eBGP prefix into iBGP means that the external prefix will receive the router ID
(loopback interface IP address) of the border router rather than the external next hop.
Several ISPs choose to do this rather than transport the external point-to-point links across the backbone. ISPs with a large number of BGP customers or external private peers will use this mechanism—each peer potentially can add another /30 to the IGP across the backbone. Removing these extra /30s helps to keep the IGP table as small as possible.
This feature also is used especially by ISPs at exchange points to ensure consistency and reliability of connections across the exchange. Indeed, it is considered a strongly recommended practice because it stops the potentially fraudulent activity of stealing bandwidth at the exchange point. If the ISP is carrying the exchange-point LAN address across its backbone in the IGP (or in iBGP), then it is announcing reachability of the exchange across the entire network. So a peering customer (usually ISP) that is also present at the exchange point could send traffic to this ISP and have it successfully delivered to the exchange point using the ISP’s
infrastructure rather than his own poorer connection. A sample configuration using a GRE tunnel, which could be used by such a perpetrator, follows. Figure 3-5 gives a picture of how this might be done.
Figure 3-5. GRE Tunnels at IXPs/NAPs
Router D:
interface tunnel 0
ip address 221.0.1.1 255.255.255.252 tunnel source 220.0.0.2
tunnel destination 169.223.0.2 !
ip route 169.223.0.2 255.255.255.255 220.0.0.1 Router B:
interface tunnel 0
ip address 221.0.1.2 255.255.255.252 tunnel source 169.223.0.2
tunnel destination 220.0.0.2 !
ip route 220.0.0.2 255.255.255.255 169.223.0.1
The GRE tunnel is used both to defeat reverse path forwarding checks that AS 109 may be carrying out and to hide the traffic from AS 109. Reverse path forwarding checks are covered in more detail in Chapter 4.
Hopefully, this section has demonstrated how important the next-hop-self BGP setting is. If the ISP in AS 109 had used next-hop-self for the IXP LAN rather than carrying 169.223.0/24 across its backbone, the customer in AS 2830 would not have been able to construct the GRE tunnel as pointing the static route from Router D to Router C. Router C would not know how to get to the 169.223.0/24 network, so all the traffic would have been dropped on the floor. The same goes for Router B: If Router B does not know how to get to the 220.0.0.0/30 point-to-point link, the tunnel again could not have been built. In fact, it is very common for an ISP router at an IXP to carry nothing more than the ISP’s internal network prefixes, carrying a default route is equivalent to saying that the router knows how to get to the entire Internet.
Aggregation Routers
If a prefix is injected into the iBGP at a gateway router (the standard way of injecting a customer prefix into the iBGP), the next -hop address is the IP address of the point-to-point link between the gateway aggregation router and the customer. This means that the iBGP has a large number of next -hop addresses to resolve from the IGP (not bad in itself) and that the IGP will be larger, resulting in slower convergence and greater potential instability in case of instability or failures in the network.
The obvious solution to this is to use IP unnumbered. The next -hop address in that case will be the router ID. However, many IS Ps that started off using IP addresses on point-to-point links have a lot of work to do to migrate to IP unnumbered on all their customer point-to-point connections. A quicker fix, which lets them scale the IGP but does not require undue haste (that is, panic!) in renumbering large numbers of customer interfaces is to set next-hop-self on the iBGP peers of the gateway router. The customer prefixes then will appear in the iBGP with the loopback address of the aggregation router, simplifying the route lookups and, more important,
meaning that the IGP no longer has to carry all the point-to-point link addresses used for customer connections. (This also assumes that the point-to-point link
addresses have been assigned in a block per router and are transported by the iBGP.
If the point-to-point addresses are not in the iBGP, the customer point-to-point link will not be pingable, which could be an unacceptable situation for providers that monitor the state of their customer links.)