HUAWEI NetEngine5000E Core Router V800R002C01. Configuration Guide - Network Reliability. Issue 01 Date HUAWEI TECHNOLOGIES CO., LTD.

Transcription

1 V800R002C01 Configuration Guide - Network Reliability Issue 01 Date HUAWEI TECHNOLOGIES CO., LTD.

2 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: Website: Huawei Industrial Base Bantian, Longgang Shenzhen People's Republic of China i

3 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: 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. ii

4 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 Description The keywords of a command line are in boldface. Command arguments are in italics. [ ] Items (keywords or arguments) in brackets [ ] are optional. { x y... } Optional items are grouped in braces and separated by vertical bars. One item is selected. [ x y... ] Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected. { x y... } * 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. [ x y... ] * Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected. &<1-n> The parameter before the & sign can be repeated 1 to n times. A line starting with the sign is comments. Change History Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues. Changes in The initial commercial release. iii

5 Contents Contents About This Document...ii 1 Reliability Overview Introduction to Reliability Reliability Technology Overview Indexes of Reliability Levels of Reliability Requirements Principles of Highly Reliable IP Networking Reliability Technologies for IP Networks Fault Detection Technologies for IP Networks Protection Switchover for IP Networks Reliability Technologies Supported by the NE5000E FRR BFD Networking Scheme for Ensuring the Reliability of IP Networks Faults on Intermediate Nodes or on the Link Between PEs - LDP FRR/TE FRR Fault on the Link Between PEs Fault on the Remote PE - VPN FRR Fault on the Downlink Interface on the PE - IP FRR BFD Overview BFD Features Supported by the NE5000E Configuring BFD to Detect an IP Link Enabling BFD Globally Establishing a BFD Session (Optional) Adjusting BFD Detection Time (Optional) Setting the BFD WTR Time (Optional) Configuring the Description of a BFD Session Checking the Configuration Configuring BFD to Detect VPN Routes Enabling BFD Globally Establishing a BFD Session (Optional) Adjusting BFD Detection Time...24 iv

6 Contents (Optional) Setting the BFD WTR Time (Optional) Configuring the Description of a BFD Session Checking the Configuration Configuring a Static BFD Session with Automatically-Negotiated Discriminators Enabling BFD Globally Establishing a BFD Session (Optional) Adjusting BFD Detection Time (Optional) Setting the BFD WTR Time (Optional) Configuring the Description of a BFD Session Checking the Configuration Configuring Multi-hop BFD Enabling BFD Globally Establishing a BFD Session (Optional) Adjusting BFD Detection Time (Optional) Setting the BFD WTR Time (Optional) Configuring the Description of a BFD Session Checking the Configuration Associating a BFD Session with an Interface Associating a BFD Session with the Sub-interface Enabling a BFD Session to Modify the PST Configuring the Delay of a BFD Session to Go Up Maintaining BFD Clearing the BFD Statistics Monitoring the BFD Operating Status Configuration Examples Example for Configuring Single-Hop BFD for an IP-Trunk Example for Configuring Single-Hop BFD for a Layer 3 Eth-Trunk Example for Configuring BFD for VPN Routes Example for Configuring Multi-Hop BFD Example for Associating a BFD Session with an Interface Example for Associating a BFD Session and a Sub-interface Example for Configuring the Delay of a BFD Session to Go Up Example for Configuring BFD for VPN Static Routes Example for Enabling a BFD Session to Modify the PST Example for Configuring Single-hop BFD for IPv Example for Configuring Multi-hop BFD for IPv VRRP Configuration VRRP Overview VRRP Features Supported by the NE5000E Configuring a VRRP Backup Group in Master/Backup Mode Configuring a VRRP Backup Group and Assigning a Virtual IP Address Configuring the Priority of an Interface in a VRRP Backup Group v

7 Contents (Optional) Configuring an Authentication Mode for VRRP Packets (Optional) Setting the Interval for Sending VRRP Advertisement Packets (Optional) Enabling a Device to Learn the Interval at Which a VRRP Advertisement Packet Is Sent (Optional) Setting the Preemption Delay for the Device in a VRRP Backup Group (Optional) Setting the Timeout Period of Sending Gratuitous ARP Packets on the Master Device Checking the Configuration Configuring VRRP Backup Groups in Load Balancing Mode Configuring a VRRP Backup Group and Assigning a Virtual IP Address Setting the Priority of an Interface in a VRRP Backup Group (Optional) Configuring an Authentication Mode for VRRP Packets (Optional) Setting the Interval for Sending VRRP Advertisement Packets (Optional) Enabling a Device to Learn the Interval at Which a VRRP Advertisement Packet Is Sent (Optional) Setting the Preemption Delay for the Device in a VRRP Backup Group (Optional) Setting the Timeout Period of Sending Gratuitous ARP Packets on the Master Device Checking the Configuration Configuring the Tracking Function for a VRRP Backup Group Configuring a VRRP Backup Group to Track an Interface Configuring a VRRP Backup Group to Track a BFD Session Checking the Configuration Optimizing VRRP Enabling a Virtual IP Address to Be Pinged Disabling the Checking of TTLs in VRRP Packets Checking the Configuration Maintaining VRRP Monitoring the Operation Status of VRRP Configuration Examples Example for Configuring a VRRP Backup Group in Master/Backup Mode Example for Configuring VRRP Backup Groups in Load Balancing Mode Example for Configuring VRRP Multi-instance Example for Configuring a VRRP Backup Group to Track Interfaces Example for Configuring a VRRP Backup Group to Track a BFD Session EFM OAM Configuration Overview of EFM OAM EFM OAM Features Supported by the NE5000E Configuring Basic EFM OAM Functions Enabling EFM OAM Globally Configuring the EFM OAM Working Mode for an Interface (Optional) Setting the Maximum Size of an OAM PDU (Optional) Setting the Interval at Which OAM PDUs Are Sent (Optional) Setting the Timeout Period for Waiting for OAM PDUs Enabling EFM OAM on an Interface vi

8 Contents Checking the Configuration Configuring Link Monitoring (Optional) Configuring Error Frame Detection (Optional) Configuring Error Code Detection (Optional) Configuring Error Frame Second Detection Checking the Configuration Testing the Packet Loss Ratio of a Physical Link Configuring Remote Loopback Configuring an Interface to Send Testing Packets (Optional) Disabling Remote Loopback Checking the Configuration Configuring Association Between EFM and Interfaces Associating EFM OAM with an Interface (Optional)Setting the Time During Which the EFM OAM Protocol State of an Interface Remains Down Checking the Configuration Maintaining EFM OAM Monitoring the Operation Status of EFM OAM Configuration Examples Example for Configuring EFM OAM vii

9 1 Reliability Overview 1 Reliability Overview About This Chapter 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. 1

10 1 Reliability Overview 1.1 Introduction to Reliability Reliability technologies are used to shorten the duration of interruption on networks and improve the network performance 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) Indexes of Reliability MTTR MTBF Availability 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 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 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 indicates the utility of a system. The availability is improved when MTBF increases or MTTR decreases. 2

11 1 Reliability Overview The formula of the availability is as follows: Availability = MTBF/(MTBF + MTTR) In the telecom industry, % 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 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 Target Implementation 1 Few faults in the software and hardware of a system 2 No impact on a system if a fault occurs 3 Rapid recovery if a fault occurs and affects the system Hardware: simplified design, standardized circuits, reliable application of components, reliability control in purchased components, reliable manufacture, environment endurability, and reliability experiment (HALT/HASS) Software: specifications for the software reliability design Redundancy design, switchover policy, and high availability of switchover Fault detection, diagnosis, isolation, and recovery Principles of Highly Reliable IP Networking The principles of reliable IP networking include hierarchical networking, redundancy, and load balancing. The details are as follows: 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 3

12 1 Reliability Overview this manner, two devices are reachable to each other with one route at a fast traffic rate, avoiding multi-interconnection. 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 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. Special fault detection technologies include: APS (applied to the transport layer) RPR OAM and Eth-OAM (applied to the link layer) 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: 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: 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 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: 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: 4

13 1 Reliability Overview 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 FRR IP FRR LDP FRR 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. 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. 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: 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. 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 5

14 1 Reliability Overview MPLS TE FRR VPN FRR BFD 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 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. 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. 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: 6

15 1 Reliability Overview 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 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. 7

16 1 Reliability Overview Fault on the Link Between PEs BFD can be used to detect the link between PEs 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. 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 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. 8

17 1 Reliability Overview 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. 9

18 About This Chapter 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 IPv 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 10

19 Enabling a BFD session to modify the PST speeds up detection if a fault occurs. Only singlehop BFD sessions are configured with this function 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 Maintaining BFD Maintaining BFD help you clear the BFD statistics, monitor the BFD operating status, and debug BFD in the event of a fault 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. 11

20 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: 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. The preceding detection methods have the following problems: 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. BFD is developed to address the preceding problems. BFD provides the following functions: 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: Static BFD sessions with manually-specified discriminators The local and remote discriminators must be set manually. Static BFD sessions with automatically-negotiated discriminators 12

21 Detection Modes 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. 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: 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. 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: 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. IP-Trunk Layer 3 Eth-Trunk 13

22 NOTE 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 BFD for IPv6 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 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 BFD for IPv6 BFD for IPv4 IP link Supported Supported Static route Supported Supported OSPF Not supported Supported OSPFv3 Supported Not supported BGP Supported Supported IS-IS Supported Supported PST Supported Supported PIS Not supported Supported PW Not supported Supported TE Not supported Supported LSP Supported Supported 2.3 Configuring BFD to Detect an IP Link Applicable Environment You can configure a single-hop BFD session to fast detect faults in direct links on a network. To fast monitor an IP link on a network, you can configure BFD to detect faults in the IP link. 14

23 Pre-configuration Tasks Configuration Procedures Before configuring BFD to detect an IP link, complete the following tasks: 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 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 Enabling BFD Globally BFD must be enabled globally before configurations relevant to BFD are performed. Procedure Step 1 system-view The system view is displayed. Step 2 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. 15

24 Step 3 (Optional) 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) default-ip-address The default multicast address is configured for a BFD session. Step 5 commit The configurations are committed. ----End Establishing a BFD Session Procedure A BFD session is established on both ends of a direct link to rapidly detect link faults. Step 1 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: 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 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. 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. 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. 16

25 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. 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 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. 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. 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 discriminator local discr-value The local discriminator of the BFD session is created. Step 4 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 commit The configurations are committed. ----End (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 system-view 17

26 The system view is displayed. Step 2 bfd session-name The BFD session view is displayed. Step 3 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 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 detect-multiplier multiplier The local detection multiplier is set. By default, the value is 3. Step 6 commit The configurations are committed. ----End (Optional) Setting the BFD WTR Time Context Procedure 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. 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. Step 1 system-view The system view is displayed. 18

27 Step 2 bfd session-name The BFD session view is displayed. Step 3 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 commit The configurations are committed. ----End (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 system-view The system view is displayed. Step 2 bfd session-name The BFD session view is displayed. Step 3 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 commit The configurations are committed. ----End 19

28 2.3.6 Checking the Configuration Prerequisite 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. 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 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. ----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 : 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 : 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. 20

29 <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 BFD_IO_SESSION_NUM BFD_PER_TUNNEL_CFG_NUM 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 : Sent Negotiation Packets : 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/ UP Total Interface Number : 1 21