Table of Contents Table of Contents... 1-1 1.1 Introduction to BFD... 1-1 1.1.1 How BFD Works... 1-1 1.1.2 BFD Packet Format... 1-3 1.1.3 Protocols and Standards... 1-5 1.2 BFD Configuration Task List... 1-5 1.3 Configuring BFD Basic Functions... 1-6 1.3.1 Configuration Prerequisites... 1-6 1.3.2 Configuration Procedure... 1-6 1.4 Configuring BFD for Static Routing... 1-7 1.5 Enabling BFD Trap... 1-8 1.6 Displaying and Maintaining BFD... 1-8 1.7 BFD Configuration Examples... 1-9 1.7.1 Configuring BFD for Static Routing... 1-9 Chapter 2 GR... 2-1 2.1 Introduction to Graceful Restart... 2-1 2.2 Basic Concepts in Graceful Restart... 2-1 2.3 Graceful Restart Communication Procedure... 2-2 2.4 Graceful Restart Mechanism for Several Commonly Used Protocols... 2-4 i
When configuring BFD, go to these sections for information you are interested in: Introduction to BFD BFD Configuration Task List Displaying and Maintaining BFD Note: The term router or router icon in this document refers to a router in a generic sense or an Ethernet switch running routing protocols. 1.1 Introduction to BFD Bidirectional forwarding detection (BFD) provides a consistent mechanism to quickly detect and monitor the connectivity of links or IP forwarding paths in networks. To improve network performance, protocols on adjacent devices must quickly detect communication failures to restore the communication through backup paths as soon as possible. Normally, a network employs the following detection methods: Quickly detecting link failures by sending hardware detection signals, such as SDH (synchronous digital hierarchy) transmission system alarms. If no hardware detection signals are provided or failures cannot be detected through hardware detection signals, the network uses the hello mechanism of a routing protocol for failure detection, which has a slower failure detection rate of more than one second. In Gigabit data transmission, such a rate will cause a large quantity of data to be dropped. Implementing real-time detection for all media types and protocols through a uniform mechanism and providing different detection intervals and costs. 1.1.1 How BFD Works BFD provides a general-purpose, standard, medium- and protocol-independent fast failure detection mechanism. It can uniformly and quickly detect the failures of the bidirectional forwarding paths between two routers for upper-layer protocols, such as routing protocols and Multiprotocol Label Switching (MPLS). BFD establishes sessions between two routers to monitor the bidirectional forwarding paths in between providing services for upper-layer protocols. BFD provides no neighbor discovery mechanism. Upper-layer protocols that BFD services notify BFD of 1-1
routers to which it needs to establish sessions. After a session is established, if no BFD control packet is received from the peer within the negotiated BFD interval, BFD notifies a failure to the upper-layer, which takes appropriate measures. I. How BFD interacts with an application-layer protocol After discovering neighbors by using its own neighbor discovery mechanism, an application-layer protocol notifies BFD of the protocol type, neighbor address, interface, and whether the neighbor is directly connected. Upon receiving the notification, BFD sends control packets to establish sessions. When BFD is disabled or a neighbor is removed, BFD receives a notification from the application-layer protocol to tear down the session. If no other applications need to monitor this link, BFD tears down the corresponding session. II. Failure detection mechanism After a BFD session is established, if no BFD control packet is received from the neighbor within the BFD interval, BFD sets the session state to down and notifies it to the protocol concerned. Upon receiving the link failure notification from BFD, the application-layer protocol considers the neighbor down. Note: No detection time resolution is defined in the BFD draft. At present, most devices supporting BFD provide detection measured in milliseconds. III. BFD session modes Control packet mode: Both ends of the link exchange BFD control packets to monitor link status. Echo mode: One end of the link sends Echo packets to the other end, which then forwards the packets back to the originating end, thereby monitoring link status in both directions. IV. BFD operation modes Before a BFD session is established, there are two BFD operation modes: active or passive. Active mode: Before a session is established, BFD actively sends BFD control packets regardless of whether any BFD control packet is received from the peer. Passive mode: Before a session is established, no BFD control packet is sent until a BFD control packet is received from the peer. 1-2
During session initialization, at least one end of the two in communication must operate in the active mode for a session to be established. After a BFD session is established, there are two BFD operation modes: asynchronous and query. Both ends in communication must operate in the same mode. Asynchronous mode: A device operating in the asynchronous mode periodically sends BFD control packets. It tears down the BFD session if it receives no BFD control packet from the peer within the BFD interval. Query mode: This mode assumes that every protocol acknowledges its connection to another protocol by using its unique method. In this way, the protocol stops sending BFD control packets as long as a BFD session is established, unless a protocol needs to explicitly verify the connectivity. Note: At present, only the asynchronous mode is supported. At present, BFD can be implemented in the Echo mode for static routes only and in a way different from that defined in the BFD draft. When a BFD session operates in the Echo mode, the session is independent of the operation mode. V. Dynamic BFD parameter changes After a BFD session is established, both ends can negotiate the related BFD parameters, such as the minimum transmit interval, minimum receive interval, initialization mode, and packet authentication. After that, both ends use the negotiated parameter settings, without affecting the current session state. VI. Authentication modes BFD provides the following authentication methods: Simple: Plain text authentication MD5: MD5 (Message Digest 5) authentication SHA1: SHA1 (Secure Hash Algorithm 1) authentication 1.1.2 BFD Packet Format Figure 1-1 illustrates the BFD control packet format. 1-3
0 7 23 31 Vers Diag Sta P F C A D R Detect Mult Length My Discriminator Your Discriminator Desired Min TX Interval Resired Min RX Interval Required Min Echo RX Interval Auth Type Auth Len Authentication Data... Figure 1-1 BFD control packet format Vers: Protocol version. The protocol version is 1. Diag: This bit indicates the reason for the last transition of the local protocol from up to some other state. Table 1-1 lists the states. Table 1-1 Diag bit values Diag Description 0 No Diagnostic 1 Control Detection Time Expired 2 Echo Function Failed 3 Neighbor Signaled Session Down 4 Forwarding Pane Reset 5 Path Down 6 Concatenated Path Down 7 Administratively Down 8~31 Reserved for future use State (Sta): Current BFD session state. Its value can be 0 for AdminDown, 1 for Down, 2 for Init, and 3 for Up. Demand (D): If set to 1, it means the transmitting protocol wishes to operate in the query mode; if set to 0, it means the transmitting protocol ignores the query mode or cannot operate in the query mode. Poll (P): If it is set to 1, the transmitting protocol requests the connection acknowledgement or acknowledges a parameter change. If it is set to 0, the transmitting protocol does not request the acknowledgement. Final (F): If it is set to 1, the transmitting protocol responds to a received BFD control packet that has the Poll (P) bit set. If it is set to 0, the transmitting protocol does not respond to any received BFD control packet that has the Poll (P) bit set. 1-4
Control Plane Independent(C): If set to 1, it means the BFD implementation for the transmitting protocol is independent of its control plane. That is, BFD is implemented at the forwarding plane and takes effect even if the control plane fails. If set to 0, it means BFD is implemented at the control plane. Authentication Present (A): If it is set to 1, the control packet contains the authentication field and the session is authenticated. Reserved (R): It is set to 0 during transmission and ignored during reception. Detect Mult: Detect time multiplier. In the BFD asynchronous mode, the negotiated transmit interval multiplied by the detect time multiplier determines the detection time for the transmitting protocol. Length: BFD control packet length, in bytes. My Discriminator: It is a unique and non-zero discriminator value generated by the transmitting protocol to demultiplex multiple BFD sessions between two protocols. Your Discriminator: It is the discriminator received from the corresponding remote protocol. This field reflects the received value of My Discriminator or returns 0 if that value is unknown. Desired Min Tx Interval: Minimum interval at which the local protocol wishes to send BFD control packets, in milliseconds. Required Min Rx Interval: Interval at which the local protocol can receive BFD control packets, in milliseconds. Required Min Echo Rx Interval: Interval at which the local protocol can receive BFD echo packets, in milliseconds. If this field is set to 0, the transmitting protocol does not receive any BFD echo packets. Auth Type: Authentication type used by BFD control packets. Auth Len: Authentication field length, including authentication type field and authentication length field. 1.1.3 Protocols and Standards BFD-related specifications are described in the following documents: draft-ietf-bfd-base-05: Protocol Independent Bidirectional Forwarding Detection draft-ietf-bfd-v4v6-1hop-05: BFD for IPv4 and IPv6 (Single Hop) 1.2 BFD Configuration Task List Configure BFD to provide a detection mechanism for the network. 1-5
Complete the following tasks to configure BFD: Task Configuring BFD Basic Functions Configuring BFD for Static Routing Remarks BFD basic configurations provide basis for other configuration tasks. Required Enable BFD for the links of static routes. 1.3 Configuring BFD Basic Functions 1.3.1 Configuration Prerequisites Before configuring BFD detection modes, complete the following tasks: Configure the network layer addresses of the interfaces so that adjacent nodes are reachable to each other at the network layer; Configure the routing protocols that support BFD 1.3.2 Configuration Procedure Follow these steps to configure BFD session parameters: To do Use the command Remarks Enter system view system-view Specify a BFD session initiation mode Configure the source IP address of echo packets Enter interface view Configure the minimum BFD transmit interval of the interface Configure the minimum echo receive interval of the interface Configure the minimum packet receive interval of the interface Configure the detect time multiplier bfd session init-mode { active passive } bfd echo-source-ip ip-address interface interface-type interface-number bfd min-transmit-interval value bfd min-echo-receive-interv al value bfd min-receive-interval value bfd detect-multiplier value active by default 400 milliseconds by default 400 milliseconds by default 400 milliseconds by default 5 by default 1-6
To do Use the command Remarks Configure the authentication type of the interface bfd authentication-mode { md5 key-id key sha1 key-id key simple key-id password } By default, the interface operates in the non-authentication mode. Note: The source address of echo packets must be configured if the BFD session operates in the echo mode. 1.4 Configuring BFD for Static Routing A dynamic routing protocol notifies BFD of the neighbor information. BFD uses such information to establish sessions with neighbors by sending BFD control packets. Static routing, which cannot discover neighbors dynamically, uses the following approaches: Configure a static route with the local device as the nexthop, and enable BFD on the peer device Use echo packets to establish a session. These echo messages use the local device interface address as the destination and are directly forwarded back to the local device after being sent to the nexthop, without being processed by the BFD processes. Follow these steps to configure BFD for static routes: To do Use the command Remarks Enter system view system-view ip route-static dest-address mask mask-length { [ gateway-address bfd { control-packet echo-packet } ] [ interface-type interface-number gateway-address bfd { control-packet echo-packet } ] } Enable BFD for a static route ip route-static vpn-instance s-vpn-instance-name&<1-6> dest-address { mask mask-length } { gateway-address bfd { control-packet echo-packet } [ public ] interface-type interface-number [ gateway-address bfd { control-packet echo-packet } ] vpn-instance d-vpn-instance-name gateway-address bfd { control-packet echo-packet } } Use either command 1-7
Caution: If route flaps occur, enabling BFD may worsen the route flaps. Therefore, enable BFD with care in such cases. BFD cannot be used for a static route with the outbound interface having the spoofing attribute. BFD can be used for a static route with a direct nexthop rather than a static route with a non-direct nexthop. In the draft, the BFD echo function is revised to specify that a BFD session is established at only one end when the echo mode is used. For static route configuration, refer to Static Routing Configuration in IPv4 Routing. 1.5 Enabling BFD Trap Follow these steps to enable BFD trap: To do Use the command Remarks Enter system view system-view Enable BFD trap snmp-agent trap enable bfd Enabled by default 1.6 Displaying and Maintaining BFD To do Use the command Remarks Display information about BFD-enabled interfaces Display PAF configuration information Display BFD session information Clear BFD session statistics. display bfd interface [ verbose ] display bfd paf display bfd session [ verbose ] reset bfd session statistics Available in any view Available in any view Available in any view Available in user view 1-8
1.7 BFD Configuration Examples 1.7.1 Configuring BFD for Static Routing I. Network requirements Switch A, Switch B, and Switch C are interconnected and reachable to one another. Configure a static route on Switch A to Switch C and enable BFD. II. Network diagram Switch A Hub Switch B Switch C Vlan-int10 10.1.1.102/24 Vlan-int10 10.1.1.100/24 Vlan-int10 120.1.1.1/24 Figure 1-2 Network diagram for BFD configuration on a static route III. Configuration procedure # Configure a static route on Switch A and enable BFD on it. Implement BFD through BFD echo packets. <SwitchA> system-view [SwitchA] bfd echo-source-ip 123.1.1.1 [SwitchA] interface vlan-interface 10 [SwitchA-vlan-interface10] bfd min-echo-receive-interval 300 [SwitchA-vlan-interface10] bfd detect-multiplier 7 [SwitchA-vlan-interface10] quit [SwitchA] ip route-static 120.1.1.1 24 10.1.1.100 bfd echo-packet [SwitchA] quit # Enable BFD debugging on Switch A. <SwitchA> debugging bfd event <SwitchA> debugging bfd scm <SwitchA> terminal debugging Enable BFD debugging on Switch A and tear down the link between Switch A and Switch B to verify the configuration. The display shows that Switch A can quickly detect the changes on Switch B. 1-9
Chapter 2 GR Chapter 2 GR Go to these sections for information you are interested in: Introduction to Graceful Restart Basic Concepts in Graceful Restart Graceful Restart Communication Procedure Graceful Restart Mechanism for Several Commonly Used Protocols Note: Throughout this chapter, the term router in this document refers to a router in a generic sense or a Layer 3 switch. 2.1 Introduction to Graceful Restart Graceful Restart ensures the continuity of packet forwarding when a routing protocol restarts. The mechanism of Graceful Restart works as follows: after the routing protocol on a Graceful Restart capable device restarts, the device will notify its neighbors to temporarily preserve its adjacencies with them and the routing information. The neighbors will help the restarting device to update its routing information and to restore it to the state prior to the restart in minimal time. The routing and forwarding remain highly stable across the restart, the packet forwarding path remains the same, and the whole system can forward IP packets continuously. Hence, it is called Graceful Restart. 2.2 Basic Concepts in Graceful Restart A router with the Graceful Restart feature enabled is called a Graceful Restart capable router. It can perform a Graceful Restart when its routing protocol restarts. Routers that are not Graceful Restart capable will follow the normal restart procedures after a routing protocol restart. GR Restarter: Graceful restarting router, the router whose routing protocol has restarted due to administrator instructions or network failure. It must be Graceful Restart capable. GR Helper: The neighbor of the GR Restarter, which helps the GR Restarter to retain the routing information. It must be Graceful Restart capable. 2-1
Chapter 2 GR GR Session: A Graceful Restart session, which is the negotiation between the GR Restarter and the GR Helper. A GR session includes restart notification and communications across restart. Through this session, GR Restarter and GR Helper can know the GR capability of each other. GR Time: The time taken for the GR Restarter and the GR Helper to establish a session between them. Upon detection of the down state of a neighbor, the GR Helper will preserve the topology and routing information sent from the GR Restarter for a period as specified by the GR Time. 2.3 Graceful Restart Communication Procedure Configure a device as GR Restarter in a network. This device and its GR Helper must support GR or be GR capable. Thus, when GR Restarter restarts, its GR Helper can know its restart process. Note: In some cases, GR Restarter and GR Helper can replace with each other. If a router is to act as a Graceful Restarter, it must have the ability to preserve the routing information in the routing table (forwarding table). Routers that fail to meet this can only act as a GR Helper. The communication procedure between the GR Restarter and the GR Helper works as follows: 1) A GR session is established between the GR Restarter and the GR Helper. Router D Router A GR restarter Router B Router C GR capable GR session Figure 2-1 A GR session is established between the GR Restarter and the GR Helper 2-2
Chapter 2 GR As illustrated in Figure 2-1, Router A works as GR Restarter, Router B, Router C and Router D are the GR Helpers of Router A. A GR session is established between the GR Restarter and the GR Helper. 2) GR Restarter restarting Router D Router A GR restarter Router B Router C GR capable GR session The administrator restarts GR Restarter or GR Restarter is operating abnormally Figure 2-2 Restarting process for the GR Restarter As illustrated in Figure 2-2. The GR Helper detects that the GR Restarter has restarted its routing protocol and assumes that it will recover within the GR Time. Before the GR Time expires, the GR Helper will neither terminate the session with the GR Restarter nor delete the topology or routing information of the latter. 3) GR Restarter signaling to GR Helper Router D Router A GR restarter Router B Router C Signals to establish GR session Figure 2-3 The GR Restarter signals to the GR Helper(s) after restart 2-3
Chapter 2 GR As illustrated in Figure 2-3, after the GR Restarter has recovered, it will signal to all its neighbors and will reestablish GR Session. 4) The GR Restarter obtaining topology and routing information from the GR Helper Router D Router A GR restarter Router B Router C Signals to establish GR session Figure 2-4 The GR Restarter obtains topology and routing information from the GR Helper As illustrated in Figure 2-4, the GR Restarter obtains the necessary topology and routing information from all its neighbors through the GR sessions between them and calculates its own routing table based on this information. 2.4 Graceful Restart Mechanism for Several Commonly Used Protocols The switch supports Graceful Restart for Boarder Gateway Protocol (BGP), Open Shortest Path First (OSPF), and Intermediate System to Intermediate System (IS-IS). For the implementation and configuration procedure of the Graceful Restart mechanism of the above protocols, refer to BGP Configuration, OSPF Configuration, and IS-IS Configuration in IPv4 Routing. 2-4