Indirect Next Hop

Definition

Indirect next hop is a technique used to speed up route convergence. This technique can change the direct association between route prefixes and next hop information into an indirect association. Indirect next hop allows next hop information to be refreshed independently of the prefixes of the same next hop, which speeds up route convergence.

Purpose

In the scenario requiring route recursion, when IGP routes or tunnels are switched, forwarding entries are rapidly refreshed, which implements fast route convergence and reduces the impact of route or tunnel switching on services.

Mapping Between the Route Prefix and the Next Hop

Mapping between route prefixes and next hops is the basis of indirect next hop. To meet the requirements of route recursion and tunnel recursion in different scenarios, next hop information includes the address family, original next hop address, and tunnel policy. The system assigns an index to each next hop, performs route recursion, communicates the recursion result to the routing protocol, and then delivers forwarding entries.

On-Demand Route Recursion

On the NetEngine 8000 F, the route to a reachable address is called a dependent route. The system forwards packets based on dependent routes. The process of finding a dependent route based on the next hop address is called route recursion.

On-demand route recursion indicates that when a dependent route changes, only the next hop associated with the dependent route performs recursion again. If the route destination address is the original next hop address or network segment address of next hop information, any route changes affect the recursion result of the next hop information. Otherwise, route changes do not affect next hop information. Therefore, when a route changes, you can perform recursion again only on the associated next hop by assessing the destination address of the route. For example, if the original next hop address of the route 2.2.2.2/32 is 1.1.1.1, the route that the original next hop 1.1.1.1 depends on may be 1.1.1.1/32 or 1.1.0.0/16. If the route 1.1.1.1/32 or 1.1.0.0/16 changes, the recursion result of the original next hop 1.1.1.1 is affected.

With respect to tunnel recursion, when a tunnel alternates between Up and Down, perform recursion again on the next hop whose original next hop address is the same as the destination address of the tunnel.

Recursion Policy

A recursion policy is used to control the recursion result of the next hop to meet requirements of different scenarios. In route recursion, behaviors do not need to be controlled by the recursion policy. Instead, recursion behaviors only need to comply with the longest match rule. In addition, the recursion policy needs to be applied only when VPN routes recurse to tunnels.

By default, the system selects Label Switched Paths (LSPs) for VPNs without performing load balancing. If load balancing or other types of tunnels are required, configure a tunnel policy and bind it to a tunnel. After the tunnel policy is applied, the system uses the tunnel bound to the tunnel policy or selects a tunnel based on the priorities specified in the tunnel policy during next hop recursion.

Mechanism for Indirect Next Hop

Without indirect next hop, the forwarding information corresponds to the prefix, and therefore, the route convergence time is decided by the number of route prefixes. With indirect next hop, multiple route prefixes correspond to one next hop. Forwarding information is added to the forwarding table using the next hop, and traffic with relevant route prefixes can be switched, which speeds up route convergence.

Figure 1 Implementation without indirect next hop

As shown in Figure 1, without indirect next hop, prefixes are totally independent, each corresponding to its next hop and forwarding information. When a dependent route changes, the next hop corresponding to each prefix performs recursion and forwarding information is updated based on the prefix. In this case, the convergence time is decided by the number of prefixes.

Note that prefixes of a BGP peer have the same next hop, forwarding information, and refreshed forwarding information.

Figure 2 Implementation with indirect next hop

As shown in Figure 2, with indirect next hop, prefixes of routes from the same BGP peer share the same next hop. When a dependent route changes, only the shared next hop performs recursion and forwarding information is updated based on the next hop. In this case, routes of all prefixes can converge at a time. Therefore, the convergence time is irrelevant to the number of prefixes.

Comparison Between Route Recursion and Tunnel Recursion

The following table lists differences between route recursion and tunnel recursion.

IBGP Route Recursion to an IGP Route

Figure 3 Networking for IBGP route recursion

In Figure 3, an IBGP peer relationship is established between Device A and Device D. The IBGP peer relationship is established between two loopback interfaces on the routers, but the next hop cannot be used to guide packet forwarding, because it is not directly reachable. Therefore, to refresh the forwarding table and guide packet forwarding, the system needs to search for the actual outbound interface and directly connected next hop based on the original IBGP next hop.

Device D receives 100,000 routes from Device A. These routes have the same original BGP next hop. After recursion, these routes eventually follow the same IGP path (A->B->D). If the IGP path (A->B->D) fails, these IBGP routes do not need to perform recursion separately, and the relevant forwarding entries do not need to be refreshed one by one. Note that only the shared next hop needs to perform recursion and be refreshed. Consequently, these IBGP routes converge to the path (A->C->D) on the forwarding plane. Therefore, the convergence time depends on only the number of next hops, not the number of prefixes.

If Device A and Device D establish a multi-hop EBGP peer relationship, the convergence procedure is the same as the preceding one. Indirect next hop also applies to the recursion of a multi-hop EBGP route.

VPN Routes Recursion to a Tunnel

Figure 4 Networking for VPN route recursion

In Figure 4, a neighbor relationship is established between PE1 and PE2, and PE2 receives 100,000 VPN routes from PE1. These routes have the same original BGP next hop. After recursion, these VPN routes eventually follow the same public network tunnel (tunnel 1). If tunnel 1 fails, these routes do not need to perform recursion separately, and the relevant forwarding entries do not need to be refreshed one by one. Note that only the shared next hop needs to perform recursion, and the relevant forwarding entries need to be refreshed. Consequently, these VPN routes converge to tunnel 2 on the forwarding plane. In this manner, the convergence time depends on only the number of next hops, not the number of prefixes.