The NEXT_HOP Attribute

The NEXT_HOP attribute is a well-known mandatory attribute (type code 3). In IGP, the next hop to reach a route is the IP address of the connected interface of the router that has announced the route.

---

Troubleshooting:  
Example: Ch. 10, pp. 330-331. The NEXT_HOP Attribute

---

The next hop concept with BGP is slightly more elaborate and takes one of the following three forms:

1.  For EBGP sessions: the next hop is the IP address of the neighbor that announced the route.

2.  For IBGP sessions: for routes originated inside the AS, the next hop is the IP address of the neighbor that announced the route.
For routes injected into the AS via EBGP, the next hop learned from EBGP is carried unaltered into IBGP. The next hop is the IP address of the EBGP neighbor from which the route was learned.

3.  When the route is advertised on a multiaccess media (such as Ethernet, Frame Relay, and so on), the next hop is usually the IP address of the interface of the router, connected to that media, that originated the route.

Figure 5-10 illustrates the BGP NEXT_HOP attribute environment.

Figure 5-10  BGP NEXT_ HOP example.

The SF router is running an EBGP session with the LA router and an IBGP session with the SJ router. The SF router is learning route 128.213.1.0/24 from the LA router. In turn, the SF router is injecting the local route 192.212.1.0/24 into BGP.

The SJ router learns route 192.212.1.0/24 via 2.2.2.2, the IP address of the IBGP peer announcing the route. Thus, 2.2.2.2 is the next hop, according to the definition, for SJ to reach 192.212.1.0/24. Similarly, the SF router sees 128.213.1.0/24 coming from the LA router via next hop 1.1.1.1. When it passes this route update to the SJ router via IBGP, SF includes the next hop information, unaltered. Thus, the SJ router would receive the BGP update about 128.213.1.0/24 with next hop 1.1.1.1. This is an example of the EBGP next hop being carried into IBGP.

As you can see from the preceding example, the next hop is not necessarily reachable via a direct connection. SJ's next hop for 128.213.1.0/24, for example, is 1.1.1.1, but reaching it requires a pathway through 3.3.3.3. Thus, the next hop behavior mandates a recursive IP lookup for a router to know where to send the packet. To reach the next hop 1.1.1.1, the SJ router will recursively look into its IGP routing table to see if and how 1.1.1.1 is reachable. This recursive search continues until the router associates destination 1.1.1.1 with an outgoing interface. The same recursive behavior is performed to reach next hop 2.2.2.2. If a hop is not reachable, BGP would consider the route as being inaccessible.

The following is a sample of how IP recursive lookup is used to direct the traffic toward the final destination. Table 5-2 and table 5-3 list the BGP and IP routing tables for the SJ router illustrated in figure 5-10.

Table 5-2 indicates that 128.213.1.0/24 is reachable via next hop 1.1.1.1. Looking into the IP routing table, network 1.1.1.0/24 is reachable via next hop 3.3.3.3. Another recursive lookup in the IP routing table indicates that network 3.3.3.0/24 is directly connected via Serial 0. This would indicate that traffic toward next hop 1.1.1.1 should go via Serial 0. The same reasoning applies to deliver traffic toward next hop 2.2.2.2.

Care must be taken to make sure that reachability of the next hop is advertised via some IGP or static routing. In case the BGP next hop cannot be reached, the BGP route would be considered inaccessible.

NEXT_HOP Behavior on Multiaccess Media

A media is considered multiaccess (MA) if routers connected to that media have the capability to exchange data in a many-to-many relationship. Routers on MA media share the same IP subnet and can physically access all other routers on the media in one hop (directly connected). Ethernet, FDDI, Token Ring, Frame Relay, and ATM are examples of multiaccess media.

---

Troubleshooting:  
Verifying next hop reachability.

---

IP has a rule on MA media that states that a router should always advertise the actual source of the route in case the source is on the same MA media as the router. In other words, if RTA (router A) is advertising a route learned from RTB, and RTA and RTB share a common MA media, when RTA advertises the route, it should indicate RTB as being the source of the route. If not, routers on the same media would have to make an unnecessary hop via RTA to get to a router that is sitting in the same segment.

In figure 5-11, RTA, RTB, and RTC share a common multiaccess media. RTA and RTC are running EBGP, while RTC and RTB are running OSPF. RTC has learned network 11.11.11.0/24 from RTB via OSPF and is advertising it to RTA via EBGP. Because RTA and RTB are running different protocols, you might think that RTA would consider RTC (10.10.10.2) as its next hop to reach 11.11.11.0/24, but this is incorrect. The correct behavior is for RTA to consider RTB (10.10.10.3) as the next hop because RTB shares the same media with RTC.

Figure 5-11  Example multiaccess media environment.

In situations where the media is broadcast, such as Ethernet and FDDI, physical connectivity is a given and the next hop behavior is no problem. On the contrary, in situations where the media is nonbroadcast, such as Frame Relay and ATM, special care should be taken as described in the following section.