NEXT_HOP Behavior Over
Nonbroadcast Multiaccess Media (NBMA)

Media such as Frame Relay and ATM are nonbroadcast multiaccess. The many-to-many direct interaction between routers is not guaranteed unless virtual circuits are configured from each router to all other routers. This is called a fully meshed topology, and it is not always implemented for a number of reasons. In practice, Frame Relay or ATM virtual circuits are provided by the access carrier at a certain dollar amount per circuit, and additional circuits translate into extra money. In addition to this cost disincentive, most organizations use a hub and spoke approach, where multiple remote sites have virtual circuits built to one or more concentration routers at a central site (the hub site) where information resides. Figure 5-12 illustrates an example of next hop behavior in a nonbroadcast multiaccess environment.

Figure 5-12  Nonbroadcast multiaccess NEXT_HOP example.

The only difference between the environments illustrated in figure 5-12 and figure 5-11 is that the media in figure 5-12 is a Frame Relay cloud that is NBMA. RTC is the hub router; RTA and RTB are the spokes. Notice how the virtual circuits are laid out between RTC and RTA, and between RTC and RTB, but not between RTA and RTB. This is called a partially meshed topology.

RTA gets a BGP routing update about 11.11.11.0/24 from RTC and would try to use RTB (10.10.10.3) as the next hop (the same behavior as on MA media). Routing will fail because no virtual circuit exists between RTA and RTB.

Cisco IOS software supports a special case parameter that remedies this situation. The next-hop-self parameter (when configured as part of the BGP neighbor connection) forces the router (in this case, RTC) to advertise 11.11.11.0/24 with itself as the next hop (10.10.10.2). RTA would then direct its traffic to RTC to reach destination 11.11.11.0/24.

Use of next-hop-self Versus Advertising DMZ

The demilitarized zone (DMZ) defines the shared network between ASs. The IP subnet used for the DMZ link might be part of any of the networked ASs or might not belong to any of them. As you have already seen, the next hop address learned from the EBGP peer is carried inside IBGP. It is important for the IGP to be able to reach the next hop. One way of doing so is for the DMZ subnet to be part of the IGP and have the subnet advertised in the AS. The other way is to override the next hop address by forcing the next hop to be the IP address of the border IBGP neighbor.

In figure 5-13 the SJ router is receiving updates about 128.213.1.0/24 with next hop 1.1.1.1 (part of the DMZ). For the SJ router to be able to reach this next hop, one option is for network 1.1.1.0/24 to be advertised inside the AS by the SF border router.

Figure 5-13  NEXT-HOP-SELF parameter.

The other option is to have the SF router set the next-hop-self parameter as part of the IBGP neighbor connection to the SJ router. This will set the next hop address of all EBGP routes to 2.2.2.2, that is already part of the IGP. The SJ router can now reach the next hop with no problem.

---

Troubleshooting:  
Use of next-hop-self to override carrying the EBGP next hop into IBGP.

---

Choosing one method over the other depends on whether you want to reach the DMZ. An example could be an operator trying to do a ping from inside the AS to a router interface that belongs to the DMZ. For the ping to succeed, the DMZ must be injected in the IGP. In other cases, the DMZ might be reachable via some suboptimal route external to the AS. Instead of reaching the DMZ from inside the AS, the router might attempt to use another EBGP link to reach the DMZ. In this case, using next-hop-self ensures that the next hop is reachable from within the AS. In all other cases, both methods are similar as far as the BGP routing functionality.

The AS_Path Attribute

An AS_path attribute is a well-known mandatory attribute (type code 2). It is a sequence of autonomous system numbers a route has traversed to reach a destination. The AS that originates the route adds its own AS number when sending the route to its external BGP peers. Thereafter, each AS that receives the route and passes it on to other BGP peers will prepend its own AS number to the list. Prepending is the act of adding the AS number to the beginning of the list. The final list represents all the AS numbers that a route has traversed with the AS number of the AS that originated the route all the way at the end of the list. This type of AS_path list is called an AS_sequence, because all the AS numbers are ordered sequentially.

---

Troubleshooting:  
Example: Ch. 10, pp. 331-335. The AS_Path Attribute

---

BGP uses the AS_path attribute as part of the routing updates (UPDATE packet) to ensure a loop-free topology on the Internet. Each route that gets passed between BGP peers will carry a list of all AS numbers that the route has already been through. If the route is advertised to the AS that originated it, that AS will see itself as part of the AS_path attribute list and will not accept the route. BGP speakers prepend their AS numbers when advertising routing updates to other ASs (external peers). When the route is passed to a BGP speaker within the same AS, the AS_path information is left intact.

Figure 5-14 illustrates the AS_path attribute at each instance of the route 172.16.10.0/24, originating in AS1 and passed to AS2 then AS3 and AS4 and back to AS1. Note how each AS that passes the route to other external peers adds its own AS number to the beginning of the list. When the route gets back to AS1, the BGP border router will realize that this route has already been through its AS (AS number 1 appears in the list) and would not accept the route.

Figure 5-14  Example loop condition addressed by AS_ path attribute.

AS_path information is one of the attributes BGP looks at to determine the best route to take to get to a destination. In comparing two or more different routes, given that all other attributes are identical, a shorter path is always preferred. In case of a tie, other attributes are used to make the decision.