Table of Contents

Chapter 1 BFD Configuration. 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

 

Chapter 1  BFD Configuration

When configuring BFD, go to these sections for information you are interested in:

l           Introduction to BFD

l           BFD Configuration Task List

l           Displaying and Maintaining BFD

 

 

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:

l           Quickly detecting link failures by sending hardware detection signals, such as SDH (synchronous digital hierarchy) transmission system alarms.

l           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.

l           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 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

l           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.

l           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.

 

 

III. BFD session modes

l           Control packet mode: Both ends of the link exchange BFD control packets to monitor link status.

l           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.

l           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.

l           Passive mode: Before a session is established, no BFD control packet is sent until a BFD control packet is received from the peer.

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.

l           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.

l           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.

 

 

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:

l           Simple: Plain text authentication

l           MD5: MD5 (Message Digest 5) authentication

l           SHA1: SHA1 (Secure Hash Algorithm 1) authentication

1.1.2  BFD Packet Format

Figure 1-1 illustrates the BFD control packet format.

Figure 1-1 BFD control packet format

l           Vers: Protocol version. The protocol version is 1.

l           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

 

l           State (Sta): Current BFD session state. Its value can be 0 for AdminDown, 1 for Down, 2 for Init, and 3 for Up.

l           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.

l           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.

l           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.

l           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.

l           Authentication Present (A): If it is set to 1, the control packet contains the authentication field and the session is authenticated.

l           Reserved (R): It is set to 0 during transmission and ignored during reception.

l           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.

l           Length: BFD control packet length, in bytes.

l           My Discriminator: It is a unique and non-zero discriminator value generated by the transmitting protocol to demultiplex multiple BFD sessions between two protocols.

l           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.

l           Desired Min Tx Interval: Minimum interval at which the local protocol wishes to send BFD control packets, in milliseconds.

l           Required Min Rx Interval: Interval at which the local protocol can receive BFD control packets, in milliseconds.

l           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.

l           Auth Type: Authentication type used by BFD control packets.

l           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:

l           draft-ietf-bfd-base-05: Protocol Independent Bidirectional Forwarding Detection

l           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.

Complete the following tasks to configure BFD:

Task	Remarks
Configuring BFD Basic Functions	Optional BFD basic configurations provide basis for other configuration tasks.
Configuring BFD for Static Routing	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:

l           Configure the network layer addresses of the interfaces so that adjacent nodes are reachable to each other at the network layer;

l           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	bfd session init-mode { active | passive }	Optional active by default
Configure the source IP address of echo packets	bfd echo-source-ip ip-address	Optional
Enter interface view	interface interface-type interface-number	—
Configure the minimum BFD transmit interval of the interface	bfd min-transmit-interval value	Optional 400 milliseconds by default
Configure the minimum echo receive interval of the interface	bfd min-echo-receive-interval value	Optional 400 milliseconds by default
Configure the minimum packet receive interval of the interface	bfd min-receive-interval value	Optional 400 milliseconds by default
Configure the detect time multiplier	bfd detect-multiplier value	Optional 5 by default
Configure the authentication type of the interface	bfd authentication-mode { md5 key-id key | sha1 key-id key | simple key-id password }	Optional By default, the interface operates in the non-authentication 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:

l           Configure a static route with the local device as the nexthop, and enable BFD on the peer device

l           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	—
Enable BFD for a static route	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 } ] }	Use either command
	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 } }

 

 

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	Optional Enabled by default

 

1.6  Displaying and Maintaining BFD

To do…	Use the command…	Remarks
Display information about BFD-enabled interfaces	display bfd interface [ verbose ]	Available in any view
Display PAF configuration information	display bfd paf	Available in any view
Display BFD session information	display bfd session [ verbose ]	Available in any view
Clear BFD session statistics.	reset bfd session statistics	Available in user view

 

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

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.

 

Chapter 2  GR

Go to these sections for information you are interested in:

l           Introduction to Graceful Restart

l           Basic Concepts in Graceful Restart

l           Graceful Restart Communication Procedure

l           Graceful Restart Mechanism for Several Commonly Used Protocols

 

 

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.

l           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.

l           GR Helper: The neighbor of the GR Restarter, which helps the GR Restarter to retain the routing information. It must be Graceful Restart capable.

l           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.

l           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.

 

 

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.

Figure 2-1 A GR session is established between the GR Restarter and the GR Helper

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

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

Figure 2-3 The GR Restarter signals to the GR Helper(s) after restart

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

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.