Configuration Guide - Network Reliability (V800R002C01 - 01)

HUAWEI NetEngine5000E Core Router V800R002C01
Configuration Guide - Network Reliability

Issue Date 01 2011-10-15
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China http://www.huawei.com support@huawei.com
Website: Email:
Issue 01 (2011-10-15)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability
About This Document
About This Document

Intended Audience
This document provides the basic concepts, configuration procedures, and configuration examples in different application scenarios of the Network Reliability feature supported by the NE5000E device. This document describes how to configure the Network Reliability feature. This document is intended for: l l l l Data configuration engineers Commissioning engineers Network monitoring engineers System maintenance engineers
Related Versions (Optional)

The following table lists the product versions related to this document. Product Name HUAWEI NetEngine5000E Core Router Version V800R002C01
Symbol Conventions
The symbols that may be found in this document are defined as follows. Symbol Description Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury. Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury.
Issue 01 (2011-10-15)
ii
About This Document
Symbol
Description Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important points of the main text.
Command Conventions (Optional)

The command conventions that may be found in this document are defined as follows. Convention Boldface Italic [] { x | y | ... } [ x | y | ... ] { x | y | ... }* Description The keywords of a command line are in boldface. Command arguments are in italics. Items (keywords or arguments) in brackets [ ] are optional. Optional items are grouped in braces and separated by vertical bars. One item is selected. Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected. Optional items are grouped in braces and separated by vertical bars. A minimum of one item or a maximum of all items can be selected. Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected. The parameter before the & sign can be repeated 1 to n times. A line starting with the # sign is comments.
[ x | y | ... ]* &<1-n> #
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues.
Changes in Issue 01 (2011-10-15)

The initial commercial release.
Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. iii
Contents
Contents
About This Document.....................................................................................................................ii 1 Reliability Overview.....................................................................................................................1
1.1 Introduction to Reliability..................................................................................................................................2 1.1.1 Reliability Technology Overview.............................................................................................................2 1.1.2 Indexes of Reliability.................................................................................................................................2 1.1.3 Levels of Reliability Requirements...........................................................................................................3 1.1.4 Principles of Highly Reliable IP Networking............................................................................................3 1.2 Reliability Technologies for IP Networks..........................................................................................................4 1.2.1 Fault Detection Technologies for IP Networks.........................................................................................4 1.2.2 Protection Switchover for IP Networks.....................................................................................................4 1.3 Reliability Technologies Supported by the NE5000E........................................................................................5 1.3.1 FRR............................................................................................................................................................5 1.3.2 BFD...........................................................................................................................................................6 1.4 Networking Scheme for Ensuring the Reliability of IP Networks.....................................................................7 1.4.1 Faults on Intermediate Nodes or on the Link Between PEs - LDP FRR/TE FRR....................................7 1.4.2 Fault on the Link Between PEs.................................................................................................................8 1.4.3 Fault on the Remote PE - VPN FRR.........................................................................................................8 1.4.4 Fault on the Downlink Interface on the PE - IP FRR................................................................................8
2 BFD Configuration......................................................................................................................10
2.1 BFD Overview..................................................................................................................................................12 2.2 BFD Features Supported by the NE5000E.......................................................................................................12 2.3 Configuring BFD to Detect an IP Link............................................................................................................14 2.3.1 Enabling BFD Globally...........................................................................................................................15 2.3.2 Establishing a BFD Session.....................................................................................................................16 2.3.3 (Optional) Adjusting BFD Detection Time.............................................................................................17 2.3.4 (Optional) Setting the BFD WTR Time..................................................................................................18 2.3.5 (Optional) Configuring the Description of a BFD Session.....................................................................19 2.3.6 Checking the Configuration.....................................................................................................................20 2.4 Configuring BFD to Detect VPN Routes.........................................................................................................22 2.4.1 Enabling BFD Globally...........................................................................................................................22 2.4.2 Establishing a BFD Session.....................................................................................................................23 2.4.3 (Optional) Adjusting BFD Detection Time.............................................................................................24 Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. iv
Contents
2.4.4 (Optional) Setting the BFD WTR Time..................................................................................................25 2.4.5 (Optional) Configuring the Description of a BFD Session.....................................................................26 2.4.6 Checking the Configuration.....................................................................................................................27 2.5 Configuring a Static BFD Session with Automatically-Negotiated Discriminators........................................29 2.5.1 Enabling BFD Globally...........................................................................................................................30 2.5.2 Establishing a BFD Session.....................................................................................................................30 2.5.3 (Optional) Adjusting BFD Detection Time.............................................................................................31 2.5.4 (Optional) Setting the BFD WTR Time..................................................................................................32 2.5.5 (Optional) Configuring the Description of a BFD Session.....................................................................33 2.5.6 Checking the Configuration.....................................................................................................................33 2.6 Configuring Multi-hop BFD.............................................................................................................................34 2.6.1 Enabling BFD Globally...........................................................................................................................35 2.6.2 Establishing a BFD Session.....................................................................................................................35 2.6.3 (Optional) Adjusting BFD Detection Time.............................................................................................37 2.6.4 (Optional) Setting the BFD WTR Time..................................................................................................38 2.6.5 (Optional) Configuring the Description of a BFD Session.....................................................................38 2.6.6 Checking the Configuration.....................................................................................................................39 2.7 Associating a BFD Session with an Interface..................................................................................................41 2.8 Associating a BFD Session with the Sub-interface..........................................................................................43 2.9 Enabling a BFD Session to Modify the PST....................................................................................................44 2.10 Configuring the Delay of a BFD Session to Go Up.......................................................................................46 2.11 Maintaining BFD............................................................................................................................................48 2.11.1 Clearing the BFD Statistics...................................................................................................................48 2.11.2 Monitoring the BFD Operating Status...................................................................................................48 2.12 Configuration Examples.................................................................................................................................49 2.12.1 Example for Configuring Single-Hop BFD for an IP-Trunk................................................................49 2.12.2 Example for Configuring Single-Hop BFD for a Layer 3 Eth-Trunk...................................................55 2.12.3 Example for Configuring BFD for VPN Routes...................................................................................61 2.12.4 Example for Configuring Multi-Hop BFD............................................................................................66 2.12.5 Example for Associating a BFD Session with an Interface...................................................................70 2.12.6 Example for Associating a BFD Session and a Sub-interface...............................................................75 2.12.7 Example for Configuring the Delay of a BFD Session to Go Up.........................................................80 2.12.8 Example for Configuring BFD for VPN Static Routes.........................................................................83 2.12.9 Example for Enabling a BFD Session to Modify the PST....................................................................98 2.12.10 Example for Configuring Single-hop BFD for IPv6.........................................................................102 2.12.11 Example for Configuring Multi-hop BFD for IPv6...........................................................................105
3 VRRP Configuration.................................................................................................................110
3.1 VRRP Overview.............................................................................................................................................111 3.2 VRRP Features Supported by the NE5000E..................................................................................................111 3.3 Configuring a VRRP Backup Group in Master/Backup Mode......................................................................112 3.3.1 Configuring a VRRP Backup Group and Assigning a Virtual IP Address...........................................114 3.3.2 Configuring the Priority of an Interface in a VRRP Backup Group......................................................115 Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. v
Contents
3.3.3 (Optional) Configuring an Authentication Mode for VRRP Packets....................................................115 3.3.4 (Optional) Setting the Interval for Sending VRRP Advertisement Packets..........................................116 3.3.5 (Optional) Enabling a Device to Learn the Interval at Which a VRRP Advertisement Packet Is Sent ........................................................................................................................................................................117 3.3.6 (Optional) Setting the Preemption Delay for the Device in a VRRP Backup Group............................118 3.3.7 (Optional) Setting the Timeout Period of Sending Gratuitous ARP Packets on the Master Device.....119 3.3.8 Checking the Configuration...................................................................................................................120 3.4 Configuring VRRP Backup Groups in Load Balancing Mode......................................................................120 3.4.1 Configuring a VRRP Backup Group and Assigning a Virtual IP Address...........................................122 3.4.2 Setting the Priority of an Interface in a VRRP Backup Group..............................................................122 3.4.3 (Optional) Configuring an Authentication Mode for VRRP Packets....................................................123 3.4.4 (Optional) Setting the Interval for Sending VRRP Advertisement Packets..........................................124 3.4.5 (Optional) Enabling a Device to Learn the Interval at Which a VRRP Advertisement Packet Is Sent ........................................................................................................................................................................125 3.4.6 (Optional) Setting the Preemption Delay for the Device in a VRRP Backup Group............................126 3.4.7 (Optional) Setting the Timeout Period of Sending Gratuitous ARP Packets on the Master Device.....127 3.4.8 Checking the Configuration...................................................................................................................127 3.5 Configuring the Tracking Function for a VRRP Backup Group....................................................................128 3.5.1 Configuring a VRRP Backup Group to Track an Interface...................................................................129 3.5.2 Configuring a VRRP Backup Group to Track a BFD Session..............................................................130 3.5.3 Checking the Configuration...................................................................................................................131 3.6 Optimizing VRRP...........................................................................................................................................132 3.6.1 Enabling a Virtual IP Address to Be Pinged.........................................................................................133 3.6.2 Disabling the Checking of TTLs in VRRP Packets..............................................................................133 3.6.3 Checking the Configuration...................................................................................................................134 3.7 Maintaining VRRP.........................................................................................................................................134 3.7.1 Monitoring the Operation Status of VRRP............................................................................................135 3.8 Configuration Examples.................................................................................................................................135 3.8.1 Example for Configuring a VRRP Backup Group in Master/Backup Mode........................................135 3.8.2 Example for Configuring VRRP Backup Groups in Load Balancing Mode........................................141 3.8.3 Example for Configuring VRRP Multi-instance...................................................................................145 3.8.4 Example for Configuring a VRRP Backup Group to Track Interfaces.................................................152 3.8.5 Example for Configuring a VRRP Backup Group to Track a BFD Session.........................................157
4 EFM OAM Configuration........................................................................................................163

4.1 Overview of EFM OAM.................................................................................................................................165 4.2 EFM OAM Features Supported by the NE5000E..........................................................................................165 4.3 Configuring Basic EFM OAM Functions......................................................................................................166 4.3.1 Enabling EFM OAM Globally..............................................................................................................167 4.3.2 Configuring the EFM OAM Working Mode for an Interface...............................................................168 4.3.3 (Optional) Setting the Maximum Size of an OAM PDU......................................................................169 4.3.4 (Optional) Setting the Interval at Which OAM PDUs Are Sent...........................................................169 4.3.5 (Optional) Setting the Timeout Period for Waiting for OAM PDUs....................................................170 4.3.6 Enabling EFM OAM on an Interface....................................................................................................171 Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. vi
Contents
4.3.7 Checking the Configuration...................................................................................................................171 4.4 Configuring Link Monitoring.........................................................................................................................172 4.4.1 (Optional) Configuring Error Frame Detection.....................................................................................173 4.4.2 (Optional) Configuring Error Code Detection.......................................................................................174 4.4.3 (Optional) Configuring Error Frame Second Detection........................................................................175 4.4.4 Checking the Configuration...................................................................................................................176 4.5 Testing the Packet Loss Ratio of a Physical Link..........................................................................................177 4.5.1 Configuring Remote Loopback.............................................................................................................178 4.5.2 Configuring an Interface to Send Testing Packets................................................................................179 4.5.3 (Optional) Disabling Remote Loopback................................................................................................179 4.5.4 Checking the Configuration...................................................................................................................180 4.6 Configuring Association Between EFM and Interfaces.................................................................................181 4.6.1 Associating EFM OAM with an Interface.............................................................................................182 4.6.2 (Optional)Setting the Time During Which the EFM OAM Protocol State of an Interface Remains Down ........................................................................................................................................................................183 4.6.3 Checking the Configuration...................................................................................................................183 4.7 Maintaining EFM OAM.................................................................................................................................184 4.7.1 Monitoring the Operation Status of EFM OAM...................................................................................184 4.8 Configuration Examples.................................................................................................................................185 4.8.1 Example for Configuring EFM OAM...................................................................................................185
Issue 01 (2011-10-15)
vii
1 Reliability Overview
1
About This Chapter
Reliability Overview
Reliability of a network is improved by using reliability technologies and reliable networking schemes. 1.1 Introduction to Reliability Reliability technologies are used to shorten the duration of interruption on networks and improve the network performance. 1.2 Reliability Technologies for IP Networks This section describes the fault detection technologies and network protection switchover technologies that are used to improve the reliability of IP networks. 1.3 Reliability Technologies Supported by the NE5000E The reliability technologies include fault detection technologies and switchover technologies for IP networks. 1.4 Networking Scheme for Ensuring the Reliability of IP Networks This section describes the application scenarios and schemes for reliability, and FRR technologies.
Issue 01 (2011-10-15)
1.1 Introduction to Reliability

Reliability technologies are used to shorten the duration of interruption on networks and improve the network performance.
1.1.1 Reliability Technology Overview

The reliability of a device is assessed in the following aspects: the principle of reliable system and hardware design, principle of reliable software design, reliability test and authentication, and reliable IP network design. With the popularity of networks and diversification of applications, various value-added services are deployed on networks. The bandwidth increases exponentially. Therefore, even a short-time interruption may affect a great number of services and produce an incredible loss. The reliability of a fundamental network that bears various services is highlighted much more than ever. This chapter describes the IP reliability technologies supported by the Versatile Routing Platform (NE5000E).
1.1.2 Indexes of Reliability

The indexes of reliability are the Mean Time to Repair (MTTR), Mean Time Between Failures (MTBF), and availability. Generally, the reliability of a product or a system is evaluated based on MTTR and MTBF.
MTTR
MTTR indicates the default recovery capability in terms of maintainability. This index refers to the average time that a component or a device takes to recover from a failure. In fact, it indicates the fault-tolerance capabilities of the device. In the broad sense, MTTR also concerns spare parts management and customer service. It plays an important role in evaluating maintainability of a device. MTTR is calculated with the following formula: MTTR = Fault detection time + Board replacement time + System initialization time + Link recovery time + Route convergence time + Forwarding recovery time The smaller the addends are, the smaller the MTTR value is and the higher the availability the device offers.
MTBF
MTBF indicates the probability of faults. The index refers to the average time (usually expressed in hours) when a component or a device works without any failure.
Availability
Availability indicates the utility of a system. The availability is improved when MTBF increases or MTTR decreases.
Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2
The formula of the availability is as follows: Availability = MTBF/(MTBF + MTTR) In the telecom industry, 99.999% availability means that service interruption due to device failures is less than 5 minutes each year. On existing networks, network faults and service interruption are inevitable due to various causes. Therefore, a technology that helps a device rapidly recover from faults, which means to decrease the MTTR, is very important.
1.1.3 Levels of Reliability Requirements

The reliability requirements at different levels differ in the target and implementation. Table 1-1 shows three requirement levels, their targets, and implementation. Table 1-1 Reliability requirements Leve l 1 Target Few faults in the software and hardware of a system Implementation l Hardware: simplified design, standardized circuits, reliable application of components, reliability control in purchased components, reliable manufacture, environment endurability, and reliability experiment (HALT/HASS) l Software: specifications for the software reliability design 2 3 No impact on a system if a fault occurs Rapid recovery if a fault occurs and affects the system Redundancy design, switchover policy, and high availability of switchover Fault detection, diagnosis, isolation, and recovery
1.1.4 Principles of Highly Reliable IP Networking

The principles of reliable IP networking include hierarchical networking, redundancy, and load balancing. The details are as follows: l Hierarchical networking: A network is divided into three layers, namely, the core layer, convergence layer, and edge layer. According to the current status of services and a forecast of future services, redundancy backup is configured when a customer edge device is accessed so that the customer edge device can be dual-homed to the devices at the convergence layer. Devices at the convergence layer are dual-homed to the multiple devices in a single node or different nodes at the upper layer. The devices at the core layer and convergence layer can be deployed according to the actual requirements. The device at the core layer is enabled with full interconnection or half interconnection to reach the peer. In
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 3
Issue 01 (2011-10-15)
this manner, two devices are reachable to each other with one route at a fast traffic rate, avoiding multi-interconnection. l l l At the same layer, multi-interconnection is preferred; in a single node, multi-device is preferred. The lower-layer device is dual-homed or multi-homed to the multiple devices in a single node or different nodes. Adjustment can be made based on the actual traffic volume.
1.2 Reliability Technologies for IP Networks

This section describes the fault detection technologies and network protection switchover technologies that are used to improve the reliability of IP networks.
1.2.1 Fault Detection Technologies for IP Networks

In terms of the application scope, fault detection technologies can be divided into special detection technologies and common detection technologies. l Special fault detection technologies include: APS (applied to the transport layer) RPR OAM and Eth-OAM (applied to the link layer) l Common fault detection technologies include Bidirectional Forwarding Detection (BFD), which can be applied to all layers.
The fault detection mechanism is available on each layer of the TCP/IP reference model. The fault detection mechanisms are as follows: l l l l Transport layer/Physical layer: APS Data link layer: RPR OAM, Eth-OAM, STP, RSTP, MSTP, and RRPP Network layer: Hello mechanism provided by different protocols, and GR Application layer: heartbeat mechanism and retransmission mechanism provided by various protocols
The modes of fault detection are as follows: l l l Asynchronous mode: The detection packet is sent periodically. Demand mode: A series of packets are sent for confirmation. Echo mode: The received packet is sent back to the peer without any change.
1.2.2 Protection Switchover for IP Networks

The standard protection switchover in a data communications network takes not more than 50 ms. Link redundancy is a prerequisite for the implementation of switchover. The protection modes are as follows: l l End-to-end protection: 1:1, 1+1, 1:N, and M:N Local protection: FRR
Faults detected by BFD and FRR can trigger protection switchover. The protection switchover functions are as follows:
l l l l l l
Local request protection Local real-time protection Latency of switchover signal processing Anti-switching against a single node Coexistence of switchover requests and preemption Switchback mode
1.3 Reliability Technologies Supported by the NE5000E

The reliability technologies include fault detection technologies and switchover technologies for IP networks. This section describes the applications of fault detection technologies and protection switchover technologies of IP networking in the NE5000E.
1.3.1 FRR
FRR is the most common technology used to trigger fast switchover if faults occur. FRR technologies include IP FRR, Label Distribution Protocol (LDP) FRR, MPLS Traffic Engineering (TE) FRR, and Virtual Private Network (VPN) FRR.
IP FRR
On traditional IP networks, if a forwarding link fails, a visible evidence is that a physical interface on a router goes Down. After the router detects the fault, it instructs the upper-layer routing system to recalculate routes and then update routing information. Usually, the routing system takes several seconds to re-select an available route. For services that are very sensitive to packet loss and delay, the convergence time of several seconds is intolerable because it leads to service interruption. For example, Voice over Internet Protocol (VoIP) services are tolerant of millisecond-level interruption. IP FRR allows a forwarding system to rapidly detect the fault and take measures to restore services. IP FRR functions if a fault occurs at a lower layer (physical or data link layer). The lower layer reports the fault to the upper-layer routing system. At the same time, the system immediately forwards packets along a bypass link. The method of implementing IP FRR is as follows: l A routing protocol automatically calculates a pair of primary and secondary routes and forwards the forwarding information associated with these two routes to the forwarding engine. If the forwarding engine is notified of a link fault, the engine uses the bypass link to forward traffic before the routes on the control plane converge.
LDP FRR
Conventional IP FRR cannot protect traffic on an MPLS network. The NE5000E provides the MPLS network with conventional LDP FRR for protection at the interface level. Unlike IP FRR, LDP FRR calculates a secondary interface first. The time spent in route calculation and reestablishment of an LSP after a failure occurs is saved. This speeds up a switchover. When LDP works in a mode of Downstream Unsolicited (DU) label distribution, ordered label control, and liberal label retention, a Label Switching Router (LSR) saves all label mapping
messages. A label forwarding table is generated only based on the label mapping messages sent by the next hop corresponding to the Forwarding Equivalence Class (FEC). With the preceding feature, when a forwarding table is generated for the mapping of liberal retention labels, a bypass LSP is established. Usually, a packet is forwarded alongthe primary LSP. If the outgoing interface of the primary LSP goes Down, the packet is forwarded along the bypass LSP. This ensures the continuous traffic flow in the short period before network convergence.
MPLS TE FRR
MPLS TE FRR is a commonly used switchover technology to deal with a failure. The solution is to create an end-to-end TE tunnel between Provider Edge (PE) devices and a bypass LSP for protecting a primary LSP. When either of the PE devices detects that the primary LSP is unavailable because of an intermediate node failure or a link failure, the traffic is switched to the bypass LSP. As for the working principle, MPLS TE FRR can enable fast switchover to respond to link failures and node failures between two PEs that serve as the start node and end node of a TE tunnel. Nevertheless, MPLS TE FRR cannot deal with the failure of PEs that serve as the start node and end node of a TE tunnel. When a PE fails, the traffic transmission can be resumed only by endto-end route convergence and LSP convergence. The time of convergence is closely associated with the number of routes of the MPLS VPN and the number of hops on the bearer network.
VPN FRR
Based on the fast VPN route switching technology, VPN FRR sets switchover forwarding entries that are destined for the primary PE and backup PE on a remote PE. With VPN FRR and the technology of fast detection of PE faults, on an MPLS VPN where Customer Edge (CE) devices are dual-homed to PEs, the duration of end-to-end convergence is shortened and the time of PE fault rectification is not affected by the number of private network routes. When a PE fails, the convergence of end-to-end services takes less than 1s. On a PE configured with VPN FRR, proper VPNv4 routes are selected based on the matching policy. For these routes, in addition to the routing information sent by the optimal next hop (including the forwarding prefix, inner label, and selected outer LSP), information about the sub-optimal next hop (including the forwarding prefix, inner label, and selected outer LSP) are also contained in the forwarding entry. If the optimal next hop fails, the PE uses a technology such as BFD to detect the fault that the outer tunnel between the PE and the optimal next hop is unavailable. In this case, the CE switches traffic to the sub-optimal next hop.
1.3.2 BFD
BFD is a set of detection mechanisms applied to the entire network. BFD is used to quickly detect faults on a network, thus minimizing the impact of device faults on services and improving the availability of the network. As the network-wide detection mechanism, BFD detects and monitors the connectivity of a link or an IP route during forwarding. For better performance, two adjacent systems must detect communications faults fast to switch traffic to a normal tunnel for service recovery. To meet this requirement, BFD provides the following functions:
l l
Detecting faults on the channel between adjacent forwarding engines in a short time, which brings only light load to the system Using a single mechanism to perform real-time detection for all media or protocol layers and supporting different detection time and costs
1.4 Networking Scheme for Ensuring the Reliability of IP Networks

This section describes the application scenarios and schemes for reliability, and FRR technologies.
1.4.1 Faults on Intermediate Nodes or on the Link Between PEs LDP FRR/TE FRR
In LDP/TE applications, if there are intermediate devices between PE devices, BFD can be adopted to detect the link between the PE devices. Figure 1-1 Networking diagram of an LDP/TE FRR application
PE1
P1
P2
P3
PE3
PE2
PE4
As shown in Figure 1-1, an LDP LSP serves as a public network tunnel and TE is enabled between P devices to ensure QoS. This deployment enhances the QoS across the entire network and simplifies the TE deployment in changing PE devices. Without intermediate devices, if a fault occurs on the link between P1 and P2, or P2 fails on a non-broadcast network, LDP FRR performs switchover on PE1 and ensures that the switchover takes not more than 50 ms. The prerequisite of the preceding application is that no transmission device exists, since the switchover performed by TE FRR/LDP FRR depends on the detection of the electrical signals or optical signals on the interface. If transmission devices exist and a link fails, the router cannot detect the interruption of optical signals, and the switchover cannot be performed. Then, another mechanism is required to detect the link between transmission devices, that is, BFD or OAM.
NOTE
If LDP FRR and IP FRR are both available, IP FRR is preferred.
Issue 01 (2011-10-15)
1.4.2 Fault on the Link Between PEs

BFD can be used to detect the link between PEs.
1.4.3 Fault on the Remote PE - VPN FRR

In VPN FRR applications, BFD can be used to detect the connectivity faults between PEs. Figure 1-2 Networking diagram of a VPN FRR application
PE1
P1
P2
P3
PE3
PE2
PE4
As shown in Figure 1-2, PE3 and PE4 access the VPN. If the user network on the left of PE1 needs to communicate with the user network on the right of PE3, PE1 can access the user network on the right through PE3 and PE4. In this case, PE3 and PE4 provide backup for each other, through which PE1 sends packets. This is how VPN FRR works. Similar to other FRR technologies, in VPN FRR, an available bypass path is reserved for fast switchover in case that the primary path fails. For VPN FRR, two next hops (PEs) are reserved for the local device to access the private network. One is the active PE and the other is the standby PE. The active and standby PEs are configured by users. As shown in the preceding figure, PE1 reserves two next hops, namely, PE3 and PE4, to access the remote VPN. PE1 can select either of them as the active next hop, and the other one serves as the standby next hop. l Without VPN FRR, only an active next-hop entry is delivered from the control plane to the forwarding plane. When the active next hop becomes invalid, the standby next-hop entry is delivered to the forwarding plane, which slows down the switchover. With VPN FRR, both the active and standby next-hop entries are delivered from the control plane to the forwarding plane. When the active next hop becomes invalid, the standby next hop can be applied fast to the forwarding plane. So, the switchover speeds up.
After BFD detects that the active next hop fails, switchover is performed within a very short period, which ensures high reliability.
1.4.4 Fault on the Downlink Interface on the PE - IP FRR

In an IP FRR application, when the primary path between a CE and PE fails, traffic can be switched to the bypass path.
Figure 1-3 Networking diagram of an IP FRR application
PE1 MPLS-VPN
Backbone
CE
PE2
As shown in Figure 1-3, the traffic to the CE is forwarded by PE1 (the active PE). If the link between PE1 and the CE fails, IP FRR switches the traffic from the link between PE1 and the CE to the link between PE2 and the CE. In fact, the working principle of FRR is to retain a bypass path on the forwarding plane for fast switchover. Likewise, with IP FRR, PE1 has two paths to reach the CE, namely, a directly connected route and a route with PE2 being the intermediate device. Generally, a PE accesses a Layer 3 Virtual Private Network (L3VPN). Thus, IP FRR here is also applied to a private network. Then, the private network neighbor relationship between PE1 and PE2 needs to be created, and the primary and bypass paths are created for PE1 accessing the CE.
NOTE
If LDP FRR and IP FRR are both available, IP FRR is preferred.
Issue 01 (2011-10-15)
2 BFD Configuration
2
About This Chapter
BFD Configuration
You can create a Bidirectional Forwarding Detection (BFD) session to fast detect link failures on a network. 2.1 BFD Overview BFD is a detection mechanism applicable to an entire network, and it detects and monitors connectivity of a link or an IP route during forwarding. 2.2 BFD Features Supported by the NE5000E The NE5000E supports BFD session establishment modes, two detection modes, single-hop and multi-hop BFD, dynamic BFD parameter adjustment, BFD bound to Virtual Private Network (VPN) instances, BFD for label switched path (LSP), BFD for traffic engineering (TE), and BFD for IPv6. 2.3 Configuring BFD to Detect an IP Link You can configure a single-hop BFD session to fast detect faults in direct links on a network. 2.4 Configuring BFD to Detect VPN Routes By configuring BFD, you can detect whether the VPN routes are reachable. 2.5 Configuring a Static BFD Session with Automatically-Negotiated Discriminators By configuring a static BFD session with automatically-negotiated discriminators on a local device, you can enable the local device to interwork with the device on which a BFD session is dynamically set up. The static BFD session with automatically-negotiated discriminators detects static routes. 2.6 Configuring Multi-hop BFD Multi-hop BFD helps a device fast detect faults in a multi-hop link on a network. 2.7 Associating a BFD Session with an Interface Association between a BFD session and an interface triggers rapid route convergence. Only a single-hop BFD session with a default multicast IP address can be bound to an interface. 2.8 Associating a BFD Session with the Sub-interface Association between a BFD session and a sub-interface triggers rapid route convergence. Association between the BFD session and the sub-interface is applicable to a single-hop BFD session with the default multicast IP address. 2.9 Enabling a BFD Session to Modify the PST
2 BFD Configuration
Enabling a BFD session to modify the PST speeds up detection if a fault occurs. Only singlehop BFD sessions are configured with this function. 2.10 Configuring the Delay of a BFD Session to Go Up The delay of a BFD session to go Up is configured to prevent traffic loss because a routing protocol goes Up later than an interface. 2.11 Maintaining BFD Maintaining BFD help you clear the BFD statistics, monitor the BFD operating status, and debug BFD in the event of a fault. 2.12 Configuration Examples This section provides examples for configuring BFD and provides the networking requirements, configuration precautions, and configuration roadmap. You can better understand the configuration process with the help of the configuration flowchart.
Issue 01 (2011-10-15)
11
2 BFD Configuration
2.1 BFD Overview

BFD is a detection mechanism applicable to an entire network, and it detects and monitors connectivity of a link or an IP route during forwarding. On a network, a link fault can be detected using the following methods: l l Hardware detection signals, for example, the Synchronous Digital Hierarchy (SDH) alarm function. The hardware detection can fast detect a fault. Hello mechanism of a routing protocol, functioning as an alternative if the preceding method is unavailable. Only certain mediums support fault detection using hardware. It takes more than 1 second for the Hello mechanism of a routing protocol to detect a fault. Data transmission at the Gbit/s speed leads to loss of a great amount of data. On small-scale Layer 3 networks, if no routing protocols are deployed, the Hello mechanism cannot be used to detect a fault. In this case, a fault between the interconnected router is hard to locate.
The preceding detection methods have the following problems: l l l
BFD is developed to address the preceding problems. BFD provides the following functions: l l Allows fault detection with light load and high speed for paths between the neighboring forwarding engines. Provides a single mechanism to detect any medium and protocol layer in real time.
BFD sessions cannot be created on a management interface or bound to the IP address of a management interface.
2.2 BFD Features Supported by the NE5000E

The NE5000E supports BFD session establishment modes, two detection modes, single-hop and multi-hop BFD, dynamic BFD parameter adjustment, BFD bound to Virtual Private Network (VPN) instances, BFD for label switched path (LSP), BFD for traffic engineering (TE), and BFD for IPv6. BFD, functioning as a detection mechanism applicable to an entire network, is used by multiple protocols. This section describes BFD features supported by the NE5000E.
BFD Session Establishment Modes

BFD uses the local and remote discriminators to differentiate multiple BFD sessions between the same pair of systems. Based on the differences in methods of creating the local and the remote discriminators, the NE5000E supports the following types of BFD sessions: l l
Issue 01 (2011-10-15)
Static BFD sessions with manually-specified discriminators The local and remote discriminators must be set manually. Static BFD sessions with automatically-negotiated discriminators
2 BFD Configuration
Such a session detects a static route and helps a node communicate with a remote node on which a dynamic BFD session is established. No local or remote discriminator needs to be set. l BFD sessions dynamically triggered by protocols, where no local or remote discriminator needs to be set: BFD sessions with dynamically-allocated local discriminators BFD sessions with self-learned remote discriminators If the two ends of a BFD session are to create discriminators in different methods, the following conditions must be satisfied: l l In a static BFD session, if the discriminators on the local end are manually specified, the discriminators on the remote end must also be manually specified. If the static discriminators on the local end are automatically negotiated, the discriminators on the remote end can be automatically negotiated or a dynamic BFD session can be established on the remote end. On the local end, if a static BFD session with the automatically-negotiated discriminators and a dynamic BFD session are established, the following principles are applicable: If a dynamic BFD session and a static BFD session with automatically-negotiated discriminators are configured with the same five-tuple set (the source and destination addresses, outbound interface, VPN index, and VR identifier), the NE5000E uses the shared BFD session to which both the dynamic BFD session and static BFD session with automatically-negotiated discriminators belong. If the dynamic BFD session named DYN_local discriminator is configured first and then the static BFD session with automatically-negotiated discriminators is configured, the name of the shared BFD session is updated as the name of the static BFD session. The smaller values of parameters between two BFD sessions are adopted.
Detection Modes
The NE5000E supports the following Asynchronous mode. Each system sends BFD control packets at negotiated intervals. If a system does not receive packets from the peer within a detection period, the BFD session goes Down.
Single- and Multi-hop BFD

The NE5000E supports single- and multi-hop BFD. Single- and multi-hop BFD functions detect connectivity of IP routes. On the NE5000E, single-hop BFD can detect the following types of interfaces and links: l l Layer 3 physical interfaces Ethernet sub-interfaces including Eth-Trunk sub-interfaces If a physical Ethernet interface has multiple sub-interfaces, BFD sessions can be established separately on the physical Ethernet interface and each of its sub-interfaces. l l IP-Trunk Layer 3 Eth-Trunk
Issue 01 (2011-10-15)
13

NOTE
2 BFD Configuration
Both IP-Trunk and Eth-Trunk consist of multiple member links, which provide high bandwidth or enhance reliability. A trunk remains Up only when a certain number of member links are Up.
Dynamically Adjusting BFD Parameters

After a BFD session is set up, you can change related parameters of BFD, such as the minimum intervals at which BFD packets are sent and received and detection mode, with no impact on the current session status.
Binding a BFD Session to a VPN Instance

On the NE5000E, a BFD session can be bound to a VPN instance. This allows BFD control packets to be sent over a specified VPN.
BFD for IPv6

BFD for IPv6 and BFD for IPv4 have similar functions. They rapidly detect communication faults between systems and notify the upper-layer applications of the fault. The following table shows features supported by BFD for IPv6 and BFD for IPv4. Features IP link Static route OSPF OSPFv3 BGP IS-IS PST PIS PW TE LSP BFD for IPv6 Supported Supported Not supported Supported Supported Supported Supported Not supported Not supported Not supported Supported BFD for IPv4 Supported Supported Supported Not supported Supported Supported Supported Supported Supported Supported Supported
2.3 Configuring BFD to Detect an IP Link

You can configure a single-hop BFD session to fast detect faults in direct links on a network.
Applicable Environment
To fast monitor an IP link on a network, you can configure BFD to detect faults in the IP link.
2 BFD Configuration
Pre-configuration Tasks
Before configuring BFD to detect an IP link, complete the following tasks: l l Setting parameters of a data link layer protocol to ensure the link protocol status of interfaces are Up Correctly assigning an IP address to each interface
Configuration Procedures
Figure 2-1 Flowchart of configuring BFD to detect an IP link
Enable BFD globally
Establish a BFD session
Adjust BFD detection time
Set the BFD WTR time
Configure the description of a BFD session
Mandatory procedure Optional procedure
2.3.1 Enabling BFD Globally

BFD must be enabled globally before configurations relevant to BFD are performed.
Procedure
Step 1 Run:
system-view
The system view is displayed. Step 2 Run:

bfd
BFD is enabled globally on the local node and the BFD view is displayed. Configurations relevant to BFD can be performed only after the bfd command has been run globally.
2 BFD Configuration
Step 3 (Optional) Run:

process-mode
Both BFD distributed and centralized processing modes are supported.

NOTE
If a single-hop BFD session is bound to an interface board but the board does not support BFD negotiation, BFD negotiation fails and the BFD session cannot go Up. To prevent this failure, run the process-mode command to support both BFD distributed and centralized processing modes. After this, an interface board or multiple interface boards that support BFD negotiation can be specified. If a bound interface board has free BFD resources, the BFD session bound to the board that does not support BFD negotiation will used the resources to negotiation. If the negotiation is successful, the BFD session will go Up.
Step 4 (Optional) Run:

default-ip-address
The default multicast address is configured for a BFD session. Step 5 Run:
commit
The configurations are committed. ----End
2.3.2 Establishing a BFD Session

A BFD session is established on both ends of a direct link to rapidly detect link faults.
Procedure
Step 1 Run:
system-view
The system view is displayed. Step 2 According to whether BFD detects an IPv4 link or an IPv6 link, perform either of the following operations: l According to whether the remote end is configured with an IP address, run either of the following commands to configure the BFD binding relationship: To bind the BFD session to a Layer 3 interface with an IP address, run:
bfd session-name bind peer-ip peer-ip [ vpn-instance vpn-name ] interface interface-type interface-number [ source-ip source-ip ]
A BFD session for IPv4 is bound to a Layer 3 interface.

NOTE
l If a single-hop BFD session for IPv4 is created for the first time, a peer IPv4 address must be specified for the BFD session, and the BFD session must be bound to the local interface. The binding cannot be modified after being created. l When configuring the BFD session for IPv4, the system checks only the validity of the IPv4 address format but not correctness. Binding the BFD session for IPv4 to an incorrect remote or local IPv4 address results in a failure in establishing the BFD session for IPv4. l If BFD and URPF are used together, source-ip must be configured correctly before a BFD session is bound to the IPv4 address. This prevents BFD packets from being incorrectly discarded. URPF checks format of the source IPv4 addresses in received packets, and discards the packets whose source IPv4 addresses are incorrect.
Issue 01 (2011-10-15)
16
2 BFD Configuration
To bind the BFD session to a Layer 2 interface or a Layer 3 member interface without an IP address, run:
bfd bind peer-ip default-ip interface intierface-type interface-number [ source-ip source-ip ]
A BFD session for IPv4 is bound to an interface. l Run:

bfd session-name bind peer-ipv6 peer-ipv6 [ vpn-instance vpn-name ] [ interface interface-type interface-number ] [ source-ipv6 source-ipv6 ]
A BFD session for IPv6 is bound to an interface.

NOTE
l If a single-hop BFD session for IPv6 is created for the first time, the BFD session must be bound to the remote IPv6 address and the local interface. The binding cannot be modified after being created. l When configuring the BFD session for IPv6, the system checks only the validity of the IPv6 address format but not correctness. Binding the BFD session for IPv6 to an incorrect remote or local IPv6 address results in a failure in establishing the BFD session for IPv6. l If BFD and URPF are used together, source-ip must be configured correctly before a BFD session is bound to the interface. This prevents BFD packets from being incorrectly discarded. URPF checks the format of the source IPv6 addresses in received packets, and discards the packets whose source IPv6 addresses are incorrect.
Step 3 Run:
discriminator local discr-value
The local discriminator of the BFD session is created. Step 4 Run:

discriminator remote discr-value
The remote discriminator of the BFD session is created.

NOTE
The local and remote discriminators on the two ends of a BFD session must be correctly associated. This means the local discriminator of the local device and the remote discriminator of the remote device are the same, and the remote discriminator of the local device and the local discriminator of the remote device are the same. Otherwise, the BFD session cannot be set up. In addition, the local and remote discriminators cannot be modified after being successfully configured.
Step 5 Run:
commit
2.3.3 (Optional) Adjusting BFD Detection Time

By adjusting the BFD detection time, you can more efficiently use a BFD session to monitor links on a network.
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
17
2 BFD Configuration

bfd session-name
The BFD session view is displayed. Step 3 Run:

min-tx-interval interval
The minimum interval at which BFD control packets are sent is set. The default minimum interval at which BFD control packets are sent is 10 milliseconds. Step 4 Run:
min-rx-interval interval
The minimum interval at which BFD control packets are received is set. By default, the minimum interval at which BFD control packets are received is 10 milliseconds.
NOTE
If a BFD session goes Down, the system automatically sets the local intervals at which BFD packets are sent and received to a random value larger than 1000, in milliseconds. After the BFD session goes Up, the system restores the set intervals.
Step 5 Run:
detect-multiplier multiplier
The local detection multiplier is set. By default, the value is 3. Step 6 Run:
commit
2.3.4 (Optional) Setting the BFD WTR Time

By setting the BFD wait-to-restore (WTR) time, you can prevent an application from being switched between the master and slave devices due to the BFD session flapping.
Context
If a BFD session flaps, the master/slave switchover is frequently performed on the application associated with BFD. To avoid the preceding problem, you can set the WTR time of the BFD session. When the BFD session changes from Down to Up, BFD reports the change to the upperlayer application after the WTR time expires.
Procedure
Step 1 Run:
system-view
The system view is displayed.

2 BFD Configuration
Step 2 Run:
bfd session-name

wtr wtr-value
The WTR time of the BFD session is set. By default, the WTR time is 0. That is, the WTR time does not wait to restore.
NOTE
A BFD session is unidirectional. Therefore, if the WTR time is set, you need to set the same WTR time on both ends of the BFD session. Otherwise, when the session status changes on one end, applications on both ends of the BFD session are aware of BFD sessions in different states.
Step 4 Run:
commit
2.3.5 (Optional) Configuring the Description of a BFD Session

By configuring the descriptions of BFD sessions, you can distinguish between different BFD sessions.
Procedure
Step 1 Run:
system-view

bfd session-name

description description
The description of a BFD session is configured. description is a string of 1 to 51 case-sensitive characters with spaces supported. By default, the description of a BFD session is null. You can run the undo description command to delete the description of the BFD session. Step 4 Run:
commit

2 BFD Configuration
2.3.6 Checking the Configuration

After the BFD detection parameters are set, you can view the minimum intervals at which BFD control packets are sent and received, the WTR time, and the description of a BFD session.
Prerequisite
The configurations of BFD in detection of an IP link are complete.
NOTE
You can view statistics about a BFD session and information about the BFD session only after all BFD parameters are set and the BFD session is successfully set up.
Procedure
l Run the display bfd session { all | discriminator discr-value | dynamic | peer-ip peerip [ vpn-instance vpn-name ] | static } [ verbose ] command to check information about BFD sessions. Run the display bfd statistics command to check global BFD statistics. Run the display bfd statistics session { all | static | dynamic | discriminator discrvalue | peer-ip peer-ip [ vpn-instance vpn-name ] } command to check statistics about BFD sessions. Run the display bfd interface command to check information about BFD interfaces.
l l
----End
Example
After configuring a BFD session, run the display bfd session all verbose command, and you can view detailed information about all BFD sessions.
<HUAWEI> display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : atob -----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 10.10.10.2 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
Run the display bfd statistics command, and you can view global BFD statistics.
2 BFD Configuration
<HUAWEI> display bfd statistics Current Display Board Number : Main ; Current Product Register Type: Total Up/Down Session Number : 1/0 Current Session Number : Static session : 1 Dynamic session : 0 E_Dynamic session : 0 STATIC_AUTO session : 0 LDP_LSP session : 0 STATIC_LSP session : 0 TE_TUNNEL session : 0 TE_LSP session : 0 PW session : 0 IP session : 1 VSI PW session : 0 -----------------------------------------------------------------------------PAF/LCS Name Maximum Minimum Create -----------------------------------------------------------------------------BFD_CFG_NUM 8192 1 1 BFD_IO_SESSION_NUM 512 1 0 BFD_PER_TUNNEL_CFG_NUM 16 1 0 -----------------------------------------------------------------------------Current Total Used Discriminator Num : 1 -----------------------------------------------------------------------------BFD HAF Information : -----------------------------------------------------------------------------Current HAF Status : Work -----------------------------------------------------------------------------BFD for LSP Information : -----------------------------------------------------------------------------Ability of auto creating BFD session on egress : Disable Period of LSP Ping : 60 -----------------------------------------------------------------------------BFD other Information : -----------------------------------------------------------------------------System Session Delay Up Timer : OFF ------------------------------------------------------------------------------
Run the display bfd statistics session all command, and you can view statistics about all BFD sessions.
<HUAWEI> display bfd statistics session all -----------------------------------------------------------------------------State : Up Name : atob -----------------------------------------------------------------------------Session Type : Static Bind Type : IP Local/Remote Discriminator : 10/20 Received Negotiation Packets : 1710577 Sent Negotiation Packets : 1710593 Received Bad Negotiation Packets : 0 Sent Failed Negotiation Packets : 0 Down Count : 0 ShortBreak Count : 0 Sent Lsp Ping Count : 0 Create Time : 2009/09/27 07:20:06 Last Down Time : 0000/00/00 00:00:00 Total Time From Last DOWN : ---D:--H:--M:--S Total Time From Create : 000D:09H:03M:47S -------------------------------------------------------------------------------Total Session Number : 1
Run the display bfd interface command to check information about BFD interfaces.
<HUAWEI> display bfd interface -------------------------------------------------------------------------Interface Name MIndex Sess-Count BFD-State -------------------------------------------------------------------------Serial6/0/0 256 1 UP -------------------------------------------------------------------------Total Interface Number : 1
Issue 01 (2011-10-15)
21
2 BFD Configuration
2.4 Configuring BFD to Detect VPN Routes

By configuring BFD, you can detect whether the VPN routes are reachable.
To fast detect and monitor VPN routes, you can configure BFD.
Before configuring BFD to detect VPN routes, complete the following task: l l Configuring network layer attributes for interfaces to ensure network connectivity Configuring VPN instances on PEs
Figure 2-2 Flowchart of configuring BFD to detect VPN routes
Enable BFD globally

BFD must be enabled globally before performing configurations relevant to BFD.
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
22
2 BFD Configuration

bfd
BFD is enabled globally on the local node and the BFD view is displayed. Configuration relevant to BFD can be performed only after the bfd command has been run globally. Step 3 (Optional) Run:
process-mode

NOTE
Step 4 Run:
commit

A BFD session on both ends of a link is configured to detect faults in VPN routes.
Procedure
Step 1 Run:
system-view
The system view is displayed. Step 2 According to whether BFD detects an IPv4 link or an IPv6 link, perform either of the following operations: l To bind BFD IPv4 to an interface, run:
bfd session-name bind peer-ip peer-ip vpn-instance vpn-name [ interface interface-type interface-number ] [ source-ip source-ip ]
Issue 01 (2011-10-15)
23

NOTE
2 BFD Configuration
l If a single-hop BFD session for IPv4 is created for the first time, a peer IPv4 address must be specified for the BFD session, and the BFD session must be bound to a local interface. The binding cannot be modified after being created. l When configuring the BFD session for IPv4, the system checks only the validity of the IPv4 address format but not correctness. Binding the BFD session for IPv4 to an incorrect remote or local IPv4 address results in a failure in establishing the BFD session for IPv4. l If BFD and URPF are used together, source-ip must be configured correctly before a BFD session is bound to the IPv4 address. This prevents BFD packets from being incorrectly discarded. URPF checks the format of the source IPv4 addresses in received packets, and discards the packets whose source IPv4 addresses are incorrect.
l To bind BFD session for IPv6 to an interface, run:

bfd session-name bind peer-ipv6 peer-ipv6 vpn-instance vpn-name [ interface interface-type interface-number ] [ source-ipv6 source-ipv6 ]
NOTE
l If a single-hop BFD session for IPv6 is created for the first time, the BFD session must be bound to the remote IPv6 address and the local interface. The binding cannot be modified after being created. l When configuring the BFD session for IPv6, the system checks only the validity of the IPv6 address format but not correctness. Binding the BFD session for IPv6 to an incorrect remote or local IPv6 address results in a failure in establishing the BFD session for IPv6. l If BFD and URPF are used together, source-ip must be configured correctly before a BFD session is bound to the IPv6 address. This prevents BFD packets from being incorrectly discarded. URPF checks the format of the source IPv6 addresses in received packets, and discards the packets whose source IPv6 addresses are incorrect.
Step 3 Run:


NOTE
The local and remote discriminators on the two ends of a BFD session must be correctly associated. The local discriminator of the local device and the remote discriminator of the remote device are the same, and the remote discriminator of the local device and the local discriminator of the remote device are the same. Otherwise, the BFD session cannot be correctly set up. In addition, the local and remote discriminators cannot be modified after being successfully configured.
Step 5 Run:
commit

2 BFD Configuration
Procedure
Step 1 Run:
system-view

bfd session-name

NOTE
Step 5 Run:
commit

Context
2 BFD Configuration
Procedure
Step 1 Run:
system-view

bfd session-name

wtr wtr-value
NOTE
Step 4 Run:
commit

Procedure
Step 1 Run:
system-view

bfd session-name


commit
2 BFD Configuration

After BFD is successfully configured to detect VPN routes, you can view the configurations of the BFD session such as the session type and status.
Prerequisite
The configurations of BFD in detection of VPN routes are complete.
NOTE
You can view information about a BFD session only after all BFD parameters are set and the BFD session is successfully set up.
Procedure
l Run the display bfd session { all | discriminator discr-value | dynamic | peer-ip peerip [ vpn-instance vpn-name ] | static } [ verbose ] command to check information about BFD sessions. Run the display bfd statistics command to check global BFD statistics. Run the display bfd statistics session { all | static | dynamic | discriminator discrvalue | peer-ip peer-ip [ vpn-instance vpn-name ] } command to check statistics about BFD sessions. Run the display bfd interface command to check information about BFD interfaces.
l l
----End
Example
After completing the configurations, run the display bfd session peer-ip vpn-instance vpnname verbose command. A single-hop BFD session is set up and its status is Up.
<HUAWEI> display bfd session peer-ip 10.2.1.2 vpn-instance vpna verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : atob -----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 10.10.10.2 Bind Interface : GigabitEthernet1/0/0 Vpn Instance Name : vpna FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : -
Issue 01 (2011-10-15)
27
2 BFD Configuration
Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
Run the display bfd statistics command, and you can view global BFD statistics.
<HUAWEI> display bfd statistics session all -----------------------------------------------------------------------------State : Up Name : atob -----------------------------------------------------------------------------Session Type : Static Bind Type : IP Local/Remote Discriminator : 10/20 Received Negotiation Packets : 1710577 Sent Negotiation Packets : 1710593 Received Bad Negotiation Packets : 0 Sent Failed Negotiation Packets : 0 Down Count : 0 ShortBreak Count : 0 Sent Lsp Ping Count : 0 Create Time : 2009/09/27 07:20:06 Last Down Time : 0000/00/00 00:00:00 Total Time From Last DOWN : ---D:--H:--M:--S Total Time From Create : 000D:09H:03M:47S -------------------------------------------------------------------------------Total Session Number : 1
Run the display bfd interface command to check information about BFD interfaces.
<HUAWEI> display bfd interface --------------------------------------------------------------------------
Issue 01 (2011-10-15)
28
2 BFD Configuration
Interface Name MIndex Sess-Count BFD-State -------------------------------------------------------------------------Serial6/0/0 256 1 UP -------------------------------------------------------------------------Total Interface Number : 1
2.5 Configuring a Static BFD Session with AutomaticallyNegotiated Discriminators

By configuring a static BFD session with automatically-negotiated discriminators on a local device, you can enable the local device to interwork with the device on which a BFD session is dynamically set up. The static BFD session with automatically-negotiated discriminators detects static routes.
If a dynamic BFD session is set up on the remote device, you must configure the static BFD session with automatically-negotiated discriminators on the local device to interwork with the remote device and support static routes to track BFD.
Before configuring a static BFD session with automatically-negotiated discriminators, complete the following tasks: l l Correctly connecting interfaces Correctly assigning an IP address to each Layer 3 interface
Figure 2-3 Configuring a static BFD session with automatically-negotiated discriminators
Enable BFD globally
Issue 01 (2011-10-15)
29
2 BFD Configuration

Procedure
Step 1 Run:
system-view

bfd
BFD is enabled globally on the local node and the BFD view is displayed. Configurations relevant to BFD can be performed only after the bfd command is run globally. Step 3 (Optional) Run:
process-mode

NOTE
Step 4 Run:
commit

Establishing a static BFD session with automatically-negotiated discriminators on both ends of a link allows a device to rapidly detect faults in a link.
Procedure
Step 1 Run:
system-view
The system view is displayed. Step 2 According to whether BFD detects an IPv4 link or an IPv6 link, perform either of the following operations: l Run:
bfd session-name bind peer-ip ip-address [ vpn-instance vpn-name ] [ interface interface-type interface-number ] source-ip ip-address auto
Issue 01 (2011-10-15)
30
2 BFD Configuration
A static BFD session for IPv4 with automatically-negotiated discriminators is set up.
NOTE
l A source address must be configured. l The IP address must be an explicit IPv4 address but not a multicast one.
l Run:
bfd session-name bind peer-ipv6 ipv6-address [ vpn-instance vpn-name ] [ interface interface-type interface-number ] source-ipv6 ipv6-address auto
A static BFD session for IPv6 with automatically-negotiated discriminators is set up.
NOTE
l A source address must be configured. l The IP address must be an explicit IPv6 address but not a multicast one.
Step 3 Run:
commit

Procedure
Step 1 Run:
system-view

bfd session-name

NOTE
Issue 01 (2011-10-15)
31
2 BFD Configuration
Step 5 Run:
commit

Context
Procedure
Step 1 Run:
system-view

bfd session-name

wtr wtr-value
NOTE
Step 4 Run:
commit

2 BFD Configuration

Procedure
Step 1 Run:
system-view

bfd session-name

commit

After a static BFD session with automatically-negotiated discriminators is successfully set up, you can view information about the BFD session such as the session type being static and the discriminators being automatically negotiated.
Prerequisite
The configurations of a static BFD session with automatically-negotiated discriminators are complete.
Procedure
Step 1 Run the display bfd session { all | static | dynamic | discriminator discr-value | peer-ip peerip [ vpn-instance vpn-name ] } [ verbose ] command to check information about BFD sessions. Step 2 Run the display bfd interface command to check information about BFD interfaces. ----End
Example
# Display detailed information about all BFD sessions.
2 BFD Configuration
<HUAWEI> display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : atob -----------------------------------------------------------------------------Local Discriminator : 8193 Remote Discriminator : 8194 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static_Auto Bind Peer IP Address : 10.10.10.2 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : AUTO Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
The command output shows a BFD session with the type being Static_Auto, the local discriminator being 8193, and the remote discriminator being 8194. In addition, the discriminators are automatically negotiated. Run the display bfd interface command to check information about BFD interfaces.
<HUAWEI> display bfd interface -------------------------------------------------------------------------Interface Name MIndex Sess-Count BFD-State -------------------------------------------------------------------------Serial6/0/0 256 1 UP -------------------------------------------------------------------------Total Interface Number : 1
2.6 Configuring Multi-hop BFD

Multi-hop BFD helps a device fast detect faults in a multi-hop link on a network.
To fast detect and monitor connectivity of IP routes, you can configure multi-hop BFD.
Before configuring multi-hop BFD, complete the following tasks: l l l Configuring parameters of a data link layer protocol on interfaces to ensure that the link protocol status on the interfaces is Up Assigning IP addresses to interfaces Configuring a routing protocol to ensure that the network layer is reachable
Issue 01 (2011-10-15)
34
2 BFD Configuration
Figure 2-4 Flowchart of configuring multi-hop BFD
Enable BFD globally

Procedure
Step 1 Run:
system-view

bfd
BFD is enabled globally on the local node and the BFD view is displayed. Configurations relevant to BFD can be performed only after the bfd command is run globally. Step 3 Run:
commit

You can establish a BFD session on both ends of a multi-hop link to rapidly detect faults in the multi-hop link.
2 BFD Configuration
Procedure
Step 1 Run:
system-view
The system view is displayed. Step 2 According to whether BFD detects an IPv4 link or an IPv6 link, perform either of the following operations: l Run:
bfd session-name bind peer-ip peer-ip [ vpn-instance vpn-name ] [ source-ip source-ip ]
The binding information about a BFD session is created.

NOTE
l If a BFD session for IPv4 is created for the first time, a peer IPv4 address must be specified for the BFD session, and the BFD session must be bound to the local interface. The binding cannot be modified after being created. l When configuring the BFD session for IPv4, the system checks only the validity of the IPv4 address format but not correctness. Binding the BFD session for IPv4 to an incorrect remote or local IPv4 address results in a failure in establishing the BFD session for IPv4. l If BFD and URPF are used together, source-ip must be configured correctly before a BFD session is bound to the interface. This prevents BFD packets from being incorrectly discarded. URPF checks the format of the source IPv4 addresses in received packets, and discards the packets whose source IPv4 addresses are incorrect.
l Run:
bfd session-name bind peer-ipv6 peer-ipv6 [ vpn-instance vpn-name ] [ sourceipv6 source-ipv6 ]
The binding information about a BFD session is created.

NOTE
l If a multi-hop BFD session for IPv6 is created for the first time, a peer IPv6 address must be specified for the BFD session, and the BFD session must be bound to the local interface. The binding cannot be modified after being created. l When configuring the BFD session for IPv6, the system checks only the validity of the IPv6 address format but not correctness. Binding the BFD session for IPv6 to an incorrect remote or local IPv6 address results in a failure in establishing the BFD session for IPv6. l If BFD and URPF are used together, source-ip must be configured correctly before a BFD session is bound to the IPv6 address. This prevents BFD packets from being incorrectly discarded. URPF checks the format of the source IPv6 addresses in received packets, and discards the packets whose source IPv6 addresses are incorrect.
Step 3 Run:

Issue 01 (2011-10-15)
36

NOTE
2 BFD Configuration
The local discriminators and remote discriminators on the two ends of a BFD session must be correctly associated. The local discriminator of the local device and the remote discriminator of the remote device are the same, and the remote discriminator of the local device and the local discriminator of the remote device are the same. Otherwise, the BFD session cannot be set up. In addition, the local and remote discriminators cannot be modified after being successfully configured.
Step 5 Run:
commit

Procedure
Step 1 Run:
system-view

bfd session-name

NOTE
Step 5 Run:
commit
Issue 01 (2011-10-15)
37
2 BFD Configuration

Context
Procedure
Step 1 Run:
system-view

bfd session-name

wtr wtr-value
NOTE
Step 4 Run:
commit

Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
38
2 BFD Configuration

bfd session-name

commit

After the configurations of multi-hop BFD are successful, you can view that the type of the BFD session is multi-hop and the status of the BFD session is Up.
Prerequisite
The configurations of multi-hop BFD are complete.
NOTE
You can view statistics about a BFD session or information about BFD sessions only after all BFD parameters are set and the BFD session is successfully set up.
Procedure
l Run the display bfd session { all | discriminator discr-value | dynamic | peer-ip peerip [ vpn-instance vpn-name ] | static } [ verbose ] command to check information about BFD sessions. Run the display bfd statistics command to check global BFD statistics. Run the display bfd statistics session { all | static | dynamic | discriminator discrvalue | peer-ip peer-ip [ vpn-instance vpn-name ] } command to check statistics about BFD sessions.
l l
----End
Example
After completing the configurations, run the display bfd session all verbose command, and you can see that a multi-hop BFD session is set up and the status is Up.
<RouterA> display bfd session all verbose -----------------------------------------------------------------------------(Multi Hop) State : Up Name : atob
Issue 01 (2011-10-15)
39
2 BFD Configuration
-----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Peer IP Address Bind Session Type : Static Bind Peer IP Address : 10.10.10.2 Bind Interface : Bind Source IP Address : 10.10.10.1 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 4784 TTL : 254 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
Run the display bfd statistics command, and you can view global statistics about a BFD session.
<HUAWEI> display bfd statistics session all -----------------------------------------------------------------------------State : Up Name : atob -----------------------------------------------------------------------------Session Type : Static Bind Type : IP
Issue 01 (2011-10-15)
40
2 BFD Configuration
Local/Remote Discriminator : 10/20 Received Negotiation Packets : 1710577 Sent Negotiation Packets : 1710593 Received Bad Negotiation Packets : 0 Sent Failed Negotiation Packets : 0 Down Count : 0 ShortBreak Count : 0 Sent Lsp Ping Count : 0 Create Time : 2009/09/27 07:20:06 Last Down Time : 0000/00/00 00:00:00 Total Time From Last DOWN : ---D:--H:--M:--S Total Time From Create : 000D:09H:03M:47S -------------------------------------------------------------------------------Total Session Number : 1
2.7 Associating a BFD Session with an Interface

Association between a BFD session and an interface triggers rapid route convergence. Only a single-hop BFD session with a default multicast IP address can be bound to an interface.
On the network shown in Figure 2-5, transmission devices between two NE5000Es on two ends of a link, on which the two NE5000Es are directly connected at the network layer but segmented physically by the transmission devices. If the link fails, the NE5000Es on the two ends of the link take a long time to detect the fault and age the direct route. As a result, the network interruption lasts for a long time. Figure 2-5 Networking diagram for a link with transmission devices between two ends
RouterA
RouterB
To prevent the preceding problem, the NE5000E associates the BFD session with the interface. If a fault occurs, the BFD session detects the fault and goes Down. The BFD status change triggers the interface's BFD status to Down, triggering rapid route convergence.
Before associating a BFD session with an interface, complete the following tasks: l l l Enabling BFD globally Creating a single-hop BFD session which is bound to the main interface and configured with the default multicast address for detection Setting up the BFD session and ensuring that the BFD session is Up
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
41
2 BFD Configuration

bfd session-name

process-interface-status
The BFD session is associated with the interface to which the BFD session is bound. By default, a BFD session is not associated with an interface. A BFD session status change does not affect the interface status.
NOTE
l Although the process-interface-status command has been run, the BFD status will not be reported to the interface if the BFD status changes while the commit command is being entered. This prevents an incorrect BFD status message (when the BFD session is not established or does not go Up) from causing an incorrect interface status change. After the commit command is run, if the BFD status changes, the interface is notified of the change and sets the BFD status to Down. This implements association between the BFD session status and the interface status. l If the process-interface-status command associated with a BFD session exists in the configuration file, after the router is restarted, the BFD session reports the Down state to the interface so that the interface sets its BFD status to Down. This prevents traffic loss in the situation where the BFD session is Up but the interface is Down during initialization of the router. l The BFD configurations on two routers must be correct and match before the BFD session is associated with the interface. If the remote BFD configurations are incorrect or the shutdown command is run on the remote router, the local BFD status is Down. l Changing the status of the BFD session immediately synchronizes the BFD status with the interface status by running the shutdown and undo shutdown commands. This triggers the BFD session to start a detection timer. If the BFD session goes Up before the timer expires, the BFD session reports the Up state to the interface; if the BFD session detects a fault and goes Down, the BFD session reports the Down state to the interface after the timer expires. The BFD session and the interface achieve real-time status synchronization.
Step 4 Run:
commit
The configuration is committed. ----End
Checking the Configuration

Run the following commands to check the previous configuration. l Run the display bfd session command to check information about BFD sessions.
After completing the configuration, run the display bfd session command. The Proc interface status field displays Enable.
<HUAWEI> display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : pis -----------------------------------------------------------------------------Local Discriminator : 2 Remote Discriminator : 1 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 224.0.0.184
Issue 01 (2011-10-15)
42
2 BFD Configuration
Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Enable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
2.8 Associating a BFD Session with the Sub-interface

Association between a BFD session and a sub-interface triggers rapid route convergence. Association between the BFD session and the sub-interface is applicable to a single-hop BFD session with the default multicast IP address.
Application Environment
If high reliability is required and sub-interfaces are configures with a large number of services, only a BFD session needs to be configured on the main interface not on each sub-interface. The BFD session is associated with the sub-interface status, allowing the sub-interface's protocol status to be synchronized with the main interface's protocol status. This improves the reliability for services and saves BFD session resources.
Before associating a BFD session with a sub-interface, complete the following tasks: l l l Enabling BFD globally Creating a single-hop BFD session which is bound to the primary interface and configured with the default multicast address for detection Setting up the BFD session and ensuring that the BFD session is Up
Procedure
Step 1 Run:
system-view

bfd session-name

process-interface-status sub-if
The BFD session is associated with the sub-interface.

2 BFD Configuration
By default, the BFD session is not associated with the sub-interface. This means a BFD session status change does not affect the sub-interface status. Step 4 Run:
commit
The configuration is committed.

NOTE
If a BFD session goes Down, the BFD status on the main interface bound to the BFD session and subinterfaces also becomes Down.
----End

After completing the configuration, run the display bfd session command. The Proc interface status field displays Enable(Sub-If).
<HUAWEI> display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : pis -----------------------------------------------------------------------------Local Discriminator : 1 Remote Discriminator : 2 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 224.0.0.184 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Enable (Sub-If) Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : Control Detection Time Expired Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
The command output shows that the BFD session status has been associated with the status of the main interface and its sub-interface.
2.9 Enabling a BFD Session to Modify the PST

Enabling a BFD session to modify the PST speeds up detection if a fault occurs. Only singlehop BFD sessions are configured with this function.
2 BFD Configuration
If BFD is allowed to modify the PST, BFD can modify the PST after detecting that an interface goes Down. This allows forwarding traffic to detect the fault based on the PST change. On the NE5000E, LDP FRR and IP FRR obtains a BFD detection result based on a PST change. If an application does not need to detect a fault based on the PST change triggered by BFD, the process-pst command does not need to be configured.
Before enabling a BFD session to modify the PST, complete the following task: Configuring single-hop BFD
Procedure
Step 1 Run:
system-view

bfd session-name

process-pst
A BFD session is allowed to modify the PST. By default, the BFD session does not change the PST if the BFD session detects a fault. If the BFD session on the trunk member interface or the VLAN member interface allows BFD to modify the PST, and the main interface is configured with the BFD session, you must configure the wait to restore (WTR) time for the BFD session that detects the main interface. This prevents the BFD session on the main interface from flapping when the member interface joins or leave the main interface. Step 4 Run:
commit

After completing the configuration, run the display bfd session command. The Process PST field displays Enable.
<HUAWEI> display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : pst1
Issue 01 (2011-10-15)
45
2 BFD Configuration
-----------------------------------------------------------------------------Local Discriminator : 2 Remote Discriminator : 1 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 10.1.1.1 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 6 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Enable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : ----------------------------------------------------------------------------------------------------------------------------------------------------------(One Hop) State : Up Name : pst2 -----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet2/0/0) Bind Session Type : Static Bind Peer IP Address : 2001::2 Bind Interface : GigabitEthernet2/0/0 FSM Board Id : 2 TOS-EXP : 6 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 2/0
2.10 Configuring the Delay of a BFD Session to Go Up

The delay of a BFD session to go Up is configured to prevent traffic loss because a routing protocol goes Up later than an interface.
On a live network, some devices switch traffic only based on the Up state of a BFD session. If a routing protocol goes Up later than an interface, although the BFD session goes Up, no route is available for switching traffic back. As a result, traffic is discarded. The delay time must be set to compensate for the time difference caused when the routing protocol goes Up later than the interface.
2 BFD Configuration
Before configuring the delay of a BFD session to go Up, complete the following task: l Ensuring that the router operates normally
Procedure
Step 1 Run:
system-view

bfd
BFD is enabled globally on the local node and the BFD view is displayed. Configurations relevant to BFD can be performed only after the bfd command is run globally. Step 3 Run:
delay-up seconds
The delay of the BFD session to go Up is set. By default, the delay is 0s. Step 4 Run:
commit

After completing the configurations, you can run the following command to check the configurations. l Run the display bfd statistics command to check global BFD statistics.
After completing the configurations, restart the router. After the router is restarted and starts to restore configurations, run the display bfd statistics command, and you can see that the System Session Delay Up Timer field is 300. It means that the delay timer is set to 300s and after the timer expires, the BFD session can go Up. For example:
<HUAWEI> display bfd statistics Current Display Board Number : Main ; Current Product Register Type: Total Up/Down Session Number : 1/0 Current Session Number : Static session : 1 Dynamic session : 0 E_Dynamic session : 0 STATIC_AUTO session : 0 LDP_LSP session : 0 STATIC_LSP session : 0 TE_TUNNEL session : 0 TE_LSP session : 0 PW session : 0 IP session : 1 VSI PW session : 0 -----------------------------------------------------------------------------PAF/LCS Name Maxnum Minnum Create -----------------------------------------------------------------------------BFD_CFG_NUM 16384 1 1 BFD_IO_SESSION_NUM 2048 1 0 BFD_PER_TUNNEL_CFG_NUM 16 1 0
Issue 01 (2011-10-15)
47
2 BFD Configuration
-----------------------------------------------------------------------------Current Total Used Discriminator Num : 1 -----------------------------------------------------------------------------BFD HAF Information : -----------------------------------------------------------------------------Current HAF Status : Work -----------------------------------------------------------------------------BFD for LSP Information : -----------------------------------------------------------------------------Ability of auto creating BFD session on egress : Disable Period of LSP Ping : 60 -----------------------------------------------------------------------------BFD other Information : -----------------------------------------------------------------------------System Session Delay Up Timer : 300 ------------------------------------------------------------------------------
2.11 Maintaining BFD

Maintaining BFD help you clear the BFD statistics, monitor the BFD operating status, and debug BFD in the event of a fault.
2.11.1 Clearing the BFD Statistics

To collect the BFD statistics of a certain period, you are recommended to clear the original BFD statistics of this period.
Context
CAUTION
BFD statistics cannot be restored after being cleared. So, confirm the action before you use this command.
Procedure
Step 1 Run (in the user view):
reset bfd statistics { all | discriminator discr-value }
The BFD statistics are cleared. ----End
2.11.2 Monitoring the BFD Operating Status

By monitoring the BFD operating status, you can view information about the BFD operation.
Context
Run the following commands in any view.
2 BFD Configuration
Procedure
l Run:
display bfd session { all | static | dynamic | discriminator discr-value | peerip peer-ip [ vpn-instance vpn-name ] } [ verbose ]
Information about the BFD session is displayed. l Run:

display bfd statistics
The global BFD statistics are displayed. l Run:

display bfd statistics session { all | static | dynamic | discriminator discrvalue | peer-ip peer-ip [ vpn-instance vpn-name ] }
The statistics on the BFD sessions are displayed. ----End
2.12 Configuration Examples

This section provides examples for configuring BFD and provides the networking requirements, configuration precautions, and configuration roadmap. You can better understand the configuration process with the help of the configuration flowchart.
2.12.1 Example for Configuring Single-Hop BFD for an IP-Trunk

This section exemplifies how to establish a single-hop BFD session on the IP-Trunk interface to detect the directly connected link between the IP-Trunk interfaces on the local and remote devices.
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/ interface number. On an NE5000E cluster, the interface is numbered in the format of chassis ID/slot number/card number/interface number. This requires the chassis ID to be specified along with the slot number. IP-Trunk is used to enhance link reliability. BFD sessions can be established to fast detect and monitor IP-Trunk. As shown in Figure 2-6, the IP-Trunk connecting Router A to Router B consists of two POS links. It is required that BFD be performed over the IP-Trunk. Figure 2-6 Networking for configuring single-hop BFD for an IP-Trunk
POS1/0/0
POS1/0/0
RouterA
POS2/0/0
IP-Trunk1 100.1.1.1/24
IP-Trunk1 100.1.1.2/24
POS2/0/0
RouterB
Issue 01 (2011-10-15)
49
2 BFD Configuration
Configuration Notes
The BFD session must be established on the IP-Trunk interface of both the local and remote devices.
Configuration Roadmap
The configuration roadmap is as follows: 1. 2. Create an IP-Trunk interface on both the local and remote devices. Configure single-hop BFD for an IP-Trunk.
Data Preparation
To complete the configuration, you need the following data: l l l l Local IP-Trunk interface that sends and receives BFD packets Peer IP address detected by BFD (the IP address of the IP-Trunk interface) Name of the BFD session for detecting the IP-Trunk Local and remote discriminators of BFD sessions
Procedure
Step 1 Configure the IP-Trunk interface. # Create an IP-Trunk interface on Router A and set the lower threshold of the IP-Trunks in the Up state to 1.
<HUAWEI> system-view [~HUAWEI] sysname RouterA [~HUAWEI] commit [~RouterA] interface ip-trunk 1 [~RouterA-Ip-Trunk1] undo shutdown [~RouterA-Ip-Trunk1] ip address 100.1.1.1 255.255.255.0 [~RouterA-Ip-Trunk1] least active-linknumber 1 [~RouterA-Ip-Trunk1] quit [~RouterA] interface Pos 1/0/0 [~RouterA-Pos1/0/0] undo shutdown [~RouterA-Pos1/0/0] link-protocol hdlc [~RouterA-Pos1/0/0] ip-trunk 1 [~RouterA-Pos1/0/0] quit [~RouterA] interface Pos 2/0/0 [~RouterA-Pos2/0/0] undo shutdown [~RouterA-Pos2/0/0] link-protocol hdlc [~RouterA-Pos2/0/0] ip-trunk 1 [~RouterA-Pos2/0/0] commit [~RouterA-Pos2/0/0] quit
# Create an IP-Trunk interface on Router B and set the lower threshold of IP-Trunks in the Up state to 1.
<HUAWEI> system-view [~HUAWEI] sysname RouterB [~HUAWEI] commit [~RouterB] interface ip-trunk 1 [~RouterB-Ip-Trunk1] undo shutdown [~RouterB-Ip-Trunk1] ip address 100.1.1.2 255.255.255.0 [~RouterB-Ip-Trunk1] least active-linknumber 1
Issue 01 (2011-10-15)
50

[~RouterB-Ip-Trunk1] quit [~RouterB] interface Pos 1/0/0 [~RouterB-Pos1/0/0] undo shutdown [~RouterB-Pos1/0/0] link-protocol hdlc [~RouterB-Pos1/0/0] ip-trunk 1 [~RouterB-Pos1/0/0] quit [~RouterB] interface Pos 2/0/0 [~RouterB-Pos2/0/0] undo shutdown [~RouterB-Pos2/0/0] link-protocol hdlc [~RouterB-Pos2/0/0] ip-trunk 1 [~RouterB-Pos2/0/0] commit [~RouterB-Pos2/0/0] quit
2 BFD Configuration
After configurations are complete, run the display interface ip-trunk command on Router A or Router B. You can view that the interface status is Up. # Take the display on Router A as an example.
[~RouterA] display interface ip-trunk 1 Ip-Trunk1 current state : Up Line protocol current state : Up Description : HUAWEI, Quidway Series, Ip-Trunk1 Interface, Route Port Hash arithmetic : According to flow The Maximum Transmit Unit is 4470 bytes Internet Address is 100.1.1.1/24 Link layer protocol is nonstandard HDLC Physical is IP_TRUNK Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets,0 bytes, 0 errors,0 drops,0 unknownprotocol Output:0 packets,0 bytes, 0 errors,0 drops ----------------------------------------------------PortName Status Weight ----------------------------------------------------Pos1/0/0 UP 1 Pos2/0/0 UP 1 ----------------------------------------------------The Number of Ports in Trunk : 2 The Number of UP Ports in Trunk : 2
IP-Trunk interfaces on Router A and Router B can ping through each other. # Take the display on Router A as an example.
[~RouterA] ping 100.1.1.2 PING 100.1.1.2: 56 data bytes, press CTRL_C to break Reply from 100.1.1.2: bytes=56 Sequence=1 ttl=255 time=220 ms Reply from 100.1.1.2: bytes=56 Sequence=2 ttl=255 time=30 ms Reply from 100.1.1.2: bytes=56 Sequence=3 ttl=255 time=10 ms Reply from 100.1.1.2: bytes=56 Sequence=4 ttl=255 time=30 ms Reply from 100.1.1.2: bytes=56 Sequence=5 ttl=255 time=40 ms --- 100.1.1.2 ping statistics --5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 10/66/220 ms
Step 2 Configure single-hop BFD for an IP-Trunk. # Enable BFD on Router A and establish a BFD session to detect the link between Router A and Router B. You need to bind an IP-Trunk interface to the BFD session.
[~RouterA] bfd
Issue 01 (2011-10-15)
51

[~RouterA-bfd] quit [~RouterA] bfd atob bind [~RouterA-bfd-sess-atob] [~RouterA-bfd-sess-atob] [~RouterA-bfd-sess-atob] [~RouterA-bfd-sess-atob]
2 BFD Configuration
peer-ip 100.1.1.2 interface ip-trunk 1 discriminator local 10 discriminator remote 20 commit quit
# # Enable BFD on Router B and establish a BFD session to detect the link between Router B and Router A. You need to bind an IP-Trunk interface to the BFD session.
[~RouterB] bfd [~RouterB-bfd] quit [~RouterB] bfd btoa bind [~RouterB-bfd-sess-btoa] [~RouterB-bfd-sess-btoa] [~RouterB-bfd-sess-btoa] [~RouterB-bfd-sess-btoa]
peer-ip 100.1.1.1 interface ip-trunk 1 discriminator local 20 discriminator remote 10 commit quit
Step 3 Verify the configuration. After configurations are complete, run the display bfd session all verbose command on Router A and Router B. You can view that a single-hop BFD session is established, with the status being Up. # Take the display on Router A as an example.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : atob -----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(Ip-Trunk 1) Bind Session Type : Static Bind Peer IP Address : 100.1.1.2 Bind Interface : Ip-Trunk 1 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
# Run the shutdown command on POS 1/0/0 of Router A to simulate the link fault.
[~RouterA] interface Pos 1/0/0 [~RouterA-Pos1/0/0] shutdown [~RouterA-Pos1/0/0] commit [~RouterA-Pos1/0/0] quit
Run the display bfd session all verbose and display interface ip-trunk commands on Router A and Router B. You can view that the status of both the BFD session and the IP-Trunk interfaces is still Up. # # Take the display on Router A as an example.
-----------------------------------------------------------------------------(One Hop) State : Up Name : atob
Issue 01 (2011-10-15)
52
2 BFD Configuration
-----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(Ip-Trunk 1) Bind Session Type : Static Bind Peer IP Address : 100.1.1.2 Bind Interface : Ip-Trunk 1 FSM Board Id : 0 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0 [~RouterA] display interface ip-trunk 1 Ip-Trunk1 current state : UP Line protocol current state : UP Description : HUAWEI, Quidway Series, Ip-Trunk1 Interface, Route Port Hash arithmetic : According to flow The Maximum Transmit Unit is 4470 bytes Internet Address is 100.1.1.1/24 Link layer protocol is nonstandard HDLC Physical is IP_TRUNK Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets,0 bytes, 0 errors,0 drops,0 unknownprotocol Output:0 packets,0 bytes, 0 errors,0 drops ----------------------------------------------------PortName Status Weight ----------------------------------------------------Pos1/0/0 DOWN 1 Pos2/0/0 UP 1 ----------------------------------------------------The Number of Ports in Trunk : 2 The Number of UP Ports in Trunk : 1
[~RouterA] interface Pos 2/0/0 [~RouterA-Pos2/0/0] shutdown [~RouterA-Pos2/0/0] commit [~RouterA-Pos2/0/0] quit
Run the display bfd session all verbose and display interface ip-trunk commands on Router A and Router B. You can view that the status of both the BFD session and the IP-Trunk interface becomes Down. # # Take the display on Router A as an example.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Down Name : atob ------------------------------------------------------------------------------
Issue 01 (2011-10-15)
53
2 BFD Configuration
Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(Ip-Trunk 1) Bind Session Type : Static Bind Peer IP Address : 100.1.1.2 Bind Interface : Ip-Trunk 1 FSM Board Id : 0 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0 [~RouterA] display interface ip-trunk 1 Ip-Trunk1 current state : DOWN Line protocol current state : UP Description : HUAWEI, Quidway Series, Ip-Trunk1 Interface, Route Port Hash arithmetic : According to flow The Maximum Transmit Unit is 4470 bytes Internet Address is 100.1.1.1/24 Link layer protocol is nonstandard HDLC Physical is IP_TRUNK Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets,0 bytes, 0 errors,0 drops,0 unknownprotocol Output:0 packets,0 bytes, 0 errors,0 drops ----------------------------------------------------PortName Status Weight ----------------------------------------------------Pos1/0/0 DOWN 1 Pos2/0/0 DOWN 1 ----------------------------------------------------The Number of Ports in Trunk : 2 The Number of UP Ports in Trunk : 0
----End
Configuration File
l Configuration file of Router A
# sysname RouterA # bfd # interface Ip-Trunk1 ip address 100.1.1.1 255.255.255.0 # interface Pos1/0/0 undo shutdown link-protocol hdlc ip-trunk 1
Issue 01 (2011-10-15)
54

# interface Pos2/0/0 undo shutdown link-protocol hdlc ip-trunk 1 # bfd atob bind peer-ip 100.1.1.2 interface Ip-Trunk1 discriminator local 10 discriminator remote 20 return
2 BFD Configuration
Configuration file of Router B

# sysname RouterB # bfd # interface Ip-Trunk1 ip address 100.1.1.2 255.255.255.0 # interface Pos1/0/0 undo shutdown link-protocol hdlc ip-trunk 1 # interface Pos2/0/0 undo shutdown link-protocol hdlc ip-trunk 1 # bfd btoa bind peer-ip 100.1.1.1 interface Ip-Trunk1 discriminator local 20 discriminator remote 10 return
2.12.2 Example for Configuring Single-Hop BFD for a Layer 3 EthTrunk

This section exemplifies how to establish single-hop BFD sessions on the Eth-Trunk interfaces to detect the directly connected link between two Eth-Trunk interfaces.
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/ interface number. On an NE5000E cluster, the interface is numbered in the format of chassis ID/slot number/card number/interface number. This requires the chassis ID to be specified along with the slot number. Eth-Trunk is used to enhance link reliability. BFD sessions are established to fast detect and monitor Eth-Trunk. As shown in Figure 2-7, the Eth-Trunk connecting Router A to Router B consists of two GE links. It is required that BFD be performed over the Eth-Trunk.
Issue 01 (2011-10-15)
55
2 BFD Configuration
Figure 2-7 Networking for configuring single-hop BFD for a Layer 3 Eth-Trunk
GE1/0/0
GE1/0/0
RouterA
GE2/0/0
Eth-Trunk1 100.1.1.1/24
Eth-Trunk1 100.1.1.2/24
RouterB
GE2/0/0
Configuration Notes
BFD sessions must be established on the Eth-Trunk interface of both the local and remote devices.
The configuration roadmap is as follows: 1. 2. Create an Eth-Trunk interface on both the local and remote devices. Configure single-hop BFD for an Eth-Trunk.
Data Preparation
To complete the configuration, you need the following data: l l l l Local Eth-Trunk interface that sends and receives BFD packets Peer IP address detected by BFD (the IP address of the Eth-Trunk interface) Name of the BFD session for detecting the Eth-Trunk Local and remote discriminators of BFD sessions
Procedure
Step 1 Configure an Eth-Trunk interface. # Create an Eth-Trunk interface on Router A and set the lower threshold of Eth-Trunks in the Up state to 1.
<HUAWEI> system-view [~HUAWEI] sysname RouterA [~HUAWEI] commit [~RouterA] interface eth-trunk 1 [~RouterA-Eth-Trunk1] undo shutdown [~RouterA-Eth-Trunk1] ip address 100.1.1.1 24 [~RouterA-Eth-Trunk1] least active-linknumber 1 [~RouterA-Eth-Trunk1] quit [~RouterA] interface gigabitethernet 1/0/0 [~RouterA-Gigabitethernet1/0/0] undo shutdown [~RouterA-Gigabitethernet1/0/0] eth-trunk 1 [~RouterA-Gigabitethernet1/0/0] quit [~RouterA] interface gigabitethernet 2/0/0 [~RouterA-Gigabitethernet2/0/0] undo shutdown [~RouterA-Gigabitethernet2/0/0] eth-trunk 1 [~RouterA-Gigabitethernet2/0/0] commit
Issue 01 (2011-10-15)
56

[~RouterA-Gigabitethernet2/0/0] quit
2 BFD Configuration
# Create an Eth-Trunk interface on Router B and set the lower threshold of Eth-Trunks in the Up state to 1.
<HUAWEI> system-view [~HUAWEI] sysname RouterB [~HUAWEI] commit [~RouterB] interface eth-trunk 1 [~RouterB-Eth-Trunk1] undo shutdown [~RouterB-Eth-Trunk1] ip address 100.1.1.2 24 [~RouterB-Eth-Trunk1] least active-linknumber 1 [~RouterB-Eth-Trunk1] quit [~RouterB] interface gigabitethernet 1/0/0 [~RouterB-Gigabitethernet1/0/0] undo shutdown [~RouterB-Gigabitethernet1/0/0] eth-trunk 1 [~RouterB-Gigabitethernet1/0/0] quit [~RouterB] interface gigabitethernet 2/0/0 [~RouterB-Gigabitethernet2/0/0] undo shutdown [~RouterB-Gigabitethernet2/0/0] eth-trunk 1 [~RouterB-Gigabitethernet2/0/0] commit [~RouterB-Gigabitethernet2/0/0] quit
After configurations are complete, run the display interface eth-trunk command on Router A or Router B. You can view that the interface status is Up. # Take the display on Router A as an example.
[~RouterA] display interface eth-trunk 1 Eth-Trunk1 current state : UP Line protocol current state : UP Description : HUAWEI, Quidway Series, Eth-Trunk1 Interface, Route Port Hash arithmetic : According to flow,Maximal BW: 200M, Current BW: 0M The Maximum Transmit Unit is 1500 bytes Internet Address is 100.1.1.1/24 IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-4b0c-f700 Physical is ETH_TRUNK Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets,0 bytes, 0 unicast,0 broadcast,0 multicast 0 errors,0 drops,0 unknownprotocol Output:0 packets,0 bytes, 0 unicast,0 broadcast,0 multicast 0 errors,0 drops ----------------------------------------------------PortName Status Weight ----------------------------------------------------Gigabitethernet1/0/0 UP 1 Gigabitethernet2/0/0 UP 1 ----------------------------------------------------The Number of Ports in Trunk : 2 The Number of UP Ports in Trunk : 2
Eth-Trunk interfaces on Router A and Router B can ping through each other. # Take the display on Router A as an example.
[~RouterA] ping -a 100.1.1.1 100.1.1.2 PING 100.1.1.2: 56 data bytes, press CTRL_C to break Reply from 100.1.1.2: bytes=56 Sequence=1 ttl=255 time=31 Reply from 100.1.1.2: bytes=56 Sequence=2 ttl=255 time=31 Reply from 100.1.1.2: bytes=56 Sequence=3 ttl=255 time=62 Reply from 100.1.1.2: bytes=56 Sequence=4 ttl=255 time=62 Reply from 100.1.1.2: bytes=56 Sequence=5 ttl=255 time=62 --- 100.1.1.2 ping statistics --5 packet(s) transmitted
ms ms ms ms ms
Issue 01 (2011-10-15)
57

5 packet(s) received 0.00% packet loss round-trip min/avg/max = 31/49/62 ms
2 BFD Configuration
Step 2 Configure single-hop BFD for a Layer 3 Eth-Trunk. # Enable BFD on Router A and establish a BFD session to detect the link from Router A to Router B. Bind the BFD session to an Eth-Trunk interface.
[~RouterA] bfd [~RouterA-bfd] quit [~RouterA] bfd atob bind [~RouterA-bfd-sess-atob] [~RouterA-bfd-sess-atob] [~RouterA-bfd-sess-atob] [~RouterA-bfd-sess-atob]
peer-ip 100.1.1.2 interface eth-trunk 1 discriminator local 10 discriminator remote 20 commit quit
# Enable BFD on Router B and establish a BFD session to detect the link from Router B toRouter A. Bind the BFD session to an Eth-Trunk interface.
[~RouterB] bfd [~RouterB-bfd] quit [~RouterB] bfd btoa bind [~RouterB-bfd-sess-btoa] [~RouterB-bfd-sess-btoa] [~RouterB-bfd-sess-btoa] [~RouterB-bfd-sess-btoa]
peer-ip 100.1.1.1 interface eth-trunk 1 discriminator local 20 discriminator remote 10 commit quit
Step 3 Verify the configuration. After configurations are complete, run the display bfd session all verbose command on Router A and Router B. You can view that a single-hop BFD session is established, with the status being Up. # Take the display on Router A as an example.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : atob -----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(Eth-Trunk1) Bind Session Type : Static Bind Peer IP Address : 100.1.1.2 Bind Interface : Eth-Trunk1 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
# Run the shutdown command on GE 1/0/0 of Router A to simulate the link fault.
[~RouterA] interface gigabitethernet 1/0/0 [~RouterA-Gigabitethernet1/0/0] shutdown
Issue 01 (2011-10-15)
58

[~RouterA-Gigabitethernet1/0/0] quit
2 BFD Configuration
Run the display bfd session all verbose and display interface eth-trunk commands on Router A and Router B. You can view that the status of both the BFD session and the Eth-Trunk interface is still Up. # # Take the display on Router A as an example.
[~RouterA] display bfd session all verbose -------------------------------------------------------------------------------(One Hop) State : Up Name : atob -----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(Eth-Trunk1) Bind Session Type : Static Bind Peer IP Address : 100.1.1.2 Bind Interface : Eth-Trunk1 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : Control Detection Time Expired Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0 [~RouterA] display interface eth-trunk 1 Eth-Trunk1 current state : UP Line protocol current state : UP Description : HUAWEI, Quidway Series, Eth-Trunk1 Interface, Route Port Hash arithmetic : According to flow,Maximal BW: 200M, Current BW: 0M The Maximum Transmit Unit is 1500 bytes Internet Address is 100.1.1.1/24 IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-4b0c-f700 Physical is ETH_TRUNK Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets,0 bytes, 0 unicast,0 broadcast,0 multicast 0 errors,0 drops,0 unknownprotocol Output:0 packets,0 bytes, 0 unicast,0 broadcast,0 multicast 0 errors,0 drops ----------------------------------------------------PortName Status Weight ----------------------------------------------------Gigabitethernet1/0/0 DOWN 1 Gigabitethernet2/0/0 UP 1 ----------------------------------------------------The Number of Ports in Trunk : 2 The Number of UP Ports in Trunk : 1
Run the shutdown command on GE 2/0/0 of Router A to simulate the link fault.
[~RouterA] interface interface gigabitethernet 2/0/0 [~RouterA-Gigabitethernet2/0/0] shutdown [~RouterA-Gigabitethernet2/0/0] commit [~RouterA-Gigabitethernet2/0/0] quit
Issue 01 (2011-10-15)
59
2 BFD Configuration
Run the display bfd session all verbose and display interface eth-trunk commands on Router A and Router B. You can view that the status of both the BFD session and the Eth-Trunk interface becomes Down. # Take the display on Router A as an example.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Down Name : atob -----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(Eth-Trunk1) Bind Session Type : Static Bind Peer IP Address : 100.1.1.2 Bind Interface : Eth-Trunk1 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 0/1 [~RouterA] display interface eth-trunk 1 Eth-Trunk1 current state : DOWN Line protocol current state : DOWN Description : HUAWEI, Quidway Series, Eth-Trunk1 Interface, Route Port Hash arithmetic : According to flow,Maximal BW: 200M, Current BW: 0M The Maximum Transmit Unit is 1500 bytes Internet Address is 100.1.1.1/24 IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-4b0c-f700 Physical is ETH_TRUNK Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets,0 bytes, 0 unicast,0 broadcast,0 multicast 0 errors,0 drops,0 unknownprotocol Output:0 packets,0 bytes, 0 unicast,0 broadcast,0 multicast 0 errors,0 drops ----------------------------------------------------PortName Status Weight ----------------------------------------------------Gigabitethernet1/0/0 DOWN 1 Gigabitethernet2/0/0 DOWN 1 ----------------------------------------------------The Number of Ports in Trunk : 2 The Number of UP Ports in Trunk : 0
----End
Configuration File
#
Issue 01 (2011-10-15)
60

sysname RouterA # bfd # interface Eth-Trunk1 ip address 100.1.1.1 255.255.255.0 # interface Gigabitethernet1/0/0 undo shutdown eth-trunk 1 # interface Gigabitethernet2/0/0 undo shutdown eth-trunk 1 # bfd atob bind peer-ip 100.1.1.2 interface Eth-Trunk 1 discriminator local 10 discriminator remote 20 return
2 BFD Configuration

# sysname RouterB # bfd # interface Eth-Trunk1 ip address 100.1.1.2 255.255.255.0 # interface Gigabitethernet1/0/0 undo shutdown eth-trunk 1 # interface Gigabitethernet2/0/0 undo shutdown eth-trunk 1 # bfd btoa bind peer-ip 100.1.1.1 interface Eth-Trunk 1 discriminator local 20 discriminator remote 10 return
2.12.3 Example for Configuring BFD for VPN Routes

This part provides an example for configuring BFD to detect VPN routes.
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/ interface number. On an NE5000E cluster, the interface is numbered in the format of chassis ID/slot number/card number/interface number. This requires the chassis ID to be specified along with the slot number. As shown in Figure 2-8: l l
Issue 01 (2011-10-15)
CE1 and CE2 belong to VPN-A. They access the MPLS backbone network through PE1 and PE2 respectively. GE 1/0/0 of PE1 and GE 1/0/0 of PE2 are bound with VPN-A.
2 BFD Configuration
BFD in asynchronous mode is used to detect the VPN route between PE1 and PE2.
Figure 2-8 Networking for configuring BFD for static routes
Loopback1 1.1.1.1/32
Loopback1 2.2.2.2/32 POS1/0/0 172.1.1.2/24
POS2/0/0 GE1/0/0 172.1.1.1/24 10.1.1.2/24
PE1
P MPLS Backbone AS:100
POS2/0/0 172.2.1.1/24 POS2/0/0 172.2.1.2/24
PE2
GE1/0/0 10.2.1.2/24
GE1/0/0 10.1.1.1/24
GE1/0/0 10.2.1.1/24
CE1 VPN-A AS:65410
CE2 VPN-A AS:65420
Configuration Notes
BFD sessions must be established on the interface of both the local and remote devices.
The configuration roadmap is as follows: 1. 2. Configure a BFD session on PE1 to detect the multi-hop path from PE1 to PE2. Configure a BFD session on PE2 to detect the multi-hop path from PE2 to PE1.
Data Preparation
To complete the configuration, you need the following data: l l l Peer IP address detected by BFD Name of a BFD session Local and remote discriminators of BFD sessions
Procedure
Step 1 # Assign an IP address to interfaces on PE1, PE2, P, CE1, and CE2. The configuration details are not mentioned here. Step 2 Configure the MPLS backbone network to interconnect PE1 and PE2. The configuration details are not mentioned here. Step 3 Configure a VPN instance. The configuration details are not mentioned here.
2 BFD Configuration
Step 4 Configure the route between PE1 and PE2 to be reachable. The configuration details are not mentioned here. After configurations are complete, PE1 can ping through the IP address of GE 1/0/0 on PE2.
<PE1> ping -vpn-instance vpna 10.2.1.2 PING 10.2.1.2: 56 data bytes, press CTRL_C to break Reply from 10.2.1.2: bytes=56 Sequence=1 ttl=254 time=60 Reply from 10.2.1.2: bytes=56 Sequence=2 ttl=254 time=50 Reply from 10.2.1.2: bytes=56 Sequence=3 ttl=254 time=50 Reply from 10.2.1.2: bytes=56 Sequence=4 ttl=254 time=60 Reply from 10.2.1.2: bytes=56 Sequence=5 ttl=254 time=50 --- 10.2.1.2 ping statistics --5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 50/54/60 ms
ms ms ms ms ms
Step 5 Configure BFD to detect the VPN route between PE1 and PE2. # On PE1, enable BFD, establish a BFD session with PE2, and bind the session with the VPN instance.
[~PE1] bfd [~PE1-bfd] quit [~PE1] bfd 1to2_vpn bind [~PE1-bfd-sess-1to2_vpn] [~PE1-bfd-sess-1to2_vpn] [~PE1-bfd-sess-1to2_vpn] [~PE1-bfd-sess-1to2_vpn]
peer-ip 10.2.1.2 vpn-instance vpna discriminator local 12 discriminator remote 21 commit quit
# On PE2, enable BFD, establish a BFD session with PE1, and bind the session with the VPN instance.
[~PE2] bfd [~PE2-bfd] quit [~PE2] bfd 2to1_vpn bind [~PE2-bfd-sess-2to1_vpn] [~PE2-bfd-sess-2to1_vpn] [~PE2-bfd-sess-2to1_vpn] [~PE2-bfd-sess-2to1_vpn]
peer-ip 10.1.1.2 vpn-instance vpna discriminator local 21 discriminator remote 12 commit quit
Step 6 Verify the configuration. After configurations are complete, run the display bfd session peer-ip vpn-instance vpnname verbose command on PE1 and PE2, and you can view that a multi-hop BFD session is established, with the status being Up. # Take the display on PE1 as an example.
<PE1> display bfd session peer-ip 10.2.1.2 vpn-instance vpna verbose -------------------------------------------------------------------------------(Multi Hop) State : Up Name : 1to2_vpn -----------------------------------------------------------------------------Local Discriminator : 12 Remote Discriminator : 21 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Peer Ip Address Bind Session Type : Static Bind Peer IP Address : 10.2.1.2 Bind Interface : Vpn Instance Name : vpna FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 4784 TTL : 255 Proc Interface Status : Disable Process PST : Disable
Issue 01 (2011-10-15)
63
2 BFD Configuration
WTR Interval (ms) : Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : Session Detect TmrID : Session Init TmrID : Session WTR TmrID : PDT Index : FSM-0|RCV-0|IF-0|TOKEN-0 Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
----End
Configuration File
l Configuration file of PE1
# sysname PE1 # ip vpn-instance vpna route-distinguisher 100:1 vpn-target 111:1 export-extcommunity vpn-target 111:1 import-extcommunity # bfd # mpls lsr-id 1.1.1.1 mpls # mpls ldp # interface gigabitethernet1/0/0 undo shutdown ip binding vpn-instance vpna ip address 10.1.1.2 255.255.255.0 # interface Pos2/0/0 undo shutdown link-protocol ppp ip address 172.1.1.1 255.255.255.0 mpls mpls ldp # interface LoopBack1 ip address 1.1.1.1 255.255.255.255 # bgp 100 peer 3.3.3.3 as-number 100 peer 3.3.3.3 connect-interface LoopBack1 # ipv4-family unicast undo synchronization peer 3.3.3.3 enable # ipv4-family vpnv4 policy vpn-target peer 3.3.3.3 enable # ipv4-family vpn-instance vpna peer 10.1.1.1 as-number 65410 import-route direct # ospf 100 area 0.0.0.0 network 1.1.1.1 0.0.0.0 network 172.1.1.0 0.0.0.255 # bfd 1to2_vpn bind peer-ip 10.2.1.2 vpn-instance vpna
Issue 01 (2011-10-15)
64

discriminator local 12 discriminator remote 21 return
2 BFD Configuration
Configuration file of PE2

# sysname PE2 # ip vpn-instance vpna route-distinguisher 200:1 vpn-target 111:1 export-extcommunity vpn-target 111:1 import-extcommunity # bfd # mpls lsr-id 3.3.3.3 mpls # mpls ldp # interface Pos2/0/0 undo shutdown link-protocol ppp ip address 172.2.1.2 255.255.255.0 mpls mpls ldp # interface gigabitethernet1/0/0 undo shutdown ip binding vpn-instance vpna ip address 10.2.1.2 255.255.255.0 # interface LoopBack1 ip address 3.3.3.3 255.255.255.255 # bgp 100 peer 1.1.1.1 as-number 100 peer 1.1.1.1 connect-interface LoopBack1 # ipv4-family unicast undo synchronization peer 1.1.1.1 enable # ipv4-family vpnv4 policy vpn-target peer 1.1.1.1 enable # ipv4-family vpn-instance vpn1 peer 10.2.1.1 as-number 65420 import-route direct # ospf 100 area 0.0.0.0 network 3.3.3.3 0.0.0.0 network 172.2.1.0 0.0.0.255 # bfd 2to1_vpn bind peer-ip 10.1.1.2 vpn-instance vpna discriminator local 21 discriminator remote 12 return
Configuration file of P
# sysname P # mpls lsr-id 2.2.2.2 mpls # mpls ldp #
Issue 01 (2011-10-15)
65

interface Pos1/0/0 undo shutdown link-protocol ppp ip address 172.1.1.2 255.255.255.0 mpls mpls ldp # interface Pos2/0/0 undo shutdown link-protocol ppp ip address 172.2.1.1 255.255.255.0 mpls mpls ldp # interface LoopBack1 ip address 2.2.2.2 255.255.255.255 # ospf 100 area 0.0.0.0 network 172.1.1.0 0.0.0.255 network 172.2.1.0 0.0.0.255 network 2.2.2.2 0.0.0.0 return
2 BFD Configuration
Configuration file of CE1

# sysname CE1 # interface gigabitethernet1/0/0 undo shutdown ip address 10.1.1.1 255.255.255.0 # bgp 65410 peer 10.1.1.2 as-number 100 # ipv4-family unicast import-route direct peer 10.1.1.2 enable return

# sysname CE2 # interface gigabitethernet1/0/0 undo shutdown ip address 10.2.1.1 255.255.255.0 # bgp 65420 peer 10.2.1.2 as-number 100 # ipv4-family unicast import-route direct peer 10.2.1.2 enable return
2.12.4 Example for Configuring Multi-Hop BFD

This part provides examples for configuring multi-hop BFD to fast detect the multi-hop link on the network.
Issue 01 (2011-10-15)
66
2 BFD Configuration
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/ interface number. On an NE5000E cluster, the interface is numbered in the format of chassis ID/slot number/card number/interface number. This requires the chassis ID to be specified along with the slot number. BFD sessions can be established to fast detect and monitor multi-hop links. As shown in Figure 2-9, BFD in asynchronous mode is configured to detect the multi-hop link between Router A and Router C. Figure 2-9 Networking for configuring multi-hop BFD
POS1/0/0 10.1.1.1/24
POS1/0/0 10.1.1.2/24
POS2/0/0 10.2.1.1/24
POS1/0/0 10.2.1.2/24
RouterA
RouterB
RouterC
Configuration Notes
BFD sessions must be established on the interface of both the local and remote devices.
The configuration roadmap is as follows: 1. 2. Configure a BFD session on Router A to detect the multi-hop link from Router A toRouter C. Configure a BFD session on Router C to detect the multi-hop link from Router C toRouter A.
Data Preparation
To complete the configuration, you need the following data: l l l Peer IP address detected by BFD Name of the BFD session for detecting the multi-hop link Local and remote discriminators of BFD sessions
Procedure
Step 1 Configure Router A, Router B, and Router C to be routable. # Assign an IP address to the interface on Router A.
<HUAWEI> system-view
Issue 01 (2011-10-15)
67

[~HUAWEI] sysname RouterA [~HUAWEI] commit [~RouterA] interface pos 1/0/0 [~RouterA-Pos1/0/0] undo shutdown [~RouterA-Pos1/0/0] ip address 10.1.1.1 24 [~RouterA-Pos1/0/0] commit [~RouterA-Pos1/0/0] quit
2 BFD Configuration
# Assign an IP address to the interface on Router B.

<HUAWEI> system-view [~HUAWEI] sysname RouterB [~HUAWEI] commit [~RouterB] interface pos 1/0/0 [~RouterB-Pos1/0/0] undo shutdown [~RouterB-Pos1/0/0] ip address 10.1.1.2 24 [~RouterB-Pos1/0/0] quit [~RouterB] interface pos 2/0/0 [~RouterB-Pos2/0/0] undo shutdown [~RouterB-Pos2/0/0] ip address 10.2.1.1 24 [~RouterB-Pos2/0/0] commit [~RouterB-Pos2/0/0] quit
# Assign an IP address to the interface on Router C.

<HUAWEI> system-view [~HUAWEI] sysname RouterC [~HUAWEI] commit [~RouterC] interface pos 1/0/0 [~RouterC-Pos1/0/0] undo shutdown [~RouterC-Pos1/0/0] ip address 10.2.1.2 24 [~RouterC-Pos1/0/0] commit [~RouterC-Pos1/0/0] quit
# Configure the static routers.

[~RouterA] [~RouterA] [~RouterC] [~RouterC] ip route-static 10.2.1.0 255.255.255.0 10.1.1.2 commit ip route-static 10.1.1.0 255.255.255.0 10.2.1.1 commit
Step 2 Configure BFD to detect the multi-hop link between Router A and Router C. # Enable BFD on Router A and establish a BFD session to detect the link from Router A toRouter C. You do not need to bind the BFD session to an interface.
[~RouterA] bfd [~RouterA-bfd] quit [~RouterA] bfd atoc bind [~RouterA-bfd-sess-atoc] [~RouterA-bfd-sess-atoc] [~RouterA-bfd-sess-atoc] [~RouterA-bfd-sess-atoc]
peer-ip 10.2.1.2 discriminator local 10 discriminator remote 20 commit quit
# Enable BFD on Router C and create a BFD session to detect the link from Router C toRouter A. You do not need to bind the BFD session to an interface.
[~RouterC] bfd [~RouterC-bfd] quit [~RouterC] bfd ctoa bind [~RouterC-bfd-sess-ctoa] [~RouterC-bfd-sess-ctoa] [~RouterC-bfd-sess-ctoa] [~RouterC-bfd-sess-ctoa]
peer-ip 10.1.1.1 discriminator local 20 discriminator remote 10 commit quit
Step 3 Verify the configuration.

2 BFD Configuration
After configurations are complete, run the display bfd session all verbose command on Router A and Router C. You can view that a multi-hop BFD session is established, with the status being Up. # Take the display on Router A as an example.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(Multi Hop) State : Up Name : atoc -----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Peer Ip Address Bind Session Type : Static Bind Peer IP Address : 10.2.1.2 Bind Interface : FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 4784 TTL : 254 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
[~RouterA] interface pos 1/0/0 [~RouterA-Pos1/0/0] shutdown [~RouterA-Pos1/0/0] commit [~RouterA-Pos1/0/0] quit
Run the display bfd session all verbose command on Router A, and you can view that the status of the BFD session is Down. # Take the display on Router A as an example.
-----------------------------------------------------------------------------(Multi Hop) State : Down Name : atoc -----------------------------------------------------------------------------Local Discriminator : 10 Remote Discriminator : 20 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Peer Ip Address Bind Session Type : Static Bind Peer IP Address : 10.2.1.2 Bind Interface : FSM Board Id : 1 TOS-EXP : 6 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 4784 TTL : 254 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : -
Issue 01 (2011-10-15)
69
2 BFD Configuration
Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 0/1
----End
Configuration File
# sysname RouterA # bfd # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 10.1.1.1 255.255.255.0 # ip route-static 10.2.1.0 255.255.255.0 10.1.1.2 # bfd atoc bind peer-ip 10.2.1.2 discriminator local 10 discriminator remote 20 return

# sysname RouterB # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 10.1.1.2 255.255.255.0 # interface pos2/0/0 undo shutdown link-protocol ppp ip address 10.2.1.1 255.255.255.0 return
Configuration file of Router C

# sysname RouterC # bfd # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 10.2.1.2 255.255.255.0 # ip route-static 10.1.1.0 255.255.255.0 10.2.1.1 # bfd ctoa bind peer-ip 10.1.1.1 discriminator local 20 discriminator remote 10 return
2.12.5 Example for Associating a BFD Session with an Interface

In this example, a BFD session is associated with an interface. This triggers rapid route convergence if a fault occurs.
Issue 01 (2011-10-15)
70
2 BFD Configuration
CAUTION
On a single NE5000E, an interface is numbered in the format: slot number/subcard number/ interface number. On an NE5000E cluster, an interface is numbered in the format: chassis ID/ slot number/subcard number/interface number. If the slot number is specified, the chassis ID of the slot must also be specified. On the network shown in Figure 2-10, transmission devices exist on the link between Routers. A BFD session is associated with an interface on the Routers. If the link between GE 1/0/0 on Router A and GE 1/0/0 on Router B fails, the BFD session detects the fault and goes Down. The BFD session status change causes the interface's BFD status change, triggering rapid route convergence. Figure 2-10 Networking diagram for association between a BFD session and an interface
GE1/0/0
GE1/0/0
RouterA
RouterB
The configuration roadmap is as follows: 1. 2. 3. 4. Configure a BFD session on Router A. Configure a BFD session on Router B. Associate the BFD session and an interface on Router A. Associate the BFD session and an interface on Router B.
Configuration Notes
A BFD session needs to be established on the two ends of a link.
Data Preparation
To complete the configuration, you need the following data: l l l Remote IP address of a BFD session IP address of a local interface that sends and receives BFD control packets Local and remote discriminators of a BFD session
Procedure
Step 1 Assign IP addresses to interfaces directly connecting Router A and Router B. # Assign an IP address to the interface on Router A.

<HUAWEI> system-view [~HUAWEI] sysname RouterA [~HUAWEI] commit [~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] undo shutdown [~RouterA-GigabitEthernet1/0/0] ip address 10.1.1.1 24 [~RouterA-GigabitEthernet1/0/0] commit [~RouterA-GigabitEthernet1/0/0] quit
2 BFD Configuration

<HUAWEI> system-view [~HUAWEI] sysname RouterB [~HUAWEI] commit [~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] undo shutdown [~RouterB-GigabitEthernet1/0/0] ip address 10.1.1.2 24 [~RouterB-GigabitEthernet1/0/0] commit [~RouterB-GigabitEthernet1/0/0] quit
After the configuration is complete, Router A and Router B successfully ping each other. Use the display on Router A as an example.
[~RouterA] ping 10.1.1.2 PING 10.1.1.2 : 56 data Reply from 10.1.1.2: Reply from 10.1.1.2: Reply from 10.1.1.2: Reply from 10.1.1.2: Reply from 10.1.1.2: bytes, press CTRL_C bytes=56 Sequence=1 bytes=56 Sequence=2 bytes=56 Sequence=3 bytes=56 Sequence=4 bytes=56 Sequence=5 to break ttl=255 time=3 ttl=255 time=1 ttl=255 time=1 ttl=255 time=1 ttl=255 time=1
ms ms ms ms ms
--- 10.1.1.2 ping statistics --5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/3 ms
Step 2 Configure single-hop BFD. # Enable BFD on Router A, and configure a BFD session between Router A and Router B.
[~RouterA] bfd [~RouterA-bfd] quit [~RouterA] bfd pis bind [~RouterA-bfdsess-pis] discriminator [~RouterA-bfd-sess-pis] [~RouterA-bfd-sess-pis] [~RouterA-bfd-sess-pis]
peer-ip default-ip interface gigabitethernet 1/0/0 local 1 discriminator remote 2 commit quit
# Enable BFD on Router B, and configure a BFD session between Router B and Router A.
[~RouterB] bfd [~RouterB-bfd] quit [~RouterB] bfd pis bind [~RouterB-bfd-sess-pis] [~RouterB-bfd-sess-pis] [~RouterB-bfd-sess-pis] [~RouterB-bfd-sess-pis]
peer-ip default-ip interface gigabitethernet 1/0/0 discriminator local 2 discriminator remote 1 commit quit
# After completing the preceding configurations, run the display bfd session all verbose command on Router A or Router B. A BFD session has been established and its status is Up. Use the display on Router A as an example.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : pis -----------------------------------------------------------------------------Local Discriminator : 2 Remote Discriminator : 1
Issue 01 (2011-10-15)
72
2 BFD Configuration
Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 224.0.0.184 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
Step 3 Associate the BFD session and the interfaces. # Configure Router A.
[~RouterA] bfd pis [~RouterA-bfd-bfd-sess-pis] process-interface-status [~RouterA-bfd-bfd-sess-pis] commit [~RouterA-bfd-bfd-sess-pis] quit
# Configure Router B.
[~RouterB] bfd pis [~RouterB-bfd-bfd-sess-pis] process-interface-status [~RouterB-bfd-bfd-sess-pis] commit [~RouterB-bfd-bfd-sess-pis] quit
Step 4 Verify the configuration. After completing the configuration, run the display bfd session all verbose command on Router A or Router B. The Proc interface status field displays Enable. Use the display on Router A as an example.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : pis -----------------------------------------------------------------------------Local Discriminator : 2 Remote Discriminator : 1 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 224.0.0.184 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Enable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : -
Issue 01 (2011-10-15)
73
2 BFD Configuration
Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
Run the shutdown command on GE 1/0/0 of Router B. The BFD session goes Down.
[~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] shutdown [~RouterB-GigabitEthernet1/0/0] commit [~RouterB-GigabitEthernet1/0/0] quit
Run the display bfd session all verbose and display interface gigabitethernet 1/0/0 commands on Router A. The BFD session is Down, and GE 1/0/0 is Up.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Down Name : pis -----------------------------------------------------------------------------Local Discriminator : 1 Remote Discriminator : 2 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 224.0.0.184 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 2100 Actual Rx Interval (ms): 2100 Local Detect Multi : 3 Detect Interval (ms) : 0 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Enable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : Control Detection Time Expired Bind Application : No Application Bind Session TX TmrID : 2725402068 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 0/1 [~RouterA] display interface gigabitethernet 1/0/0 GigabitEthernet1/0/0 current state : UP Line protocol current state : DOWN (BFD status down) EDescription: HUAWEI, Quidway Series, GigabitEthernet1/0/0 Interface (ifindex: 20, vr: 0) Route Port,The Maximum Transmit Unit is 1500 Internet Address is 10.1.1.2/24 IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 2203-0004-0001 Current BW: 100 Mbits Last physical up time : 2010-07-31 09:35:03 Last physical down time : 2010-08-03 02:58:22 Current system time: 2010-08-03 03:02:48 Statistics last cleared:never Last 300 seconds input rate 0 bits/sec, 4 packets/sec Last 300 seconds output rate 0 bits/sec, 4 packets/sec Input: 0 bytes, 662126 packets Output: 0 bytes, 661789 packets Input: Unicast: 662111 packets, Multicast: 12 packets Broadcast: 3 packets, JumboOctets: 0 packets CRC: 0 packets, Symbol: 0 packets Overrun: 0 packets, InRangeLength: 0 packets LongPacket: 0 packets, Jabber: 0 packets, Alignment: 0 packets Fragment: 0 packets, Undersized Frame: 0 packets RxPause: 0 packets Output:
Issue 01 (2011-10-15)
74

Unicast: 661784 packets, Multicast: 3 packets Broadcast: 2 packets, JumboOctets: 0 packets Lost: 0 packets, Overflow: 0 packets, Underrun: 0 packets System: 0 packets, Overruns: 0 packets TxPause: 0 packets Last 300 seconds input utility rate: 0.00% Last 300 seconds output utility rate: 0.00%
2 BFD Configuration
----End
Configuration Files
# sysname RouterA # bfd # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.1 255.255.255.0 # bfd pis bind peer-ip default-ip interface GigabitEthernet1/0/0 discriminator local 1 discriminator remote 2 process-interface-status return

# sysname RouterB # bfd # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.2 255.255.255.0 # bfd pis bind peer-ip default-ip interface GigabitEthernet1/0/0 discriminator local 2 discriminator remote 1 process-interface-status return
2.12.6 Example for Associating a BFD Session and a Sub-interface

In this example, a BFD session is associated with a sub-interface, improving service reliability on the sub-interface.
CAUTION
On a single NE5000E, an interface is numbered in the format: slot number/subcard number/ interface number. On an NE5000E cluster, an interface is numbered in the format: chassis ID/ slot number/subcard number/interface number. If the slot number is specified, the chassis ID of the slot must also be specified. On the large metro Ethernet network shown in Figure 2-11, a great number of VLAN services are configured on a sub-interface and high reliability is required. A BFD session needs to be
2 BFD Configuration
established to detect the connectivity of the main interface. The BFD session needs to be associated with the sub-interface. This improves service reliability on the sub-interface and saves BFD session resources. Figure 2-11 Networking diagram for association between a BFD session and a sub-interface
GE1/0/0 RouterA
GE1/0/0 RouterB
The configuration roadmap is as follows: 1. 2. 3. 4. Configure a BFD session on Router A. Configure a BFD session on Router B. Associate the BFD session and a sub-interface on Router A. Associate the BFD session and a sub-interface on Router B.
Configuration Notes
Data Preparation
To complete the configuration, you need the following data: l l l IP address of the remote interface on a link to be detected by a BFD session IP address of a local interface that sends and receives BFD control packets Local and remote discriminators of a BFD session
Procedure
Step 1 Assign IP addresses to interfaces on Router A and Router B, and create sub-interfaces. # Configure Router A.
<HUAWEI> system-view [~HUAWEI] sysname RouterA [~HUAWEI] commit [~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] undo shutdown [~RouterA-GigabitEthernet1/0/0] ip address 10.1.1.1 24 [~RouterA-GigabitEthernet1/0/0] quit [~RouterA] interface gigabitethernet 1/0/0.1 [~RouterA-GigabitEthernet1/0/0.1] undo shutdown [~RouterA-GigabitEthernet1/0/0.1] ip address 11.1.1.1 24 [~RouterA-GigabitEthernet1/0/0.1] commit [~RouterA-GigabitEthernet1/0/0.1] quit
<HUAWEI> system-view
Issue 01 (2011-10-15)
76

[~HUAWEI] sysname RouterB [~HUAWEI] commit [~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] undo shutdown [~RouterB-GigabitEthernet1/0/0] ip address 10.1.1.2 24 [~RouterB-GigabitEthernet1/0/0] quit [~RouterB] interface gigabitethernet 1/0/0.1 [~RouterB-GigabitEthernet1/0/0.1] undo shutdown [~RouterB-GigabitEthernet1/0/0.1] ip address 11.1.1.2 24 [~RouterB-GigabitEthernet1/0/0.1] commit [~RouterB-GigabitEthernet1/0/0.1] quit
2 BFD Configuration
Step 2 Configure single-hop BFD. # Configure Router A.

[~RouterA] bfd [~RouterA-bfd] quit [~RouterA] bfd pissub bind peer-ip default-ip interface gigabitethernet 1/0/0 [~RouterA-sess-pissub] discriminator local 1 [~RouterA-sess-pissub] discriminator remote 2 [~RouterA-sess-pissub] commit [~RouterA-sess-pissub] quit
[~RouterB] bfd [~RouterB-bfd] quit [~RouterB] bfd pissub bind peer-ip default-ip interface gigabitethernet 1/0/0 [~RouterB-sess-pissub] discriminator local 2 [~RouterB-sess-pissub] discriminator remote 1 [~RouterB-sess-pissub] commit [~RouterB-sess-pissub] quit
# After completing the preceding configurations, run the display bfd session all verbose command on Router A or Router B. A BFD session has been established and its status is Up. Use the display on Router A as an example.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : pissub --------------------------------------------------------------------------Local Discriminator : 1 Remote Discriminator : 2 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 224.0.0.184 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : Control Detection Time Expired Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
Step 3 Associate the BFD session with the sub-interface. # Configure Router A.

[~RouterA] bfd pissub [~RouterA-sess-pissub] process-interface-status sub-if [~RouterA-sess-pissub] commit [~RouterA-sess-pissub] quit
2 BFD Configuration
[~RouterB] bfd [~RouterB-bfd] quit [~RouterB] bfd pissub [~RouterB-sess-pissub] process-interface-status sub-if [~RouterB-sess-pissub] commit [~RouterB-sess-pissub] quit
Step 4 Verify the configuration. # After completing the configuration, run the display bfd session all verbose command on Router A or Router B. The Proc interface status field displays Enable (Sub-If). Use the display on Router A as an example.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : pissub -----------------------------------------------------------------------------Local Discriminator : 1 Remote Discriminator : 2 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 224.0.0.184 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Enable (Sub-If) Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : Control Detection Time Expired Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
# Run the shutdown command on GE 1/0/0 of Router B. The BFD session goes Down.
[~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] shutdown [~RouterB-GigabitEthernet1/0/0] commit [~RouterB-GigabitEthernet1/0/0] quit
# Run the display bfd session all verbose and display interface gigabitethernet 1/0/0.1 commands on Router A. The BFD session is Down, and GE 1/0/0.1 is Up.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Down Name : pissub -----------------------------------------------------------------------------Local Discriminator : 1 Remote Discriminator : 2 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 224.0.0.184 Bind Interface : GigabitEthernet1/0/0
Issue 01 (2011-10-15)
78
2 BFD Configuration
FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Enable (Sub-If) Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : Control Detection Time Expired Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 0/1 [~RouterA] display interface gigabitethernet 1/0/0.1 GigabitEthernet1/0/0.1 current state : DOWN Line protocol current state : DOWN (Main BFD status down) Description: HUAWEI, Quidway Series, GigabitEthernet1/0/0.1 Interface (ifindex: 33, vr: 0) Route Port,The Maximum Transmit Unit is 1500 Internet Address is 20.1.1.1/24 IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 2202-0004-0002 Current BW: 100 Mbits Current system time: 2010-08-03 16:23:43 Last 300 seconds input rate 0 bits/sec, 0 packets/sec Last 300 seconds output rate 0 bits/sec, 0 packets/sec Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec Input: 0 packets, 0 bytes, 0 unicast, 0 broadcast,0 multicast, 0 errors, 0 drops Output:0 packets, 0 bytes, 0 unicast, 0 broadcast, 0 multicast, 0 errors, 0 drops Last 300 seconds input utility rate: 0.00% Last 300 seconds output utility rate: 0.00%
----End
Configuration Files
# sysname RouterA # bfd # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.1 255.255.255.0 # interface GigabitEthernet1/0/0.1 undo shutdown ip address 11.1.1.1 255.255.255.0 # bfd pissub bind peer-ip default-ip interface GigabitEthernet1/0/0 discriminator local 1 discriminator remote 2 process-interface-status sub-if return

# sysname RouterB
Issue 01 (2011-10-15)
79
2 BFD Configuration
# bfd # interface GigabitEthernet1/0/0 undo shutdown ip address 11.1.1.2 255.255.255.0 # interface GigabitEthernet1/0/0.1 undo shutdown ip address 10.1.1.2 255.255.255.0 # bfd pissub bind peer-ip default-ip interface GigabitEthernet1/0/0 discriminator local 2 discriminator remote 1 process-interface-status sub-if return
2.12.7 Example for Configuring the Delay of a BFD Session to Go Up

By configuring the delay of the BFD session to go Up, you can prevent traffic loss because a routing protocol goes Up later than an interface.
In actual networking, certain devices switch traffic according to whether a BFD session is Up. The routing protocol, however, goes Up later than the interface. Therefore, no route can be found when the traffic is switched back, and the traffic is then discarded. The delay time must be set to compensate for the time difference caused when the routing protocol goes Up later than the interface.
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/ interface number. On an NE5000E cluster, the interface is numbered in the format of chassis ID/slot number/card number/interface number. This requires the chassis ID to be specified along with the slot number. As shown in Figure 2-12, BFD in asynchronous mode is set to detect the direct link between Router A and Router B. Figure 2-12 Networking of configuring the delay of a BFD session to go Up
GE1/0/0 10.1.1.1/24
GE1/0/0 10.1.1.2/24
RouterA
RouterB
The configuration roadmap is as follows:
2 BFD Configuration
1. 2.
Configure a BFD session on Router A to detect the directly connected link from Router A to Router B. Configure a BFD session on Router B to detect the directly connected link fromRouter B to Router A.
Configuration Notes
None.
Data Preparation
To complete the configuration, you need the following data: l l l l l Peer IP address detected by BFD IP address of the local interface that sends and receives BFD control packets Name of a BFD session Local and remote discriminators of BFD sessions Delay of the BFD session to go Up
Procedure
Step 1 Assign IP addresses to the interfaces directly connected Router A to Router B. # Assign an IP address to the interface on Router A.

Step 2 Configure the delay of the BFD session to go Up. # Enable BFD on Router A and configure the delay of the BFD session to go Up in the BFD view. The BFD session going Up is delayed for 120s.
NOTE
To configure the delay of a BFD session to go Up, you need to run the delay-up command only in the BFD view. In this case, this command takes effect on the BFD sessions to be established rather than the existing BFD sessions.
[~RouterA] bfd [~RouterA-bfd] delay-up 120 [~RouterA-bfd] commit [~RouterA-bfd] quit
Issue 01 (2011-10-15)
81
2 BFD Configuration
# Configure BFD on Router A. Take the configuration of single-hop BFD as an example.

[~RouterA] bfd atob bind [~RouterA-bfd-sess-atob] [~RouterA-bfd-sess-atob] [~RouterA-bfd-sess-atob] [~RouterA-bfd-sess-atob] peer-ip 10.1.1.2 interface gigabitethernet 1/0/0 discriminator local 10 discriminator remote 20 commit quit
# # Enable BFD on Router B and configure the delay of the BFD session to go Up in the BFD view, with the delayed time being 120s.
[~RouterB]bfd [~RouterB-bfd] delay-up 120 [~RouterB-bfd] quit
# Configure BFD on Router B. Take the configuration of single-hop BFD as an example.

[~RouterB] bfd btoa bind [~RouterB-bfd-sess-btoa] [~RouterB-bfd-sess-btoa] [~RouterB-bfd-sess-btoa] [~RouterB-bfd-sess-btoa] peer-ip 10.1.1.2 interface gigabitethernet 1/0/0 discriminator local 10 discriminator remote 20 commit quit
Step 3 Verify the configuration. After configurations are complete, run the display bfd statistics command on Router A and Router B. You can view that the information "System Session DelayUp Timer" in the command output, indicating the status of the delay timer. The BFD session going Up is delayed 120s. # Take the display on Router A as an example.
[~RouterA] display bfd statistics Current Display Board Number : Main ; Current Product Register Type: Total Up/Down Session Number : 1/0 Current Session Number : Static session : 1 Dynamic session : 0 E_Dynamic session : 0 STATIC_AUTO session : 0 LDP_LSP session : 0 STATIC_LSP session : 0 TE_TUNNEL session : 0 TE_LSP session : 0 PW session : 0 IP session : 1 VSI PW session : 0 -----------------------------------------------------------------------------PAF/LCS Name Maxnum Minnum Create -----------------------------------------------------------------------------BFD_CFG_NUM 16384 1 1 BFD_IO_SESSION_NUM 2048 1 0 BFD_PER_TUNNEL_CFG_NUM 16 1 0 -----------------------------------------------------------------------------Current Total Used Discriminator Num : 1 -----------------------------------------------------------------------------BFD HAF Information : -----------------------------------------------------------------------------Current HAF Status : Work -----------------------------------------------------------------------------BFD for LSP Information : -----------------------------------------------------------------------------Ability of auto creating BFD session on egress : Disable Period of LSP Ping : 60 -----------------------------------------------------------------------------BFD other Information : -----------------------------------------------------------------------------System Session Delay Up Timer : 120 ------------------------------------------------------------------------------
----End
Issue 01 (2011-10-15)
82
2 BFD Configuration
Configuration File
# sysname RouterA # bfd delay-up 120 # interface gigabitethernet1/0/0 undo shutdown ip address 10.1.1.1 255.255.255.0 # bfd atob bind peer-ip 10.1.1.2 interface gigabitethernet 1/0/0 discriminator local 10 discriminator remote 20 # return

# sysname RouterA # bfd delay-up 120 # interface gigabitethernet1/0/0 undo shutdown ip address 10.1.1.2 255.255.255.0 # bfd btoa bind peer-ip 10.1.1.2 interface gigabitethernet 1/0/0 discriminator local 20 discriminator remote 10 # return
2.12.8 Example for Configuring BFD for VPN Static Routes

In the networking of CE dual-homing, the link fault can be sensed and a static route on a CE that is bound to a BFD session can be refreshed according to the BFD session status. This helps implement the fast convergence of VPN traffic.
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/ interface number. On an NE5000E cluster, the interface is numbered in the format of chassis ID/slot number/card number/interface number. This requires the chassis ID to be specified along with the slot number. As shown in Figure 2-13, CE1 and CE2 belong to VPN A. Two default routes with the next hops as PE1 and PE2 are configured on CE1. Two routes carry out load balancing. The static routes bound to VPN A are configured on PE1 and PE2 respectively. The static routes are imported to BGP. BFD sessions are established between PE1 and CE1, and between PE2 and CE1. Configure BFD for VPN static routes on PE1 and PE2. In the normal situation, the traffic from CE1 to the public network can be forwarded through PE1 and PE2 in the mode of load balancing. If the link
2 BFD Configuration
between CE1 and PE1 or PE2 fails, the static route senses the link fault by tracking BFD session status and then updates the route. Then the traffic is forwarded through another link. Figure 2-13 Networking diagram of configuring BFD for static routes
Loopback1 2.2.2.2/32 AS:100 PE1 PO 100 S1/0/0 .1.1 .1/2 4 PO 100 S1 .1.1 /0/0 POS2/0/0 .2/2 4 100.3.1.1/24 Loopback1 4.4.4.4/32 POS2/0/0 100.3.1.2/24
/0 3/0 GE .2/24 1.1 10.

/0 1/0 24 GE 1.1.1/ 10. GE 10. 2/0/0 2.1 .1/2 4
AS:65410 PE3 GE3/0/0 10.3.1.1/24 VPNA GE1/0/0 10.3.1.2/24 CE2
CE1
VPNA
G 10. E3/0 2.1 .2/2 /0 4
0 /0 2 4 / S1/ PO .2.1.1 00 1 MPLS PE2 Loopback1 backbone 3.3.3.3/32
/0 2 /0 OS .2/24 P 1 .2 . 100
Configuration Notes
None.
The configuration roadmap is as follows: 1. 2. 3. 4. 5. 6. 7. 8. 9.
Issue 01 (2011-10-15)
Configure OSPF between the PEs to implement interworking between the PEs. Establish MPLS LSPs between PEs. Configure VPN instances on PEs and bind PE interfaces connected with the CE to corresponding VPN instances. Enable Multi-protocol Extensions for Interior Border Gateway Protocol (MP IBGP) on PEs to exchange VPN routing information. Configure two default routes with the next hops as PE1 and PE2 respectively on CE1 to implement load balancing between PE1 and PE2. Configure the static route bound to VPN A on PE1 and PE2 and import the static route into BGP. Configure MP EBGP between PE3 and CE2. Configure static BFD sessions with automatically negotiated discriminators between PE1 and CE1, and between PE2 and CE1. Configure BFD for VPN static routes on PE1 and PE2.
2 BFD Configuration
Data Preparation
To complete the configuration, you need the following data: l l l MPLS LSR IDs of the PEs Names of the VPN instances, RDs, and VPN targets on the PEs Local and peer IP addresses of BFD
Procedure
Step 1 Configure IGP on the MPLS backbone network to implement interworking of the backbone network. # Configure PE1.
<HUAWEI> system-view [~HUAWEI] sysname PE1 [~HUAWEI] commit [~PE1] interface loopback 1 [~PE1-LoopBack1] ip address 2.2.2.2 32 [~PE1-LoopBack1] quit [~PE1] interface pos 1/0/0 [~PE1-Pos1/0/0] ip address 100.1.1.1 24 [~PE1-Pos1/0/0] quit [~PE1] interface pos 2/0/0 [~PE1-Pos2/0/0] ip address 100.3.1.1 24 [~PE1-Pos2/0/0] quit [~PE1] ospf [~PE1-ospf-1] area 0 [~PE1-ospf-1-area-0.0.0.0] network 100.1.1.0 0.0.0.255 [~PE1-ospf-1-area-0.0.0.0] network 100.3.1.0 0.0.0.255 [~PE1-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0 [~PE1-ospf-1-area-0.0.0.0] commit [~PE1-ospf-1-area-0.0.0.0] quit [~PE1-ospf-1] quit
Configure PE2.
<HUAWEI> system-view [~HUAWEI] sysname PE2 [~HUAWEI] commit [~PE2] interface loopback 1 [~PE2-LoopBack1] ip address 3.3.3.3 32 [~PE2-LoopBack1] quit [~PE2] interface pos 1/0/0 [~PE2-Pos1/0/0] ip address 100.2.1.1 24 [~PE2-Pos1/0/0] quit [~PE2] interface pos 2/0/0 [~PE2-Pos2/0/0] ip address 100.3.1.2 24 [~PE2-Pos2/0/0] quit [~PE2] ospf [~PE2-ospf-1] area 0 [~PE2-ospf-1-area-0.0.0.0] network 100.2.1.0 0.0.0.255 [~PE2-ospf-1-area-0.0.0.0] network 100.3.1.0 0.0.0.255 [~PE2-ospf-1-area-0.0.0.0] network 3.3.3.3 0.0.0.0 [~PE2-ospf-1-area-0.0.0.0] commit [~PE2-ospf-1-area-0.0.0.0] quit [~PE2-ospf-1] quit
Configure PE3.
<HUAWEI> system-view [~HUAWEI] sysname PE3 [~HUAWEI] commit [~PE3] interface loopback 1 [~PE3-LoopBack1] ip address 4.4.4.4 32 [~PE3-LoopBack1] quit
Issue 01 (2011-10-15)
85

[~PE3] interface pos 1/0/0 [~PE3-Pos1/0/0] ip address [~PE3-Pos1/0/0] quit [~PE3] interface pos 2/0/0 [~PE3-Pos2/0/0] ip address [~PE3-Pos2/0/0] quit [~PE3] ospf [~PE3-ospf-1] area 0 [~PE3-ospf-1-area-0.0.0.0] [~PE3-ospf-1-area-0.0.0.0] [~PE3-ospf-1-area-0.0.0.0] [~PE3-ospf-1-area-0.0.0.0] [~PE3-ospf-1-area-0.0.0.0] [~PE3-ospf-1] quit
2 BFD Configuration
100.1.1.2 24 100.2.1.2 24
network 100.1.1.0 0.0.0.255 network 100.2.1.0 0.0.0.255 network 4.4.4.4 0.0.0.0 commit quit
After the configuration, OSPF neighbor relationship is set up between PE1, PE2, and PE3. Run the display ip routing-table command, and you can view that the PEs learn the loopback1 route from each other. Take the command output on PE1 as an example.
[~PE1] display ip routing-table Route Flags: R - relay, D - download for forwarding -----------------------------------------------------------------------------Routing Tables: _public_ Destinations : 12 Routes : 13 Destination/Mask 2.2.2.2/32 3.3.3.3/32 4.4.4.4/32 127.0.0.0/8 127.0.0.1/32 100.3.1.0/24 100.3.1.1/32 100.3.1.2/32 100.1.1.0/24 100.1.1.1/32 100.1.1.2/32 100.2.1.0/24 Proto Direct OSPF OSPF Direct Direct Direct Direct Direct Direct Direct Direct OSPF OSPF Pre 0 10 10 0 0 0 0 0 0 0 0 10 10 Cost 0 2 2 0 0 0 0 0 0 0 0 2 2 Flags NextHop D D D D D D D D D D D D D 127.0.0.1 100.3.1.2 100.1.1.2 127.0.0.1 127.0.0.1 100.3.1.1 127.0.0.1 100.3.1.2 100.1.1.1 127.0.0.1 100.1.1.2 100.1.1.2 100.3.1.2 Interface InLoopBack0 Pos2/0/0 Pos1/0/0 InLoopBack0 InLoopBack0 Pos2/0/0 InLoopBack0 Pos2/0/0 Pos1/0/0 InLoopBack0 Pos1/0/0 Pos1/0/0 Pos2/0/0
Step 2 Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the MPLS backbone network. # Configure PE1.
[~PE1] mpls lsr-id 2.2.2.2 [~PE1] mpls [~PE1-mpls] quit [~PE1] mpls ldp [~PE1-mpls-ldp] quit [~PE1] interface pos 1/0/0 [~PE1-Pos1/0/0] mpls [~PE1-Pos1/0/0] mpls ldp [~PE1-Pos1/0/0] quit [~PE1] interface pos 2/0/0 [~PE1-Pos2/0/0] mpls [~PE1-Pos2/0/0] mpls ldp [~PE1-Pos2/0/0] commit [~PE1-Pos2/0/0] quit
# Configure PE2.
[~PE2] mpls lsr-id 3.3.3.3 [~PE2] mpls [~PE2-mpls] quit [~PE2] mpls ldp
Issue 01 (2011-10-15)
86

[~PE2-mpls-ldp] quit [~PE2] interface pos 1/0/0 [~PE2-Pos1/0/0] mpls [~PE2-Pos1/0/0] mpls ldp [~PE2-Pos1/0/0] quit [~PE2] interface pos 2/0/0 [~PE2-Pos2/0/0] mpls [~PE2-Pos2/0/0] mpls ldp [~PE2-Pos2/0/0] commit [~PE2-Pos2/0/0] quit
2 BFD Configuration
Configure PE3.
[~PE3] mpls lsr-id 4.4.4.4 [~PE3] mpls [~PE3-mpls] quit [~PE3] mpls ldp [~PE3-mpls-ldp] quit [~PE3] interface pos 1/0/0 [~PE3-Pos1/0/0] mpls [~PE3-Pos1/0/0] mpls ldp [~PE3-Pos1/0/0] quit [~PE3] interfacepos 2/0/0 [~PE3-Pos2/0/0] mpls [~PE3-Pos2/0/0] mpls ldp [~PE3-Pos2/0/0] commit [~PE3-Pos2/0/0] quit
After the preceding configuration, LDP sessions are set up between PEs. Run the display mpls ldp session command. The command output shows that the Status field displays Operational. Take the command output on PE1 as an example.
[~PE1] display mpls ldp session LDP Session(s) in Public Network -----------------------------------------------------------------------------Peer-ID Status LAM SsnRole SsnAge KA-Sent/Rcv -----------------------------------------------------------------------------3.3.3.3:0 Operational DU Passive 000:02:22 572/572 4.4.4.4:0 Operational DU Passive 000:02:21 566/566 -----------------------------------------------------------------------------TOTAL: 2 session(s) Found. LAM : Label Advertisement Mode SsnAge Unit : DDD:HH:MM
Step 3 Configure VPN instances on PEs and configure CEs to access both PEs. # Configure PE1.
[~PE1] ip vpn-instance VPNA [~PE1-vpn-instance-VPNA] route-distinguisher 100:1 [~PE1-vpn-instance-VPNA] vpn-target 111:1 both [~PE1-vpn-instance-VPNA] quit [~PE1] interface gigabitethernet 3/0/0 [~PE1-GigabitEthernet3/0/0] ip binding vpn-instance VPNA [~PE1-GigabitEthernet3/0/0] ip address 10.1.1.2 24 [~PE1-GigabitEthernet3/0/0] commit [~PE1-GigabitEthernet3/0/0] quit
# Configure PE2.
Issue 01 (2011-10-15)
87
2 BFD Configuration
# Configure PE3.
Configure CE1.
[~CE1] interface gigabitethernet 1/0/0 [~CE1-GigabitEthernet1/0/0] ip address 10.1.1.1 24 [~CE1-GigabitEthernet1/0/0] quit [~CE1] interface gigabitethernet 2/0/0 [~CE1-GigabitEthernet2/0/0] ip address 10.2.1.1 24 [~CE1-GigabitEthernet2/0/0] commit [~CE1-GigabitEthernet2/0/0] quit
# Configure CE2.
[~CE2] interface gigabitethernet 1/0/0 [~CE2-GigabitEthernet1/0/0] ip address 10.3.1.2 24 [~CE2-GigabitEthernet1/0/0] commit [~CE2-GigabitEthernet1/0/0] quit
After the configuration, run the display ip vpn-instance verbose command on the PEs to view the configurations of VPN instances. Each PE can ping its connected CE. Take PE1 and CE1 as an example:
[~PE1] display ip vpn-instance verbose Total VPN-Instances configured : 1 VPN-Instance Name and ID : VPNA, 1 Create date : 2008/09/21 12:18:46 Up time : 0 days, 02 hours, 35 minutes and 58 seconds Route Distinguisher : 100:1 Export VPN Targets : 111:1 Import VPN Targets : 111:1 Label policy : label per route The diffserv-mode Information is : uniform The ttl-mode Information is : pipe Interfaces : GigabitEthernet3/0/0 [~PE1] ping -vpn-instance VPNA 10.1.1.1 PING 10.1.1.1: 56 data bytes, press CTRL_C to break Reply from 10.1.1.1: bytes=56 Sequence=1 ttl=255 time=130 ms Reply from 10.1.1.1: bytes=56 Sequence=2 ttl=255 time=60 ms Reply from 10.1.1.1: bytes=56 Sequence=3 ttl=255 time=40 ms Reply from 10.1.1.1: bytes=56 Sequence=4 ttl=255 time=30 ms Reply from 10.1.1.1: bytes=56 Sequence=5 ttl=255 time=30 ms --- 10.1.1.1 ping statistics --5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 30/58/130 ms
Step 4 Import the VPN route between PE1, PE2, and CE1. Configure two default routes with the next hops as PE1 and PE2 respectively on CE1 to implement load balancing between PE1 and PE2. Configure the static routes bound to VPN instances on PE1 and PE2 and import the static routes into BGP. # Configure CE1.

[~CE1] [~CE1] [~CE1] [~CE1] load-balance packet all ip route-static 0.0.0.0 0 10.1.1.2 ip route-static 0.0.0.0 0 10.2.1.2 commit
2 BFD Configuration
# Configure PE1.
[~PE1] ip route-static vpn-instance VPNA 1.1.1.1 32 10.1.1.1 [~PE1] bgp 100 [~PE1-bgp] ipv4-family vpn-instance VPNA [~PE1-bgp-VPNA] import-route direct [~PE1-bgp-VPNA] import-route static [~PE1-bgp-VPNA] commit [~PE1-bgp-VPNA] quit
# Configure PE2.
[~PE2] ip route-static vpn-instance VPNA 1.1.1.1 32 10.2.1.1 [~PE2] bgp 100 [~PE2-bgp] ipv4-family vpn-instance VPNA [~PE2-bgp-VPNA] import-route direct [~PE2-bgp-VPNA] import-route static [~PE2-bgp-VPNA] commit [~PE2-bgp-VPNA] quit
Step 5 Set up the EBGP peer relationship between PE3 and CE2. Import VPN routes to EBGP. # Configure CE2.
[~CE2] bgp 65410 [~CE2-bgp] peer 10.3.1.1 as-number 100 [~CE2-bgp] import-route direct [~CE2-bgp] commit [~CE2] quit
# Configure PE3. Configure the number of routes carrying out load balancing to 2 on PE3.
[~PE3] bgp 100 [~PE3-bgp] ipv4-family vpn-instance VPNA [~PE3-bgp-VPNA] peer 10.3.1.2 as-number 65410 [~PE3-bgp-VPNA] import-route direct [~PE3-bgp-VPNA] maximum load-balancing 2 [~PE3-bgp-VPNA] commit [~PE3-bgp-VPNA] quit
Step 6 Set up MP-IBGP peer relationships between PEs. # Configure PE1.

[~PE1] bgp 100 [~PE1-bgp] peer 3.3.3.3 as-number 100 [~PE1-bgp] peer 3.3.3.3 connect-interface loopback 1 [~PE1-bgp] peer 4.4.4.4 as-number 100 [~PE1-bgp] peer 4.4.4.4 connect-interface loopback 1 [~PE1-bgp] ipv4-family vpnv4 [~PE1-bgp-af-vpnv4] peer 3.3.3.3 enable [~PE1-bgp-af-vpnv4] peer 4.4.4.4 enable [~PE1-bgp-af-vpnv4] commit [~PE1-bgp-af-vpnv4] quit [~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100 [~PE2-bgp] peer 2.2.2.2 as-number 100 [~PE2-bgp] peer 2.2.2.2 connect-interface loopback 1 [~PE2-bgp] peer 4.4.4.4 as-number 100 [~PE2-bgp] peer 4.4.4.4 connect-interface loopback 1 [~PE2-bgp] ipv4-family vpnv4 [~PE2-bgp-af-vpnv4] peer 2.2.2.2 enable
Issue 01 (2011-10-15)
89

[~PE2-bgp-af-vpnv4] peer 4.4.4.4 enable [~PE2-bgp-af-vpnv4] commit [~PE2-bgp-af-vpnv4] quit [~PE2-bgp] quit
2 BFD Configuration
# Configure PE3.
[~PE3] bgp 100 [~PE3-bgp] peer 2.2.2.2 as-number 100 [~PE3-bgp] peer 2.2.2.2 connect-interface loopback 1 [~PE3-bgp] peer 3.3.3.3 as-number 100 [~PE3-bgp] peer 3.3.3.3 connect-interface loopback 1 [~PE3-bgp] ipv4-family vpnv4 [~PE3-bgp-af-vpnv4] peer 2.2.2.2 enable [~PE3-bgp-af-vpnv4] peer 3.3.3.3 enable [~PE3-bgp-af-vpnv4] commit [~PE3-bgp-af-vpnv4] quit [~PE3-bgp] quit
After the configuration, run the display bgp peer command on the PEs, and you can view that the peer relationship is set up between the PEs and the status of the peer relationship is "Established."
[~PE1] display bgp peer BGP local router ID : 2.2.2.2 Local AS number : 100 Total number of peers : 2 Peer 4.4.4.4 3.3.3.3 V 4 4 AS 100 100 MsgRcvd 205 197 MsgSent 202 254
Peers in established state : 2 OutQ Up/Down State PrefRcv 0 0
0 03:05:25 Established 0 03:06:54 Established
Step 7 Establish a static BFD session with automatically-negotiated discriminators. Set up the BFD sessions between CE1 and PE1, and between CE1 and PE2. # Configure PE1.
[~PE1] bfd [~PE1-bfd] quit [~PE1] bfd pe1_to_ce1 bind peer-ip 10.1.1.1 vpn-instance VPNA interface gigabitethernet 3/0/0 source-ip 10.1.1.2 auto [~PE1-bfd-sess-pe1_to_ce1] commit [~PE1-bfd-sess-pe1_to_ce1] quit
# Configure PE2.
[~PE2] bfd [~PE2-bfd] quit [~PE2] bfd pe2_to_ce1 bind peer-ip 10.2.1.1 vpn-instance VPNA interface gigabitethernet 3/0/0 source-ip 10.2.1.2 auto [~PE2-bfd-sess-pe2_to_ce1] commit [~PE2-bfd-sess-pe2_to_ce1] quit
# Configure CE1.
[~CE1] bfd [~CE1-bfd] quit [~CE1] bfd ce1_to_pe1 bind ip 10.1.1.1 auto [~CE1-bfd-sess-ce1_to_pe1] [~CE1] bfd ce1_to_pe2 bind -ip 10.2.1.1 auto [~CE1-bfd-sess-ce1_to_pe2] [~CE1-bfd-sess-ce1_to_pe2]
peer-ip 10.1.1.2 interface gigabitethernet 1/0/0 sourcequit peer-ip 10.2.1.2 interface gigabitethernet 2/0/0 source commit quit
After the configuration, run the display bfd session all verbose command on PEs and CEs, and you can view that a single-hop static auto-negotiation BFD session is set up, and the session
2 BFD Configuration
status is Up. The local and remote IDs of the BFD session are obtained through auto-negotiation. Take PE1 and CE1 as an example: # The display on PE1 is as follows:
[~PE1] display bfd session all verbose -------------------------------------------------------------------------------(One Hop) State : Up Name : pe1_to_ce1 -------------------------------------------------------------------------------Local Discriminator : 8193 Remote Discriminator : 8193 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet3/0/0) Bind Session Type : Static_Auto Bind Peer IP Address : 10.1.1.1 Bind Interface : GigabitEthernet3/0/0 Bind Source IP Address : 10.1.1.2 Vpn Instance Name : VPNA FSM Board Id : 3 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 254 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : AUTO Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -------------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
# The display on CE1 is as follows:

[~CE1] display bfd session all verbose -------------------------------------------------------------------------------(One Hop) State : Up Name : ce1_to_pe1 -------------------------------------------------------------------------------Local Discriminator : 8192 Remote Discriminator : 8192 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static_Auto Bind Peer IP Address : 10.1.1.2 Bind Interface : GigabitEthernet1/0/0 Bind Source IP Address : 10.1.1.1 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : AUTO Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : --------------------------------------------------------------------------------------------------------------------------------------------------------------(One Hop) State : Up Name : ce1_to_pe2 -------------------------------------------------------------------------------Local Discriminator : 8193 Remote Discriminator : 8193 Session Detect Mode : Asynchronous Mode Without Echo Function
Issue 01 (2011-10-15)
91
2 BFD Configuration
BFD Bind Type : Interface(GigabitEthernet2/0/0) Bind Session Type : Static_Auto Bind Peer IP Address : 10.2.1.2 Bind Interface : GigabitEthernet2/0/0 Bind Source IP Address : 10.2.1.1 FSM Board Id : 2 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : AUTO Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -------------------------------------------------------------------------------Total UP/DOWN Session Number : 2/0
Step 8 Configure BFD for VPN static routes on PEs. # Configure PE1.
[~PE1] ip route-static vpn-instance VPNA 1.1.1.1 255.255.255.255 10.1.1.1 track bfdsession pe1_to_ce1 [~PE1] commit
# Configure PE2.
[~PE2] ip route-static vpn-instance VPNA 1.1.1.1 255.255.255.255 10.2.1.1 track bfdsession pe2_to_ce1 [~PE2] commit
Step 9 Verify the configuration. # Check the VPN routing table on PEs. The result shows that the static route exists in the routing table of each PE.
[~PE1] display ip routing-table vpn-instance VPNA Route Flags: R - relay, D - download for forwarding -----------------------------------------------------------------------------Routing Tables: VPNA Destinations : 5 Routes : 5 Destination/Mask Proto Pre 60 0 0 255 255 Cost 0 0 0 0 0 Flags NextHop RD D D RD RD 10.1.1.1 10.1.1.2 127.0.0.1 3.3.3.3 4.4.4.4 InLoopBack0 Pos2/0/0 Pos1/0/0 Interface
1.1.1.1/32 Static GigabitEthernet3/0/0 10.1.1.0/24 Direct GigabitEthernet3/0/0 10.1.1.2/32 Direct 10.2.1.0/24 BGP 10.3.1.0/24 BGP
# On CE1, check the gateway through which the packets destined for CE2 pass. You can view that load balancing is carried out between PE1 and PE2 at the first hop.
[~CE1] tracert traceroute to 1 10.1.1.2 20 2 10.3.1.1 40 3 10.3.1.2 80 10.3.1.2 10.3.1.2(10.3.1.2) 30 hops max,40 bytes packet ms 10.2.1.2 1 ms 10.1.1.2 40 ms ms 30 ms 50 ms ms 80 ms 60 ms
Issue 01 (2011-10-15)
92
2 BFD Configuration
# Check the routing table of PE3. You can find that there are two routes to PE1 (1.1.1.1) with the next hops as 3.3.3.3 and 2.2.2.2 respectively. The two routes carry out load balancing for BGP routes.
[~PE3] display ip routing-table vpn-instance VPNA Route Flags: R - relay, D - download for forwarding -----------------------------------------------------------------------------Routing Tables: VPNA Destinations : 5 Routes : 6 Destination/Mask 1.1.1.1/32 Proto BGP BGP BGP BGP Direct Pre 255 255 255 255 0 Cost 0 0 0 0 0 0 Flags NextHop RD RD RD RD D D 3.3.3.3 2.2.2.2 2.2.2.2 3.3.3.3 10.3.1.1 127.0.0.1 Interface Pos2/0/0 Pos1/0/0 Pos1/0/0 Pos2/0/0 InLoopBack0
10.1.1.0/24 10.2.1.0/24 10.3.1.0/24 GigabitEthernet3/0/0 10.3.1.1/32 Direct 0
# On CE2, check the traffic destined for CE1, and you can find that load balancing is performed when the traffic leaves PE3.
[~CE2] tracert 1.1.1.1 traceroute to 1.1.1.1(1.1.1.1) 30 hops max,40 bytes packet 1 10.3.1.1 9 ms 2 ms 2 ms 2 10.2.1.2 < AS=100 > 6 ms 5 ms 2 ms 3 10.2.1.1 < AS=100 > 6 ms 6 ms 5 ms
# Run the shutdown command on GE 1/0/0 of GE1 to simulate a link fault.

[~CE1-GigabitEthernet1/0/0] shutdown [~CE1-GigabitEthernet1/0/0] commit [~CE1-GigabitEthernet1/0/0] quit
# The status of the BFD session on PE1 becomes Down.

[~PE1] display bfd session all verbose -------------------------------------------------------------------------------(One Hop) State : Down Name : pe1_to_ce1 -------------------------------------------------------------------------------Local Discriminator : 8192 Remote Discriminator : 8192 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet3/0/0) Bind Session Type : Static_Auto Bind Peer IP Address : 10.1.1.1 Bind Interface : GigabitEthernet3/0/0 Bind Source IP Address : 10.1.1.2 FSM Board Id : 3 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : AUTO Session TX TmrID : 2584985432 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -------------------------------------------------------------------------------Total UP/DOWN Session Number : 0/1
# Check the VPN routing table on PE1, and you can find that the next hop of the route destined for CE1 is only PE2.
2 BFD Configuration
[~PE1] display ip routing-table vpn-instance VPNA Route Flags: R - relay, D - download for forwarding -----------------------------------------------------------------------------Routing Tables: VPNA Destinations : 3 Routes : 3 Destination/Mask Proto Pre Cost 0 0 Flags NextHop RD 3.3.3.3 RD 3.3.3.3 RD 4.4.4.4 Interface Pos2/0/0 Pos2/0/0 Pos1/0/0
1.1.1.1/32 BGP 255 0 10.2.1.0/24 BGP 255 10.3.1.0/24 BGP 255
# On CE1, check the gateway through which the packets destined for CE2 pass. You can view that load balancing is not carried out between PE1 and PE2 at the first hop, and the traffic flows only through PE2.
[~CE1] tracert 10.3.1.2 traceroute to 10.3.1.2(10.3.1.2) 30 hops max,40 bytes packet 1 10.2.1.2 50 ms 30 ms 10 ms 2 10.3.1.1 110 ms 70 ms 90 ms 3 10.3.1.2 60 ms 70 ms 80 ms
# Check the routing table on PE3. You can view that there is only one route to CE1 (1.1.1.1) with the next hop as PE1 (3.3.3.3).
[~PE3] display ip routing-table vpn-instance VPNA Route Flags: R - relay, D - download for forwarding -----------------------------------------------------------------------------Routing Tables: VPNA Destinations : 4 Routes : 4 Destination/Mask Proto Pre 255 255 0 0 Cost 0 0 0 0 Flags NextHop RD RD D D 3.3.3.3 3.3.3.3 10.3.1.1 127.0.0.1 Interface Pos2/0/0 Pos2/0/0 InLoopBack0
1.1.1.1/32 BGP 10.2.1.0/24 BGP 10.3.1.0/24 Direct GigabitEthernet3/0/0 10.3.1.1/32 Direct
# On CE2, check the traffic destined for CE1, and you can find that the traffic is forwarded through POS 2/0/0 (10.2.1.2) after the traffic leaves PE3.
[~CE2] tracert 1.1.1.1 traceroute to 1.1.1.1(1.1.1.1) 30 hops max,40 bytes packet 1 10.3.1.1 9 ms 2 ms 2 ms 2 10.2.1.2 < AS=100 > 6 ms 5 ms 5 ms 3 10.2.1.1 < AS=100 > 6 ms 5 ms 5 ms
Use a tester to generate traffic, and traffic is forwarded through load balancing. After a link between CE1 and PE1 or a link between CE1 and PE2 fails, you can find that the service switchover time is less than 50 ms. ----End
Configuration File
l Configuration file of PE1
# # sysname PE1 # ip vpn-instance VPNA route-distinguisher 100:1 vpn-target 111:1 export-extcommunity vpn-target 111:1 import-extcommunity #
Issue 01 (2011-10-15)
94
2 BFD Configuration
bfd # mpls lsr-id 2.2.2.2 mpls # mpls ldp # interface GigabitEthernet3/0/0 undo shutdown ip binding vpn-instance VPNA ip address 10.1.1.2 255.255.255.0 # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 100.1.1.1 255.255.255.0 mpls mpls ldp # interface Pos2/0/0 undo shutdown link-protocol ppp ip address 100.3.1.1 255.255.255.0 mpls mpls ldp # interface LoopBack1 ip address 2.2.2.2 255.255.255.255 # bgp 100 peer 4.4.4.4 as-number 100 peer 4.4.4.4 connect-interface LoopBack1 peer 3.3.3.3 as-number 100 peer 3.3.3.3 connect-interface LoopBack1 # ipv4-family unicast undo synchronization peer 4.4.4.4 enable peer 3.3.3.3 enable # ipv4-family vpnv4 policy vpn-target peer 3.3.3.3 enable peer 4.4.4.4 enable # ipv4-family vpn-instance VPNA import-route direct import-route static # ospf 1 area 0.0.0.0 network 100.1.1.0 0.0.0.255 network 100.3.1.0 0.0.0.255 network 2.2.2.2 0.0.0.0 # ip route-static vpn-instance VPNA 1.1.1.1 255.255.255.255 10.1.1.1 track bfdsession pe1_to_ce1 # bfd pe1_to_ce1 bind peer-ip 10.1.1.1 vpn-instance VPNA interface GigabitEthernet3/0/0 source-ip 10.1.1.2 auto # return

# sysname PE2 # ip vpn-instance VPNA route-distinguisher 100:2 vpn-target 111:1 export-extcommunity
Issue 01 (2011-10-15)
95
2 BFD Configuration
vpn-target 111:1 import-extcommunity # bfd # mpls lsr-id 3.3.3.3 mpls # mpls ldp # interface GigabitEthernet3/0/0 undo shutdown ip binding vpn-instance VPNA ip address 10.2.1.2 255.255.255.0 # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 100.2.1.1 255.255.255.0 mpls mpls ldp # interface Pos2/0/0 undo shutdown link-protocol ppp ip address 100.3.1.2 255.255.255.0 mpls mpls ldp # interface LoopBack1 ip address 3.3.3.3 255.255.255.255 # bgp 100 peer 4.4.4.4 as-number 100 peer 4.4.4.4 connect-interface LoopBack1 peer 2.2.2.2 as-number 100 peer 2.2.2.2 connect-interface LoopBack1 # ipv4-family unicast undo synchronization peer 4.4.4.4 enable peer 2.2.2.2 enable # ipv4-family vpnv4 policy vpn-target peer 2.2.2.2 enable peer 4.4.4.4 enable # ipv4-family vpn-instance VPNA import-route direct import-route static # ospf 1 area 0.0.0.0 network 100.3.1.0 0.0.0.255 network 100.2.1.0 0.0.0.255 network 3.3.3.3 0.0.0.0 # ip route-static vpn-instance VPNA 1.1.1.1 255.255.255.255 10.2.1.1 track bfdsession pe2_to_ce1 # bfd pe2_to_ce1 bind peer-ip 10.2.1.1 vpn-instance VPNA interface GigabitEthernet3/0/0 source-ip 10.2.1.2 auto # return

# sysname PE3 # ip vpn-instance VPNA
Issue 01 (2011-10-15)
96

route-distinguisher 100:3 vpn-target 111:1 export-extcommunity vpn-target 111:1 import-extcommunity # mpls lsr-id 4.4.4.4 mpls # mpls ldp # interface GigabitEthernet3/0/0 undo shutdown ip binding vpn-instance VPNA ip address 10.3.1.1 255.255.255.0 # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 100.1.1.2 255.255.255.0 mpls mpls ldp # interface Pos2/0/0 undo shutdown link-protocol ppp ip address 100.2.1.2 255.255.255.0 mpls mpls ldp # interface LoopBack1 ip address 4.4.4.4 255.255.255.255 # bgp 100 peer 2.2.2.2 as-number 100 peer 2.2.2.2 connect-interface LoopBack1 peer 3.3.3.3 as-number 100 peer 3.3.3.3 connect-interface LoopBack1 # ipv4-family unicast peer 2.2.2.2 enable peer 3.3.3.3 enable # ipv4-family vpnv4 policy vpn-target peer 2.2.2.2 enable peer 3.3.3.3 enable # ipv4-family vpn-instance VPNA peer 10.3.1.2 as-number 65410 import-route direct maximum load-balancing 2 # ospf 1 area 0.0.0.0 network 100.1.1.0 0.0.0.255 network 100.2.1.0 0.0.0.255 network 4.4.4.4 0.0.0.0 # return
2 BFD Configuration

# sysname CE1 # bfd # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.1 255.255.255.0 # interface GigabitEthernet2/0/0
Issue 01 (2011-10-15)
97
2 BFD Configuration
undo shutdown ip address 10.2.1.1 255.255.255.0 # interface LoopBack1 ip address 1.1.1.1 255.255.255.255 # load-balance packet all # ip route-static 0.0.0.0 0.0.0.0 10.1.1.2 ip route-static 0.0.0.0 0.0.0.0 10.2.1.2 # bfd ce1_to_pe1 bind peer-ip 10.1.1.2 interface GigabitEthernet1/0/0 source-ip 10.1.1.1 auto # bfd ce1_to_pe2 bind peer-ip 10.2.1.2 interface GigabitEthernet2/0/0 source-ip 10.2.1.1 auto # return

# sysname CE2 # interface GigabitEthernet1/0/0 undo shutdown ip address 10.3.1.2 255.255.255.0 # bgp 65410 peer 10.3.1.1 as-number 100 # ipv4-family unicast undo synchronization import-route direct peer 10.3.1.1 enable # return
2.12.9 Example for Enabling a BFD Session to Modify the PST

In this example, a BFD session is enabled to modify the PST if a link fault occurs. This triggers an upper-layer protocol to switch traffic to a backup link.
CAUTION
On a single NE5000E, an interface is numbered in the format: slot number/subcard number/ interface number. On an NE5000E cluster, an interface is numbered in the format: chassis ID/ slot number/subcard number/interface number. If the slot number is specified, the chassis ID of the slot must also be specified. If BFD and IP FRR or LDP FRR are deployed together, a BFD session must be able to modify the PST if a fault occurs. On the network shown in Figure 2-14, a BFD session in asynchronous mode is set up to detect faults in the direct link between Router A and Router B.
Issue 01 (2011-10-15)
98
2 BFD Configuration
Figure 2-14 Networking diagram for enabling a BFD session to modify the PST
GE1/0/0 10.1.1.1/24
GE1/0/0 10.1.1.2/24
RouterA
RouterB
Configuration Notes
The configuration roadmap is as follows: 1. 2. Enable BFD globally on Router A and Router B. Create a single-hop BFD session and bind the session to outbound interfaces on Router A and Router B.
Data Preparation
To complete the configuration, you need the following data: l l l Remote IP address of a BFD session Local and remote discriminators of a BFD session BFD session name
Procedure
Step 1 Assign IP addresses to interfaces directly connecting Router A and Router B. # Configure Router A.
<RouterA> ping 10.1.1.2
Issue 01 (2011-10-15)
99

PING 10.1.1.2 : 56 data Reply from 10.1.1.2: Reply from 10.1.1.2: Reply from 10.1.1.2: Reply from 10.1.1.2: Reply from 10.1.1.2: bytes, press CTRL_C bytes=56 Sequence=1 bytes=56 Sequence=2 bytes=56 Sequence=3 bytes=56 Sequence=4 bytes=56 Sequence=5 to break ttl=255 time=3 ttl=255 time=1 ttl=255 time=1 ttl=255 time=1 ttl=255 time=1
2 BFD Configuration
ms ms ms ms ms
--- 10.1.1.2 ping statistics --5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/3 ms
Step 2 Configure single-hop BFD. # Configure Router A.

[~RouterA] bfd [~RouterA-bfd] quit [~RouterA] bfd pst bind peer-ip 10.1.1.2 interface gigabitethernet 1/0/0 [~RouterA-sess-pst] discriminator local 1 [~RouterA-sess-pst] discriminator remote 2 [~RouterA-sess-pst] commit [~RouterA-sess-pst] quit
[~RouterB] bfd [~RouterB-bfd] quit [~RouterB] bfd pst bind peer-ip 10.1.1.1 interface gigabitethernet 1/0/0 [~RouterB-sess-pst] discriminator local 2 [~RouterB-sess-pst] discriminator remote 1 [~RouterB-sess-pst] commit [~RouterB-sess-pst] quit
After completing the preceding configurations, run the display bfd session all verbose command on Router A or Router B. A single-hop BFD session has been established and its status is Up. Use the display on Router B as an example.
[~RouterB] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : pst -----------------------------------------------------------------------------Local Discriminator : 2 Remote Discriminator : 1 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 10.1.1.1 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
Step 3 Enable the BFD to modify the PST on Router A and Router B.
2 BFD Configuration
# Configure Router A.
[~RouterA] bfd pst [~RouterA-sess-pst] process-pst [~RouterA-sess-pst] commit [~RouterA-sess-pst] quit
[~RouterB] bfd pst [~RouterB-sess-pst] process-pst [~RouterB-sess-pst] commit [~RouterB-sess-pst] quit
Step 4 Verify the configuration. After completing the configuration, run the display bfd session all verbose command on Router A or Router B. The Process PST field displays Enable. Use the display on Router B as an example.
[~RouterB] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : pst -----------------------------------------------------------------------------Local Discriminator : 2 Remote Discriminator : 1 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 10.1.1.1 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Enable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
----End
Configuration Files
# sysname RouterA # bfd # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.1 255.255.255.0 # bfd pst bind peer-ip 10.1.1.2 interface GigabitEthernet1/0/0 discriminator local 1 discriminator remote 2
Issue 01 (2011-10-15)
101

process-pst return
2 BFD Configuration

# sysname RouterB # bfd # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.2 255.255.255.0 # bfd pst bind peer-ip 10.1.1.1 interface GigabitEthernet1/0/0 discriminator local 2 discriminator remote 1 process-pst return
2.12.10 Example for Configuring Single-hop BFD for IPv6

In this example, BFD for IPv6 is configured to detect faults in a single-hop IPv6 link on a network.
CAUTION
On a single NE5000E, an interface is numbered in the format: slot number/subcard number/ interface number. On an NE5000E cluster, an interface is numbered in the format: chassis ID/ slot number/subcard number/interface number. If the slot number is specified, the chassis ID of the slot must also be specified. A BFD session for IPv6 is established to rapidly detect faults in IPv6 links on a network. On the network shown in Figure 2-15, a BFD session in asynchronous mode is set up to detect faults in the direct link between Router A and Router B. Figure 2-15 Networking diagram of single-hop BFD for IPv6
RouterA GE1/0/0 2001::1/64 GE1/0/0 2001::2/64
RouterB
Configuration Notes
A BFD session for IPv6 needs to be established on the two ends of a link.
2 BFD Configuration
1. 2.
Enable BFD globally on Router A and Router B. Create a single-hop BFD session and bind the session to outbound interfaces on Router A and Router B.
Data Preparation
To complete the configuration, you need the following data: l l l Remote IPv6 address of the link to be detected by a BFD session Local and remote discriminators of a BFD session BFD session name
Procedure
Step 1 Assign IP addresses to interfaces directly connecting Router A and Router B. # Assign an IPv6 address to the interface on Router A.
<HUAWEI> system-view [~HUAWEI] sysname RouterA [~HUAWEI] commit [~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] undo shutdown [~RouterA-GigabitEthernet1/0/0] ipv6 enable [~RouterA-GigabitEthernet1/0/0] ipv6 address 2001::1 64 [~RouterA-GigabitEthernet1/0/0] commit [~RouterA-GigabitEthernet1/0/0] quit
# Assign an IPv6 address to the interface on Router B.

<HUAWEI> system-view [~HUAWEI] sysname RouterB [~HUAWEI] commit [~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] undo shutdown [~RouterB-GigabitEthernet1/0/0] ipv6 enable [~RouterB-GigabitEthernet1/0/0] ipv6 address 2001::2 64 [~RouterB-GigabitEthernet1/0/0] commit [~RouterB-GigabitEthernet1/0/0] quit
[~RouterA] ping ipv6 2001::2 PING 2001::2 : 56 data bytes, press Reply from 2001::2 bytes=56 Sequence=1 hop limit=64 Reply from 2001::2 bytes=56 Sequence=2 hop limit=64 Reply from 2001::2 bytes=56 Sequence=3 hop limit=64 Reply from 2001::2 bytes=56 Sequence=4 hop limit=64 Reply from 2001::2 bytes=56 Sequence=5 hop limit=64 ---2001::2 ping statistics--5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max=1/1/3 ms CTRL_C to break time=3 ms time=1 ms time=1 ms time=1 ms time=1 ms
Step 2 Configure a single-hop BFD session. # Configure Router A.

2 BFD Configuration
[~RouterA] bfd [~RouterA-bfd] quit [~RouterA] bfd ipv6session bind peer-ipv6 2001::2 interface gigabitethernet 1/0/0 [~RouterA-sess-ipv6session] discriminator local 1 [~RouterA-sess-ipv6session] discriminator remote 2 [~RouterA-sess-ipv6session] commit [~RouterA-sess-ipv6session] quit
[~RouterB] bfd [~RouterB-bfd] quit [~RouterB] bfd ipv6session bind peer-ipv6 2001::1 interface gigabitethernet 1/0/0 [~RouterB-sess-ipv6session] discriminator local 2 [~RouterB-sess-ipv6session] discriminator remote 1 [~RouterB-sess-ipv6session] commit [~RouterB-sess-ipv6session] quit
Step 3 Verify the configuration. After the preceding configurations are complete, run the display bfd session all verbose command on Router A or Router B. A single-hop BFD session has been established and its status is Up. Use the display on Router A as an example.
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(One Hop) State : Up Name : ipv6session -----------------------------------------------------------------------------Local Discriminator : 1 Remote Discriminator : 2 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Interface(GigabitEthernet1/0/0) Bind Session Type : Static Bind Peer IP Address : 2001::2 Bind Interface : GigabitEthernet1/0/0 FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 3784 TTL : 255 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 0 Session Detect TmrID : 0 Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
----End
Configuration Files
# sysname RouterA # bfd # interface GigabitEthernet1/0/0 undo shutdown ipv6 enable ipv6 address 2001::1/64 #
Issue 01 (2011-10-15)
104
2 BFD Configuration
bfd ipv6session bind peer-ipv6 2001::2 interface GigabitEthernet1/0/0 discriminator local 1 discriminator remote 2 return

# sysname RouterB # bfd # interface GigabitEthernet1/0/0 undo shutdown ipv6 enable ipv6 address 2001::2/64 # bfd ipv6session bind peer-ipv6 2001::1 interface GigabitEthernet1/0/0 discriminator local 2 discriminator remote 1 return
2.12.11 Example for Configuring Multi-hop BFD for IPv6

In this example, multi-hop BFD for IPv6 is configured to detect faults in a multi-hop IPv6 link on a network.
CAUTION
On a single NE5000E, an interface is numbered in the format: slot number/subcard number/ interface number. On an NE5000E cluster, an interface is numbered in the format: chassis ID/ slot number/subcard number/interface number. If the slot number is specified, the chassis ID of the slot must also be specified. A BFD session for IPv6 is established to rapidly detect faults in IPv6 links on a network. On the network shown in Figure 2-16, a BFD session in asynchronous mode is set up to detect faults in the direct link between Router A and Router C. Figure 2-16 Networking diagram for multi-hop BFD for IPv6
GE1/0/0 2001::1/64 RouterA
GE1/0/0 2001::2/64 RouterB
GE2/0/0 GE2/0/0 2002::1/64 2002::2/64 RouterC
Configuration Notes
A BFD session for IPv6 needs to be established on the two ends of a link.
Issue 01 (2011-10-15)
105
2 BFD Configuration
The configuration roadmap is as follows: 1. 2. 3. Enable BFD globally on Router A and Router C. Configure multi-hop BFD for IPv6 on Router A to detect faults in the links between Router A and Router C. Configure multi-hop BFD for IPv6 on Router C to detect faults in the links between Router C and Router A.
Data Preparation
To complete the configuration, you need the following data: l l l Remote IPv6 address of the link to be detected by a BFD session Local and remote discriminators of a BFD session BFD session name
Procedure
Step 1 Assign an IP address to each interface on Router A, Router B, and Router C, and configure OSPFv3 to ensure that these devices communicate with each other. # Configure Router A.
<HUAWEI> system-view [~HUAWEI] sysname RouterA [~HUAWEI] commit [~RouterA] ospfv3 [~RouterA-ospfv3-1] router-id 1.1.1.1 [~RouterA-ospfv3-1] area 0 [~RouterA-ospfv3-1-area-0.0.0.0] quit [~RouterA-ospfv3-1] quit [~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] undo shutdown [~RouterA-GigabitEthernet1/0/0] ipv6 enable [~RouterA-GigabitEthernet1/0/0] ipv6 address 2001::1 64 [~RouterA-GigabitEthernet1/0/0] ospfv3 1 area 0 [~RouterA-GigabitEthernet1/0/0] commit [~RouterA-GigabitEthernet1/0/0] quit
<HUAWEI> system-view [~HUAWEI] sysname RouterB [~HUAWEI] commit [~RouterB] ospfv3 [~RouterB-ospfv3-1] router-id 2.2.2.2 [~RouterB-ospfv3-1] area 0 [~RouterB-ospfv3-1-area-0.0.0.0] quit [~RouterB-ospfv3-1] quit [~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] undo shutdown [~RouterB-GigabitEthernet1/0/0] ipv6 enable [~RouterB-GigabitEthernet1/0/0] ipv6 address 2001::2 64 [~RouterB-GigabitEthernet1/0/0] ospfv3 1 area 0 [~RouterB-GigabitEthernet1/0/0] commit [~RouterB-GigabitEthernet1/0/0] quit [~RouterB] interface gigabitethernet 2/0/0 [~RouterB-GigabitEthernet2/0/0] undo shutdown [~RouterB-GigabitEthernet2/0/0] ipv6 enable [~RouterB-GigabitEthernet2/0/0] ipv6 address 2002::1 64 [~RouterB-GigabitEthernet2/0/0] ospfv3 1 area 0
Issue 01 (2011-10-15)
106

[~RouterB-GigabitEthernet2/0/0] commit [~RouterB-GigabitEthernet2/0/0] quit
2 BFD Configuration
# Configure Router C.
<HUAWEI> system-view [~HUAWEI] sysname RouterC [~HUAWEI] commit [~RouterC] ipv6 [~RouterC] ospfv3 [~RouterC-ospfv3-1] router-id 3.3.3.3 [~RouterC-ospfv3-1] area 0 [~RouterC-ospfv3-1-area-0.0.0.0] quit [~RouterC-ospfv3-1] quit [~RouterC] interface gigabitethernet 2/0/0 [~RouterC-GigabitEthernet2/0/0] undo shutdown [~RouterC-GigabitEthernet2/0/0] ipv6 enable [~RouterC-GigabitEthernet2/0/0] ipv6 address 2002::2 64 [~RouterC-GigabitEthernet2/0/0] ospfv3 1 area 0 [~RouterC-GigabitEthernet2/0/0] commit [~RouterC-GigabitEthernet2/0/0] quit
[~RouterA] ping ipv6 2002::2 PING 2002::2 : 56 data bytes, press Reply from 2002::2 bytes=56 Sequence=1 hop limit=64 Reply from 2002::2 bytes=56 Sequence=2 hop limit=64 Reply from 2002::2 bytes=56 Sequence=3 hop limit=64 Reply from 2002::2 bytes=56 Sequence=4 hop limit=64 Reply from 2002::2 bytes=56 Sequence=5 hop limit=64 ---2002::2 ping statistics--5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max=1/5/22 ms CTRL_C to break time=22 ms time=1 ms time=1 ms time=1 ms time=1 ms
Step 2 Configure multi-hop BFD between Router A and Router C. # Configure Router A.
[~RouterA] bfd [~RouterA-bfd] quit [~RouterA] bfd ipv6session bind peer-ipv6 2002::2 [~RouterA-sess-ipv6session] discriminator local 1 [~RouterA-sess-ipv6session] discriminator remote 2 [~RouterA-sess-ipv6session] commit [~RouterA-sess-ipv6session] quit
[~RouterC] bfd [~RouterC-bfd] quit [~RouterC] bfd ipv6session bind peer-ipv6 2001::1 [~RouterC-sess-ipv6session] discriminator local 2 [~RouterC-sess-ipv6session] discriminator remote 1 [~RouterC-sess-ipv6session] commit [~RouterC-sess-ipv6session] quit
Step 3 Verify the configuration. After completing the preceding configurations, run the display bfd session all verbose command on Router A or Router C. A multi-hop BFD session has been established and its status is Up. Use the display on Router A as an example.
2 BFD Configuration
[~RouterA] display bfd session all verbose -----------------------------------------------------------------------------(Multi Hop) State : UP Name : ipv6session -----------------------------------------------------------------------------Local Discriminator : 1 Remote Discriminator : 2 Session Detect Mode : Asynchronous Mode Without Echo Function BFD Bind Type : Peer IP Address Bind Session Type : Static Bind Peer IP Address : 2002::2 Bind Interface : FSM Board Id : 1 TOS-EXP : 7 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 Actual Tx Interval (ms): 10 Actual Rx Interval (ms): 10 Local Detect Multi : 3 Detect Interval (ms) : 30 Echo Passive : Disable Acl Number : Destination Port : 4784 TTL : 254 Proc Interface Status : Disable Process PST : Disable WTR Interval (ms) : 0 Local Demand Mode : Disable Active Multi : 3 Last Local Diagnostic : No Diagnostic Bind Application : No Application Bind Session TX TmrID : 2720409460 Session Detect TmrID : Session Init TmrID : Session WTR TmrID : Session Echo Tx TmrID : Session Description : -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
----End
Configuration Files
# sysname RouterA # bfd # ospfv3 1 router-id 1.1.1.1 area 0.0.0.0 # interface GigabitEthernet1/0/0 undo shutdown ipv6 enable ipv6 address 2001::1/64 ospfv3 1 area 0.0.0.0 # bfd ipv6session bind peer-ipv6 2002::2 discriminator local 1 discriminator remote 2 return

# sysname RouterB # bfd # ospfv3 1 router-id 2.2.2.2 area 0.0.0.0 # interface GigabitEthernet1/0/0 undo shutdown ipv6 enable ipv6 address 2001::2/64
Issue 01 (2011-10-15)
108

ospfv3 1 area 0.0.0.0 # interface GigabitEthernet2/0/0 undo shutdown ipv6 enable ipv6 address 2002::1/64 ospfv3 1 area 0.0.0.0 return
2 BFD Configuration

# sysname RouterC # bfd # ospfv3 1 router-id 3.3.3.3 area 0.0.0.0 # interface GigabitEthernet2/0/0 undo shutdown ipv6 enable ipv6 address 2002::2/64 ospfv3 1 area 0.0.0.0 # bfd ipv6session bind peer-ipv6 2001::1 discriminator local 2 discriminator remote 1 return
Issue 01 (2011-10-15)
109
3 VRRP Configuration
3
About This Chapter
VRRP Configuration
By configuring a Virtual Router Redundancy Protocol (VRRP) backup group, you can use a backup device to transmit traffic of a network when the master device fails. 3.1 VRRP Overview VRRP combines a group of devices to a virtual router and set the IP address of a virtual router as the address of the default gateway of the hosts in the network. 3.2 VRRP Features Supported by the NE5000E The NE5000E supports the VRRP backup group in master/backup mode, VRRP backup groups in load balancing mode, VRRP security, VRRP tracking function, and the capability of enabling or disabling a device to ping a virtual IP address. 3.3 Configuring a VRRP Backup Group in Master/Backup Mode By configuring a VRRP backup group in master/backup mode, you can ensure the continuity and reliability of communications when the next hop of a host fails in a LAN. 3.4 Configuring VRRP Backup Groups in Load Balancing Mode By configuring VRRP backup groups in load balancing mode, you can ensure the continuity and reliability of communications when the next hop of a host fails in a LAN. 3.5 Configuring the Tracking Function for a VRRP Backup Group A VRRP backup group can be configured to track either interfaces or BFD sessions. 3.6 Optimizing VRRP By adjusting the parameters of a VRRP backup group, you can optimizing the functions of the VRRP backup group. 3.7 Maintaining VRRP This section describes how to maintain VRRP. Detailed operations include clearing VRRP statistics, monitoring the operation status of VRRP, and debugging VRRP when a fault occurs. 3.8 Configuration Examples This part provides examples for using VRRP to improve reliability. Familiarize yourself with the configuration procedures against the networking diagram. Each configuration example consists of the networking requirements, configuration roadmap, configuration procedures, and configuration files.
Issue 01 (2011-10-15)
110
3.1 VRRP Overview

VRRP combines a group of devices to a virtual router and set the IP address of a virtual router as the address of the default gateway of the hosts in the network. Usually, all hosts within a network are configured with the same default route destined for an egress gateway (such as Router A as shown in Figure 3-1). In this manner, the hosts communicate with external networks. When the egress gateway becomes faulty, all hosts fail to communicate with external networks. Figure 3-1 Schematic diagram of a default gateway in a LAN
Gateway:10.0.0.1 IP Address:10.0.0.2/24 Gateway:10.0.0.1 IP Address:10.0.0.3/24 Gateway:10.0.0.1 IP Address:10.0.0.4/24 Ethernet 10.0.0.1/24 Network
RouterA
To improve the reliability of a system, a common method is to configure multiple egress gateways. The problem of route selection among these gateways, however, must be solved. VRRP is a fault-tolerant protocol defined in RFC 3768. It implements route selection among multiple egress gateways by separating physical devices from logical devices. In a LAN enabled with multicast or broadcast (for example, Ethernet), VRRP offers logical gateways to ensure high utility of links. This solves the problem that services are interrupted due to a gateway failure.
3.2 VRRP Features Supported by the NE5000E

The NE5000E supports the VRRP backup group in master/backup mode, VRRP backup groups in load balancing mode, VRRP security, VRRP tracking function, and the capability of enabling or disabling a device to ping a virtual IP address.
VRRP Backup Group in Master/Backup Mode

VRRP provides IP address backup in master/backup mode. In this mode, a virtual router must be set up, consisting of a master device and several backup devices. These routers form a VRRP backup group. The master device and backup devices have different priorities in the VRRP backup group. The router having the highest priority functions as the master device. Normally, the master device carries all services. When the master device fails, a backup device takes over the services.
VRRP Backup Groups in Load Balancing Mode

In load balancing mode, two or more VRRP backup groups are set up and multiple routers transmit services at the same time. In this mode, a VRRP backup group has the following characteristics: l l l One NE5000E can join multiple VRRP backup groups and obtain different priorities. When multiple backup groups are configured, load balancing can be carried out among them. Each backup group consists of a master device and several backup devices. The master devices of the backup groups can be different.
VRRP Security
Different authentication modes and authentication keys can be set in VRRP packet headers in networks at different security levels. In a secure network, the default setting can be adopted. That is, the device does not authenticate the VRRP packets to be sent or the received VRRP packets. In addition, all received VRRP packets are considered as valid. In this case, no authentication key needs to be set. VRRP provides simple text authentication and MD5 authentication for networks that are vulnerable to attacks. In simple text authentication mode, a string of 1 to 8 characters can be configured as the authentication key. In MD5 authentication mode, a string of 1 to 8 characters in plain text or a string of 24 characters in encrypted text can be configured as the authentication key.
Tracking Function of a VRRP Backup Group

Tracking the interface: On the NE5000E, a VRRP backup group tracks the interface status. If the interface status changes, the VRRP priorities in the VRRP backup group automatically change. This allows the VRRP backup group to re-elect a master device. Tracking the BFD session: Bidirectional Forwarding Detection (BFD) rapidly detects faults in links and IP routes, helping monitor the connectivity of the links and IP routes. VRRP implements rapid master/backup switchovers in milliseconds by tracking the BFD session.
Enabling the Virtual IP Address to Be Pinged

The virtual IP address in a VRRP backup group serves as the IP address of the default gateway for hosts. Although pinging the virtual IP address is a useful method for monitoring a VRRP backup group, it exposes the VRRP backup group to ICMP packet attacks. Commands are provided on the VRRP-enabled NE5000E to make devices able or unable to ping the virtual IP address.
3.3 Configuring a VRRP Backup Group in Master/Backup Mode

By configuring a VRRP backup group in master/backup mode, you can ensure the continuity and reliability of communications when the next hop of a host fails in a LAN.
A VRRP backup group can work in either master/backup mode or load balancing mode.
The VRRP backup group in master/backup mode works as follows: l l l l Only one VRRP backup group is configured and it consists of a master device and several backup devices. A router with the highest priority in the VRRP backup group functions as the master device to transmit services. Other routers in the VRRP backup group function as backup devices to listen to the status of the master device. If the master device fails, a backup device with the highest priority is selected as a new master to provide the routing service.
NOTE
The Ethernet interface, Gigabit Ethernet interface, Eth-Trunk interface, Eth-Trunk sub-interface, and Ethernet sub-interface support VRRP.
Before configuring a VRRP backup group in master/backup mode, complete the following tasks: l l l Setting physical parameters of each interface Configuring the link attributes of each interface Configuring the network attributes of each interface to ensure connectivity of a network
Figure 3-2 Flowchart of configuring a VRRP backup group in master/backup mode
Configure a VRRP backup group and Assign a virtual IP address Set the priority of an interface in a VRRP backup group Configure an authentication mode for VRRP packets Set the interval at which a VRRP Advertisement packet is sent Enable a device to learn the interval at which a VRRP Advertisement packet is sent Set the preemption delay for the device in a VRRP backup group Set the timeout period for sending gratuitous ARP packets on the master device Mandatory procedure Optional procedure
Issue 01 (2011-10-15)
113
Related Tasks
3.8.1 Example for Configuring a VRRP Backup Group in Master/Backup Mode
3.3.1 Configuring a VRRP Backup Group and Assigning a Virtual IP Address

By configuring a VRRP backup group, you can configure the virtual IP address of the VRRP backup group as the IP address of the default gateway of the hosts in a LAN.
Procedure
Step 1 Run:
system-view

interface interface-type interface-number
The view of the interface to which a VRRP backup group belongs is displayed. Step 3 Run:
vrrp vrid virtual-router-id virtual-ip virtual-address
A VRRP backup group is configured and assigned a virtual IP address.

NOTE
l The virtual IP addresses of VRRP backup groups must be different. l All devices in a VRRP backup group must be configured with the same virtual-router-id. l The values of virtual-router-id of different interfaces can be the same.
When the first virtual IP address is assigned to a VRRP backup group, the system creates the VRRP backup group. When other virtual IP addresses are assigned to this VRRP backup group, the system adds these addresses to a virtual IP address list. For users have the same reliability requirements for VRRP in a network, to facilitate management and prevent the addresses of the default gateways from changing due to VRRP configuration changes, you can configure multiple virtual IP addresses for the same VRRP backup group, and use different virtual IP addresses to serve different user groups. Each backup group can be configured with a maximum number of 16 virtual IP addresses.
NOTE
Each interface can be configured with a maximum number of 255 VRRP backup groups.
Step 4 Run:
commit

3.3.2 Configuring the Priority of an Interface in a VRRP Backup Group

By configuring the priority of an interface in a VRRP backup group, you can use the master device to transmit traffic of a network.
Context
In master/backup mode, only one VRRP backup group is set up. Different routers have different priorities. The router with the highest priority becomes the master device and other routers with lower priorities function as backup devices.
Procedure
Step 1 Run:
system-view

The view of the interface on which a VRRP backup group is configured is displayed. Step 3 Run:
vrrp vrid virtual-router-ID priority priority-value
The priority of the router in the VRRP backup group is set. By default, the priority is 100. Priority 0 is reserved for special use, and priority 255 is reserved for the IP address owner whose priority cannot be changed. The value of a configurable priority ranges from 1 to 254. Step 4 Run:
commit
3.3.3 (Optional) Configuring an Authentication Mode for VRRP Packets

In networks that are vulnerable to attacks, you can configure an authentication mode for VRRP packets to prevent a device against attacks.
Context
In a secure network, the default setting can be adopted. That is, the router does not authenticate the VRRP packets to be sent or the received VRRP packets. In addition, all received VRRP packets are considered as valid. In this case, no authentication key needs to be set. VRRP provides simple text authentication and MD5 authentication for networks that are vulnerable to attacks. In simple text authentication mode, a string of 1 to 8 characters can be configured as the authentication key. In MD5 authentication mode, a string of 1 to 8 characters
in plain text or a string of 24 characters in encrypted text can be configured as the authentication key.
Procedure
Step 1 Run:
system-view

vrrp vrid virtual-router-id authentication-mode { simple key | md5 md5-key }
An authentication mode for VRRP packets is configured. The authentication keys on the master device and backup devices must be the same. The MD5 authentication password that starts and ends with $@$@ is invalid, because $@$@ is used to distinguish old and new passwords. Step 4 Run:
commit
3.3.4 (Optional) Setting the Interval for Sending VRRP Advertisement Packets
By setting the interval for sending gratuitous VRRP advertisement packets, you can relieve the load of the protocol packets in a network.
Context
The master device periodically sends VRRP advertisement packets to other backup devices to inform them that the master device works normally. If the backup devices receive no VRRP advertisement packets sent by the master device after the timers expire, the master device is regarded as failed and a backup device becomes the master device.
Procedure
Step 1 Run:
system-view

The view of the interface on which a VRRP backup group is configured is displayed.
Step 3 Run:
vrrp vrid virtual-router-id timer advertise { advertise-interval | millisecond millisecond-interval }
The interval for sending VRRP advertisement packets is set. By default, the interval is 1s. When multiple VRRP backup groups exist, sending VRRP advertisement packets at short intervals may cause frequent VRRP status switching. In this case, you can increase the interval. Step 4 Run:
commit
3.3.5 (Optional) Enabling a Device to Learn the Interval at Which a VRRP Advertisement Packet Is Sent
By enabling a device to learn the interval at which a VRRP Advertisement packet is sent, you can prevent double master devices from coexisting in a VRRP backup group.
Context
The master device in a VRRP backup group periodically sends a VRRP Advertisement packet to non-master devices, notifying them of the correct Master status. After receiving the Advertisement packet, a non-master device compares the interval at which the Advertisement packet is sent with the local one, and proceeds to the following operations based on comparison: l l If they are the same, the device discards the received Advertisement packet, resets the Adver_Timer, and continues monitoring the master device. If they are different and the non-master device is unable to learn the interval, the non-master device discards the Advertisement packet. Before the Master_Down_Interval expires, the non-master device continues receiving Advertisement packets and proceeds to the following operations based on similar comparison: If the interval carried in another received Advertisement packet is different from the local interval, the non-master device will become the master after the Master_Down_Interval expires. In this case, two VRRP master devices coexist. To help prevent double master devices from coexisting, the device needs to be enabled to learn the interval at which a VRRP Advertisement packet is sent. If the interval carried in another received Advertisement packet is the same as the local interval, the non-master device will discard the packet, reset the Adver_Timer, and continue monitoring the master device.
Procedure
Step 1 Run:
system-view

vrrp timer-advertise learning enable
The device is enabled to learn the interval at which a VRRP Advertisement packet is sent.
By default, the device is enabled to learn the interval at which a VRRP Advertisement packet is sent. Step 3 Run:
commit
3.3.6 (Optional) Setting the Preemption Delay for the Device in a VRRP Backup Group
By setting the preemption delay for the router in a VRRP backup group, you can speed up or slow the switchover between the master state and backup state.
Context
Backup devices in a VRRP backup group work in either non-preemption mode or preemption mode. By default, the backup devices work in immediate preemption mode. If a backup device detects that it has a higher VRRP priority than the master device, the backup device immediately preempts the master device. On an unstable network, if the link status frequently changes, preemption attempts in a VRRP backup group increase, causing the unsteady VRRP status. An appropriate preemption delay time can be set so that the VRRP status does not flap if the link status frequently changes.
Procedure
Step 1 Run:
system-view

vrrp vrid virtual-router-ID preempt-mode timer delay delay-value
The preemption delay is set on the router in the VRRP backup group. By default, the preemption mode is enabled and the preemption delay is 0s, indicating immediate preemption. In immediate preemption mode, a backup device becomes the master device when detecting that its priority is higher than the priority of the master device. Then, the original master device becomes a backup device. After the preemption delay is set, a backup device is delayed for a specified period before preempting the master device. The vrrp vrid virtual-router-ID preempt-mode disable command is used to enable the nonpreemption mode for devices in a VRRP backup group. In non-preemption mode, after a certain device becomes the master device in the backup group and works properly, another device cannot preempt the master device even if its priority is set to a value higher than that of the master device. When the IP address owner recovers from a fault, the IP address owner immediately becomes the master device despite the set delay. The preemption delay refers to a period during which a
backup device waits for preempting the master device, whereas an IP address owner is irrelevant to the preemption delay. In a VRRP backup group that needs to be configured with the preemption delay, the master device cannot be configured as the IP address owner. You can run the undo vrrp vrid virtual-router-ID preempt-mode command to restore the default preemption mode, that is, immediate preemption.
NOTE
To configure the preemption mode for each device in a VRRP backup group, you are recommended to configure the immediate preemption mode on each backup device by setting the delay to 0s, and configure the delayed preemption mode on the master device by setting a delay. This allows a transition period for the uplink status and the downlink status to restore consistency in an unstable network, and thus prevents user devices from learning incorrect address of the master device due to dual master devices or frequent preemption.
Step 4 Run:
commit
3.3.7 (Optional) Setting the Timeout Period of Sending Gratuitous ARP Packets on the Master Device
By adjusting the timeout period of sending gratuitous ARP packets by the master device, you can relieve a network of the load from the protocol packets.
Procedure
Step 1 Run:
system-view

vrrp gratuitous-arp timeout time
A timeout period of sending gratuitous ARP packets on the master device is set. The ARP packets sent by the master device carry the virtual MAC address. By default, the master device sends gratuitous ARP packets at intervals of 120s (namely, 2 minutes). To restore the default timeout period, you can run the undo vrrp gratuitous-arp timeout command in the system view. To disable the master device from sending gratuitous ARP packets, you can run the vrrp gratuitous-arp timeout disable command in the system view. Step 3 Run:
commit


After the configurations of the VRRP backup group in master/backup mode are successful, you can view the status of the VRRP backup group.
Prerequisite
The configurations of the VRRP backup group in master/backup mode are complete.
Procedure
Step 1 Run the display vrrp [ interface interface-type interface-number [ virtual-router-ID ] ] command to check the status of a VRRP backup group. ----End
Example
After the configurations are successful, run the display vrrp command, and you can view the status of the VRRP backup group.
<HUAWEI> display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 100.1.1.111 PriorityRun : 120 PriorityConfig : 120 MasterPriority : 120 Preempt : YES Delay Time : 0 TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES
3.4 Configuring VRRP Backup Groups in Load Balancing Mode

By configuring VRRP backup groups in load balancing mode, you can ensure the continuity and reliability of communications when the next hop of a host fails in a LAN.
A VRRP backup group can work in either master/backup mode or load balancing mode. In load balancing mode, multiple VRRP backup groups are configured to share traffic of a network. One router can join multiple VRRP backup groups. The VRRP backup groups in master/backup mode work as follows: l l l Router A is the master device in backup group 1 and the backup device in backup group 2. Router A is the master device in backup group 1 and the backup device in backup group 2. In the network, certain hosts use backup group 1 as the gateway and other hosts use backup group 2 as the gateway.
In this manner, the two VRRP backup groups can back up each other and share traffic of the network.

NOTE
The Ethernet interface, Gigabit Ethernet interface, Eth-Trunk interface, Eth-Trunk sub-interface, and Ethernet sub-interface support VRRP.
Before configuring a VRRP backup group in load balancing mode, complete the following tasks: l l l Setting physical parameters of each interface Configuring the link attributes of each interface Configuring the network attributes of each interface to ensure connectivity of a network
Figure 3-3 Flowchart of configuring a VRRP backup group in load balancing mode
Configure a VRRP backup group and Assign a virtual IP address Set the priority of an interface in a VRRP backup group Configure an authentication mode for VRRP packets Set the interval at which a VRRP Advertisement packet is sent Enable a device to learn the interval at which a VRRP Advertisement packet is sent Set the preemption delay for the device in a VRRP backup group Set the timeout period for sending gratuitous ARP packets on the master device Mandatory procedure Optional procedure
Related Tasks
3.8.2 Example for Configuring VRRP Backup Groups in Load Balancing Mode 3.8.3 Example for Configuring VRRP Multi-instance
Issue 01 (2011-10-15)
121
3.4.1 Configuring a VRRP Backup Group and Assigning a Virtual IP Address

By configuring a VRRP backup group, you can configure the virtual IP address of the VRRP backup group as the IP address of the default gateway of the hosts in a LAN.
Procedure
Step 1 Run:
system-view

vrrp vrid virtual-router-ID virtual-ip virtual-address
A VRRP backup group is configured and assigned a virtual IP address.

NOTE
l The virtual IP addresses of VRRP backup groups must be different. l All devices of a backup group must be configured with the same virtual-router-ID. l The values of virtual-router-ID of different interfaces can be the same.
When the first virtual IP address is assigned to a VRRP backup group, the system creates the VRRP backup group. When other virtual IP addresses are assigned to this VRRP backup group, the system adds these addresses to a virtual IP address list. For users that have the same reliability requirements for VRRP in a network, to facilitate management and prevent the addresses of the default gateways from changing due to VRRP configuration changes, you can configure multiple virtual IP addresses for the same backup group, and use different virtual IP addresses to serve different user groups. Each backup group can be configured with a maximum number of 16 virtual IP addresses. In load balancing mode, you need to repeat this step to configure multiple VRRP backup groups on the interface. At least two VRRP backup groups need to be created and each VRRP backup group is identified by a distinct VRID. In addition, virtual IP addresses of the VRRP backup groups must be different.
NOTE
Each interface can be configured with a maximum number of 255 VRRP backup groups.
Step 4 Run:
commit
3.4.2 Setting the Priority of an Interface in a VRRP Backup Group

By configuring the priority of an interface in a VRRP backup group, you can use the master device to transmit traffic of a network.
Context
In load balancing mode, two or more VRRP backup groups are configured. The status of each router in each VRRP backup group is determined according to the priority. Each router has different priorities in different VRRP backup groups.
Procedure
Step 1 Run:
system-view

vrrp vrid virtual-router-ID priority priority-value
The priority of the router in the VRRP backup group is set. By default, the priority is 100. Priority 0 is reserved for special use, and priority 255 is reserved for the IP address owner whose priority cannot be changed. The value of a configurable priority ranges from 1 to 254. You need to repeat this procedure to set the priority for each router in each VRRP backup group and ensure that the master devices of different VRRP backup groups are different. Step 4 Run:
commit
3.4.3 (Optional) Configuring an Authentication Mode for VRRP Packets

In networks that are vulnerable to attacks, you can configure an authentication mode for VRRP packets to prevent a device against attacks.
Context
In a secure network, the default setting can be adopted. That is, the router does not authenticate the VRRP packets to be sent or the received VRRP packets. In addition, all received VRRP packets are considered as valid. In this case, no authentication key needs to be set. VRRP provides simple text authentication and MD5 authentication for networks that are vulnerable to attacks. In simple text authentication mode, a string of 1 to 8 characters can be configured as the authentication key. In MD5 authentication mode, a string of 1 to 8 characters in plain text or a string of 24 characters in encrypted text can be configured as the authentication key.
Procedure
Step 1 Run:
system-view

vrrp vrid virtual-router-id authentication-mode { simple key | md5 md5-key }
An authentication mode for VRRP packets is configured. The authentication keys on the master device and backup devices must be the same. The MD5 authentication password that starts and ends with $@$@ is invalid, because $@$@ is used to distinguish old and new passwords. Step 4 Run:
commit
3.4.4 (Optional) Setting the Interval for Sending VRRP Advertisement Packets
By setting the interval for sending gratuitous VRRP advertisement packets, you can relieve the load of the protocol packets in a network.
Context
The master device periodically sends VRRP advertisement packets to other backup devices to inform them that the master device works normally. If the backup devices receive no VRRP advertisement packets sent by the master device after the timers expire, the master device is regarded as failed and a backup device becomes the master device.
Procedure
Step 1 Run:
system-view

vrrp vrid virtual-router-id timer advertise { advertise-interval | millisecond millisecond-interval }
The interval for sending VRRP advertisement packets is set.

By default, the interval is 1s. When multiple VRRP backup groups exist, sending VRRP advertisement packets at short intervals may cause frequent VRRP status switching. In this case, you can increase the interval. Step 4 Run:
commit
3.4.5 (Optional) Enabling a Device to Learn the Interval at Which a VRRP Advertisement Packet Is Sent
By enabling a device to learn the interval at which a VRRP Advertisement packet is sent, you can prevent double master devices from coexisting in a VRRP backup group.
Context
The master device in a VRRP backup group periodically sends a VRRP Advertisement packet to non-master devices, notifying them of the correct Master status. After receiving the Advertisement packet, a non-master device compares the interval at which the Advertisement packet is sent with the local one, and proceeds to the following operations based on comparison: l l If they are the same, the device discards the received Advertisement packet, resets the Adver_Timer, and continues monitoring the master device. If they are different and the non-master device is unable to learn the interval, the non-master device discards the Advertisement packet. Before the Master_Down_Interval expires, the non-master device continues receiving Advertisement packets and proceeds to the following operations based on similar comparison: If the interval carried in another received Advertisement packet is different from the local interval, the non-master device will become the master after the Master_Down_Interval expires. In this case, two VRRP master devices coexist. To help prevent double master devices from coexisting, the device needs to be enabled to learn the interval at which a VRRP Advertisement packet is sent. If the interval carried in another received Advertisement packet is the same as the local interval, the non-master device will discard the packet, reset the Adver_Timer, and continue monitoring the master device.
Procedure
Step 1 Run:
system-view

vrrp timer-advertise learning enable
The device is enabled to learn the interval at which a VRRP Advertisement packet is sent. By default, the device is enabled to learn the interval at which a VRRP Advertisement packet is sent. Step 3 Run:

commit
3.4.6 (Optional) Setting the Preemption Delay for the Device in a VRRP Backup Group
By setting the preemption delay for the router in a VRRP backup group, you can speed up or slow the switchover between the master state and backup state.
Context
Backup devices in a VRRP backup group work in either non-preemption mode or preemption mode. By default, the backup devices work in immediate preemption mode. If a backup device detects that it has a higher VRRP priority than the master device, the backup device immediately preempts the master device. On an unstable network, if the link status frequently changes, preemption attempts in a VRRP backup group increase, causing the unsteady VRRP status. An appropriate preemption delay time can be set so that the VRRP status does not flap if the link status frequently changes.
Procedure
Step 1 Run:
system-view

vrrp vrid virtual-router-ID preempt-mode timer delay delay-value
The preemption delay is set on the router in the VRRP backup group. By default, the preemption mode is enabled and the preemption delay is 0s, indicating immediate preemption. In immediate preemption mode, a backup device becomes the master device when detecting that its priority is higher than the priority of the master device. Then, the original master device becomes a backup device. After the preemption delay is set, a backup device is delayed for a specified period before preempting the master device. The vrrp vrid virtual-router-ID preempt-mode disable command is used to enable the nonpreemption mode for devices in a VRRP backup group. In non-preemption mode, after a certain device becomes the master device in the backup group and works properly, another device cannot preempt the master device even if its priority is set to a value higher than that of the master device. When the IP address owner recovers from a fault, the IP address owner immediately becomes the master device despite the set delay. The preemption delay refers to a period during which a backup device waits for preempting the master device, whereas an IP address owner is irrelevant to the preemption delay. In a VRRP backup group that needs to be configured with the preemption delay, the master device cannot be configured as the IP address owner.
You can run the undo vrrp vrid virtual-router-ID preempt-mode command to restore the default preemption mode, that is, immediate preemption.
NOTE
To configure the preemption mode for each device in a VRRP backup group, you are recommended to configure the immediate preemption mode on each backup device by setting the delay to 0s, and configure the delayed preemption mode on the master device by setting a delay. This allows a transition period for the uplink status and the downlink status to restore consistency in an unstable network, and thus prevents user devices from learning incorrect address of the master device due to dual master devices or frequent preemption.
Step 4 Run:
commit
3.4.7 (Optional) Setting the Timeout Period of Sending Gratuitous ARP Packets on the Master Device
By adjusting the timeout period of sending gratuitous ARP packets by the master device, you can relieve a network of the load from the protocol packets.
Procedure
Step 1 Run:
system-view

vrrp gratuitous-arp timeout time
A timeout period of sending gratuitous ARP packets on the master device is set. The ARP packets sent by the master device carry the virtual MAC address. By default, the master device sends gratuitous ARP packets at intervals of 120s (namely, 2 minutes). To restore the default timeout period, you can run the undo vrrp gratuitous-arp timeout command in the system view. To disable the master device from sending gratuitous ARP packets, you can run the vrrp gratuitous-arp timeout disable command in the system view. Step 3 Run:
commit

After the configurations of the VRRP backup groups in load balancing mode, you can view the status of the VRRP backup groups.
Prerequisite
The configurations of the VRRP backup groups in load balancing mode are complete.
Procedure
Step 1 Run the display vrrp [ interface interface-type interface-number [ virtual-router-ID ] ] command to check the status of VRRP backup groups. ----End
Example
After the configurations are successful, run the display vrrp command, and you can view the status of the router in different VRRP backup groups.
<HUAWEI> display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 10.1.1.111 PriorityRun : 120 PriorityConfig : 120 MasterPriority : 120 Preempt : YES Delay Time : 0 TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES GigabitEthernet2/0/0 | Virtual Router 2 State : Backup Virtual IP : 10.1.1.112 PriorityRun : 100 PriorityConfig : 100 MasterPriority : 120 Preempt : YES Delay Time TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0102 Check TTL : YES
: 0
3.5 Configuring the Tracking Function for a VRRP Backup Group

A VRRP backup group can be configured to track either interfaces or BFD sessions.
A VRRP backup group tracks either interfaces or BFD sessions. l Tracking the interface: A VRRP backup group can be configured to track an interface. If the interface or another network-connected interface on the same device fails, a backup is provided. Tracking the BFD session status: If the BFD session status tracked by a VRRP backup group changes, the VRRP backup group is notified of the change, and rapidly performs a master/backup switchover.
Issue 01 (2011-10-15)
Before configuring the tracking function for a VRRP backup group, complete the following tasks: l l Configuring a VRRP backup group Configuring a BFD session
You can choose one or more configuration tasks (excluding "Checking the Configuration") as required.
Related Tasks
3.8.4 Example for Configuring a VRRP Backup Group to Track Interfaces 3.8.5 Example for Configuring a VRRP Backup Group to Track a BFD Session
3.5.1 Configuring a VRRP Backup Group to Track an Interface

Configuring a VRRP backup group to track an interface triggers a master/backup switchover if the interface fails.
Procedure
Step 1 Run:
system-view
The system view is displayed. Step 2 (Optional) Run:

vrrp recover-delay delay-value
The delay time for restoring the status of a VRRP backup group is set. By default, the delay time for restoring the status of a VRRP backup group is 0 seconds. This allows preemption to be performed immediately after the priority of the master device changes, which may cause frequent VRRP status changes. Step 3 Run:
The view of the interface on which the VRRP backup group is established is displayed. Step 4 Run:
vrrp vrid virtual-router-ID track interface interface-type interface-number [ increased value-increased | reduced value-reduced ]
The VRRP backup group is configured to track an interface. After the VRRP backup group is configured to track the interface, a status change can trigger VRRP priority changes on devices in the VRRP backup group. This allows the VRRP backup group to re-determine the master and backup devices. Either of the following parameters can be set in the command to enable a VRRP backup group to track an interface: l increased value-increased: specifies the value by which the VRRP priority increases if the tracked interface goes Down. The value is an integer ranging from 1 to 255. As 255 is the
priority value of the IP address owner, the largest priority value can be set to 254. This parameter takes effect on both the master and backup devices in a VRRP backup group. l reduced value-reduced: specifies the value by which the VRRP priority reduces if the tracked interface goes Down. The value is an integer ranging from 1 to 255. The smallest priority value is 1. By default, the VRRP priority reduces by 10 if the tracked interface goes Down. This parameter takes effect on both the master and backup devices in a VRRP backup group.
NOTE
l A VRRP backup group can track a maximum of eight interfaces. l When the router is the IP address owner, the router cannot be configured with a tracked interface. l If VRRP is configured on an Eth-Trunk interface, VRRP does not track the statuses of member interfaces of the Eth-Trunk interface.
Step 5 Run:
commit
3.5.2 Configuring a VRRP Backup Group to Track a BFD Session

Configuring a VRRP backup group to tack a BFD session allows the VRRP backup group to rapidly perform a master/backup switchover if the BFD session goes Down.
Context
After a VRRP backup group is configured to track a BFD session, either of the following situations occurs: l l If the BFD session tracked by the VRRP backup group goes Down, the VRRP priorities of devices in the VRRP backup group change, causing the master and backup states to change. If the BFD session tracked by the VRRP backup group goes Up, the original VRRP priority values of devices in the VRRP backup group are restored. This allows the original status of devices in the VRRP backup group to be restored.
Procedure
Step 1 Run:
system-view
The system view is displayed. Step 2 (Optional) Run:

vrrp recover-delay delay-value
The delay time for restoring the status of a VRRP backup group is set. By default, the delay time for restoring the status of a VRRP backup group is 0 seconds. This allows preemption to be performed immediately after the priority of the master device changes, which may cause frequent VRRP status changes. Step 3 Run:
The view of the interface on which the VRRP backup group is established is displayed.
Step 4 Run:
vrrp vrid virtual-router-ID track bfd-session { bfd-session-id | session-name bfdconfigure-name } [ increased value-increased | reduced value-reduced ]
The VRRP backup group is configured to track a BFD session. After the VRRP backup group is configured to track the BFD session, a status change can trigger changes in the VRRP priorities of devices in the VRRP backup group. This allows the VRRP backup group to re-determine the master and backup devices. Either of the following parameters can be set in the command to enable a VRRP backup group to track a BFD session: l increased value-increased: specifies the value by which the VRRP priority increases if the tracked BFD session goes Down. The value ranges from 1 to 255. The largest priority value can be set to 254. If the tracked BFD session becomes Down, the priorities of devices in the VRRP backup group whose VRID is virtual-router-id increase. This parameter takes effect on both the master and backup devices in a VRRP backup group. l reduced value-reduced: specifies the value by which the VRRP priority reduces if the tracked BFD session becomes Down. The value is an integer ranging from 1 to 255. The smallest priority value is 1. By default, the VRRP priority reduces by 10 if the tracked BFD session goes Down. This parameter takes effect on both the master and backup devices in a VRRP backup group. When configuring a VRRP backup group to track the status of a BFD session, note the following points: l If the parameter session-name bfd-configure-name is specified, the VRRP backup group can track the status of only static BFD sessions with automatically negotiated discriminators. l If the parameter session-id is specified, the VRRP backup group can track the status of only static BFD sessions. Step 5 Run:
commit

By viewing the status of an interface or a BFD session tracked by a VRRP backup group, you can check whether or not the configuration is successful.
Prerequisite
The configurations of the tracking function of a VRRP backup group are complete.
Procedure
Step 1 Run the display vrrp [ interface interface-type interface-number [ virtual-router-id ] ] [ brief ] command to check the status of a VRRP backup group. ----End
Example
After the configuration is successful, run the display vrrp command, you can view information about the interface or BFD session tracked by the VRRP backup group.

<HUAWEI> display vrrp GigabitEthernet3/0/1 | Virtual Router 1 State : Backup Virtual IP : 10.10.1.111 PriorityRun : 200 PriorityConfig : 200 MasterPriority : 210 Preempt : YES TimerRun : 1 TimerConfig : 1 Auth Type : NONE Virtual Mac : 0000-5e00-0101 Check TTL : YES Track IF : GigabitEthernet3/0/1 IF State : DOWN GigabitEthernet3/0/2 | Virtual Router 2 State : Initialize Virtual IP : 192.2.1.10 PriorityRun : 100 PriorityConfig : 100 MasterPriority : 100 Preempt : YES Delay Time : 0 TimerRun : 1 TimerConfig : 1 Auth Type : NONE Virtual Mac : 0000-5e00-0102 Check TTL : YES Track BFD : 1 BFD-Session State : UP
Delay Time : 0
priority reduced :20
Priority reduced : 20
3.6 Optimizing VRRP

By adjusting the parameters of a VRRP backup group, you can optimizing the functions of the VRRP backup group.
You can optimize the following functions of a VRRP backup group by setting parameters relevant to VRRP packets: l l By prohibiting the system from checking TTLs in VRRP packets, you can improve the compatibility of Huawei devices with different vendors' devices. After being configured with the network management function, the VRRP backup group can send trap messages to notify the network management system (NMS) of faults.
Before optimizing VRRP, complete the following tasks: l l l l Setting physical parameters of each interface Configuring the link attributes of each interface Configuring the network attributes of each interface to ensure connectivity of a network Configure each VRRP backup group
Perform one or multiple procedures (excluding procedures in "Checking the Configuration") as required.
3.6.1 Enabling a Virtual IP Address to Be Pinged

By enabling a virtual IP address to be pinged, you can check the connectivity of a network.
Procedure
Step 1 Run:
system-view

vrrp virtual-ip ping enable
The VRRP-enabled device allows other devices to ping its virtual IP address. By default, pinging a virtual IP address is enabled. If the VRRP-enabled device is in the Master state, it responds to the ping packets whose destination address is the virtual IP address. Although pinging the virtual IP address is a useful method for monitoring a VRRP backup group, it exposes the VRRP backup group to ICMP packet attacks. The undo vrrp virtual-ip ping enable command can be run to disable the VRRP-enabled device from responding to ping packets whose destination address is the virtual IP address. Step 3 Run:
commit
3.6.2 Disabling the Checking of TTLs in VRRP Packets

By prohibiting the checking of TTLs in VRRP packets, you can improve the compatibility of Huawei devices with different vendors' devices.
Context
As defined in RFC 3768, the device checks TTLs in received VRRP packets. If the TTL values are not 255, VRRP packets are discarded. In the network where devices of different vendors are deployed, checking TTLs in VRRP packets may cause the device to incorrectly discard VRRP packets. To prevent this problem, you can disable the device from checking TTLs in VRRP packets.
Procedure
Step 1 Run:
system-view

The view of the interface on which a VRRP backup group is configured is displayed.
Step 3 Run:
vrrp un-check ttl
Checking TTLs in VRRP packets is prohibited. By default, a device checks the TTLs in VRRP packets. If this function is disabled, you can run the undo vrrp un-check ttl command to enable the device to check TTLs in VRRP packets. Step 4 Run:
commit

After the configurations of optimizing VRRP are successful, you can view the status and the configurations of the VRRP backup group, such as the Check TTL field.
Prerequisite
The configurations of optimizing VRRP are complete.
Procedure
Step 1 Run the display vrrp [ interface interface-type interface-number [ virtual-router-ID ] ] command to check the status of a VRRP backup group. ----End
Example
Run the display vrrp command, and you can view the results of optimizing a VRRP backup group. For example, the Check TTL field displays YES.
<HUAWEI> display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 100.1.1.111 PriorityRun : 120 PriorityConfig : 120 MasterPriority : 120 Preempt : YES Delay Time : 0 TimerConfig : 20 Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES
3.7 Maintaining VRRP

This section describes how to maintain VRRP. Detailed operations include clearing VRRP statistics, monitoring the operation status of VRRP, and debugging VRRP when a fault occurs.
Issue 01 (2011-10-15)
134
3.7.1 Monitoring the Operation Status of VRRP

By monitoring the VRRP operation status, you can view information about VRRP during the operation.
Context
In daily maintenance, you can run the following command to view the operation status of VRRP.
Procedure
Step 1 Run the display vrrp [ interface interface-type interface-number [ virtual-router-ID ] ] [ brief ] command in any view to check the status and configurations of a VRRP backup group. ----End

This part provides examples for using VRRP to improve reliability. Familiarize yourself with the configuration procedures against the networking diagram. Each configuration example consists of the networking requirements, configuration roadmap, configuration procedures, and configuration files.
3.8.1 Example for Configuring a VRRP Backup Group in Master/ Backup Mode
In this example, by configuring a VRRP backup group in master/backup mode, you can use the master device in the VRRP backup group to transmit all traffic of a network.
Network Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/ interface number. On an NE5000E cluster, the interface is numbered in the format of chassis ID/slot number/card number/interface number. This requires the chassis ID to be specified along with the slot number. As shown in Figure 3-4, Host A accesses Host B through the default gateway. l l l Router A and Router B form a VRRP backup group functioning as the default gateway of Host A. Normally, Router A functions as the gateway. When Router A fails, Router B replaces Router A to function as the gateway. After Router A recovers from the fault, it can preempt the master device within 20 seconds.
Issue 01 (2011-10-15)
135
Figure 3-4 Networking diagram of a VRRP backup group in master/backup mode
Backup group 1 Virtual IP Address: 10.1.1.111
RouterA Master
GE1/0/0 10.1.1.1/24
POS1/0/0 192.168.1.1/24
10.1.1.100/24 GE1/0/0 10.1.1.2/24
HostA
POS1/0/0 192.168.1.2/24 GE3/0/0 20.1.1.1/24 RouterC POS2/0/0 HostB 192.168.2.2/24 20.1.1.100/24 POS1/0/0 192.168.2.1/24
Ethernet
RouterB Backup
Configuration Notes
The IP address of GE 1/0/0 on Router A and the IP address of GE 1/0/0 on Router B must be in the same network segment.
The configuration roadmap is as follows: 1. Create backup group 1 on GE 1/0/0 of Router A; configure Router A with the highest priority to ensure that Router A is the master device; enable the preemption mode; set the preemption delay to 20s. Create backup group 1 on GE 1/0/0 of Router B and use the default priority.
2.
Data Preparation
To complete the configuration, you need the following data: l l l ID and virtual IP address of a VRRP backup group Priority of each router in the VRRP backup group Preemption delay
Procedure
Step 1 Assign IP addresses to interfaces on Router A, Router B, and Router C, and configure OSPF on these interfaces to ensure connectivity between them. # Configure RouterA.
<HUAWEI> system-view [~HUAWEI] sysname RouterA
Issue 01 (2011-10-15)
136

[~HUAWEI] commit [~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] undo shutdown [~RouterA-GigabitEthernet1/0/0] ip address 10.1.1.1 24 [~RouterA-GigabitEthernet1/0/0] quit [~RouterA] interface pos 1/0/0 [~RouterA-Pos1/0/0] undo shutdown [~RouterA-Pos1/0/0] ip address 192.168.1.1 24 [~RouterA-Pos1/0/0] quit [~RouterA] ospf 1 [~RouterA-ospf-1] area 0 [~RouterA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255 [~RouterA-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255 [~RouterA-ospf-1-area-0.0.0.0] commit [~RouterA-ospf-1-area-0.0.0.0] quit [~RouterA-ospf-1] quit
<HUAWEI> system-view [~HUAWEI] sysname RouterB [~HUAWEI] commit [~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] undo shutdown [~RouterB-GigabitEthernet1/0/0] ip address 10.1.1.2 24 [~RouterB-GigabitEthernet1/0/0] quit [~RouterB] interface pos 1/0/0 [~RouterB-Pos1/0/0] undo shutdown [~RouterB-Pos1/0/0] ip address 192.168.2.1 24 [~RouterB-Pos1/0/0] quit [~RouterB] ospf 1 [~RouterB-ospf-1] area 0 [~RouterB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255 [~RouterB-ospf-1-area-0.0.0.0] network 192.168.2.0 0.0.0.255 [~RouterB-ospf-1-area-0.0.0.0] commit [~RouterB-ospf-1-area-0.0.0.0] quit [~RouterB-ospf-1] quit
<HUAWEI> system-view [~HUAWEI] sysname RouterC [~HUAWEI] commit [~RouterC] interface pos 1/0/0 [~RouterC-Pos1/0/0] undo shutdown [~RouterC-Pos1/0/0] ip address 192.168.1.2 24 [~RouterC-Pos1/0/0] quit [~RouterC] interface pos 2/0/0 [~RouterC-Pos2/0/0] undo shutdown [~RouterC-Pos2/0/0] ip address 192.168.2.2 24 [~RouterC-Pos2/0/0] quit [~RouterC] interface gigabitethernet 3/0/0 [~RouterC-GigabitEthernet3/0/0] undo shutdown [~RouterC-GigabitEthernet3/0/0] ip address 20.1.1.1 24 [~RouterC-GigabitEthernet3/0/0] quit [~RouterC] ospf 1 [~RouterC-ospf-1] area 0 [~RouterC-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255 [~RouterC-ospf-1-area-0.0.0.0] network 192.168.2.0 0.0.0.255 [~RouterC-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255 [~RouterC-ospf-1-area-0.0.0.0] commit [~RouterC-ospf-1-area-0.0.0.0] quit [~RouterC-ospf-1] quit
Step 2 Configure a VRRP backup group. # On Router A, assign an IP address to each interface, create backup group 1, and set the priority of Router A in the backup group to 120. That is, Router A functions as the master device.
<RouterA> system-view
Issue 01 (2011-10-15)
137
[~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 virtual-ip 10.1.1.111 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 priority 120 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 preempt-mode timer delay 20 [~RouterA-GigabitEthernet1/0/0] commit [~RouterA-GigabitEthernet1/0/0] quit
# On Router B, assign an IP address to each interface, create backup group 1, and set the priority of Router B in the backup group to the default value. That is, Router B functions as the backup device.
<RouterB> system-view [~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] vrrp vrid 1 virtual-ip 10.1.1.111 [~RouterB-GigabitEthernet1/0/0] commit [~RouterB-GigabitEthernet1/0/0] quit
Step 3 Verify the configuration. l Verify that the VRRP backup group can provide the gateway function. After the configurations, Host A can ping through Host B. Run the display vrrp command on Router A. You can view that Router A is in the master state in the backup group. Then, run the display vrrp command on Router B. You can view that Router B is in the backup state in the backup group.
<RouterA> display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 10.1.1.111 PriorityRun : 120 PriorityConfig : 120 MasterPriority : 120 Preempt : YES Delay Time : 20 TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES <RouterB> display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Backup Virtual IP : 10.1.1.111 PriorityRun : 100 PriorityConfig : 100 MasterPriority : 120 Preempt : YES Delay Time : 0 TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES
Run the display ip routing-table command on Router A and Router B. You can view that a direct route destined for the virtual IP address exists in the routing table of Router A, and an OSPF route exists on the routing table of Router B. The command output on Router A and Router B is as follows:
<RouterA> display ip routing-table Route Flags: R - relied, D - download to fib -----------------------------------------------------------------------------Routing Tables: Public Destinations : 10 Routes : 10 Destination/Mask Proto Pre Cost Flags NextHop Interface 10.1.1.0/24 Direct 0 0 D 10.1.1.1 GigabitEthernet1/0/0 10.1.1.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0 10.1.1.111/32 Direct 0 0 D 127.0.0.1 InLoopBack0 20.1.1.0/24 OSPF 10 2 D 192.168.1.2 Pos1/0/0 127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0 127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
Issue 01 (2011-10-15)
138
192.168.1.0/24 Direct 0 0 D 192.168.1.1 Pos1/0/0 192.168.1.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0 192.168.1.2/32 Direct 0 0 D 192.168.1.2 Pos1/0/0 192.168.2.0/24 OSPF 10 2 D 10.1.1.2 GigabitEthernet1/0/0 <RouterB> display ip routing-table Route Flags: R - relied, D - download to fib -----------------------------------------------------------------------------Routing Tables: Public Destinations : 10 Routes : 10 Destination/Mask Proto Pre Cost Flags NextHop Interface 10.1.1.0/24 Direct 0 0 D 10.1.1.2 GigabitEthernet1/0/0 10.1.1.2/32 Direct 0 0 D 127.0.0.1 InLoopBack0 10.1.1.111/32 OSPF 10 3 D 192.168.2.2 POS1/0/0 20.1.1.0/24 OSPF 10 2 D 192.168.2.2 Pos1/0/0 127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0 127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0 192.168.1.0/24 OSPF 10 2 D 10.1.1.1 GigabitEthernet1/0/0 192.168.2.0/24 Direct 0 0 D 192.168.2.1 Pos1/0/0 192.168.2.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0 192.168.2.2/32 Direct 0 0 D 192.168.2.2 Pos1/0/0
l Verify that Router B can become the master device when Router A fails. Run the shutdown command on GE 1/0/0 of Router A to simulate a fault. Run the display vrrp command on Router A. You can view that Router A is in the backup state in the backup group. Then, run the display vrrp command on Router B. You can view that Router B is in the master state in the backup group.
<RouterA> display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Backup Virtual IP : 10.1.1.111 PriorityRun : 120 PriorityConfig : 120 MasterPriority : 120 Preempt : YES Delay Time : 20 TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES <RouterB> display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 10.1.1.111 PriorityRun : 100 PriorityConfig : 100 MasterPriority : 100 Preempt : YES Delay Time : 0 TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES
l Verify that Router A can preempt the master device after recovering from the fault. Run the undo shutdown command on GE 1/0/0 of Router A. After GE 1/0/0 goes Up, wait for 20s and run the display vrrp command on Router A. You can view that Router A restores the master state in the backup group. Then, run the display vrrp command on Router B. You can view that the status of Router B becomes backup.
<RouterA> display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 10.1.1.111 PriorityRun : 120 PriorityConfig : 120 MasterPriority : 120 Preempt : YES Delay Time : 20
Issue 01 (2011-10-15)
139

TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES <RouterB> display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Backup Virtual IP : 10.1.1.111 PriorityRun : 100 PriorityConfig : 100 MasterPriority : 120 Preempt : YES Delay Time : 0 TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES
----End
Configuration Files
# sysname RouterA # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.1 255.255.255.0 vrrp vrid 1 virtual-ip 10.1.1.111 vrrp vrid 1 priority 120 vrrp vrid 1 preempt-mode timer delay 20 # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 192.168.1.1 255.255.255.0 # ospf 1 area 0.0.0.0 network 192.168.1.0 0.0.0.255 network 10.1.1.0 0.0.0.255 return

# sysname RouterB # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.2 255.255.255.0 vrrp vrid 1 virtual-ip 10.1.1.111 # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 192.168.2.1 255.255.255.0 # ospf 1 area 0.0.0.0 network 192.168.2.0 0.0.0.255 network 10.1.1.0 0.0.0.255 return

# sysname RouterC # interface GigabitEthernet3/0/0
Issue 01 (2011-10-15)
140

undo shutdown ip address 20.1.1.1 255.255.255.0 # interface Pos1/0/0 undo shutdown link-protocol ppp clock master ip address 192.168.1.2 255.255.255.0 # interface Pos2/0/0 undo shutdown link-protocol ppp clock master ip address 192.168.2.2 255.255.255.0 # ospf 1 area 0.0.0.0 network 192.168.1.0 0.0.0.255 network 192.168.2.0 0.0.0.255 network 20.1.1.0 0.0.0.255 return
Related Tasks
3.3 Configuring a VRRP Backup Group in Master/Backup Mode
3.8.2 Example for Configuring VRRP Backup Groups in Load Balancing Mode
In this example, by configuring VRRP backup groups in load balancing mode, you can use the devices in the VRRP backup groups to back up each other and share traffic of a network.
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/ interface number. On an NE5000E cluster, the interface is numbered in the format of chassis ID/slot number/card number/interface number. This requires the chassis ID to be specified along with the slot number. As shown in Figure 3-5, l l l Router A is the master device in backup group 1 and the backup device in backup group 2. Router B is the master device in backup group 2 and the backup device in backup group 1. Host A in the LAN uses backup group 1 as the default gateway, and Host C uses backup group 2 as the default gateway. In this manner, the two backup groups can share data flows and back up each other.
Issue 01 (2011-10-15)
141
Figure 3-5 Networking diagram of configuring VRRP backup groups in load balancing mode
Backup group 2 RouterA Virtual IP Address: group 1:Master 10.1.1.112
HostA
10.1.1.100/24
group 2:Backup POS1/0/0 192.168.1.1/24 GE1/0/0 POS1/0/0 10.1.1.1/24 192.168.1.2/24
RouterC
GE3/0/0 20.1.1.1/24
10.1.1.101/24
HostC
Ethernet
Backup group 1 Virtual IP Address: 10.1.1.111
GE1/0/0 10.1.1.2/24 RouterB group 2:Master group 1:Backup
POS2/0/0 192.168.2.2/24 HostB 20.1.1.100/24 POS1/0/0 192.168.2.1/24
Configuration Precautions
The IP address of GE 1/0/0 on Router A and the IP address of GE 1/0/0 on Router B must be in the same network segment.
The configuration roadmap is as follows: 1. 2. Create two backup groups on GE 1/0/0 of Router A to ensure that Router A functions as the master device in backup group 1 and the backup device in backup group 2. Create two backup groups on GE 1/0/0 of Router B to ensure that Router B functions as the backup device in backup group 1 and the master device in backup group 2.
Data Preparation
To complete the configuration, you need the following data: l l ID and virtual IP address of a VRRP backup group Priority of each router in each VRRP backup group
Procedure
Step 1 Connect devices to ensure connectivity of the network. # Set the default gateway address used by Host A to 10.1.1.111 (the virtual IP address of backup group 1), the default gateway address used by Host B to 20.1.1.1, and the default gateway address used by Host C to 10.1.1.112 (the virtual IP address of backup group 2).
# Configure OSPF on Router A, Router B, and Router C. Step 2 Configure each VRRP backup group. # On Router A, configure GE 1/0/0, create backup group 1, and set the priority of Router A in backup group 1 to 120. That is, Router A functions as the master device. Create VRRP backup group 2 and set the priority of Router A in backup group 2 to the default value. Router A thus functions as a backup device.
<RouterA> system-view [~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] undo shutdown [~RouterA-GigabitEthernet1/0/0] ip address 10.1.1.1 24 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 virtual-ip 10.1.1.111 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 priority 120 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 2 virtual-ip 10.1.1.112 [~RouterA-GigabitEthernet1/0/0] commit [~RouterA-GigabitEthernet1/0/0] quit
# On Router B, configure GE 1/0/0, create backup group 1, and set the priority of Router B in backup group 1 to the default value. Router B thus functions as a backup device. Create VRRP backup group 2 and set the priority of Router B in backup group 2 to 120. Router B thus functions as a master device.
<RouterB> system-view [~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] undo shutdown [~RouterB-GigabitEthernet1/0/0] ip address 10.1.1.2 24 [~RouterB-GigabitEthernet1/0/0] vrrp vrid 1 virtual-ip 10.1.1.111 [~RouterB-GigabitEthernet1/0/0] vrrp vrid 2 virtual-ip 10.1.1.112 [~RouterB-GigabitEthernet1/0/0] vrrp vrid 2 priority 120 [~RouterB-GigabitEthernet1/0/0] commit [~RouterB-GigabitEthernet1/0/0] quit
Step 3 Verify the configuration. After the preceding configurations, Host A and Host C can successfully ping Host B. Run the tracert command on Host A and Host C to tracert the IP address of Host B. You can view that traffid from Host A reaches Host B through Router A and then Router C; traffic from Host C reaches Host B through Router B and then Router C. That is, Router A and Router B balance traffic in the network.
<HostA> tracert 20.1.1.100 traceroute to 20.1.1.100(20.1.1.100) 30 hops max,40 bytes packet 1 10.1.1.1 120ms 50 ms 60 ms 2 192.168.1.2 100 ms 60 ms 60 ms 3 20.1.1.100 130 ms 90 ms 90 ms <HostC> tracert 20.1.1.100 traceroute to 20.1.1.100(20.1.1.100) 30 hops max,40 bytes packet 1 10.1.1.2 30 ms 60 ms 40 ms 2 192.168.2.2 90 ms 60 ms 60 ms 3 20.1.1.100 70 ms 60 ms 90 ms
Run the display vrrp command on Router A. You can view that Router A functions as the master device in backup group 1 and the backup device in backup group 2.
<RouterA> display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 10.1.1.111 PriorityRun : 120 PriorityConfig : 120 MasterPriority : 120 Preempt : YES Delay Time : 0 TimerConfig : 1
Issue 01 (2011-10-15)
143

Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES GigabitEthernet1/0/0 | Virtual Router 2 State : Backup Virtual IP : 10.1.1.112 PriorityRun : 100 PriorityConfig : 100 MasterPriority : 120 Preempt : YES Delay Time : 0 TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0102 Check TTL : YES
Run the display vrrp command on Router B. You can view that Router B functions as the backup device in backup group 1 and the master device in backup group 2.
<RouterB> display vrrp GigabitEthernet1/0/0 | Virtual Router State : Backup Virtual IP : 10.1.1.111 PriorityRun : 100 PriorityConfig : 100 MasterPriority : 120 Preempt : YES Delay Time TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0101 Check TTL : YES GigabitEthernet1/0/0 | Virtual Router State : Backup Virtual IP : 10.1.1.112 PriorityRun : 120 PriorityConfig : 120 MasterPriority : 120 Preempt : YES Delay Time TimerConfig : 1 Auth Type : None Virtual Mac : 0000-5e00-0102 Check TTL : YES 1
: 0
: 0
----End
Configuration Files
# sysname RouterA # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.1 255.255.255.0 vrrp vrid 1 virtual-ip 10.1.1.111 vrrp vrid 1 priority 120 vrrp vrid 2 virtual-ip 10.1.1.112 # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 192.168.1.1 255.255.255.0 # ospf 1 area 0.0.0.0 network 192.168.1.0 0.0.0.255 network 10.1.1.0 0.0.0.255 return
Issue 01 (2011-10-15)
144

# sysname RouterB # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.2 255.255.255.0 vrrp vrid 1 virtual-ip 10.1.1.111 vrrp vrid 2 virtual-ip 10.1.1.112 vrrp vrid 2 priority 120 # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 192.168.2.1 255.255.255.0 # ospf 1 area 0.0.0.0 network 192.168.2.0 0.0.0.255 network 10.1.1.0 0.0.0.255 return

# sysname RouterC # interface GigabitEthernet3/0/0 undo shutdown ip address 20.1.1.1 255.255.255.0 # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 192.168.1.2 255.255.255.0 # interface Pos2/0/0 undo shutdown link-protocol ppp ip address 192.168.2.2 255.255.255.0 # ospf 1 area 0.0.0.0 network 192.168.1.0 0.0.0.255 network 192.168.2.0 0.0.0.255 network 20.1.1.0 0.0.0.255 return
Related Tasks
3.8.3 Example for Configuring VRRP Multi-instance

In this example, by configuring different default gateways for CEs in a VPN, you can configure VRRP backup groups in load balancing mode and enable hosts in the VPN to communicate with each other.
Issue 01 (2011-10-15)
145
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/ interface number. On an NE5000E cluster, the interface is numbered in the format of chassis ID/slot number/card number/interface number. This requires the chassis ID to be specified along with the slot number. As shown in Figure 3-6, VPN-RED and VPN-BLUE exist and MPLS and VRRP are configured. Table 3-1 Networking diagram of VRRP multi-instance Item Backup groups Network Requirements l PE-A and PE-B form backup group 1 and backup group 2. In backup group 1, PE-A functions as the master device and PE-B functions as the backup device; in backup group 2, PE-A functions as the backup device and PE-B functions as the master device. l CE-A uses the virtual IP address of backup group 1 as the default gateway address. l CE-B uses the virtual IP address of backup group 2 as the default gateway address. VPN instances to which CEs belong VPN instances to which interfaces on PEs belong l CE-A and CE-D belong to the VPN-BLUE instance. l CE-B and CE-C belong to the VPN-RED instance. l On PE-A, GE 1/0/0 belongs to the VPN-BLUE instance, and GE 2/0/0 belongs to the VPN-RED instance. l On PE-B, GE 1/0/0 belongs to the VPN-BLUE instance, and GE 2/0/0 belongs to the VPN-RED instance. l On PE-C, GE 1/0/0 belongs to the VPN-RED instance, and GE 2/0/0 belongs to the VPN-BLUE instance. Routing protocol and MPLS l OSPF is configured and MPLS is enabled in a public network. l Default routes are configured on CE-A and CE-B; CE-A and CEB exchange VPN route information with PE-A and PE-B, respectively. l BGP peer relationships are set up between PE-A, PE-B, and PE-C to transmit VPN route information.
Issue 01 (2011-10-15)
146
Figure 3-6 Networking diagram of VRRP with VPN multi-instance
HostA VPN BLUE CE-A Loopback1 GE1/0/0 PE-A GE1/0/0
HostC VPN RED
Public Network
CE-C
GE1/0/0 GE1/0/0
Loopback1
G E2 /0 /0
POS3/0/0
Backup group1 for VPN BLUE Backup group2 for VPN RED
P POS3/0/0
GE1/0/0/1
POS1/0/0 /0 G 2/0 PE-B S E1 PO /0 Loopback1 /0 POS3/0/0 POS3/0/0/4 GE2/0/0 CE-D CE-B Loopback1 HostD VPN BLUE
PE-C GE2/0/0
GE1/0/0
VPN RED HostB
Device P
Interface POS 1/0/0 POS 2/0/0 POS 3/0/0 Loopback1
IP Address 192.168.1.2/24 192.168.2.2/24 192.168.3.2/24 4.4.4.4/32 10.1.1.1/24 20.1.1.1/24 192.168.1.1/24 1.1.1.1/32 10.1.1.2/24 20.1.1.2/24 192.168.2.1/24 2.2.2.2/32 20.2.1.1/24 10.2.1.1/24 192.168.3.1/24 3.3.3.3/32
Instance to Which the Interface Belongs VPN-BLUE VPN-RED VPN-BLUE VPN-RED VPN-RED VPN-BLUE -
PE-A
GE 1/0/0 GE 2/0/0 POS 3/0/0 Loopback1
PE-B
PE-C
Issue 01 (2011-10-15)
147

CE-A CE-B CE-C CE-D GE 1/0/0 GE 1/0/0 GE 1/0/0 GE 1/0/0 10.1.1.100/24 20.1.1.100/24 20.2.1.100/24 10.2.1.100/24 -
Configuration Precautions
None.
The configuration roadmap is as follows: 1. 2. 3. Configure backup group 1 and backup group 2 on PE-A and PE-B. Configure PE-A as the master device and PE-B as the backup device in backup group 1. Configure PE-A as the backup device and PE-B as the master device in backup group 2.
Data Preparation
To complete the configuration, you need the following data: l l ID and virtual IP address of each VRRP backup group Priority of each router in each VRRP backup group
Procedure
Step 1 Configure OSPF on each PE and P to ensure that the backbone network is reachable. The configuration details are not mentioned here. Step 2 Enable MPLS and MPLS LDP, and set up LDP LSPs on the MPLS backbone network. The configuration details are not mentioned here. Step 3 Configure VPN instances on each PE and connect each CE to a PE. The configuration details are not mentioned here. Step 4 Set up an MP-IBGP peer relationship between PEs. The configuration details are not mentioned here. Step 5 Configure a default route on each of CE-A and CE-B. The configuration details are not mentioned here. For configurations from Steps 1 to 5, refer to the chapter "BGP/MPLS IP VPN" in the HUAWEI NetEngine5000E Core Router Configuration Guide - VPN. You can also see the configuration files in this example. Step 6 Configure multi-instance VRRP on PE-A and PE-B. # Create backup group 1 on PE-A and set the priority of PE-A to 120 in backup group 1. PE-A thus functions as a master device.
<PE-A> system-view [~PE-A] interface gigabitethernet 1/0/0
Issue 01 (2011-10-15)
148

[~PE-A-GigabitEthernet1/0/0] [~PE-A-GigabitEthernet1/0/0] [~PE-A-GigabitEthernet1/0/0] [~PE-A-GigabitEthernet1/0/0] vrrp vrid 1 virtual-ip 10.1.1.111 vrrp vrid 1 priority 120 commit quit
# Create backup group 2 on PE-A and set the priority of PE-A to the default value in backup group 2. PE-A thus functions as a backup device.
[~PE-A] interface gigabitethernet 2/0/0 [~PE-A-GigabitEthernet2/0/0] vrrp vrid 2 virtual-ip 20.1.1.111 [~PE-A-GigabitEthernet2/0/0] commit [~PE-A-GigabitEthernet2/0/0] quit
# Create backup group 1 on PE-B and set the priority of PE-B to the default value in backup group 1. PE-B thus functions as a backup device.
<PE-B> system-view [~PE-B] interface gigabitethernet 1/0/0 [~PE-B-GigabitEthernet1/0/0] vrrp vrid 1 virtual-ip 10.1.1.111 [~PE-B-GigabitEthernet1/0/0] commit [~PE-B-GigabitEthernet1/0/0] quit
# Create backup group 2 on PE-B and set the priority of PE-B to 120 in backup group 2. PE-B thus functions as a master device.
[~PE-B] interface gigabitethernet 2/0/0 [~PE-B-GigabitEthernet2/0/0/] vrrp vrid 2 virtual-ip 20.1.1.111 [~PE-B-GigabitEthernet2/0/0/] vrrp vrid 2 priority 120 [~PE-B-GigabitEthernet2/0/0/] commit [~PE-B-GigabitEthernet2/0/0/] quit
Step 7 Verify the configuration. Run the display ip routing-table vpn-instance vpn-instance-name command on PE-A and PEB. You can view that a route destined for the virtual IP address exists in the routing table of PEA rather than PE-B. Take the display on PE-A as an example.
<PE-A> display ip routing-table vpn-instance VPN-BLUE Route Flags: R - relied, D - download to fib -----------------------------------------------------------------------------Routing Tables: VPN-BLUE Destinations : 3 Routes : 3 Destination/Mask Proto Pre Cost Flags NextHop Interface 10.1.1.0/24 Direct 0 0 D 10.1.1.2 GigabitEthernet1/0/0 10.1.1.1/32 Direct 0 0 D 10.1.1.1 InLoopBack0 10.1.1.111/32 Direct 0 0 D 127.0.0.1 GigabitEthernet1/0/0
Run the ping command supporting multi-VRRP on PE-A and PE-B.

<PE-A> ping -vpn-instance VPN-BLUE 10.1.1.111
You can view that the virtual IP address 10.1.1.111 can be successfully pinged. ----End
Configuration Files
l Configuration file of PE-A
# sysname PE-A # ip vpn-instance VPN-BLUE route-distinguisher 100:1 vpn-target 100:1 export-extcommunity vpn-target 100:1 import-extcommunity
Issue 01 (2011-10-15)
149
# ip vpn-instance VPN-RED route-distinguisher 200:1 vpn-target 200:1 export-extcommunity vpn-target 200:1 import-extcommunity # mpls lsr-id 1.1.1.1 mpls # mpls ldp # interface GigabitEthernet1/0/0 undo shutdown ip binding vpn-instance VPN-BLUE ip address 10.1.1.1 255.255.255.0 vrrp vrid 1 virtual-ip 10.1.1.111 vrrp vrid 1 priority 120 # interface GigabitEthernet2/0/0/ undo shutdown ip binding vpn-instance VPN-RED ip address 20.1.1.1 255.255.255.0 vrrp vrid 2 virtual-ip 20.1.1.111 # interface Pos3/0/0 undo shutdown link-protocol ppp ip address 192.168.1.1 255.255.255.0 mpls mpls ldp # interface LoopBack1 ip address 1.1.1.1 255.255.255.255 # bgp 100 peer 3.3.3.3 as-number 100 peer 3.3.3.3 connect-interface LoopBack1 # ipv4-family unicast undo synchronization peer 3.3.3.3 enable # ipv4-family vpnv4 policy vpn-target peer 3.3.3.3 enable # ipv4-family vpn-instance VPN-BLUE import-route direct import-route static # ipv4-family vpn-instance VPN-RED import-route direct import-route static # ospf 1 area 0.0.0.0 network 192.168.1.0 0.0.0.255 network 1.1.1.1 0.0.0.0 # ip route-static vpn-instance VPN-BLUE 0.0.0.0 0.0.0.0 10.1.1.100 ip route-static vpn-instance VPN-RED 0.0.0.0 0.0.0.0 20.1.1.100 return
Configuration file of PE-B

# sysname PE-B # ip vpn-instance VPN-BLUE route-distinguisher 100:1 vpn-target 100:1 export-extcommunity
Issue 01 (2011-10-15)
150
vpn-target 100:1 import-extcommunity # ip vpn-instance VPN-RED route-distinguisher 200:1 vpn-target 200:1 export-extcommunity vpn-target 200:1 import-extcommunity # mpls lsr-id 2.2.2.2 mpls # mpls ldp # interface GigabitEthernet1/0/0 undo shutdown ip binding vpn-instance VPN-BLUE ip address 10.1.1.2 255.255.255.0 vrrp vrid 1 virtual-ip 10.1.1.111 # interface GigabitEthernet2/0/0/ undo shutdown ip binding vpn-instance VPN-RED ip address 20.1.1.2 255.255.255.0 vrrp vrid 2 virtual-ip 20.1.1.111 vrrp vrid 2 priority 120 # interface Pos3/0/0 undo shutdown link-protocol ppp ip address 192.168.2.1 255.255.255.0 mpls mpls ldp # interface LoopBack1 ip address 2.2.2.2 255.255.255.255 # bgp 100 peer 3.3.3.3 as-number 100 peer 3.3.3.3 connect-interface LoopBack1 # ipv4-family unicast undo synchronization peer 3.3.3.3 enable # ipv4-family vpnv4 policy vpn-target peer 3.3.3.3 enable # ipv4-family vpn-instance VPN-BLUE import-route direct import-route static # ipv4-family vpn-instance VPN-RED import-route direct import-route static # ospf 1 area 0.0.0.0 network 192.168.2.0 0.0.0.255 network 2.2.2.2 0.0.0.0 # ip route-static vpn-instance VPN-BLUE 0.0.0.0 0.0.0.0 10.1.1.100 ip route-static vpn-instance VPN-RED 0.0.0.0 0.0.0.0 20.1.1.100 return
Related Tasks
Issue 01 (2011-10-15)
151
3.8.4 Example for Configuring a VRRP Backup Group to Track Interfaces

In this example, a VRRP backup group is configured to track interfaces. If the interface or another network-connected interface on the same device fails, a master/backup switchover is performed.
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/subcard number/ interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/ slot number/subcard number/interface number. If the slot number is specified, the chassis ID of the slot must also be specified. On the network shown in Figure 3-7, Host A is connected to Host B by using a default gateway. A VRRP backup group consists of Router A and Router B. Router A is the master device, and Router B is the backup device. Host A sends traffic to Host B along a path Host A -> Router A -> Router C -> Host B.If the link between Router A and Router C fails, traffic from Host A to Host B is discarded. To prevent the problem, the VRRP backup group needs to be configured to track the interfaces connecting Router A to Router C and connecting Router B to Router C. Figure 3-7 Networking diagram for a VRRP backup group to track interfaces
Backup group 1 Virtual IP Address: 10.1.1.111 RouterA Master

GE1/0/0 10.1.1.1/24
POS1/0/0 192.168.1.1/24
POS1/0/0 192.168.1.2/24 GE3/0/0 20.1.1.1/24 RouterC POS2/0/0 HostB 192.168.2.2/24 20.1.1.100/24 POS1/0/0 192.168.2.1/24
HostA
10.1.1.100/24 GE1/0/0 10.1.1.2/24
Ethernet
RouterB Backup
Configuration Notes
The IP address of GE 1/0/0 on Router A and IP address of GE 1/0/0 on Router B must be on the same network segment.
The configuration roadmap is as follows: 1. 2. 3. 4. Configure VRRP backup group 1 on GE 1/0/0 of Router A. Set the VRRP priority value of Router A to be higher than that of Router B so that Router A can be the master device. Configure VRRP backup group 1 on GE 1/0/0 of Router B. Set the VRRP priority value of Router B to the default value so that Router B can be the backup device. Configure VRRP backup group 1 on Router A to track POS 1/0/0 connected to Router C. Configure VRRP backup group 1 on Router B to track POS 1/0/0 connected to Router C.
Data Preparation
To complete the configuration, you need the following data: l l Virtual IP address and ID of a VRRP backup group Priority value of each device in a VRRP backup group
Procedure
Step 1 Assign IP addresses to each interface on Router A, Router B, and Router C, and configure OSPF to ensure that these devices communicate with each other. # Configure Router A.
<HUAWEI> system-view [~HUAWEI] sysname RouterA [~HUAWEI] commit [~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] undo shutdown [~RouterA-GigabitEthernet1/0/0] ip address 10.1.1.1 24 [~RouterA-GigabitEthernet1/0/0] quit [~RouterA] interface pos 1/0/0 [~RouterA-Pos1/0/0] undo shutdown [~RouterA-Pos1/0/0] ip address 192.168.1.1 24 [~RouterA-Pos1/0/0] quit [~RouterA] ospf 1 [~RouterA-ospf-1] area 0 [~RouterA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255 [~RouterA-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255 [~RouterA-ospf-1-area-0.0.0.0] commit [~RouterA-ospf-1-area-0.0.0.0] quit [~RouterA-ospf-1] quit
<HUAWEI> system-view [~HUAWEI] sysname RouterB [~HUAWEI] commit [~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] undo shutdown [~RouterB-GigabitEthernet1/0/0] ip address 10.1.1.2 24 [~RouterB-GigabitEthernet1/0/0] quit [~RouterB] interface pos 1/0/0 [~RouterB-Pos1/0/0] undo shutdown [~RouterB-Pos1/0/0] ip address 192.168.2.1 24 [~RouterB-Pos1/0/0] quit [~RouterB] ospf 1 [~RouterB-ospf-1] area 0 [~RouterB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255 [~RouterB-ospf-1-area-0.0.0.0] network 192.168.2.0 0.0.0.255 [~RouterB-ospf-1-area-0.0.0.0] commit
Issue 01 (2011-10-15)
153

[~RouterB-ospf-1-area-0.0.0.0] quit [~RouterB-ospf-1] quit
<HUAWEI> system-view [~HUAWEI] sysname RouterC [~HUAWEI] commit [~RouterC] interface pos 1/0/0 [~RouterC-Pos1/0/0] undo shutdown [~RouterC-Pos1/0/0] ip address 192.168.1.2 24 [~RouterC-Pos1/0/0] quit [~RouterC] interface pos 2/0/0 [~RouterC-Pos2/0/0] undo shutdown [~RouterC-Pos2/0/0] ip address 192.168.2.2 24 [~RouterC-Pos2/0/0] quit [~RouterC] interface gigabitethernet 3/0/0 [~RouterC-GigabitEthernet3/0/0] undo shutdown [~RouterC-GigabitEthernet3/0/0] ip address 20.1.1.1 24 [~RouterC-GigabitEthernet3/0/0] quit [~RouterC] ospf 1 [~RouterC-ospf-1] area 0 [~RouterC-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255 [~RouterC-ospf-1-area-0.0.0.0] network 192.168.2.0 0.0.0.255 [~RouterC-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255 [~RouterC-ospf-1-area-0.0.0.0] commit [~RouterC-ospf-1-area-0.0.0.0] quit [~RouterC-ospf-1] quit
Step 2 Configure a VRRP backup group. # Configure VRRP backup group 1 on Router A, and set the VRRP priority value of Router A to 120 so that Router A is the master device.
[~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 virtual-ip 10.1.1.111 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 priority 120 [~RouterA-GigabitEthernet1/0/0] commit [~RouterA-GigabitEthernet1/0/0] quit
# Configure VRRP backup group 1 on Router B, without setting the VRRP priority value of Router B. This allows the default value to take effect and Router B to function as the backup device.
[~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 virtual-ip 10.1.1.111 [~RouterA-GigabitEthernet1/0/0] commit [~RouterA-GigabitEthernet1/0/0] quit
Step 3 Configure the VRRP backup group to track an interface. # Configure Router A.
[~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 track interface pos 1/0/0 reduced 20 [~RouterA-GigabitEthernet1/0/0] commit [~RouterA-GigabitEthernet1/0/0] quit
[~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] vrrp vrid 1 track interface pos 1/0/0 increased 20 [~RouterB-GigabitEthernet1/0/0] commit [~RouterB-GigabitEthernet1/0/0] quit

After the preceding configurations are complete, run the display vrrp command on Router A or Router B. Information about the interface tracked by the VRRP backup group and the interface status are displayed. Take the display on Router A as an example.
[~RouterA] display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 10.10.1.111 PriorityRun : 120 PriorityConfig : 120 MasterPriority : 120 Preempt : YES TimerRun : 1 TimerConfig : 1 Auth Type : NONE Virtual Mac : 0000-5e00-0101 Check TTL : YES Track IF : Pos1/0/0 IF State : UP
Delay Time : 0
# Run the shutdown command on POS 1/0/0 of Router A to simulate a fault.

[~RouterA] interface pos 1/0/0 [~RouterA-Pos1/0/0] shutdown [~RouterA-Pos1/0/0] commit [~RouterA-Pos1/0/0] quit
Run the display vrrp command on Router A. The VRRP status of Router A has become Backup.
[~RouterA] display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Backup Virtual IP : 10.10.1.111 PriorityRun : 100 PriorityConfig : 120 MasterPriority : 120 Preempt : YES TimerRun : 1 TimerConfig : 1 Auth Type : NONE Virtual Mac : 0000-5e00-0101 Check TTL : YES Track IF : Pos1/0/0 IF State : DOWN
Delay Time : 0
Run the display vrrp command on Router B. The VRRP status of Router B has become Master.
GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 10.10.1.111 PriorityRun : 120 PriorityConfig : 100 MasterPriority : 120 Preempt : YES TimerRun : 1 TimerConfig : 1 Auth Type : NONE Virtual Mac : 0000-5e00-0101 Check TTL : YES Track IF : Pos1/0/0 IF State : UP
Delay Time : 0
priority increased :20
----End
Configuration Files
l
Issue 01 (2011-10-15)
Configuration file of Router A


# sysname RouterA # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.1 255.255.255.0 vrrp vrid 1 virtual-ip 10.1.1.111 vrrp vrid 1 priority 120 vrrp vrid 1 track interface pos 1/0/0 reduced 20 # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 192.168.1.1 255.255.255.0 # ospf 1 area 0.0.0.0 network 10.1.1.0 0.0.0.255 network 192.168.1.0 0.0.0.255 return

# sysname RouterB # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.2 255.255.255.0 vrrp vrid 1 virtual-ip 10.1.1.111 vrrp vrid 1 track interface pos 1/0/0 increased 20 # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 192.168.2.1 255.255.255.0 # ospf 1 area 0.0.0.0 network 10.1.1.0 0.0.0.255 network 192.168.2.0 0.0.0.255 return

# sysname RouterC # interface Pos1/0/0 undo shutdown link-protocol ppp ip address 192.168.1.2 255.255.255.0 # interface Pos2/0/0 undo shutdown link-protocol ppp ip address 192.168.2.2 255.255.255.0 # interface GigabitEthernet3/0/0 undo shutdown link-protocol ppp ip address 20.1.1.1 255.255.255.0 # ospf 1 area 0.0.0.0 network 192.168.1.0 0.0.0.255 network 192.168.2.0 0.0.0.255 network 20.1.1.0 0.0.0.255 return
Issue 01 (2011-10-15)
156
Related Tasks
3.8.5 Example for Configuring a VRRP Backup Group to Track a BFD Session
In this example, a VRRP backup group is configured to track a BFD session. If the interface on which the VRRP status is Master or the link monitored by BFD is Down, the backup device in the VRRP backup group takes over traffic from the master device.
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/subcard number/ interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/ slot number/subcard number/interface number. If the slot number is specified, the chassis ID of the slot must also be specified. On the network shown in Figure 3-8, Router A, Router B, Switch A, Switch B, a Universal Media Gateway (UMG) form a simple next generation network (NGN) functioning as a bearer network. The networking is as follows: l l The UMG is dual homed to Router A and Router B through Switch A and Switch B, respectively. A VRRP backup group is configured on Router A and Router B. Router A is the master device, and Router B is the backup device.
If Router A fails or the GE link between Router A and RouterB fails, the VRRP backup group is required to perform a master/backup switchover within 1 second, implementing rapid route convergence on the bearer network. As a BFD session rapidly monitors a link on a network, the VRRP backup group needs to track the BFD session.
Issue 01 (2011-10-15)
157
Figure 3-8 Networking diagram for a VRRP backup group to track a BFD session
Backbone Network
RouterA GE1/0/0 10.1.1.1/24 SwitchA VLAN Backup group 1 Virtual IP address: 10.1.1.111
RouterB GE1/0/0 10.1.1.2/24 SwitchB
UMG
Configuration Notes
The IP address of GE 1/0/0 on Router A and IP address of GE 1/0/0 on Router B must be on the same network segment.
The configuration roadmap is as follows: 1. 2. 3. Configure a BFD session on Router A and Router B to monitor Router A, Router B, the link from Router A to Switch A, and the link from Router B to Switch B. Configure a VRRP backup group on GE 1/0/0 of Router A and GE 1/0/0 of Router B. Router A is the master device, and Router B is the backup device. The VRRP backup group on Router B (backup) is configured to track the BFD session. If the BFD session goes Down, the VRRP backup group immediately performs a master/ backup switchover.
Data Preparation
To complete the configuration, you need the following data: l l l Local and remote discriminators of a BFD session Virtual IP address and ID of a VRRP backup group Priority value of each device in a VRRP backup group
Procedure
Step 1 Configure a BFD session.
# Configure Router A.
<HUAWEI> system-view [~HUAWEI] sysname RouterA [~HUAWEI] commit [~RouterA] bfd [~RouterA-bfd] quit [~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] ip address 10.1.1.1 24 [~RouterA-GigabitEthernet1/0/0] quit [~RouterA] bfd trackbfd bind peer-ip 10.1.1.2 interface gigabitethernet 1/0/0 [~RouterA-bfd-session-trackbfd] discriminator local 1 [~RouterA-bfd-session-trackbfd] discriminator remote 2 [~RouterA-bfd-session-trackbfd] commit [~RouterA-bfd-session-trackbfd] quit
<HUAWEI> system-view [~HUAWEI] sysname RouterB [~HUAWEI] commit [~RouterB] bfd [~RouterB-bfd] quit [~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] ip address 10.1.1.2 24 [~RouterB-GigabitEthernet1/0/0] quit [~RouterB] bfd trackbfd bind peer-ip 10.1.1.1 interface gigabitethernet 1/0/0 [~RouterB-bfd-session-trackbfd] discriminator local 2 [~RouterB-bfd-session-trackbfd] discriminator remote 1 [~RouterB-bfd-session-trackbfd] commit [~RouterB-bfd-session-trackbfd] quit
# After the preceding configurations are complete, run the display bfd session all command on Router A or Router B. A BFD session has been established and its status is Up. Take the display on Router A as an example.
[~RouterA] display bfd session all -----------------------------------------------------------------------------Local Remote PeerIpAddr State Type InterfaceName -----------------------------------------------------------------------------1 2 10.1.1.2 Up S_IP_IF GigabitEthernet1/0/0 -----------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
Step 2 Configure VRRP backup group 1. # Configure VRRP backup group 1 on Router A, and set the VRRP priority value of Router A to 120 so that Router A can be the master device.
[~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 virtual-ip 10.1.1.111 [~RouterA-GigabitEthernet1/0/0] vrrp vrid 1 priority 120 [~RouterA-GigabitEthernet1/0/0] commit [~RouterA-GigabitEthernet1/0/0] quit
# Configure VRRP backup group 1 on Router B, without setting the VRRP priority value of Router B. This allows the default value to take effect and Router B to function as the backup device.
[~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] vrrp vrid 1 virtual-ip 10.1.1.111 [~RouterB-GigabitEthernet1/0/0] commit [~RouterB-GigabitEthernet1/0/0] quit
After the preceding configurations are complete, run the display vrrp command on Router A and Router B. The VRRP status of Router A is Master, and the VRRP status of Router B is Backup.

[~RouterA] display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 10.10.1.111 PriorityRun : 120 PriorityConfig : 120 MasterPriority : 120 Preempt : YES TimerRun : 1 TimerConfig : 1 Auth Type : NONE Virtual Mac : 0000-5e00-0101 Check TTL : YES [~RouterB] display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Backup Virtual IP : 10.10.1.111 PriorityRun : 100 PriorityConfig : 100 MasterPriority : 120 Preempt : YES TimerRun : 1 TimerConfig : 1 Auth Type : NONE Virtual Mac : 0000-5e00-0101 Check TTL : YES
Delay Time : 0
Delay Time : 0
Step 3 Configure the VRRP backup group to track the BFD session on Router B.
[~RouterB] interface gigabitethernet 1/0/0 [~RouterB-GigabitEthernet1/0/0] vrrp vrid 1 track bfd-session 2 increased 40 [~RouterB-GigabitEthernet1/0/0] commit [~RouterB-GigabitEthernet1/0/0] quit
After the preceding configurations are complete, run the display vrrp command on Router B. The local discriminator and the status of the BFD session tracked by the VRRP backup group are displayed.
[~RouterB] display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Backup Virtual IP : 10.10.1.111 PriorityRun : 100 PriorityConfig : 100 MasterPriority : 120 Preempt : YES TimerRun : 1 TimerConfig : 1 Auth Type : NONE Virtual Mac : 0000-5e00-0101 Check TTL : YES Track BFD : 2 BFD-Session State : UP
Delay Time : 0
Priority increased : 40
Step 4 Verify the configuration. # Run the shutdown command on GE 1/0/0 of Router A to simulate a link fault.
[~RouterA] interface gigabitethernet 1/0/0 [~RouterA-GigabitEthernet1/0/0] shutdown [~RouterA-GigabitEthernet1/0/0] commit [~RouterA-GigabitEthernet1/0/0] quit
Run the display vrrp command on Router A. The VRRP status of Router A has become Initialize.
[~RouterA] display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Initialize Virtual IP : 10.10.1.111
Issue 01 (2011-10-15)
160

PriorityRun PriorityConfig MasterPriority Preempt TimerRun TimerConfig Auth Type Virtual Mac Check TTL : : : : : : : : : 0 120 0 YES 1 1 NONE 0000-5e00-0101 YES
Delay Time : 0
Run the display vrrp command on Router B. The VRRP status of Router B has become Master.
[~RouterB] display vrrp GigabitEthernet1/0/0 | Virtual Router 1 State : Master Virtual IP : 10.10.1.111 PriorityRun : 140 PriorityConfig : 100 MasterPriority : 140 Preempt : YES Delay Time : 0 TimerRun : 1 TimerConfig : 1 Auth Type : NONE Virtual Mac : 0000-5e00-0101 Check TTL : YES Track BFD : 2 priority increased :40 BFD-Session State : DOWN
----End
Configuration Files
# sysname RouterA # bfd # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.1 255.255.255.0 vrrp vrid 1 virtual-ip 10.1.1.111 vrrp vrid 1 priority 120 # bfd trackbfd bind peer-ip 10.1.1.2 interface GigabitEthernet1/0/0 discriminator local 1 discriminator remote 2 return

# sysname RouterB # bfd # interface GigabitEthernet1/0/0 undo shutdown ip address 10.1.1.2 255.255.255.0 vrrp vrid 1 virtual-ip 10.1.1.111 vrrp vrid 1 track bfd-session 2 increased 40 # bfd trackbfd bind peer-ip 10.1.1.1 interface GigabitEthernet1/0/0 discriminator local 2 discriminator remote 1 return
Issue 01 (2011-10-15)
161
Related Tasks
Issue 01 (2011-10-15)
162
4 EFM OAM Configuration
4
About This Chapter
EFM OAM Configuration
This chapter describes Ethernet OAM and its configurations. By configuring EFM OAM, you can implement link-level Ethernet OAM detection to improve network reliability. EFM OAM is mainly applied to MANs. 4.1 Overview of EFM OAM Ethernet Operation, Administration, and Management (OAM) effectively improves manageability and maintainability of Ethernets and guarantees network stability. 4.2 EFM OAM Features Supported by the NE5000E EFM OAM defines Ethernet physical layer specifications and implements Ethernet OAM for user access. EFM OAM is link-level OAM for link detection in the last mile. 4.3 Configuring Basic EFM OAM Functions By configuring basic EFM OAM functions, you can detect link connectivity between two directly connected devices. 4.4 Configuring Link Monitoring You can configure the function that detects error codes, error frames, and error frame seconds for link fault detection and location. 4.5 Testing the Packet Loss Ratio of a Physical Link By configuring remote loopback, you can detect the link connectivity, test the packet loss ratio of a physical link, and take effective measures to ensure link performance. 4.6 Configuring Association Between EFM and Interfaces In the scenario with primary and backup links, EFM OAM can be associated with an interface for rapid service switchover. 4.7 Maintaining EFM OAM By maintaining EFM OAM, you can monitor the operation status of EFM OAM and debug EFM OAM when a fault occurs. 4.8 Configuration Examples This section provides several examples for configuring EFM OAM. You can comprehend the configuration procedures by using the configuration flowchart. Each configuration example
Issue 01 (2011-10-15)
163
consists of information about the networking requirements, configuration notes, and configuration roadmap.
Issue 01 (2011-10-15)
164
4.1 Overview of EFM OAM

Ethernet Operation, Administration, and Management (OAM) effectively improves manageability and maintainability of Ethernets and guarantees network stability. The Ethernet technology features easy implementation, low costs, and increasing bandwidth. It has been widely used on enterprise networks, MANs, and WANs as a type of service or network structure. The traditional Ethernet has weak maintainability and operability. The expanding application scope of the Ethernet strongly requires Ethernet OAM. Ethernet OAM effectively improves manageability and maintainability of Ethernets and guarantees network stability. Ethernet OAM manages faults and performance. Ethernet OAM is classified into link-level and network-level Ethernet OAM. Link-level Ethernet OAM technologies, such as Ethernet in the First Mile (EFM) OAM defined in IEEE 802.3ah, are introduced to implement Ethernet OAM in the last mile. EFM OAM provides functions including link connectivity detection, link fault monitoring, remote fault notification, and remote loopback for two directly connected devices.
4.2 EFM OAM Features Supported by the NE5000E

EFM OAM defines Ethernet physical layer specifications and implements Ethernet OAM for user access. EFM OAM is link-level OAM for link detection in the last mile. EFM OAM supported by the NE5000E provides the following functions.
Peer Discovery
When an interface on the device and the remote interface are both enabled with EFM OAM, the two interfaces send and respond to OAM Protocol Data Units (PDUs) to determine whether their EFM OAM configurations match. This is called OAM discovery. If their EFM OAM configurations match, the two interfaces enter the EFM OAM Detect state. In the Detect state, the two interfaces periodically send OAM PDUs to maintain their neighbor relationship.
Link Monitoring
Link monitoring is a link fault detection mechanism. If an interface detects threshold-crossing events of error frames, error codes, or error frame seconds, it sends an OAM PDU to notify the remote device of the link fault. Among the threshold-crossing events: l l l The threshold-crossing event of error frames indicates that the number of error frames detected on an interface within a specified period reaches or exceeds the set threshold. The threshold-crossing event of error codes indicates that the number of error codes detected on an interface within a specified period reaches or exceeds the set threshold. The threshold-crossing event of error frame seconds indicates that the number of error frame seconds detected on an interface within a specified period reaches or exceeds the set threshold.
An error frame second is a 1-second interval during which at least one error frame is detected.
Issue 01 (2011-10-15)
165
Fault Notification
If one of the following events occurs on the local device, the local device sends a message to notify the event to the remote device, logs the event, and then reports it to an NMS: l l l l The system is restarted. An interface board is reset. An interface fault occurs. Protocol packets time out.
After receiving the notification message, the remote device logs the event described in the message and reports the event to the NMS.
Remote Loopback
When the local interface sends non-OAM PDUs to the remote interface, the remote interface transmits back non-OAM PDUs to the local interface, but not forwards non-OAM PDUs based on their destination addresses. This is called remote loopback. Remote loopback can be used to locate link faults and test the link quality. The EFM OAM working mode is an attribute of an interface enabled with EFM OAM. It includes two modes, namely, active mode and passive mode. Only an interface in active mode can initiate peer discovery and remote loopback.
4.3 Configuring Basic EFM OAM Functions

By configuring basic EFM OAM functions, you can detect link connectivity between two directly connected devices.
With the development of Ethernet services, carriers focus on the maintainability of devices. During the expansion of the Ethernet into a MAN or a WAN, there is an urgent need for implementing OAM on transmission networks. Maintenance methods for link-level Ethernet, however, are limited. Therefore, Ethernet OAM is introduced. The hierarchical and layered network architecture requires hierarchical and layered Ethernet OAM. The traditional Ethernet management function is implemented at the layers upper than the network layer. EFM OAM, which is link-level OAM, defines Ethernet physical layer specifications and implements Ethernet OAM for user access. On a MAN, EFM OAM is usually applied between Customer Edges (CEs) and Provider Edges (PEs). This guarantees reliability and stability of connections between the user network and carrier network. To test link connectivity between two directly connected devices on the network shown in Figure 4-1, perform this configuration task. Figure 4-1 Networking diagram for configuring basic EFM OAM functions
EFM OAM
Interface 1 (Active mode)
Interface 2 (Passive mode)
Issue 01 (2011-10-15)
166
Before configuring basic EFM OAM functions, complete the following tasks: l l Powering on the device and ensuring a successful self-check Ensuring that the link between two directly connected devices is an Ethernet physical link and the link works properly
Figure 4-2 Flowchart for configuring basic EFM OAM functions
Enable EFM OAM globally
Configure the EFM OAM working mode for an interface Set the maximum size of an OAM PDU
Setting the Interval at Which OAM PDUs Are Sent Set the timeout period for waiting for OAM PDUs Enable EFM OAM on an interface Mandatory procedure Optional procedure
Related Tasks
4.8.1 Example for Configuring EFM OAM
4.3.1 Enabling EFM OAM Globally

You must enable EFM OAM globally before configuring EFM OAM functions.
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
167

efm enable
EFM OAM is enabled globally. By default, EFM OAM is disabled globally. Step 3 Run:
commit
4.3.2 Configuring the EFM OAM Working Mode for an Interface

The EFM OAM working mode is an attribute of an interface enabled with EFM OAM. An interface works in either active mode or passive mode.
Context
NOTE
The EFM OAM working mode can be configured for an interface only when EFM OAM is globally enabled and EFM OAM is not enabled on the interface. After EFM OAM is enabled on the interface, the EFM OAM working mode of the interface cannot be changed.
Procedure
Step 1 Run:
system-view

The view of the interface on one end of a link is displayed. Step 3 Run:
efm mode { active | passive }
The EFM OAM working mode is configured for an interface. By default, the EFM OAM working mode of an interface is the active mode. At least one of two interfaces on both ends of a link must be configured to work in active mode. l If an interface is configured to work in active mode, it initiates the peer discovery process after being enabled with EFM OAM. l If an interface is configured to work in passive mode, it does not initiate the peer discovery process. Instead, it waits for OAM PDUs from the remote interface. If interfaces on both ends of a link are configured to work in active mode, link detection is also available. If two interfaces are configured to work in passive mode, link detection is unavailable. Step 4 Run:
commit
Issue 01 (2011-10-15)
168
4.3.3 (Optional) Setting the Maximum Size of an OAM PDU

After the maximum size of an OAM PDU is set on an interface, the interface discards the OAM PDUs greater than the set maximum size as illegal packets.
Procedure
Step 1 Run:
system-view

efm packet max-size size
The maximum size of an OAM PDU is set. By default, the maximum size of an OAM PDU is 128 bytes. The OAM PDUs greater than the set maximum size are discarded as illegal packets. If different maximum sizes of an OAM PDU are set for interfaces on both ends of a link, the two interfaces negotiate the actual maximum size at the peer discovery stage. The smaller value is taken as the actual maximum size of an OAM PDU. Step 4 Run:
commit
4.3.4 (Optional) Setting the Interval at Which OAM PDUs Are Sent
To change the frequency for sending OAM PDUs or limit bandwidth of OAM PDUs, you can set the interval at which OAM PDUs are sent.
Procedure
Step 1 Run:
system-view

The view of the interface on one end of a link is displayed.

Step 3 Run:
efm interval period-value
The interval at which OAM PDUs are sent is set. By default, the interval at which OAM PDUs are sent is 1000 ms. Interfaces on both ends of a link must be configured with the same interval at which OAM PDUs are sent. Otherwise, EFM session negotiation may fail, or the EFM session may flap.
NOTE
The interval at which OAM PDUs are sent can be set on an interface only when EFM OAM is globally enabled and EFM OAM is not enabled on the interface.
Step 4 Run:
commit
4.3.5 (Optional) Setting the Timeout Period for Waiting for OAM PDUs
To change the time required for link connectivity detection, you can set the timeout period for waiting for OAM PDUs.
Procedure
Step 1 Run:
system-view

efm timeout period-value
The timeout period for waiting for OAM PDUs is set. By default, the timeout period for waiting for OAM PDUs is 5000 ms. Interfaces on both ends of a link must be configured with the same timeout period for waiting for OAM PDUs. Otherwise, EFM session negotiation may fail, or the EFM session may flap. The set timeout period for waiting for OAM PDUs should be greater than the interval at which OAM PDUs are sent. Otherwise, EFM session negotiation may fail, or the EFM session may flap.
NOTE
The timeout period for waiting for OAM PDUs can be set on an interface only when EFM OAM is globally enabled and EFM OAM is not enabled on the interface.
Step 4 Run:

commit
4.3.6 Enabling EFM OAM on an Interface

Point-to-point EFM link detection can be performed only after EFM OAM is enabled on interfaces on both ends of a link. Do as follows on devices on both ends of the link.
Procedure
Step 1 Run:
system-view

efm enable (interface view)
EFM OAM is enabled on the interface. By default, EFM OAM is disabled on an interface.
NOTE
Before running this command, you must run the efm enable (system view) command to enable EFM OAM globally.
Step 4 Run:
commit

By checking EFM OAM configurations, you can check whether basic EFM OAM functions are configured successfully.
Prerequisite
The configurations of basic EFM OAM functions are complete.
Procedure
l l Run the display efm { all | interface interface-type interface-number } command to check EFM OAM configurations of interfaces. Run the display efm session { all | interface interface-type interface-number } command to check the EFM OAM protocol state of interfaces.
----End
Example
Run the display efm command, and you can view all EFM OAM configurations of the local interface and some EFM OAM configurations of the remote interface.
<HUAWEI> display efm interface gigabitethernet2/0/1 Item Value ---------------------------------------------------Interface: Gigabitethernet2/0/1 EFM Enable Flag: enable Mode: active OAMPDU MaxSize: 520 OAMPDU Interval: 100 OAMPDU Timeout: 300 ErrCodeNotification: disable ErrCodePeriod: 1 ErrCodeThreshold: 1 ErrFrameNotification: disable ErrFramePeriod: 1 ErrFrameThreshold: 1 ErrFrameSecondNotification: disable ErrFrameSecondPeriod: 60 ErrFrameSecondThreshold: 1 Hold Up Time: 10 TriggerIfDown: enable Remote MAC: 38ea-d910-1100 Remote EFM Enable Flag: enable Remote Mode: active Remote MaxSize: 520
If EFM OAM configurations of the local and remote interfaces match, the two interfaces enter the Detect state after EFM session negotiation succeeds. When this occurs, if you run the display efm session command on the local interface, you can see that the EFM OAM protocol state of the interface is displayed as Detect.
<HUAWEI> display efm session interface gigabitethernet2/0/1 Interface EFM State Loopback Timeout -------------------------------------------------------------------GigabitEthernet2/0/1 detect --
4.4 Configuring Link Monitoring

You can configure the function that detects error codes, error frames, and error frame seconds for link fault detection and location.
Ethernet fault detection is quite difficult to implement, especially when physical communications are not interrupted but network performance is slowly degraded. EFM OAM provides the link monitoring function, which is used to detect and locate link layer faults in different scenarios. In link monitoring, when a link fault occurs, the local device reports the fault to the remote device by sending OAM PDUs. The following faults can be notified: l l l
Issue 01 (2011-10-15)
Link fault: If link signals of the remote device are lost, an OAM PDU should be sent every second. Dying gasp: If an unexpected fault such as a board or system reset occurs, OAM PDUs should be sent continuously. Critical event: If an uncertain urgent event occurs, OAM PDUs should be sent continuously.
Before configuring link monitoring, complete the following task: Configuring Basic EFM OAM Functions
Figure 4-3 Flowchart for configuring link monitoring
Configure error frame detection Configure error code detection Configure error frame second detection Mandatory procedure Optional procedure
Related Tasks
4.4.1 (Optional) Configuring Error Frame Detection

Within a specified period, if the number of error frames detected on the local interface reaches or exceeds the set threshold, the local device reports the fault to the remote device.
Context
After the function that reports the detected error frames is configured on a local interface, a device generates a threshold-crossing event of error frames and reports the event to the remote device, if the number of error frames detected on the interface reaches or exceeds the specified threshold.
Procedure
Step 1 Run:
system-view

The view of the interface on one end of a link is displayed.

Step 3 Run:
efm error-frame period period
The period during which error frames are detected is set. By default, the period during which error frames are detected is 1 second. Step 4 Run:
efm error-frame threshold threshold
The threshold for the number of detected error frames is set. By default, the threshold for the number of detected error frames is 1. Step 5 Run:
efm error-frame notification enable
The interface is enabled to report the detected error frames. By default, an interface is disabled from reporting the detected error frames. Step 6 Run:
commit
4.4.2 (Optional) Configuring Error Code Detection

Within a specified period, if the number of error codes detected on the local interface reaches or exceeds the set threshold, the local device reports the fault to the remote device.
Context
After the function that reports the detected error codes is configured on a local interface, a device generates a threshold-crossing event of error codes and reports the event to the remote device, if the number of error codes detected on the interface reaches or exceeds the specified threshold.
Procedure
Step 1 Run:
system-view

efm error-code period period
The period during which error codes are detected is set. By default, the period during which error codes are detected is 1 second. Step 4 Run:
efm error-code threshold threshold
Issue 01 (2011-10-15)
174
The threshold for the number of detected error codes is set. By default, the threshold for the number of detected error codes is 1. Step 5 Run:
efm error-code notification enable
The interface is enabled to report the detected error codes. By default, an interface is disabled from reporting the detected error codes. Step 6 Run:
commit
4.4.3 (Optional) Configuring Error Frame Second Detection

Within a specified period, if the number of error frame seconds detected on the local interface reaches or exceeds the set threshold, the local device reports the fault to the remote device.
Context
An error frame second is a 1-second interval during which at least one error frame is detected. That is, an error frame second is the time period during which error frames are detected within the specified seconds. After the function that reports the detected error frame seconds is configured on a local interface, a device generates a threshold-crossing event of error frame seconds and reports the event to the remote device, if the number of error frame seconds detected on the interface reaches or exceeds the specified threshold.
Procedure
Step 1 Run:
system-view

efm error-frame-second period period
The period during which error frame seconds are detected is set. By default, the period during which error frame seconds are detected is 60 seconds. Step 4 Run:
efm error-frame-second threshold threshold
The threshold for the number of detected error frame seconds is set. By default, the threshold for the number of detected error frame seconds is 1.
Step 5 Run:
efm error-frame-second notification enable
The interface is enabled to report the detected error frame seconds. By default, an interface is disabled from reporting the detected error frame seconds. Step 6 Run:
commit

By checking EFM OAM configurations, you can check whether link monitoring is configured successfully.
Prerequisite
The configurations of link monitoring are complete.
Procedure
l Run the display efm { all | interface interface-type interface-number } command to check EFM OAM configurations of interfaces.
----End
Example
Run the display efm command, and you can view link monitoring configurations of interfaces.
<HUAWEI> display efm interface gigabitethernet1/0/0 Item Value ---------------------------------------------------Interface: Gigabitethernet1/0/0 EFM Enable Flag: enable Mode: active OAMPDU MaxSize: 520 OAMPDU Interval: 100 OAMPDU Timeout: 300 ErrCodeNotification: enable ErrCodePeriod: 2 ErrCodeThreshold: 2 ErrFrameNotification: enable ErrFramePeriod: 2 ErrFrameThreshold: 10 ErrFrameSecondNotification: disable ErrFrameSecondPeriod: 60 ErrFrameSecondThreshold: 1 Hold Up Time: 10 TriggerIfDown: enable Remote MAC: 38eb-d910-1100 Remote EFM Enable Flag: enable Remote Mode: active Remote MaxSize: 520
Issue 01 (2011-10-15)
176
4.5 Testing the Packet Loss Ratio of a Physical Link

By configuring remote loopback, you can detect the link connectivity, test the packet loss ratio of a physical link, and take effective measures to ensure link performance.
EFM OAM is introduced to implement Ethernet OAM in the last mile. Ethernet OAM provides the following functions: l l l Link detection and analysis Fault detection Loop test
EFM OAM provides link-level loopback. During loopback, interfaces on both ends of a link can analyze loopback statistics to check whether the link works properly. Periodically detecting loops helps to determine whether a link works properly. On-demand loop detection helps to locate the specific scope where a fault occurs. In loopback mode, the local interface sends testing packets to the remote interface. Based on the numbers of sent packets and received packets, the local device computes communication quality parameters such as the packet loss ratio of the current link to determine the link quality. Remote loopback is initiated by the interface in active mode. In loopback mode, to detect the connectivity, performance, or packet loss ratio of a link, you can perform this configuration task.
CAUTION
Configuring remote loopback affects service forwarding. Therefore, remote loopback must be configured on the link over which no service data is forwarded. For example, EFM OAM is configured on Router A and Router B, and remote loopback is configured on GE 1/0/1 on Router A, as shown in Figure 4-4. Testing packets are sent from Router A to Router B, and then the returning of the testing packets is observed on Router A. Figure 4-4 Networking diagram for testing the packet loss ratio
Testing packets RouterA GE1/0/1 (Active) EFM OAM
RouterB GE2/0/1 (Passive) Data flow of testing packets
Issue 01 (2011-10-15)
177
Before testing the packet loss ratio of a link, complete the following task: Configuring Basic EFM OAM Functions
Figure 4-5 Flowchart for testing the packet loss ratio of a link
Configure remote loopback
Send testing packets
Disable remote loopback Mandatory procedure Optional procedure
Related Tasks
4.5.1 Configuring Remote Loopback

Remote loopback can be used to locate remote faults and test the link quality. Do as follows on the device where an interface in active mode resides.
Procedure
Step 1 Run:
system-view

The view of the interface in active mode is displayed. Step 3 Run:

efm loopback start [ timeout timeout ]
The interface is configured to initiate remote loopback. By default, the timeout period of remote loopback is 20 minutes. After the timeout period expires, remote loopback is disabled automatically. To make a link remain in the remote loopback state, set the timeout period to 0. Remote loopback can be performed successfully only when EFM OAM protocol states of the local and remote interfaces are Detect and the EFM OAM working mode of the local interface
is active. You can use the display efm session { all | interface interface-type interfacenumber } command to check whether the EFM OAM protocol states of the local and remote interfaces are Detect. You can use the display efm { all | interface interface-type interfacenumber } command to view the EFM OAM working modes of the local and remote interfaces. Step 4 Run:
commit
4.5.2 Configuring an Interface to Send Testing Packets

Testing packets are the Ethernet packets used together with remote loopback to test the packet loss ratio of a link. Do as follows on the device where an interface in active mode resides.
Procedure
Step 1 Run:
system-view

test-packet start [ mac mac-address ] interface interface-type interface-number [ c count | -p speed | -s size ] *
The specified interface is configured to send testing packets. By default, five 64-byte testing packets are sent at 1 Mbit/s each time. The interface on the tested link must be set as the outbound interface of testing packets. Parameters of the sent testing packets cannot be modified during the sending of testing packets. To stop sending testing packets, press Ctrl+C. ----End
4.5.3 (Optional) Disabling Remote Loopback

Remote loopback can be disabled either automatically or manually. Do as follows on the device where an interface in active mode resides.
Procedure
Step 1 Run:
system-view

The interface view is displayed. Step 3 Run:

efm loopback stop
Issue 01 (2011-10-15)
179
Remote loopback is disabled on the interface. Users may forget to stop remote loopback, which causes the link unable to forward service data for a long time. To avoid such a situation, remote loopback can be automatically disabled after a timeout period. The timeout period of remote loopback is configurable. By default, the timeout period of remote loopback is 20 minutes. After remote loopback times out, the local interface sends the remote interface a message to disable remote loopack. To disable remote loopback manually, perform the preceding steps. Step 4 Run:
commit

By checking the remote loopback status, you can determine whether a packet loss ratio test is configured successfully.
Prerequisite
The configurations of a packet loss ratio test are complete.
Procedure
l l Run the display efm session { all | interface interface-type interface-number } command to check the EFM OAM protocol state of interfaces. Run the display test-packet result command to check statistics about returned testing packets.
----End
Example
After remote loopback is configured successfully, run the display efm session command on the device where the interface in active mode resides. You can see that the EFM OAM protocol state of the interface in active mode is displayed as Loopback(control). That is, this interface initiates remote loopback.
<HUAWEI> display efm session interface gigabitethernet 1/0/1 Interface EFM State Loopback Timeout ---------------------------------------------------------------------GigabitEthernet1/0/1 Loopback(control) 20minute(s)
After remote loopback is configured successfully, run the display efm session command on the device where an interface in passive mode resides. You can see that the EFM OAM protocol state of the interface in passive mode is displayed as Loopback(be controlled). That is, this interface responds to instead of initiating remote loopback.
<HUAWEI> display efm session interface gigabitethernet 2/0/1 Interface EFM State Loopback Timeout ---------------------------------------------------------------------GigabitEthernet2/0/1 Loopback(be controlled) --
After remote loopback is disabled automatically or manually, run the display efm session command on the device on one end of a link. You can see that the EFM OAM protocol state of
the local and remote interfaces is Detect or Discovery. That is, the two interfaces are in the Detect or Discovery state.
<HUAWEI> display efm session interface gigabitethernet 1/0/1 Interface EFM State Loopback Timeout ---------------------------------------------------------------------GigabitEthernet1/0/1 Detect --
After testing packets are sent successfully, run the display test-packet result command on the device where the interface in active mode resides, and you can view statistics about returned testing packets.
<HUAWEI> display test-packet result TestResult Value -------------------------------------------------------PacketsSend : 5 PacketsReceive : 0 PacketsLost : 5 BytesSend : 320 BytesReceive : 0 BytesLost : 320 StartTime : 11-13-2008 14:44:13 EndTime : 11-13-2008 14:44:14
4.6 Configuring Association Between EFM and Interfaces

In the scenario with primary and backup links, EFM OAM can be associated with an interface for rapid service switchover.
A device configured with IP services is usually connected to an IP network by using primary and backup links to improve the network robustness and service reliability. In the current mainstream design, devices configured with IP services usually use VRRP to perform primary and backup link detection and link switchover. As a result, reliability cannot be guaranteed for carrier-class services. After EFM OAM is associated with an interface, if a link fault is detected, the link layer protocol status of the interface is set to Down. This triggers rapid route convergence, blocks services, and implements rapid route switchover. Figure 4-6 Schematic diagram of association between EFM OAM and an interface
PE1
/ GE1 / GE1
GE 1
0/1
0/1
ISP network
CE
/0 / 1 GE 2 /0 / 1
PE2
Issue 01 (2011-10-15)
181
Before associating EFM OAM with an interface, complete the following task: 4.3 Configuring Basic EFM OAM Functions
Figure 4-7 Flowchart for associating EFM OAM with an interface
Associate EFM OAM with an interface
Set the time during which the EFM OAM protocol state of an interface remains Down
Related Tasks
4.6.1 Associating EFM OAM with an Interface

In the scenario with primary and backup links, EFM OAM can be associated with an interface for rapid service switchover.
Procedure
Step 1 Run:
system-view

efm trigger if-down
EFM OAM is associated with an interface. By default, EFM OAM is not associated with any interface. Step 4 Run:
commit
Issue 01 (2011-10-15)
182
4.6.2 (Optional)Setting the Time During Which the EFM OAM Protocol State of an Interface Remains Down
After EFM OAM is associated with an interface, you can adjust the delay in changing the EFM OAM protocol state of an interface from Down to Up by setting the time during which the EFM OAM protocol state of the interface remains Down, if a link connectivity fault is rectified.
Before setting the time during which the EFM OAM protocol state of the interface remains Down, complete the following task: Associating EFM OAM with an Interface
Procedure
Step 1 Run:
system-view

efm holdup-timer timer
The time during which the EFM OAM protocol state of the interface remains Down is set. By default, the time during which the EFM OAM protocol state of an interface remains Down is 0. If the parameter time is not specified, when a link connectivity fault is rectified, the EFM OAM protocol state of an interface is changed from Down to Up immediately. If the parameter time is specified, when a link connectivity fault is rectified, the EFM OAM protocol state of an interface is changed from Down to Up after the time specified by the parameter time expires. This reduces the possibility of link flapping. You can run the recover efm-down command to change the EFM OAM protocol state of the interface from Down to Up. Step 4 Run:
commit

By checking EFM OAM configurations, you can determine whether EFM OAM is associated with an interface successfully.
Prerequisite
The configurations of association between EFM OAM and an interface are complete.
Procedure
l Run the display efm { all | interface interface-type interface-number } command to check the EFM OAM protocol state of interfaces.
----End
Example
If EFM OAM is associated with an interface successfully, run the display efm command, and you can see that the TriggerIfDown field displays enable.
[CE] display efm all Item Value ---------------------------------------------------Interface: GigabitEthernet1/0/1 EFM Enable Flag: enable Mode: active OAMPDU MaxSize: 128 OAMPDU Interval: 1000 OAMPDU Timeout: 5000 ErrCodeNotification: disable ErrCodePeriod: 1 ErrCodeThreshold: 1 ErrFrameNotification: disable ErrFramePeriod: 1 ErrFrameThreshold: 1 ErrFrameSecondNotification: disable ErrFrameSecondPeriod: 60 ErrFrameSecondThreshold: 1 Hold Up Time: 10 TriggerIfDown: enable Remote MAC: -Remote EFM Enable Flag: -Remote Mode: -Remote MaxSize: --
4.7 Maintaining EFM OAM

By maintaining EFM OAM, you can monitor the operation status of EFM OAM and debug EFM OAM when a fault occurs.
4.7.1 Monitoring the Operation Status of EFM OAM

In routine maintenance, you can run the following commands in any view to check the operation status of EFM OAM.
Procedure
l l Run the display efm { all | interface interface-type interface-number } command to check EFM OAM configurations on interfaces. Run the display efm session { all | interface interface-type interface-number } command to check the EFM OAM protocol state of interfaces.
----End

This section provides several examples for configuring EFM OAM. You can comprehend the configuration procedures by using the configuration flowchart. Each configuration example consists of information about the networking requirements, configuration notes, and configuration roadmap.

This configuration example describes basic applications of EFM OAM in a typical EFM OAM networking.
CAUTION
For the NE5000E, the interface is numbered as slot number/card number/interface number. For the NE5000E cluster, the interface is numbered as chassis ID/slot number/card number/interface number. The slot number is chassis ID/slot ID. It is required to configure EFM OAM for link detection, fault detection, and packet loss ratio test to ensure the reliability and stability of connections between users' networks and carriers' networks and to improve manageability and maintainability of links. In addition, EFM OAM can be associated with an interface to trigger link switchover in the case of a fault. Figure 4-8 Networking diagram for configuring EFM OAM
PE1 GE2/0/1 CE User network GE1/0/2 GE2/0/1 PE2 GE1/0/1 ISP network
Configuration Notes
None.
1. 2. 3. 4.
Configure EFM OAM on the CE and PE1, and configure an interface on the CE to work in passive mode. Configure remote loopback on PE1 to test the packet loss ratio before the link is used. Configure link monitoring on PE1. Associate EFM OAM with an interface on the CE.
Data Preparation
To complete the configuration, you need the following data: l l l Period during which error frames are detected on GE 2/0/1 on PEs and threshold of the number of detected error frames Period during which error codes are detected on GE 2/0/1 on PEs and threshold of the number of detected error codes Period during which error frame seconds are detected on GE 2/0/1 on PEs and threshold of the number of detected error frame seconds
Procedure
Step 1 Configure basic EFM OAM functions. # Enable EFM OAM globally on the CE.
<HUAWEI> system-view [~HUAWEI] sysname CE [~HUAWEI] commit [~CE] efm enable [~CE] commit
# Enable EFM OAM globally on PE1.

<HUAWEI> system-view [~HUAWEI] sysname PE1 [~HUAWEI] commit [~PE1] efm enable [~PE1] commit
# Enable EFM OAM globally on PE2.

<HUAWEI> system-view [~HUAWEI] sysname PE2 [~HUAWEI] commit [~PE2] efm enable [~PE2] commit
# Configure GE 1/0/1 on the CE to work in passive mode.

[~CE] interface gigabitethernet 1/0/1 [~CE-GigabitEthernet1/0/1] efm mode passive [~CE-GigabitEthernet1/0/1] commit
# Enable EFM OAM on GE 1/0/1 on the CE.

[~CE-GigabitEthernet1/0/1] efm enable [~CE-GigabitEthernet1/0/1] quit [~CE] commit
# Enable EFM OAM on GE 1/0/2 on the CE.

[~CE] interface gigabitethernet 1/0/2 [~CE-GigabitEthernet1/0/2] efm enable [~CE-GigabitEthernet1/0/2] quit
Issue 01 (2011-10-15)
186

[~CE] commit
# Enable EFM OAM on GE 2/0/1 on PE1.

[~PE1] interface gigabitethernet 2/0/1 [~PE1-GigabitEthernet2/0/1] efm enable [~PE1-GigabitEthernet2/0/1] quit [~PE1] commit
# Enable EFM OAM on GE 2/0/1 on PE2.

[~PE2] interface gigabitethernet 2/0/1 [~PE2-GigabitEthernet2/0/1] efm enable [~PE2-GigabitEthernet2/0/1] quit [~PE2] commit
# Verify the configuration. If EFM OAM configurations of PE1 and the CE match, GE 1/0/1 and GE 2/0/1 enter the Detect state after EFM session negotiation succeeds. Then, run the display efm session { all | interface interface-type interface-num } command on the CE or PE1. The command output shows that the EFM OAM protocol state of GE 1/0/1 or GE 2/0/1 is displayed as detect.
[~CE] display efm session all Interface EFM State Loopback Timeout ---------------------------------------------------------------------GigabitEthernet1/0/1 detect -GigabitEthernet1/0/2 detect --
Step 2 Configure remote loopback. # Configure remote loopback on PE1.

[~PE1] interface gigabitethernet 2/0/1 [~PE1-GigabitEthernet2/0/1] efm loopback start [~PE1-GigabitEthernet2/0/1] quit [~PE1] commit
Verify the configuration. After remote loopback is configured successfully, run the display efm session { all | interface interface-type interface-num } command on PE1. The command output shows that the EFM OAM protocol state of GE 2/0/1 is displayed as Loopback(control). That is, GE 2/0/1 is in the remote loopback state and initiates remote loopback.
[~PE1] display efm session interface gigabitethernet 2/0/1 Interface EFM State Loopback Timeout ---------------------------------------------------------------------GigabitEthernet2/0/1 loopback (control) 19 minute(s)
After remote loopback is configured successfully, run the display efm session { all | interface interface-type interface-num } command on the CE. The command output shows that the EFM OAM protocol state of GE 1/0/1 is displayed as Loopback(be controlled). That is, GE 1/0/1 is in the remote loopback state and responds to instead of initiating remote loopback.
Interface EFM State Loopback Timeout ---------------------------------------------------------------------Ethernet1/0/1 loopback (be controlled) --
Step 3 Configure PE1 to send testing packets to the CE.

[~PE1] test-packet start interface gigabitethernet 2/0/1 please waiting.. Info: The test is complete.
Issue 01 (2011-10-15)
187
Step 4 Check statistics about returned testing packets on PE1.

[~PE1] display test-packet result TestResult Value -------------------------------------------------------PacketsSend : 5 PacketsReRouterAive : 5 PacketsLost : 0 BytesSend : 320 BytesReRouterAive : 320 BytesLost : 0 StartTime : 08-08-2010 09:41:41 EndTime : 08-08-2010 09:41:41
Based on the preceding data, you can calculate the packet loss ratio of a link. Step 5 Disable remote loopback.
[~PE1] interface gigabitethernet 2/0/1 [~PE1-GigabitEthernet2/0/1] efm loopback stop [~PE1-GigabitEthernet2/0/1] quit [~PE1] commit
NOTE
By default, the timeout period of remote loopback is 20 minutes. After 20 minutes, remote loopback automatically stops. To disable remote loopback before the timeout period is expires, you can perform the preceding steps.
Step 6 Verify the configuration. After remote loopback is disabled, run the display efm session { all | interface interface-type interface-num } command on PE1 or the CE. The command output shows that the EFM OAM protocol state of interfaces on both ends of the link is displayed as Detect or Discovery. That is, the two interfaces are in the Detect or Discovery state. For example:
[~PE1] display efm session interface gigabitethernet2/0/1
If remote loopback detects that the link works properly, you can perform the following configurations to monitor the link connectivity and fault in real time. Step 7 Disable EFM OAM on GE 1/0/1 and GE 2/0/1 on the CE and PE1 respectively.
[~CE] interface gigabitethernet 1/0/1 [~CE-GigabitEthernet1/0/1] undo efm enable [~CE-GigabitEthernet1/0/1] quit [~CE] commit [~PE1] interface gigabitethernet 2/0/1 [~PE1-GigabitEthernet2/0/1] undo efm enable [~PE1-GigabitEthernet2/0/1] quit [~PE1] commit
Step 8 Configure GE 2/0/1 on PE1 to detect error codes, error frames, and error frame seconds. # Configure GE 2/0/1 on PE1 to detect error frames.
[~PE1] interface gigabitethernet 2/0/1 [~PE1-GigabitEthernet2/0/1] efm error-frame period 5 [~PE1-GigabitEthernet2/0/1] efm error-frame threshold 5 [~PE1-GigabitEthernet2/0/1] efm error-frame notification enable
# Configure GE 2/0/1 on PE1 to detect error codes.

[~PE1-GigabitEthernet2/0/1] efm error-code period 5 [~PE1-GigabitEthernet2/0/1] efm error-code threshold 5 [~PE1-GigabitEthernet2/0/1] efm error-code notification enable
# Configure GE 2/0/1 on PE1 to detect error frame seconds.

[~PE1-GigabitEthernet2/0/1] efm error-frame-second period 120
Issue 01 (2011-10-15)
188
[~PE1-GigabitEthernet2/0/1] efm error-frame-second threshold 5 [~PE1-GigabitEthernet2/0/1] efm error-frame-second notification enable [~PE1-GigabitEthernet2/0/1] quit [~PE1] commit
Step 9 Enable EFM OAM on GE 1/0/1 and GE 2/0/1 on the CE and PE1 respectively.
[~CE] interface gigabitethernet 1/0/1 [~CE-GigabitEthernet1/0/1] efm enable [~CE-GigabitEthernet1/0/1] quit [~CE] commit [~PE1] interface gigabitethernet 2/0/1 [~PE1-GigabitEthernet2/0/1] efm enable [~PE1-GigabitEthernet2/0/1] quit [~PE1] commit
Step 10 Verify the configuration. After the preceding configurations, GE 2/0/1 on the CE and GE 1/0/1 on PE1 enter the Detect state after EFM session negotiation succeeds. Then, run the display efm session { all | interface interface-type interface-num } command on the CE or PE1. The command output shows that the EFM OAM protocol state of GE 2/0/1 or GE 1/0/1 is displayed as detect.
[~CE] display efm session interface gigabitethernet 1/0/1 Interface EFM State Loopback Timeout ---------------------------------------------------------------------GigabitEthernet1/0/1 detect -GigabitEthernet1/0/2 detect --
After the preceding configurations, run the display efm { all | interface interface-type interfacenumber } command. The following EFM OAM configurations are displayed:
[~PE1] display efm interface gigabitethernet 2/0/1 Item Value ---------------------------------------------------Interface: GigabitEthernet2/0/1 EFM Enable Flag: enable Mode: active OAMPDU MaxSize: 128 OAMPDU Interval: 1000 OAMPDU Timeout: 5000 ErrCodeNotification: enable ErrCodePeriod: 5 ErrCodeThreshold: 5 ErrFrameNotification: enable ErrFramePeriod: 5 ErrFrameThreshold: 5 ErrFrameSecondNotification: enable ErrFrameSecondPeriod: 120 ErrFrameSecondThreshold: 5 Hold Up Time: 100 TriggerIfDown: enable Remote MAC: 38eb-d910-1100 Remote EFM Enable Flag: enable Remote Mode: active Remote MaxSize: 128
Step 11 Associate EFM OAM with an interface on the CE.

[~CE] interface gigabitethernet 1/0/1 [~CE-GigabitEthernet1/0/1] efm trigger if-down [~CE-GigabitEthernet1/0/1] efm holdup-timer 100 [~CE-GigabitEthernet1/0/1] quit [~CE] commit

After the preceding configurations, run the display efm { all | interface interface-type interfacenumber command on the CE. The command output shows that the TriggerIfDown field displays enable.
[~CE] display efm all Item Value ---------------------------------------------------Interface: GigabitEthernet1/0/1 EFM Enable Flag: enable Mode: active OAMPDU MaxSize: 128 OAMPDU Interval: 1000 OAMPDU Timeout: 5000 ErrCodeNotification: disable ErrCodePeriod: 1 ErrCodeThreshold: 1 ErrFrameNotification: disable ErrFramePeriod: 1 ErrFrameThreshold: 1 ErrFrameSecondNotification: disable ErrFrameSecondPeriod: 60 ErrFrameSecondThreshold: 1 Hold Up Time: 100 TriggerIfDown: enable Remote MAC: 38ea-d910-1100 Remote EFM Enable Flag: enable Remote Mode: active Remote MaxSize: 128 ---------------------------------------------------Interface: GigabitEthernet1/0/2 EFM Enable Flag: enable Mode: active OAMPDU MaxSize: 128 OAMPDU Interval: 1000 OAMPDU Timeout: 5000 ErrCodeNotification: disable ErrCodePeriod: 1 ErrCodeThreshold: 1 ErrFrameNotification: disable ErrFramePeriod: 1 ErrFrameThreshold: 1 ErrFrameSecondNotification: disable ErrFrameSecondPeriod: 60 ErrFrameSecondThreshold: 1 Hold Up Time: 100 TriggerIfDown: enable Remote MAC: 38eb-d910-1100 Remote EFM Enable Flag: enable Remote Mode: active Remote MaxSize: 128
----End
Configuration Files
l Configuration file of the CE
# sysname CE # efm enable # interface GigabitEthernet1/0/1 undo shutdown efm enable efm trigger if-down efm holdup-timer 100 #
Issue 01 (2011-10-15)
190

interface Ethernet1/0/2 undo shutdown efm enable efm trigger if-down efm holdup-timer 100 # return

# sysname PE1 # efm enable # interface GigabitEthernet2/0/1 undo shutdown efm enable efm error-frame period 5 efm error-frame threshold 5 efm error-frame notification enable efm error-frame-second period 120 efm error-frame-second threshold 5 efm error-frame-second notification enable efm error-code period 5 efm error-code threshold 5 efm error-code notification enable # return

# sysname PE2 # efm enable # interface GigabitEthernet2/0/1 undo shutdown efm enable # return
Related Tasks
4.3 Configuring Basic EFM OAM Functions 4.4 Configuring Link Monitoring 4.5 Testing the Packet Loss Ratio of a Physical Link 4.6 Configuring Association Between EFM and Interfaces
Issue 01 (2011-10-15)
191

Configuration Guide - Network Reliability (V800R002C01 - 01)

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Configuration Guide - Network Reliability (V800R002C01 - 01)

Diunggah oleh

Hak Cipta:

Format Tersedia

HUAWEI NetEngine5000E Core Router V800R002C01

Configuration Guide - Network Reliability

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

About This Document

About This Document

Related Versions (Optional)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

About This Document

Command Conventions (Optional)

Changes in Issue 01 (2011-10-15)

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

4 EFM OAM Configuration........................................................................................................163

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

1.1 Introduction to Reliability

1.1.1 Reliability Technology Overview

1.1.2 Indexes of Reliability

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

1.1.3 Levels of Reliability Requirements

1.1.4 Principles of Highly Reliable IP Networking

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

1.2 Reliability Technologies for IP Networks

1.2.1 Fault Detection Technologies for IP Networks

1.2.2 Protection Switchover for IP Networks

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

1.3 Reliability Technologies Supported by the NE5000E

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

1.4 Networking Scheme for Ensuring the Reliability of IP Networks

If LDP FRR and IP FRR are both available, IP FRR is preferred.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

1.4.2 Fault on the Link Between PEs

1.4.3 Fault on the Remote PE - VPN FRR

1.4.4 Fault on the Downlink Interface on the PE - IP FRR

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

Figure 1-3 Networking diagram of an IP FRR application

If LDP FRR and IP FRR are both available, IP FRR is preferred.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

2.1 BFD Overview

The preceding detection methods have the following problems: l l l

2.2 BFD Features Supported by the NE5000E

BFD Session Establishment Modes

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

Single- and Multi-hop BFD

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI NetEngine5000E Core Router Configuration Guide - Network Reliability

Dynamically Adjusting BFD Parameters