No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

ME60 V800R010C10SPC500 Feature Description - WAN Access 01

This is ME60 V800R010C10SPC500 Feature Description - WAN Access
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Indirect Next Hop

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 iteration, 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 iteration and tunnel iteration 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 iteration, communicates the iteration result to the routing protocol, and then delivers forwarding entries.

On-Demand Route Iteration

On the ME60, 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 iteration.

On-demand route iteration indicates that when a dependent route changes, only the next hop associated with the dependent route is re-iterated. If the route destination address is the original next hop address or network segment address of next hop information, any route changes affect the iteration result of the next hop information. Otherwise, route changes do not affect next hop information. Therefore, when a route changes, you can re-iterate only 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 iteration result of the original next hop 1.1.1.1 is affected.

With respect to tunnel iteration, when a tunnel alternates between Up and Down, re-iterate the next hop information whose original next hop address is the same as the destination address of the tunnel.

Iteration Policy

An iteration policy is used to control the iteration result of the next hop to meet requirements of different scenarios. In route iteration, behaviors do not need to be controlled by the iteration policy. Instead, iteration behaviors only need to comply with the longest match rule. In addition, the iteration policy needs to be applied only when VPN routes are iterated 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 iteration.

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 2-5 Implementation without indirect next hop

As shown in Figure 2-5, 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 is iterated 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-6 Implementation with indirect next hop

As shown in Figure 2-6, 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 is iterated 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 Iteration and Tunnel Iteration

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

Table 2-5 Differences between route iteration and tunnel iteration

Iteration Type

Description

Route iteration

  • Applies to BGP public network routes.

  • Is triggered by route changes.

  • Supports next hop iteration based on the specified routing policy.

Tunnel iteration

  • Applies to BGP VPN routes.

  • Is triggered by tunnel or tunnel policy changes.

  • Iteration behaviors can be controlled using a tunnel policy to meet requirements of different scenarios.

IBGP Route Iteration to an IGP Route

Figure 2-7 Networking for IBGP route iteration

In Figure 2-7, an IBGP peer relationship is established between Device A and Device D. The IBGP peer relationship is established between two loopback interfaces on the ME devices, 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 being iterated, 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 be iterated separately, and the relevant forwarding entries do not need to be refreshed one by one. Note that only the shared next hop needs to be iterated and 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 iteration of a multi-hop EBGP route.

VPN Routes Iteration to a Tunnel

Figure 2-8 Networking for VPN route iteration

In Figure 2-8, 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 being iterated, these VPN routes eventually follow the same public network tunnel (tunnel 1). If tunnel 1 fails, these routes do not need to be iterated separately, and the relevant forwarding entries do not need to be refreshed one by one. Note that only the shared next hop needs to be iterated, 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.

Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059473

Views: 15609

Downloads: 10

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next