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

Configuration Guide - IP Unicast Routing

S1720, S2700, S5700, and S6720 V200R011C10

This document describes IP Unicast Routing configurations supported by the switch, including the principle and configuration procedures of IP Routing Overview, Static Route, RIP, RIPng, OSPF, OSPFv3, IS-IS(IPv4), IS-IS(IPv6), BGP, Routing Policy ,and PBR, and provides configuration examples.
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).
Configuring the BGP Next Hop Delayed Response

Configuring the BGP Next Hop Delayed Response

Context

Configuring the BGP next hop delayed response can speed up BGP route convergence and minimize traffic loss.

As shown in Figure 10-42, PE1, PE2, and PE3 are the clients of the RR. CE2 is dual-homed to PE1 and PE2. PE1 and PE2 advertise their routes to CE2 to the RR. The RR advertises the route from PE1 to PE3. PE3 has a route to CE2 only and advertises this route to CE1. After the route exchange, CE1 and CE2 can communicate. If PE1 fails, PE3 detects that the next hop is unreachable and instructs CE1 to delete the route to CE2. Traffic is then interrupted. After BGP route convergence is complete, the RR selects the route advertised by PE2 and sends a route update message to PE3. PE3 then advertises this route to CE1, and traffic forwarding is restored to the normal state. A high volume of traffic will be lost during traffic interruption because BGP route convergence is rather slow.

If the BGP next hop delayed response is enabled on PE3, PE3 does not reselect a route or instruct CE1 to delete the route to CE2 immediately after detecting that the route to PE1 is unreachable. After BGP convergence is complete, the RR selects the route advertised by PE2 and sends the route to PE3. PE3 then reselects a route and sends a route update message to CE1. Traffic forwarding is restored to the normal state. After the BGP next hop delayed response is enabled on PE3, PE3 does not need to delete the route or instruct CE1 to delete the route. This delayed response speeds up BGP route convergence and minimizes traffic loss.

Figure 10-42  Networking diagram of configuring the BGP next hop delayed response

The BGP next hop delayed response applies to scenarios where the next hop has multiple links to reach the same destination. If there is only one link between the next hop and the destination, configuring the BGP next hop delayed response may cause heavier traffic loss when the link fails because link switching is impossible.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run bgp { as-number-plain | as-number-dot }

    The BGP view is displayed.

  3. Set a delay in responding to next hop changes.

    The iteration results are as follows:
    • Urgent iteration result change

      The iterated next hop is changed, and BGP route reachability is also changed. For example, if a fault occurs on a network, a device finds no next-hop route or tunnel to which a BGP route is iterated. As a result, traffic is interrupted.

    • Non-urgent iteration result change

      The iterated next hop is changed, and BGP route reachability is not affected. For example, after the interface or type of a tunnel to which the next hop of a BGP route is iterated is changed, traffic keeps traveling over the BGP route.

    Run either of the following commands to set a delay time after which a device responds to a BGP next hop change:
    • Run nexthop recursive-lookup delay [ delay-time ]

      A device is enabled to delay responses to all next hop changes.

    • Run nexthop recursive-lookup non-critical-event delay [ delay-time ]

      A device is enabled to delay responses to non-urgent next hop changes.

    If delay-time is not specified, the default delay time is 5s.

    The preceding commands can be run separately or simultaneously. The nexthop recursive-lookup non-critical-event delay command takes precedence over the nexthop recursive-lookup delay command if both commands are run.

    The delay time specified in the nexthop recursive-lookup non-critical-event delay command must be greater than or equal to that specified in the nexthop recursive-lookup delay command if both commands are run.

Translation
Download
Updated: 2019-10-21

Document ID: EDOC1000178171

Views: 336352

Downloads: 1156

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