Bidirectional forwarding detection (BFD) provides a general-purpose, standard, medium- and protocol-independent fast failure detection mechanism. It can detect and monitor the connectivity of forwarding paths to detect communication failures quickly so that measures can be taken to ensure service continuity and enhance network availability.

BFD can uniformly and quickly detect the failures of the bidirectional forwarding paths between two devices for upper-layer protocols such as routing protocols. The hello mechanism used by upper-layer protocols needs seconds to detect a link failure, while BFD can provide detection measured in milliseconds.

Mechanism

BFD establishes a session between two network devices to detect failures on the bidirectional forwarding paths between the devices and provide services for upper-layer protocols. BFD provides no neighbor discovery mechanism. Protocols that BFD services notify BFD of devices 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 protocol, which then takes appropriate measures.

Figure 1 describes the operation of BFD for OSPF.

1. OSPF discovers neighbors by sending Hello packets and establishes neighbor relationships.

2. After establishing neighbor relationships, OSPF notifies BFD of the neighbor information, including destination and source addresses.

3. BFD uses the information to establish BFD sessions.

Figure 1 BFD session establishment

Figure 2 describes the BFD fault detection process.

1. BFD detects a link failure and tears down the session.

2. BFD notifies the neighbor unreachability to OSPF.

3. OSPF terminates the neighbor relationship on the link.

Figure 2 BFD fault detection

‌

Single-hop detection and multihop detection

BFD can be used for single-hop and multihop detections.

· Single-hop detection—Detects the IP connectivity between two directly connected systems, for example, Device A and Device B as shown in Figure 3.

Figure 3 Single-hop detection

· Multihop detection—Detects any of the paths between two systems, for example, Device A and Device B as shown in Figure 4. These paths have multiple hops, and might overlap.

Figure 4 Multihop detection

‌

BFD session states

A BFD session can be in the following states:

· DOWN—The BFD session has been shut down or is newly created. This state indicates that the forwarding path is unavailable and that the upper-layer application must take action, such as primary/backup path switchover.

· ADMIN DOWN—The BFD session is administratively disabled. This state does not indicate that the forwarding path is unavailable or that the upper-layer application needs to take action.

· INIT—The local end can communicate with the remote end and hopes that the BFD session enters the UP state.

· UP—The BFD session has been established, and the forwarding path is available.

BFD session modes

BFD sessions use echo packets and control packets.

Echo packet mode

Echo packets are encapsulated into UDP packets. The packet contains destination port 3785, a destination IP address (transmitting interface's IP address), and a source IP address (transmitting interface's IP address).

The local end of the link sends echo packets to establish BFD sessions and monitor link status. The peer end does not establish BFD sessions and only forwards the packets back to the originating end. If the local end does not receive echo packets from the peer end within the detection time, it considers the session to be down.

BFD sessions in echo packet mode do not require both ends to support BFD. Upon receiving BFD echo packets, the peer end loops back the packets for detection purposes.

In echo packet mode, BFD supports multihop detection only for MPLS TE tunnel and VXLAN tunnel scenarios. Both BFD sessions for single-hop detection and BFD sessions for multihop detection are independent of the operating mode.

Control packet mode

Control packets are encapsulated into UDP packets with port number 3784 for single-hop detection or port number 4784 for multihop detection.

The two ends of the link negotiate the establishment of BFD sessions by using the session parameters carried in control packets. Session parameters include session discriminators, desired minimum packet sending and receiving intervals, and local BFD session state.

Hardware BFD

Software BFD uses the CPU to receive and send BFD packets and to maintain the BFD state machine. Software BFD greatly consumes CPU resources and cannot support a large number of BFD sessions.

Hardware BFD uses hardware chips to process CPU-intensive tasks, such as receiving and sending BFD packets and fault detection. Hardware BFD improves CPU utilization and can support a large number of BFD sessions.

The Hardware mode field in the output from the display bfd session verbose command indicates whether BFD packets are processed in hardware:

· Enabled—BFD packets are processed in hardware.

· Disabled—BFD packets are processed in software.

You can take the following actions to disable hardware BFD:

· Execute the bfd demand enable or bfd echo enable command, which is not supported by hardware BFD.

· Remove cards that support hardware BFD.

When you disable hardware BFD, the BFD session might flap. Before performing this operation, make sure you understand its potential impact on the network.

Supported features

Feature	Reference
Link aggregation	Ethernet link aggregation in Layer 2—LAN Switching Configuration Guide
IPv4 static routing	Static routing in Layer 3—IP Routing Configuration Guide
IPv6 static routing	IPv6 static routing in Layer 3—IP Routing Configuration Guide
RIP	RIP in Layer 3—IP Routing Configuration Guide
OSPF	OSPF in Layer 3—IP Routing Configuration Guide
OSPFv3	OSPFv3 in Layer 3—IP Routing Configuration Guide
IS-IS	IS-IS in Layer 3—IP Routing Configuration Guide
BGP	BGP in Layer 3—IP Routing Configuration Guide
PIM	PIM in IP Multicast Configuration Guide
IPv6 PIM	IPv6 PIM in IP Multicast Configuration Guide
MPLS	MPLS OAM in MPLS Configuration Guide
RSVP	RSVP in MPLS Configuration Guide
SRv6 TE policy	SRv6 TE policy in Segment Routing Configuration Guide
Track	"Configuring Track"
S-Trunk	"Configuring S-Trunk"

‌

Protocols and standards

· RFC 5880, Bidirectional Forwarding Detection (BFD)

· RFC 5881, Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)

· RFC 5882, Generic Application of Bidirectional Forwarding Detection (BFD)

· RFC 5883, Bidirectional Forwarding Detection (BFD) for Multihop Paths

· RFC 5884, Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)

· RFC 5885, Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)

· RFC 7130, Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces

BFD tasks at a glance

All the BFD tasks are optional.

1. Configuring BFD sessions in echo packet mode

¡ Creating a static BFD session

¡ Configuring detection time settings

¡ Ignoring the echo response receiving interface

2. Configuring BFD sessions in control packet mode

¡ Configuring the session establishment mode

¡ Configuring the detection mode

¡ Configuring a static BFD session

¡ Configuring detection time settings

¡ Configuring the authentication mode

¡ Configuring the destination port number for multihop BFD control packets

¡ Configuring the destination port number for a static BFD session used to detect SRv6 PWs

¡ Configuring the destination port number for all static BFD sessions used to detect SRv6 PWs on EVPN VPLS over SRv6 networks

¡ Configuring the destination port number for all static BFD sessions used to detect SRv6 PWs on EVPN VPWS over SRv6 networks

¡ Configuring the notification delay timer for session establishment failures

¡ Enabling the echo function

¡ Associating the interface state with BFD

3. Associating two static BFD sessions

4. Configuring BFD session flapping suppression

5. Delaying BFD session negotiation

6. Configuring a BFD template

7. Enabling the BFD whitelist feature

8. Migrating BFD sessions

9. Enabling SNMP notifications for BFD

Restrictions and guidelines: BFD configuration

· (In IRF mode.) BFD session flapping might occur on an aggregate interface with member ports on different cards. When the card that receives and sends BFD packets is removed or restarted, the backup card might not immediately take over. For example, the backup card will not take over when the card has a short detection time or a large number of BFD sessions.

· In an IRF fabric, if the detection time is smaller than the IRF link down report delay, the BFD session might flap. To prevent this problem, set the IRF link down report delay to be greater than the detection time. For information about setting the IRF link down report delay, see IRF configuration in Virtual Technologies Configuration Guide.

· By default, the device runs BFD version 1 and is compatible with BFD version 0. You cannot change the BFD version to 0 through commands. When the peer device runs BFD version 0, the local device automatically switches to BFD version 0.

· After a BFD session is established, the two ends negotiate BFD parameters, including minimum sending interval, minimum receiving interval, initialization mode, and packet authentication, by exchanging negotiation packets. They use the negotiated parameters without affecting the session status.

· In a network where a Layer 2 device exists between IRF member devices, make sure the following values are greater than four times the IRF link detection interval:

¡ Minimum interval for receiving BFD echo packets.

¡ Minimum interval for transmitting or receiving single-hop BFD control packets.

¡ Minimum interval for transmitting or receiving multihop BFD control packets.

The IRF link detection interval is set by using the irf link-detect-time command. For more information about the command, see IRF in Virtual Technologies Configuration Guide.

Enabling hardware BFD

About this task

The device supports software BFD and hardware BFD.

· Software BFD uses the CPU to receive and send BFD packets and to maintain the BFD state machine. Software BFD greatly consumes CPU resources and cannot support a large number of BFD sessions.

· Hardware BFD uses hardware chips to process CPU-intensive tasks, such as receiving and sending BFD packets and fault detection. Hardware BFD improves CPU utilization and can support a large number of BFD sessions. Hardware BFD supports high-precision detection with a minimum detection time of 3 milliseconds.

Restrictions and guidelines

After you enable hardware BFD, do not set more than six types of minimum receiving intervals for BFD sessions created on a device.

To avoid incorrect operation of BFD sessions, follow these guidelines when you enable or disable hardware BFD:

· Before you enable hardware BFD, make sure only the cards in are installed in the device:

After you enable hardware BFD, do not install any cards except those cards mentioned above.

· Make sure no BFD sessions exist when you enable or disable hardware BFD.

Hardware BFD and high-precision hardware BFD take effect only on new BFD sessions.

Table 1 Card information

Card category	Cards
CEPC	NP5 cards-CEPC, NPS400 cards-CEPC
CSPEX	NP5 cards-CSPEX, NPS400 cards-CSPEX
SPE	NP5 cards-SPE, NPS400 cards-SPE

‌

Procedure

1. Enter system view.

system-view

2. Enable hardware BFD or high-precision hardware BFD.

hardware bfd enable [ high-precision ]

By default, hardware BFD and high-precision hardware BFD are disabled.

Configuring BFD sessions in echo packet mode

About BFD session creation methods

A BFD session can be created manually by using the bfd static command or created dynamically when an application module collaborates with BFD.

Restrictions and guidelines

If you also configure uRPF on the device, follow these restrictions and guidelines:

· For the collaboration between an application module and a BFD session in echo packet mode, use an ACL for uRPF to permit echo packets from the peer device. Without the ACL configuration, uRPF will drop these echo packets.

· For a static BFD session, make sure the source IPv4/IPv6 address specified in the session can pass the uRPF check. If the source IPv4/IPv6 address cannot pass the check, uRPF will drop the echo packets from the peer device.

For more information about uRPF, see Security Configuration Guide.

Creating a static BFD session

About this task

A static BFD session in echo packet mode can be used to perform single-hop detection or multihop detection.

Restrictions and guidelines

You need to create a static BFD session in echo packet mode on only the local device to perform detection.

When creating a static BFD session, you must specify a peer IPv4 or IPv6 address. The system checks only the format of the IP address but not its correctness. If the peer IPv4 or IPv6 address is incorrect, the static BFD session cannot be established.

Different static BFD sessions cannot have the same local discriminator.

For a static BFD session in echo packet mode, the device selects the source IP address of echo packets as follows:

· As a best practice, specify the source IP address for echo packets when creating a static BFD session. If you do not specify the source IP address, the device uses the IP address specified in the bfd echo-source-ip or bfd echo-source-ipv6 command as the source IP address of echo packets.

· Without the source-ip/source-ipv6 or bfd echo-source-ip/bfd echo-source-ipv6 keyword specified, the device uses the IPv4 or IPv6 address specified for the destination-ip/destination-ipv6 keyword as the source IPv4 or IPv6 address of echo packets.

Creating a static BFD session for single-hop detection

1. Enter system view.

system-view

2. (Optional.) Configure the source IP address of echo packets.

¡ Configure the source IP address of echo packets.

bfd echo-source-ip ip-address

By default, no source IPv4 address is configured for echo packets.

As a best practice, do not configure the source IPv4 address to be on the same network segment as any local interface's IPv4 address. If you configure such a source IPv4 address, a large number of ICMP redirect packets might be sent from the peer, resulting in link congestion.

¡ Configure the source IPv6 address of echo packets.

bfd echo-source-ipv6 ipv6-address

By default, no source IPv6 address is configured for echo packets.

The source IPv6 address of echo packets can only be a global unicast address.

3. Create a static BFD session and enter static BFD session view.

IPv4:

bfd static session-name [ peer-ip ipv4-address interface interface-type interface-number destination-ip ipv4-address [ source-ip ipv4-address ] one-arm-echo [ discriminator { auto | local local-value } ] ]

IPv6:

bfd static session-name [ peer-ipv6 ipv6-address interface interface-type interface-number destination-ipv6 ipv6-address [ source-ipv6 ipv6-address ] one-arm-echo [ discriminator { auto | local local-value } ] ]

4. (Optional.) Specify a local discriminator for the static BFD session.

discriminator local local-value

By default, no local discriminator is specified.

You can use this command only if you do not specify a local discriminator when creating a static BFD session.

Creating a static BFD session for multihop detection

1. Enter system view.

system-view

2. (Optional.) Configure the source IP address of echo packets.

¡ Configure the source IPv4 address of echo packets.

bfd echo-source-ip ip-address

By default, no source IPv4 address is configured for echo packets.

As a best practice, do not configure the source IPv4 address to be on the same network segment as any local interfaces. If you configure such a source IPv4 address, a large number of ICMP redirect packets might be sent from the peer, resulting in link congestion.

¡ Configure the source IPv6 address of echo packets.

bfd echo-source-ipv6 ipv6-address

By default, no source IPv6 address is configured for echo packets.

The source IPv6 address of echo packets can only be a global unicast address.

3. Create a static BFD session and enter static BFD session view.

IPv4:

bfd static session-name [ peer-ip ipv4-address [ vpn-instance vpn-instance-name ] destination-ip ipv4-address [ source-ip ipv4-address ] one-arm-echo [ discriminator { auto | local local-value } ] ]

IPv6:

bfd static session-name [ peer-ipv6 ipv6-address [ vpn-instance vpn-instance-name ] destination-ipv6 ipv6-address [ source-ipv6 ipv6-address ] one-arm-echo [ discriminator { auto | local local-value } ] ]

4. (Optional.) Specify a local discriminator for the static BFD session.

discriminator local local-value

By default, no local discriminator is specified.

You can use this command only if you do not specify a local discriminator when creating a static BFD session.

Configuring detection time settings

About this task

When creating a BFD session in echo packet mode, you can configure the minimum interval for receiving BFD echo packets and the detection time multiplier for the device.

Restrictions and guidelines

When the same BFD session (with the same source IP address, destination IP address, interface, VPN, and destination port number) is associated with multiple upper layer applications, BFD selects the detection time settings for the BFD session as follows:

1. Minimum values of the following settings:

¡ Settings configured in static BFD session view.

¡ Settings configured in the BFD template specified by the upper layer application.

¡ Settings configured by the upper layer application.

2. Settings configured in interface view or system view.

3. Default settings.

When a BFD session is associated with only one upper layer application, BFD selects the detection time settings for the BFD session as follows:

1. BFD selects the detection time settings for the BFD session based on whether the upper layer application supports using a BFD template and configuring detection time settings:

¡ If a BFD template is specified and detection time settings are also configured for the upper layer application, BFD selects the settings configured in the specified BFD template.

¡ If a BFD template is specified for the upper layer application that does not support configuring detection time settings, BFD selects the settings configured in the specified BFD template.

¡ If detection time settings are configured for the upper layer application that does not support using a BFD template, BFD selects the configured settings.

2. Settings configured in interface view or system view.

3. Default settings.

Configure detection time settings for single-hop BFD detection

1. Enter system view.

system-view

2. Enter interface view or static BFD session view.

¡ Enter interface view.

interface interface-type interface-number

¡ Enter static BFD session view.

bfd static session-name

The static BFD session must already exist.

To configure parameters for a static BFD session, you must enter its view.

3. Set the minimum interval for receiving BFD echo packets.

bfd min-echo-receive-interval interval

The default setting is 100 milliseconds.

4. Set the detection time multiplier.

bfd detect-multiplier value

The default setting is 3.

Configure detection time settings for multihop BFD detection

1. Enter system view.

system-view

2. (Optional.) Enter static BFD session view.

bfd static session-name

The static BFD session must already exist.

To configure parameters for a static BFD session, you must enter its view.

3. Set the minimum interval for receiving BFD echo packets.

bfd multi-hop min-echo-receive-interval interval

The default setting is 100 milliseconds.

4. Set the detection time multiplier.

bfd multi-hop detect-multiplier value

The default setting is 3.

Ignoring the echo response receiving interface

About this task

By default for a static BFD session in echo packet mode between directly connected devices, the device checks for whether the echo response receiving interface is consistent with the echo packet sending interface:

· If they are consistent, the device receives the echo response packet.

· If they are inconsistent, the device discards the received echo response packet.

When multiple paths are available for a static BFD session in echo packet mode between directly connected devices, as a best practice, configure this feature. This can avoid BFD session failure when the echo response receiving interface is different from the echo packet sending interface.

This feature takes effect only on BFD sessions that are not in up state.

· After you configure the bfd ignore-receive-interface command, the device checks the BFD session state. Only when the BFD session is not in up state, the device ignores the receiving interface for echo responses.

· After you configure the bfd ignore-receive-interface command, the BFD session might come up. At this time, if you execute the undo bfd ignore-receive-interface command, the BFD session with inconsistent echo response receiving and sending interfaces does not go down. BFD checks the echo response receiving interface only when the BFD session goes down due to other reasons and attempts to come up again.

Procedure

1. Enter system view.

system-view

2. Enter static BFD session view.

bfd static session-name

The static BFD session must already exist.

3. Disable checking the echo response receiving interface.

bfd ignore-receive-interface

By default, the device checks the echo response receiving interface. If it is consistent with the echo packet sending interface, the device receives the echo response packet. If it is different from the echo packet sending interface, the device discards the echo response packet.

Configuring BFD sessions in control packet mode

About BFD session creation methods

BFD sessions in control packet mode can be created statically or established dynamically.

BFD sessions are distinguished by the local discriminator and remote discriminator in control packets. The main difference between a statically created session and a dynamically established session is that they obtain the local discriminator and remote discriminator in different ways.

· The local discriminator and remote discriminator of a static BFD session are specified manually in the bfd static command or in the commands that associate specific applications with BFD. For example, to use a static BFD session to detect MPLS LSPs, you must manually specify the local discriminator and remote discriminator. For more information, see MPLS OAM in MPLS Configuration Guide.

· The local discriminator of a dynamic BFD session is automatically assigned by the device, and the remote discriminator is obtained during BFD session negotiation. The device can automatically assign the local discriminator for the BFD session in the following conditions:

¡ The auto keyword is specified for the bfd static command.

¡ The local and remote discriminators are not specified for the BFD session associated with a specific application..

Restrictions and guidelines

BFD version 0 does not support the following commands:

· bfd session init-mode.

· bfd authentication-mode.

· bfd demand enable.

· bfd echo enable.

Configuring the session establishment mode

About this task

BFD can use the following operating modes to establish a session:

· Active mode—BFD actively sends BFD control packets regardless of whether any BFD control packet is received from the peer.

· Passive mode—BFD does not send control packets until a BFD control packet is received from the peer.

At least one end must operate in active mode for a BFD session to be established.

Procedure

1. Enter system view.

system-view

2. Configure the BFD session establishment mode.

bfd session init-mode { active | passive }

By default, BFD uses the active mode to establish a session.

Configuring the detection mode

About this task

After a BFD session is established, the two ends can operate in the following modes:

· Asynchronous mode—The device periodically sends BFD control packets. The device considers that the session is down if it does not receive any BFD control packets within the detection interval.

· Demand mode—The Demand mode can be used to reduce the overhead when a large number of BFD sessions exist.

¡ If the peer end is operating in Asynchronous mode (default), the peer end stops sending BFD control packets after receiving control packets with the D bit set. In this scenario, BFD detects only the link between the local end and the peer end. The device considers that the session is down if it does not receive any BFD control packets within the detection interval.

¡ If the peer end is operating in Demand mode, both ends stop sending BFD control packets. In this scenario, the system uses features other than BFD, such as Hello packets and hardware CC, to verify the connectivity to another system.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Specify the Demand mode for the BFD session.

bfd demand enable

By default, a BFD session is in Asynchronous mode.

Configuring a static BFD session

About this task

A static BFD session can be used for single-hop detection and multihop detection. By working with Track, a static BFD session can provide fast failure detection. For more information about Track association with BFD, see "Configuring Track."

A static BFD session can detect the path types in Table 2. This section describes only static BFD sessions for detecting IP paths.

Table 2 Supported path types

Task	Reference
IP paths.	N/A
MPLS TE tunnels	MPLS OAM in MPLS Configuration Guide
MPLS PWs	MPLS OAM in MPLS Configuration Guide
SRv6 PWs	EVPN VPWS over SRv6 in Segment Routing Configuration Guide
Network slice channel	SRv6 network slicing in Segment Routing Configuration Guide

‌

Restrictions and guidelines for static BFD session configuration

If a static BFD session is created on the remote end, the static BFD session must be created on the local end.

Different static BFD sessions cannot have the same local discriminator.

For a static BFD session in control packet mode, the source IP address of BFD packets is the IP address specified for the source-ip/source-ipv6 keyword, and the destination IP address is the IP address specified for the peer-ip/peer-ipv6 keyword. Without the source-ip/source-ipv6 keyword specified, the device selects the source IP address for sending BFD packets in the following order:

1. The device looks up its its local routing table to search for a route to the IP address or IPv6 address specified with the peer-ip/peer-ipv6 keyword. It selects the output interface IP address of that route as the source IP address for BFD packets.

2. If you edit the IP address of the output interface after the static BFD session is configured, whether the device updates the source IP address for BFD packets depends on the phase of the session:

¡ If the BFD session is in negotiation phase, the device updates the source IP address for BFD packets.

¡ If the BFD session is in detection phase, the device does not update the source IP address for BFD packets.

3. If the network-slice command is executed in static BFD session view, the device selects the network slicing address. If the network slicing address is invalid, the device cannot send BFD packets. For more information about network slicing, see SRv6 network slicing configuration in Segment Routing Configuration Guide.

For a static BFD session in echo packet mode, the source IP address of BFD packets is the IP address specified for the source-ip/source-ipv6 keyword, and the destination IP address is the IP address specified for the destination-ip/destination-ipv6 keyword. Without the source-ip/source-ipv6 or bfd echo-source-ip/bfd echo-source-ipv6 keyword specified, the device uses the IPv4 or IPv6 address specified for the destination-ip/destination-ipv6 keyword as the source IPv4 or IPv6 address of echo packets.

Creating a static BFD session for single-hop detection

1. Enter system view.

system-view

2. Create a static BFD session and enter static BFD session view.

IPv4:

bfd static session-name peer-ip ipv4-address interface interface-type interface-number source-ip ipv4-address [ discriminator { auto | local local-value remote remote-value } ] [ track-interface interface-type interface-number ]

bfd static session-name [ peer-ip ipv4-address interface interface-type interface-number [ discriminator local local-value remote remote-value] ]

For a static BFD session to be established, specify the IPv4 address of the peer interface where the static BFD session resides for the peer-ip ipv4-address option. Specify the IPv4 address of the local interface where the static BFD session resides for the source-ip ipv4-address option.

IPv6:

bfd static session-name peer-ipv6 ipv6-address interface interface-type interface-number source-ipv6 ipv6-address [ discriminator { auto | local local-value remote remote-value } ] ] [ track-interface interface-type interface-number ]

bfd static session-name [ peer-ipv6 ipv6-address interface interface-type interface-number [ discriminator local local-value remote remote-value ] ]

For a static BFD session to be established, specify the IPv6 address of the peer interface where the static BFD session resides for the peer-ipv6 ipv6-address option. Specify the IPv6 address of the local interface where the static BFD session resides for the source-ipv6 ipv6-address option.

3. (Optional.) Specify the local and remote discriminators for the static BFD session.

discriminator { local local-value | remote remote-value }

By default, no local discriminator or remote discriminator is specified for a static BFD session.

Use this command only if you do not specify the local or remote discriminator when creating a static BFD session.

Create a static BFD session for multihop detection

1. Enter system view.

system-view

2. Create a static BFD session and enter static BFD session view.

IPv4:In standalone mode:

bfd static session-name [ peer-ip ipv4-address [ vpn-instance vpn-instance-name ] source-ip ipv4-address [ discriminator auto [ track-interface interface-type interface-number ] | discriminator local local-value remote remote-value [ track-interface interface-type interface-number ] [ select-board slot slot-number1 [ slot slot-number2 ] ] ] ]

bfd static session-name [ peer-ip ipv4-address [ vpn-instance vpn-instance-name ] [ discriminator local local-value remote remote-value [ track-interface interface-type interface-number ] [ select-board slot slot-number1 [ slot slot-number2 ] ] ] ]

IPv4:In IRF mode:

IPv6:In standalone mode:

bfd static session-name [ peer-ipv6 ipv6-address [ vpn-instance vpn-instance-name ] source-ipv6 ipv6-address [ discriminator auto [ track-interface interface-type interface-number ] | discriminator local local-value remote remote-value [ track-interface interface-type interface-number ] [ select-board slot slot-number1 [ slot slot-number2 ] ] ] ]

bfd static session-name [ peer-ipv6 ipv6-address [ vpn-instance vpn-instance-name ] [ discriminator local local-value remote remote-value [ track-interface interface-type interface-number ] [ select-board slot slot-number1 [ slot slot-number2 ] ] ] ]

IPv6:In IRF mode:

For a static BFD session detecting the connectivity of network slicing channels, you cannot specify the source IPv6 address for BFD packets.

3. (Optional.) Specify the local and remote discriminators for the static BFD session.

discriminator { local local-value | remote remote-value }

By default, no local discriminator or remote discriminator is specified for a static BFD session.

Use this command only if you do not specify the local or remote discriminator when creating a static BFD session.

Configuring detection time settings

About this task

When creating a BFD session in control packet mode, you can configure the minimum interval for receiving and transmitting BFD control packets and the detection time multiplier for the device.

Restrictions and guidelines

1. Minimum values of the following settings:

¡ Settings configured in static BFD session view.

¡ Settings configured in the BFD template specified by the upper layer application.

¡ Settings configured by the upper layer application.

2. Settings configured in interface view or system view.

3. Default settings.

When a BFD session is associated with only one upper layer application, BFD selects the detection time settings for the BFD session as follows:

1. BFD selects the detection time settings for the BFD session based on whether the upper layer application supports using a BFD template and configuring detection time settings:

¡ If a BFD template is specified and detection time settings are also configured for the upper layer application, BFD selects the settings configured in the specified BFD template.

¡ If a BFD template is specified for the upper layer application that does not support configuring detection time settings, BFD selects the settings configured in the specified BFD template.

¡ If detection time settings are configured for the upper layer application that does not support using a BFD template, BFD selects the configured settings.

2. Settings configured in interface view or system view.

3. Default settings.

Configure detection time settings for single-hop BFD detection

1. Enter system view.

system-view

2. Enter interface view or static BFD session view.

¡ Enter interface view.

interface interface-type interface-number

¡ Enter static BFD session view.

bfd static session-name

The static BFD session must already exist.

To configure parameters for a static BFD session, you must enter its view.

3. Set the minimum interval for transmitting single-hop BFD control packets.

bfd min-transmit-interval interval

The default setting is 400 milliseconds.

4. Set the minimum interval for receiving single-hop BFD control packets.

bfd min-receive-interval interval

The default setting is 400 milliseconds.

5. Set the single-hop detection time multiplier.

bfd detect-multiplier value

The default setting is 3.

Configure detection time settings for multihop BFD detection

1. Enter system view.

system-view

2. (Optional.) Enter static BFD session view.

bfd static session-name

The static BFD session must already exist.

To configure parameters for a static BFD session, you must enter its view.

3. Set the multihop detection time multiplier.

bfd multi-hop detect-multiplier value

The default setting is 3.

4. Set the minimum interval for receiving multihop BFD control packets.

bfd multi-hop min-receive-interval interval

The default setting is 100 milliseconds.

5. Set the minimum interval for transmitting multihop BFD control packets.

bfd multi-hop min-transmit-interval interval

The default setting is 100 milliseconds.

Configuring the authentication mode

About this task

You can configure authentication settings, including algorithm and key, to enhance BFD session security.

Configure the authentication mode for a single-hop BFD session

1. Enter system view.

system-view

2. Enter interface view or static BFD session view.

¡ Enter interface view.

interface interface-type interface-number

¡ Enter static BFD session view.

bfd static session-name

The static BFD session must already exist.

To configure parameters for a static BFD session, you must enter its view.

3. Configure the authentication mode for single-hop control packets.

bfd authentication-mode { hmac-md5 | hmac-mmd5 | hmac-msha1 | hmac-sha1 | m-md5 | m-sha1 | md5 | sha1 | simple } key-id { cipher cipher-string | plain plain-string }

By default, no authentication mode is configured for single-hop control packets.

Configure the authentication mode for a multihop BFD session

1. Enter system view.

system-view

2. (Optional.) Enter static BFD session view.

bfd static session-name

The static BFD session must already exist.

To configure parameters for a static BFD session, you must enter its view.

3. Configure the authentication mode for multihop BFD control packets.

bfd multi-hop authentication-mode { hmac-md5 | hmac-mmd5 | hmac-msha1 | hmac-sha1 | m-md5 | m-sha1 | md5 | sha1 | simple } key-id { cipher cipher-string | plain plain-string }

By default, no authentication mode is configured for multihop BFD control packets.

Configuring the destination port number for multihop BFD control packets

About this task

IANA assigned port number 4784 to BFD for multihop BFD detection in control packet mode. By default, H3C devices use 4784 as the destination port number for multihop BFD control packets, while devices from other vendors might use 3784. To avoid BFD session establishment failures, make sure the devices on both ends of the BFD session use the same destination port number for multihop BFD control packets.

Restrictions and guidelines

This command applies to only new multihop BFD sessions in control packet mode.

Procedure

1. Enter system view.

system-view

2. Configure the destination port number for multihop BFD control packets.

bfd multi-hop destination-port port-number

The default setting is 4784.

Configuring the destination port number for a static BFD session used to detect SRv6 PWs

About this task

An H3C device and a device from another vendor can establish an SRv6 PW. When you use BFD to detect such an SRv6 PW, the two ends of the BFD session might be configured with different port numbers. Port number inconsistency will cause BFD session negotiation to fail. To resolve the issue, perform this task to edit the destination port number for the static BFD session used for SRv6 PW detection on the H3C device.

Restrictions and guidelines

The bfd destination-port command configured in static BFD session view takes effect only for that session. For the configuration to take effect globally, configure the bfd destination-port evpn-vpls-srv6 or bfd destination-port evpn-vpws-srv6 command in system view.

Only the following static BFD sessions support the bfd destination-port command:

· Static BFD sessions used to detect SRv6 PWs on EVPN VPLS over SRv6 networks.

· Static BFD sessions used to detect SRv6 PWs on EVPN VPWS over SRv6 networks.

Procedure

1. Enter system view.

system-view

2. Enter static BFD session view.

bfd static session-name

The static BFD session must already exist.

3. Configure the destination port number for the static BFD session used to detect SRv6 PWs.

bfd destination-port port-number

By default, the destination port number is not configured for a static BFD session used to detect SRv6 PWs. The port number configured by using the bfd destination-port evpn-vpls-srv6 or bfd destination-port evpn-vpws-srv6 command in system view applies.

Configuring the destination port number for all static BFD sessions used to detect SRv6 PWs on EVPN VPLS over SRv6 networks

About this task

An H3C device and a device from another vendor can establish an SRv6 PW on an EVPN VPLS over SRv6 network. When you use BFD to detect such an SRv6 PW, the two ends of the BFD session might be configured with different port numbers. Port number inconsistency will cause BFD session negotiation to fail. To resolve the issue, perform this task to edit the destination port number for the static BFD session used for SRv6 PW detection on the H3C device.

Restrictions and guidelines

You can configure the destination port number for BFD control packets in system view or static BFD session view.

· The bfd destination-port evpn-vpls-srv6 command configured in system view takes effect for all static BFD sessions used to detect SRv6 PWs on EVPN VPLS over SRv6 networks.

· The bfd destination-port command configured in static BFD session view takes effect only for that session.

Procedure

1. Enter system view.

system-view

2. Configure the destination port number for all static BFD sessions used to detect SRv6 PWs on EVPN VPLS over SRv6 networks.

bfd destination-port evpn-vpls-srv6 port-number

By default, the destination port number is 3784 for static BFD sessions used to detect SRv6 PWs on EVPN VPLS over SRv6 networks.

Configuring the destination port number for all static BFD sessions used to detect SRv6 PWs on EVPN VPWS over SRv6 networks

About this task

An H3C device and a device from another vendor can establish an SRv6 PW on an EVPN VPWS over SRv6 network. When you use BFD to detect such an SRv6 PW, the two ends of the BFD session might be configured with different port numbers. Port number inconsistency will cause BFD session negotiation to fail. To resolve the issue, perform this task to edit the destination port number for the static BFD session used for SRv6 PW detection on the H3C device.

Restrictions and guidelines

You can configure the destination port number for BFD control packets in system view or static BFD session view.

· The bfd destination-port evpn-vpws-srv6 command configured in system view takes effect for all static BFD sessions used to detect SRv6 PWs on EVPN VPWS over SRv6 networks.

· The bfd destination-port command configured in static BFD session view takes effect only for that session.

Procedure

1. Enter system view.

system-view

2. Configure the destination port number for all static BFD sessions used to detect SRv6 PWs on EVPN VPWS over SRv6 networks.

bfd destination-port evpn-vpws-srv6 port-number

By default, the destination port number is 3784 for static BFD sessions used to detect SRv6 PWs on EVPN VPWS over SRv6 networks.

Configuring the notification delay timer for session establishment failures

About this task

By default, BFD does not notify upper-layer protocols of session establishment failures. The notification is required in some scenarios. For example, upon a session establishment failure in an aggregate link, the aggregate link can place the associated member port in Unselected state based on the failure notification. You can configure the delay timer for BFD to notify upper-layer protocols of session establishment failures.

Restrictions and guidelines

This feature does not apply to BFD sessions in echo packet mode.

Procedure

1. Enter system view.

system-view

2. Set the delay timer for BFD to notify upper-layer protocols of session establishment failures.

bfd init-fail-timer seconds

By default, BFD does not notify upper-layer protocols of session establishment failures.

CAUTION:

For session establishment failures caused by configuration mismatches at the two ends, this command can cause the upper-layer protocol to act incorrectly. Therefore, use this command with caution. BFD status mismatch and BFD authentication configuration mismatch are examples of configuration mismatches.

‌

Enabling the echo function

About this task

When you use Asynchronous mode BFD to detect the connectivity between directly connected devices, you can enable the echo function. This function enables the local system to periodically send echo packets to the remote system and reduces the control packet receiving rate to save bandwidth usage. The remote system loops back the echo packets to the local system without processing them. If the local system does not receive echo packets looped back from the remote system in a consecutive number of times, the local system declares the BFD session down.

This function is supported only for single-hop detection.

Restrictions and guidelines

This function does not take effect on BFD sessions associated with interface states.

If you configure both the bfd detect-interface and bfd echo enable commands on an interface, only the bfd detect-interface command takes effect.

Procedure

1. Enter system view.

system-view

2. Enter interface view or static BFD session view.

¡ Enter interface view.

interface interface-type interface-number

¡ Enter static BFD session view.

bfd static session-name

The static BFD session must already exist.

3. Enable the echo function.

bfd echo [ receive | send ] enable

By default, the echo function is disabled.

Associating the interface state with BFD

About this task

By creating a BFD session for single-hop detection through exchange of BFD control packets, this feature implements fast link detection. When BFD detects a link fault, it sets the link layer protocol state to DOWN(BFD). This behavior helps applications relying on the link layer protocol state achieve fast convergence. The source IP address of control packets is specified manually, and the destination IP address is fixed at 224.0.0.184. As a best practice, specify the IP address of the interface as the source IP address. If the interface does not have an IP address, specify a unicast IP address other than 0.0.0.0 as the source IP address.

You can associate the state of the following interfaces with BFD:

· Layer 2 Ethernet interfaces.

· Member ports in a Layer 2 aggregation group.

· Layer 3 Ethernet interfaces.

· Member ports in a Layer 3 aggregation group.

· Layer 3 Ethernet subinterfaces.

· Layer 3 aggregate interfaces.

· Serial interfaces, POS interfaces, serial interfaces created for E1/E3/T1/T3 channels, MP-group interfaces, member ports of an MP-group interface, HDLC link bundle interfaces, and member ports of an HDLC link bundle interface.

Restrictions and guidelines

The echo function does not take effect on BFD sessions associated with interface states.

BFD sessions do not take effect on interfaces with QinQ enabled.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Associate the interface state with BFD.

bfd detect-interface source-ip ip-address [ discriminator local local-value remote remote-value ] [ template template-name ]

If the peer device does not support obtaining BFD session discriminators through autonegotiation, you must specify the discriminators on both the local and peer devices. Without the discriminators, the BFD session cannot come up.

4. (Optional.) Configure the timer that delays reporting the first BFD session establishment failure to the data link layer.

bfd detect-interface first-fail-timer seconds

By default, the first BFD session establishment failure is not reported to the data link layer.

5. (Optional.) Enable special processing for BFD sessions.

bfd detect-interface special-processing [ admin-down | authentication-change | session-up ] *

By default, all types of special processing are disabled for BFD sessions.

Associating two static BFD sessions

About this task

This task enables the state of a static BFD session to affect the state of another static BFD session.

The device supports the following association types for two static BFD sessions (static BFD session a and static BFD session b are used for illustration):

· Unidirectional association—Session a is associated with session b in the view of session a, or session b is associated with session a in the view of session b.

· Bidirectional association—Session a is associated with session b in the view of session a, and session b is associated with session a in the view of session b.

A unidirectional association works as follows (the association configured in the view of session a is taken as an example):

1. When session a changes to the Down state, session b also changes to the Down state. Before session a comes up, session b is not allowed to perform negotiation.

2. When session a changes to the Up state, session b starts to perform negotiation. The state of session a is not affected even if session b cannot come up through negotiation.

A bidirectional association works as follows:

1. When session a changes to the Down state, session b also changes to the Down state. Before session a comes up, session b is not allowed to perform negotiation.

2. When session a changes to the Up state, session b starts to perform negotiation.

¡ If session b comes up through negotiation in the specified time, both sessions are placed in the Up state.

¡ If session b fail to come up through negotiation in the specified time, both sessions are placed in the Down state.

3. The same rules apply to the state changes of session a if session b first changes to the Down state.

Procedure

1. Enter system view.

system-view

2. Enter static BFD session view.

bfd static session-name

3. Associate the static BFD session with another static BFD session.

associate-static-session session-name [ re-negotiate seconds ]

By default, a static BFD session is not associated with any other static BFD sessions.

Configuring BFD session flapping suppression

About this task

When BFD detects a link failure, it tears down the BFD session and notifies the upper-layer protocol of the failure. When the upper-layer protocol re-establishes a neighbor relationship, the BFD session comes up again. BFD session flaps occur when a link fails and recovers repeatedly, which consumes significant system resources and causes network instability.

This feature allows you to suppress BFD session flapping by using the initial-interval, secondary-interval, and maximum-interval arguments.

· A BFD session is suppressed within the specified interval. The suppression time does not exceed the maximum-interval.

· After a BFD session goes down for the second time, it cannot be re-established within the initial-interval.

· After a BFD session goes down for the third time, it cannot be re-established within the secondary-interval.

· After a BFD session goes down for the fourth time and at any later time, the following rules apply:

¡ If secondary-interval × 2n-3 is smaller than or equal to the maximum-interval, the BFD session cannot be re-established within the secondary-interval × 2n-3.

¡ If secondary-interval × 2n-3 is greater than the maximum-interval, the BFD session cannot be re-established within the maximum-interval.

The letter n, starting from 4, is the number of times the BFD session flaps.

The Dampening Down (Remaining time: XXs) value of the Diag info field in the display bfd session verbose command output indicates the remaining suppression time for BFD sessions.

Procedure

1. Enter system view.

system-view

2. Configure BFD session flapping suppression.

bfd dampening [ maximum maximum-interval initial initial-interval secondary secondary-interval ]

By default, BFD sessions are not suppressed.

The value for the initial-interval or secondary-interval argument cannot be greater than or equal to the value for the maximum-interval argument.

Delaying BFD session negotiation

About this task

If an upper-layer protocol uses BFD to detect the active path, packet loss might occur in the following situations:

· An active/standby path switchover is triggered upon a device reboot. If the BFD session comes up after a device reboot, the traffic on the standby path will be switched over to the active path. In this case, traffic loss will occur if the active path of the upper-layer protocol has not recovered completely.

· An active/standby path switchover is triggered after the active path goes down. If the BFD session comes up before the active path recovers, the traffic on the standby path will be switched over to the active path. In this case, traffic loss will occur.

To solve the traffic loss problem, you can delay BFD session negotiation.

Delaying BFD session negotiation upon a device reboot

About this task

This function starts a delay timer when the device reboots successfully. Before this timer expires, the device does not perform session negotiation on BFD sessions in down state and newly created sessions.

Procedure

1. Enter system view.

system-view

2. Enable BFD session negotiation delay upon a device reboot and set a delay timer.

bfd session-negotiation delay-upon-reboot interval

By default, BFD session negotiation delay is disabled for a device reboot.

Delaying BFD session negotiation for down BFD sessions

About this task

This function starts a delay timer for each BFD session from up to down state and each newly created session. Before the timer expires, the device does not perform session negotiation on each BFD session.

Procedure

1. Enter system view.

system-view

2. Enable session negotiation delay for down BFD sessions and set a delay timer.

bfd session-negotiation delay-upon-down interval

By default, session negotiation delay is disabled for down BFD sessions.

Configuring a BFD template

About this task

Perform this task to specify BFD parameters in a template for sessions without next hops. You can configure BFD parameters for LSPs and PWs through a BFD template.

Procedure

1. Enter system view.

system-view

2. Create a BFD template and enter BFD template view.

bfd template template-name

3. (Optional.) Configure the authentication mode for BFD control packets.

bfd authentication-mode { hmac-md5 | hmac-mmd5 | hmac-msha1 | hmac-sha1 | m-md5 | m-sha1 | md5 | sha1 | simple } key-id { cipher cipher-string | plain plain-string }

By default, no authentication is performed.

4. Set the detection time multiplier.

bfd detect-multiplier value

The default setting is 3.

5. Set the minimum interval for receiving BFD echo packets.

bfd min-echo-receive-interval interval

The default setting is 100 milliseconds.

6. Set the minimum interval for receiving BFD control packets.

bfd min-receive-interval interval

The default setting is 100 milliseconds.

7. Set the minimum interval for transmitting BFD control packets.

bfd min-transmit-interval interval

The default setting is 100 milliseconds.

Enabling the BFD whitelist feature

About this task

If the attacker sends a large number of invalid BFD packets, the CPU cannot receive and process normal BFD packets for maintaining the BFD session state. The BFD whitelist feature allows the device to create ACL rules based on five-tuple information of BFD sessions. BFD packets that match ACL rules in the BFD whitelist are reported with higher priority than packets that match no ACL rules, to the CPU.

The BFD whitelist feature works as follows:

· Upon receiving BFD control packets from the peer for session establishment, the device creates an ACL rule based on session five-tuple information, and adds the rule to the whitelist.

· Upon receiving echoed BFD echo packets from the peer, the device creates an ACL rule based on session five-tuple information, and adds the rule to the whitelist.

· The device adds BFD packets that match ACL rules to the BFD whitelist queue and packets that match no ACL rules to the ordinary queue. BFD packets in the BFD whitelist queue are processed at a higher processing rate. Packets for multiple protocols in the ordinary queue are processed at a lower processing rate. This feature allows packets that match the ACL rules to be separately reported to the CPU at a high rate.

Procedure

1. Enter system view.

system-view

2. Enable the BFD whitelist feature.

bfd whitelist enable

By default, the BFD whitelist feature is enabled.

Migrating BFD sessions

About this task

After a BFD session comes up, the device automatically selects a card to periodically send BFD packets and maintain BFD session state. Such a card is a BFD session maintenance card.

Due to the complex selection of a BFD session maintenance card, the card that actually maintains BFD sessions might be different from the card through which an upper-layer protocol forwards packets. In the output from the display bfd session verbose command, you can view that the card of the packet outgoing interface for the upper-layer protocol is different from the card where the BFD session resides. In this case, if the card where the BFD session resides fails, the upper-layer protocol might incorrectly switch packets to the backup path for forwarding or disconnect neighbor relationships. To avoid the previous issues, perform this task to migrate BFD sessions to the card through which the upper-layer protocol forwards packets.

Restrictions and guidelines

As a best practice, migrate BFD sessions with different commands depending on the following situations:

· If all upper-layer protocols on the device forward packets through the same card, and this card is not the card that maintains BFD sessions, use the bfd session change-board command to migrate BFD sessions.

· Except for the previous situation, use the change bfd session select-board command to migrate BFD sessions to the card through which an upper-layer protocol forwards packets.

Migrating all BFD sessions on a card to another card

Restrictions and guidelines

When you migrate all BFD sessions on a card to another card, follow these guidelines:

· You cannot migrate the following types of BFD sessions:

¡ BFD sessions for detecting the link between selected ports of an aggregation group.

¡ BFD sessions for detecting the interface state.

¡ BFD sessions for MAD.

¡ Single-hop BFD sessions whose outgoing interface is a local physical interface.

· BFD sessions change to AdminDown state after migration. BFD sessions in AdminDown state do not trigger the upper-layer protocols to perform operations such as active/standby switchover. BFD sessions in AdminDown state automatically try to come up, and can detect the forwarding paths of upper-layer protocols until they come up.

· You can execute the bfd session change-board command again only after the migration is completed.

· In private-mode system view or exclusive-mode system view, the bfd session change-board command takes effect immediately after configuration. You do not need to execute the commit command.

Procedure

1. Enter system view.

system-view

2. Migrate all BFD sessions on a card to another card.

In standalone mode:

bfd session change-board from slot slot-number to slot slot-number

In IRF mode:

bfd session change-board from chassis chassis-number slot slot-number to chassis chassis-number slot slot-number

Migrating a BFD session to another card

Restrictions and guidelines

When you migrate a BFD session to another card, follow these guidelines:

· You cannot migrate the following types of BFD sessions:

¡ BFD sessions for detecting the link between selected ports of an aggregation group.

¡ BFD sessions for detecting the interface state.

¡ BFD sessions for MAD.

¡ Single-hop BFD sessions whose outgoing interface is a local physical interface.

· In private-mode system view or exclusive-mode system view, the change bfd session select-board command takes effect immediately after configuration. You do not need to execute the commit command.

Procedure

1. Enter system view.

system-view

2. Migrate a BFD session to another card.

In standalone mode:

change bfd session local-discr-value select-board slot slot-number

In IRF mode:

change bfd session local-discr-value select-board chassis chassis-number slot slot-number

Enabling SNMP notifications for BFD

About this task

To report critical BFD events to an NMS, enable SNMP notifications for BFD. For BFD event notifications to be sent correctly, you must also configure SNMP as described in Network Management and Monitoring Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enable SNMP notifications for BFD.

snmp-agent trap enable bfd

By default, SNMP notifications are enabled for BFD.

Display and maintenance commands for BFD

Execute the display command in any view and the reset command in user view.

‌

Task	Command
Display BFD session information.	In standalone mode: display bfd session [ discriminator local local-value \| static name session-name \| verbose ] display bfd session [ [ dynamic ] [ control \| echo ] [ ip ] [ state { down \| admin-down \| init \| up } ] [ discriminator remote remote-value ] [ peer-ip ipv4-address [ vpn-instance vpn-instance-name ] ] [ verbose ] ] [ slot slot-number [ cpu cpu-number ] ] display bfd session [ [ dynamic ] [ control \| echo ] [ ipv6 ] [ state { down \| admin-down \| init \| up } ] [ discriminator remote remote-value ] [ peer-ipv6 ipv6-address [ vpn-instance vpn-instance-name ] ] [ verbose ] ] [ slot slot-number [ cpu cpu-number ] ] display bfd session [ [ dynamic ] [ control \| echo ] [ lsp \| te \| pw \| srv6-policy ] [ state { down \| admin-down \| init \| up } ] [ discriminator remote remote-value ] [ [ peer-ip ipv4-address [ vpn-instance vpn-instance-name ] ] \| [ peer-ipv6 ipv6-address [ vpn-instance vpn-instance-name ] ] ] [ verbose ] ] [ slot slot-number [ cpu cpu-number ] ] display bfd session [ [ static ] [ ip ] [ state { down \| admin-down \| init \| up } ] [ discriminator remote remote-value ] [ peer-ip ipv4-address [ vpn-instance vpn-instance-name ] ] [ verbose ] [ slot slot-number [ cpu cpu-number ] ] display bfd session [ [ static ] [ ipv6 ] [ state { down \| admin-down \| init \| up } ] [ discriminator remote remote-value ] [ peer-ipv6 ipv6-address [ vpn-instance vpn-instance-name ] ] [ verbose ] [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display bfd session [ discriminator local local-value \| static name session-name \| verbose ] display bfd session [ [ dynamic ] [ control \| echo ] [ ip ] [ state { down \| admin-down \| init \| up } ] [ discriminator remote remote-value ] [ peer-ip ipv4-address [ vpn-instance vpn-instance-name ] ] [ verbose ] ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] display bfd session [ [ dynamic ] [ control \| echo ] [ ipv6 ] [ state { down \| admin-down \| init \| up } ] [ discriminator remote remote-value ] [ peer-ipv6 ipv6-address [ vpn-instance vpn-instance-name ] ] [ verbose ] ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] display bfd session [ [ dynamic ] [ control \| echo ] [ lsp \| te \| pw \| srv6-policy ] [ state { down \| admin-down \| init \| up } ] [ discriminator remote remote-value ] [ [ peer-ip ipv4-address [ vpn-instance vpn-instance-name ] ] \| [ peer-ipv6 ipv6-address [ vpn-instance vpn-instance-name ] ] ] [ verbose ] ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] display bfd session [ [ static ] [ ip ] [ state { down \| admin-down \| init \| up } ] [ discriminator remote remote-value ] [ peer-ip ipv4-address [ vpn-instance vpn-instance-name ] ] [ verbose ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] display bfd session [ [ static ] [ ipv6 ] [ state { down \| admin-down \| init \| up } ] [ discriminator remote remote-value ] [ peer-ipv6 ipv6-address [ vpn-instance vpn-instance-name ] ] [ verbose ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Display the BFD working mode, hardware resource usage, and session information.	display bfd working-mode
Clear BFD session statistics.	reset bfd session statistics

‌

Configuring SBFD

About SBFD

Seamless BFD (SBFD) is a unidirectional failure detection mechanism that simplifies the BFD state machine and shortens the session negotiation time to provide shorter detection time than BFD. A SBFD session has only UP and DOWN states. SBFD is used in scenarios where only one end of a link requires failure detection.

An SBFD session involves the following roles:

· Initiator—Initiates and maintains an SBFD session by periodically sends SBFD control packets or SBFD echo packets.

· Reflector—Listens for incoming SBFD control packets and replies with response SBFD control packets. The reflector does not maintain the SBFD session state.

SBFD session modes

SBFD sessions use echo packets and control packets.

Echo packet mode

The echo packet mode requires configuration only on the initiator. You do not need to configure the reflector.

The SBFD detection mechanism in echo packet mode is as follows:

1. The initiator sends SBFD echo packets to establish an SBFD session for link detection.

2. Upon receiving the SBFD packets, the peer end returns the packets to the local end.

The peer end does not require SBFD settings, and it will not establish an SBFD session.

3. If the initiator receives the SBFD echo packets before the detection time expires, it considers the link available. Otherwise, it considers the link unavailable.

Control packet mode

The SBFD detection mechanism in control packet mode is as follows:

1. The initiator periodically sends SBFD control packets to the reflector.

2. After receiving an SBFD control packet, the reflector checks whether the remote discriminator carried in the packet is the same as the locally configured one. If they are the same, the reflector sends a response SBFD control packet to the initiator. If they are different, the reflector drops the SBFD control packet.

3. If the initiator receives the response SBFD control packet before the detection time expires, it considers the link available. Otherwise, it considers the link unavailable.

Restrictions and guidelines: SBFD configuration

A node can act as the initiator of one session and the reflector of another session at the same time.

In the current software version, you must manually specify the remote discriminator to create an SBFD session (based on the specified remote discriminator).

SBFD tasks at a glance

To configure SBFD, perform the following tasks:

· Configuring the initiator

¡ Configuring the initiator for LDP LSP detection

¡ Configuring the initiator for MPLS TE tunnel detection

¡ Configuring the initiator for SRv6 locator detection

¡ Configuring the initiator for SRv6 TE policy detection

¡ Configuring the action on received SBFD packes in down state

· Configuring the reflector

· (Optional.) Delaying SBFD session negotiation

· (Optional.) Configuring a BFD template

· (Optional.) Enabling the SBFD whitelist feature

Configuring the initiator

Restrictions and guidelines

The remote discriminator in SBFD control packets sent by the initiator must be specified in the sbfd local-discriminator command on the reflector. If the discriminator is not specified on the reflector, the reflector does not reply with response SBFD control packets.

Configuring the initiator for LDP LSP detection

About this task

SBFD detects the connectivity of an LDP LSP in the following process:

1. The initiator injects SBFD control packets into an LDP LSP. The ingress node of the LDP LSP is used as the initiator.

2. After receiving an SBFD control packet, the reflector checks whether the remote discriminator carried in the packet is the same as the local discriminator. If they are the same, the reflector sends a response SBFD control packet to the initiator according to the routing table. The egress node of the LDP LSP is used as the reflector.

3. If the initiator receives the response SBFD control packet before the detection time expires, it considers the LDP LSP available.

For more information about using LDP to dynamically establishing an LSP, see LDP in MPLS Configuration Guide.

Restrictions and guidelines

When informing SBFD to establish an SBFD session, an LDP LSP sends the source and destination IP addresses of the packet to SBFD. The LDP LSP selects a source IP address in the following order:

1. The IP address specified by the source-ip keyword in the mpls sbfd command configured for the LDP LSP.

2. The IP address specified in the mpls lsr-id command.

To configure LDP LSP detection, make sure the reflector has a route to the source IP address in the SBFD packet sent from the initiator.

Procedure

1. Enter system view.

system-view

2. Enable BFD for MPLS.

mpls bfd enable

By default, BFD for MPLS is disabled.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

3. (Optional.) Set the detection time multiplier.

bfd multi-hop detect-multiplier value

The default setting is 3.

4. (Optional.) Set the minimum interval for sending SBFD control packets.

bfd multi-hop min-transmit-interval interval

The default setting is 100 milliseconds.

5. Configure SBFD to verify LSP connectivity for an FEC.

mpls sbfd dest-addr mask-length [ nexthop nexthop-address ] [ remote remote-id ] [ template template-name ] [ source-ip ipv4-address ]

By default, SBFD is not configured to verify LSP connectivity for an FEC.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

6. (Optional.) Associate the destination IPv4 address of the detected path with the remote discriminator of the SBFD session for the initiator.

sbfd destination ipv4 destination-ipv4-address remote-discriminator { ipv4-address | integer-value }

By default, the destination IPv4 address of the detected path is not associated with the remote discriminator of the SBFD session for the initiator.

Configuring the initiator for MPLS TE tunnel detection

About this task

Control-packet-mode SBFD detects the connectivity of an SR-MPLS-based MPLS TE tunnel in the following process:

1. The initiator injects SBFD control packets into an SRLSP. The ingress node of the MPLS TE tunnel is used as the initiator.

2. After receiving an SBFD control packet, the reflector checks whether the remote discriminator carried in the packet is the same as the local discriminator. If they are the same, the reflector sends a response SBFD control packet to the initiator according to the IP routing table. The egress node of the MPLS TE tunnel is used as the reflector.

3. If the initiator receives the response SBFD control packet before the detection time expires, it considers the SRLSP available.

Echo-packet-mode SBFD can detect only the connectivity of a bidirectional MPLS TE tunnel in the following process:

1. The initiator injects SBFD echo packets into an SRLSP. The ingress node of the MPLS TE tunnel is used as the initiator.

2. The labeled SBFD packets arrive at the egress node of the MPLS TE tunnel. Upon receiving the packets, the egress node performs an LFIB table lookup and forwards the packets out of the specified output interface.

3. If the initiator receives the returned SBFD echo packets before the detection time expires, it considers the SRLSP available.

For more information about SRLSPs, see SR-MPLS in Segment Routing Configuration Guide.

Restrictions and guidelines

Echo-packet-mode SBFD can detect only the connectivity of a bidirectional MPLS TE tunnel.

When informing SBFD to establish an SBFD session, the MPLS TE tunnel sends the source and destination IP addresses of the packet to SBFD. The MPLS TE tunnel selects a source IP address in the following order:

1. The IP address specified by the source-ip keyword in the mpls sbfd command configured for the MPLS TE tunnel.

2. The IP address specified in the mpls lsr-id command.

To configure MPLS TE tunnel detection, make sure the reflector has a route to the source IP address in the SBFD packet sent from the initiator.

Configuring MPLS TE tunnel detection in control packet mode

1. Enter system view.

system-view

2. (Optional.) Associate the destination IPv4 address of the detected path with the remote discriminator of the SBFD session for the initiator.

sbfd destination ipv4 destination-ipv4-address remote-discriminator { ipv4-address | integer-value }

By default, the destination IPv4 address of the detected path is not associated with the remote discriminator of the SBFD session for the initiator.

3. Enable BFD for MPLS.

mpls bfd enable

By default, BFD for MPLS is disabled.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

4. (Optional.) Set the detection time multiplier.

bfd multi-hop detect-multiplier value

The default setting is 3.

5. (Optional.) Set the minimum interval for sending SBFD control packets.

bfd multi-hop min-transmit-interval interval

The default setting is 100 milliseconds.

6. Enter the view of an MPLS TE tunnel interface.

interface tunnel number [ mode mpls-te ]

7. (Optional.) Configure SBFD session parameters for MPLS TE tunnel detection.

¡ Set the detection time multiplier for MPLS TE tunnel detection.

mpls bfd detect-multiplier value

By default, the detection time multiplier is not set.

If you configure both the mpls bfd detect-multiplier and mpls sbfd template commands for the MPLS TE tunnel interface, the mpls sbfd template command takes effect. If you configure none of the two commands, the bfd multi-hop detect-multiplier command takes effect.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

¡ Set the minimum interval for sending SBFD packets.

mpls bfd min-transmit-interval interval

By default, the minimum interval for sending SBFD packets is not set.

If you configure both the mpls bfd min-transmit-interval and mpls sbfd template commands for the MPLS TE tunnel interface, the mpls sbfd template command takes effect. If you configure none of the two commands, the bfd multi-hop min-transmit-interval command takes effect.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

8. (Optional.) Configure SBFD session parameters for backup MPLS TE tunnel detection.

¡ Set the detection time multiplier for MPLS TE tunnel detection.

mpls bfd backup detect-multiplier value

By default, the detection time multiplier for the backup MPLS TE tunnel is not set.

If you configure both the mpls bfd backup detect-multiplier and mpls sbfd backup-path template commands for the MPLS TE tunnel interface, the mpls sbfd backup-path template command takes effect. If you configure none of the two commands, the bfd multi-hop detect-multiplier command takes effect.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

¡ Set the minimum interval for sending SBFD packets.

mpls bfd backup min-transmit-interval interval

By default, the minimum interval for sending SBFD packets is not set.

If you configure both the mpls bfd backup min-transmit-interval and mpls sbfd backup-path template commands for the MPLS TE tunnel interface, the mpls sbfd backup-path template command takes effect. If you configure none of the two commands, the bfd multi-hop min-transmit-interval command takes effect.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

9. Enable SBFD to verify MPLS TE tunnel connectivity.

mpls sbfd remote remote-id [ reverse-lsp binding-sid label label-value control ] [ template template-name ] [ source-ip ipv4-address ]

mpls sbfd reverse-lsp binding-sid label label-value control [ template template-name ] [ source-ip ipv4-address ]

By default, SBFD is not enabled for an MPLS TE tunnel.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

To use echo-packet-mode SBFD, execute the bfd echo-source-ip or bfd echo-source-ipv6 command to specify the source IPv4 or IPv6 address for echo packets.

Configuring MPLS TE tunnel detection in echo packet mode

1. Enter system view.

system-view

2. Enable BFD for MPLS.

mpls bfd enable

By default, BFD for MPLS is disabled.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

3. Enter the view of an MPLS TE tunnel interface.

interface tunnel number [ mode mpls-te ]

4. (Optional.) Configure SBFD session parameters for MPLS TE tunnel detection.

¡ Set the detection time multiplier for MPLS TE tunnel detection.

mpls bfd detect-multiplier value

By default, the detection time multiplier for the MPLS TE tunnel is not set.

If you configure both the mpls bfd detect-multiplier and mpls sbfd echo template commands for the MPLS TE tunnel interface, the mpls sbfd echo template command takes effect. If you configure none of the two commands, the bfd detect-multiplier command takes effect.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

¡ Set the minimum interval for receiving SBFD packets.

mpls bfd min-receive-interval interval

By default, the minimum interval for receiving SBFD packets is not set.

If you configure both the mpls bfd min-receive-interval and mpls sbfd echo template commands for the MPLS TE tunnel interface, the mpls sbfd echo template command takes effect. If you configure none of the two commands, the bfd min-echo-receive-interval command takes effect.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

5. (Optional.) Configure SBFD session parameters for backup MPLS TE tunnel detection.

¡ Set the detection time multiplier for MPLS TE tunnel.

mpls bfd backup detect-multiplier value

By default, the detection time multiplier for the backup MPLS TE tunnel is not set.

If you configure both the mpls bfd backup detect-multiplier and mpls sbfd echo backup-path template commands for the MPLS TE tunnel interface, the mpls sbfd echo backup-path template command takes effect. If you configure none of the two commands, the bfd detect-multiplier command takes effect.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

¡ Set the minimum interval for receiving SBFD packets.

mpls bfd backup min-receive-interval interval

By default, the minimum interval for receiving SBFD packets is not set.

If you configure both the mpls bfd backup min-receive-interval and mpls sbfd echo backup-path template commands for the MPLS TE tunnel interface, the mpls sbfd echo backup-path template command takes effect. If you configure none of the two commands, the bfd min-echo-receive-interval command takes effect.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

6. Enable SBFD to verify MPLS TE tunnel connectivity.

mpls sbfd echo [ template template-name ] [ backup-path [ template template-name ] ] [ source-ip ipv4-address ]

mpls sbfd reverse-lsp binding-sid label label-value [ template template-name ] [ backup-path [ template template-name ] ] [ source-ip ipv4-address ]

By default, SBFD is not enabled for an MPLS TE tunnel.

For more information about this command, see MPLS OAM commands in MPLS Command Reference.

Configuring the initiator for SRv6 locator detection

About this task

When the peer CE is dual-homed to two PEs in public network IP over SRv6 BE, IP L3VPN over SRv6 BE, or EVPN L3VPN over SRv6 BE, the local PE generates a primary path and a backup path after you enable FRR on it. To quickly detect failures and forward traffic through the backup path when the primary path fails, you can configure SBFD to detect the SRv6 locator routes advertised through BGP by the peer PE.

SBFD detects the connectivity of the SRv6 locator network segment advertised through BGP in the following process:

1. The local PE (the initiator) sends a SBFD packet. The source IP address is the IP address specified by the sbfd source-ipv6 command and the destination IP address is the SRv6 locator.

2. Upon receiving the SBFD packet, the peer PE (the reflector) checks whether the remote discriminator carried in the packet is the same as the local discriminator. If they are the same, the reflector sends the response SBFD control packet to the initiator according to the IPv6 routing table. If they are different, the reflector drops the SBFD control packet.

3. If the initiator receives the SBFD response packet before the detection time expires, it considers the SRv6 locator available. Otherwise, the backup path takes over.

Restrictions and guidelines

For this function to take effect, perform the following tasks:

· Execute the sbfd destination ipv6 remote-discriminator command on the local PE to specify the remote discriminator for an SBFD session to detect the SRv6 locator.

· Execute the sbfd local-discriminator command on the peer PE of the primary path to specify the local discriminator for the reflector.

· Make sure the remote discriminator on the local PE is consistent with the local discriminator on the peer PE.

For more information about commands in SRv6 view, see SRv6 commands in Segment Routing Command Reference.

Procedure

1. Enter system view.

system-view

2. Specify the source IPv6 address used by the initiator to send SBFD control packets.

sbfd source-ipv6 ipv6-address

By default, no source IPv6 address is specified for SBFD control packets.

3. Enter SRv6 view.

segment-routing ipv6

4. Configure SBFD for SRv6 locators.

locator-sbfd enable [ template template-name ] [ prefix-list prefix-list-name ]

By default, SBFD is not configured for SRv6 locators.

Configuring the initiator for SRv6 TE policy detection

About this task

SBFD can detect the connectivity of an SRv6 TE policy and provides millisecond-level fault detection and fast fault switchover. In an SRv6 TE policy, the candidate path with the greatest preference value acts as the primary path and that with the second greatest preference value acts as the backup path. SBFD detects both primary and backup paths and all SID lists of each path. If all the SID lists for the primary path are faulty, SBFD triggers a primary-to-back path switchover.

As shown in Figure 5, configure an SRv6 TE policy on Device A and use SBFD to detect the SRv6 TE policy. The detection process is as follows:

1. The source node (Device A, the initiator) sends SBFD control packets that encapsulate the SID lists of the primary and backup candidate paths of the SRv6 TE policy.

2. After the destination node (Device D, the reflector) receives an SBFD control packet, it checks whether the remote discriminator carried the packet is the same as the local discriminator. If they are the same, the reflector sends the response SBFD control packet to the initiator according to the IPv6 routing table. If they are different, the reflector drops the SBFD control packet.

3. If the source node receives the response SBFD control packet before the detection time expires, it considers the corresponding SID list (forwarding path) of the SRv6 TE policy available. Otherwise, the device considers the SID list faulty. If all the SID lists for the primary path are faulty, SBFD triggers a primary-to-back path switchover.

Figure 5 SRv6 TE policy association with SBFD

‌

By default, when SBFD detects the connectivity of an SRv6 TE policy, the SBFD response packets are forwarded through IP paths. If an intermediate device fails and discards the response packets, the SBFD session will go down and SBFD will mistakenly consider the SID list as failed.

To solve the issue, configure a local BSID and reverse BSID in the SID list. This ensures that SBFD response packets are forwarded according to the specified SID list of SRv6 TE policy as follows:

1. Configure a reverse BSID in SID list view on the source node and a local BSID in SID list view on the destination node. The reverse BSID and local BSID use the same value.

2. When the source node sends an SBFD packet, it encapsulates the Aux Path TLV (auxiliary path TLV) for the SBFD packet. The TLV contains the reverse BSID.

3. Upon receiving the SBFD packet, the destination node checks the reverse BSID. If it is the same as the local BSID, it encapsulates the SBFD response packet with an SRH header and forwards it along the SID list to which the local BSID belongs.

Restrictions and guidelines

You can enable SBFD for all SRv6 TE policies globally in SRv6 TE view or for a specific SRv6 TE policy in SRv6 TE policy view. The policy-specific configuration takes precedence over the global configuration. An SRv6 TE policy uses the global configuration only when it has no policy-specific configuration.

When informing SBFD to establish an SBFD session, the SRv6 TE policy sends the source and destination IP addresses of the packet to SBFD. The source IP address is specified by the sbfd source-ipv6 command. To configure SRv6 TE policy detection, make sure the remote device has a route to the IPv6 address specified by the sbfd source-ipv6 command.

In the current software version, you can enable SRv6 TE policy detection through BFD echo packets or SBFD. If you configure both detection methods for the same SRv6 TE policy, SBFD takes effect.

For more information about the commands configured in SRv6 view, see SRv6 TE policy commands in Segment Routing Command Reference.

Procedure

1. Enter system view.

system-view

2. Associate the destination IPv6 address of the detected path with the remote discriminator of the SBFD session for the initiator.

sbfd destination ipv6 destination-ipv6-address remote-discriminator { ipv4-address | integer-value }

By default, the destination IPv6 address of the detected path is not associated with the remote discriminator of the SBFD session for the initiator.

If you do not specify the remote discriminator for the SBFD session with the sbfd or srv6-policy sbfd command, you must configure the sbfd destination ipv6 remote-discriminator command. Without the configuration, the SBFD session cannot come up.

3. (Optional.) Set the detection time multiplier.

bfd multi-hop detect-multiplier value

The default setting is 3.

4. (Optional.) Set the minimum interval for sending SBFD control packets.

bfd multi-hop min-transmit-interval interval

The default setting is 100 milliseconds.

5. Specify the Encap mode for the SBFD packets used for SRv6 forwarding paths connectivity detection.

bfd srv6-encapsulation-mode encap

By default, the device uses the Insert mode to encapsulate the BFD or SBFD packets for SRv6 forwarding paths connectivity detection.

6. Specify the source IPv6 address used by the initiator to send SBFD control packets.

sbfd source-ipv6 ipv6-address

By default, no source IPv6 address is specified for SBFD control packets.

7. Enter SRv6 view.

segment-routing ipv6

8. Enter SRv6 TE view.

traffic-engineering

9. Enable SBFD for all SRv6 TE policies and configure the SBFD session parameters.

srv6-policy sbfd [ remote remote-id ] [ template template-name ] [ backup-template backup-template-name ] [ reverse-path reverse-binding-sid ]

By default, SBFD is disabled for all SRv6 TE policies.

10. (Optional) Configure a local BSID and reverse BSID in the SID list.

a. Enter SID list view.

segment-list segment-list-name

b. Configure a local BSID on the destination node of the SRv6 TE policy.

local-binding-sid ipv6 ipv6-address

c. Configure a reserse BSID on the source node of the SRv6 TE policy.

reverse-binding-sid ipv6 ipv6-address

d. Return to SRv6 TE view.

quit

The configured local BSID and reverse BSID cannot be the same as the BSID of the SRv6 TE policy. If they are the same, the SID list becomes invalid and cannot be used to forward packets.

The configured local BSID and reverse BSID must be within the static length of the locator specified in SRv6 TE view. If this condition is not met, the SID list associated with the BSID cannot be used to forward packets.

11. (Optional) Enable BFD session down events to trigger SRv6 TE policy path reselection globally.

srv6-policy bfd trigger path-down enable

By default, the feature for triggering SRv6 TE policy path reselection with BFD session down events is disabled globally.

12. (Optional) Configure the timer that delays reporting the first SBFD session establishment failure to an SRv6 TE policy.

srv6-policy bfd first-fail-timer seconds

By default, the timer that delays reporting the first BFD or SBFD session establishment failure to an SRv6 TE policy is 60 seconds.

13. Enter SRv6 TE policy view.

policy policy-name

14. Configure SBFD for the SRv6 TE policy.

sbfd { disable | enable [ remote remote-id ] [ template template-name ] [ backup-template backup-template-name ] [ oam-sid sid ] [ encaps | insert ] [ reverse-path reverse-binding-sid ] }

By default, SBFD is not configured for an SRv6 TE policy. The configuration in SRv6 TE view takes effect.

If you do not specify the encaps or insert keyword, the encapsulation mode configured by the bfd srv6-encapsulation-mode encap command takes effect.

15. (Optional) Configure BFD session down events to trigger SRv6 TE policy path reselection.

bfd trigger path-down { disable | enable }

By default, the feature is not configured, and the configuration in SRv6 TE view takes effect.

Configuring the action on received SBFD packes in down state

About this task

Typically, to establish an SBFD session, the initiator first sends a SBFD packet in down state. If the reflector replies with an SBFD packet in down state, the initiator will drop the packet, and the SBFD session cannot be established. To resolve this issue, configure this feature on the initiator. After configuration, when the initiator receives an SBFD packet in down state from the reflector, it sends an SBFD packet in up state for successful session establishment.

Restrictions and guidelines

During session establishment, upon receiving SBFD packets in down state from the initiator, different reflectors might reply with SBFD packets carrying different session states. As a best practice, configure this feature to ensure successful establishment of SBFD sessions.

Procedure

1. Enter system view.

system-view

2. Enable the initiator to send SBFD packets in up state upon receiving SBFD packets in down state from the reflector during session establishment.

sbfd initiator accept-down-response

By default, during session establishment, upon receiving an SBFD packet in down state from the reflector, the initiator drops the packet. The SBFD session cannot be established.

Configuring the reflector

Restrictions and guidelines

If you configure an IPv4 address as the local discriminator, the device automatically converts it to an integer. Configure an IPv4 address local discriminator only when it is required for interoperation with a third-party device.

The reflector replies with a response SBFD control packet only when the remote discriminator in the SBFD control packet sent from the initiator is specified in the sbfd local-discriminator command.

Procedure

1. Enter system view.

system-view

2. (Optional.) Enable hardware reflection for the reflector of the SBFD session.

hardware sbfd-reflector enable

By default, hardware reflection is enabled for the reflector of the SBFD session.

In standard system operating mode, only the following cards support this feature:

‌

Card category	Cards
CEPC	NPS400 cards-CEPC
CSPEX	NPS400 cards-CSPEX
SPE	NPS400 cards-SPE

‌

In SDN-WAN system operating mode, only the following cards support this feature:

‌

Card category	Cards
CEPC	NP5 cards-CEPC, NPS400 cards-CEPC
CSPEX	NP5 cards-CSPEX, NPS400 cards-CSPEX
SPE	NP5 cards-SPE, NPS400 cards-SPE

‌

3. Configure a local discriminator.

sbfd local-discriminator { ipv4-address | integer-value }

By default, no local discriminator is configured.

You can execute this command multiple times to configure multiple local discriminators.

Delaying SBFD session negotiation

About this task

When an upper-layer protocol uses SBFD to detect the active path, packet loss might occur in the following situations:

· An active/standby path switchover is triggered upon a device reboot. If the SBFD session used to detect the active path comes up after a device reboot, the traffic on the standby path will be switched over to the active path. In this case, traffic loss will occur if the active path of the upper-layer protocol has not recovered completely.

· An active/standby path switchover is triggered after the active path goes down. If the SBFD session used to detect the active path comes up before the active path recovers, the traffic on the standby path will be switched over to the active path. In this case, traffic loss will occur.

To solve the traffic loss problem, you can delay SBFD session negotiation.

Delaying SBFD session negotiation upon a device reboot

About this task

This function starts a delay timer when the device reboots successfully. Before this timer expires, the device does not perform session negotiation on SBFD sessions in down state and newly created sessions.

Procedure

1. Enter system view.

system-view

2. Enable SBFD session negotiation delay upon a device reboot and set a delay timer.

bfd session-negotiation delay-upon-reboot interval

By default, SBFD session negotiation delay is disabled for a device reboot.

Delaying SBFD session negotiation for down SBFD sessions

About this task

This function starts a delay timer for each SBFD session from up to down state and each newly created session. Before the timer expires, the device does not perform session negotiation on each SBFD session.

Procedure

1. Enter system view.

system-view

2. Enable SBFD session negotiation delay for down SBFD sessions and set a delay timer.

bfd session-negotiation delay-upon-down interval

By default, SBFD session negotiation delay is disabled for down SBFD sessions.

Configuring a BFD template

About this task

You can configure SBFD parameters for the following paths through a BFD template:

· LDP LSPs.

· MPLS TE tunnels.

· SR-MPLS TE policies.

· SRv6 TE policies.

Procedure

1. Enter system view.

system-view

2. Create a BFD template and enter BFD template view.

bfd template template-name

3. Set the detection time multiplier.

bfd detect-multiplier value

The default setting is 3.

4. Set the minimum interval for sending SBFD control packets.

bfd min-transmit-interval interval

The default setting is 100 milliseconds.

5. Set the minimum interval for receiving SBFD echo packets.

bfd min-echo-receive-interval interval

The default setting is 100 milliseconds.

Enabling the SBFD whitelist feature

About this task

If the attacker sends a large number of invalid SBFD packets, the CPU cannot receive and process normal SBFD packets for maintaining the SBFD session state. The SBFD whitelist feature allows the device to create ACL rules based on five-tuple information of SBFD sessions. BFD packets that match ACL rules in the BFD whitelist are reported with higher priority than packets that match no ACL rules, to the CPU.

The SBFD whitelist feature works as follows:

· Upon receiving SBFD control packets from the peer for session establishment, the device creates an ACL rule based on session five-tuple information, and adds the rule to the whitelist.

· Upon receiving echoed SBFD echo packets from the peer, the device creates an ACL rule based on session five-tuple information, and adds the rule to the whitelist.

· The device adds SBFD packets that match ACL rules to the SBFD whitelist queue and packets that match no ACL rules to the ordinary queue. SBFD packets in the SBFD whitelist queue are processed at a higher processing rate. Packets for multiple protocols in the ordinary queue are processed at a lower processing rate. This feature allows packets that match the ACL rules to be separately reported to the CPU at a high rate.

Procedure

1. Enter system view.

system-view

2. Enable the SBFD whitelist feature.

bfd whitelist enable

By default, the SBFD whitelist feature is enabled.

Display and maintenance commands for SBFD

Execute the display command in any view.

Task	Command
Display SBFD session information.	display sbfd session { initiator [ discriminator value \| [ ipv6 [ peer-ipv6 ipv6-address ] \| srv6-policy ] [ verbose ] \| verbose ] \| reflector [ discriminator value \| verbose ] }

14-High Availability Configuration Guide

Echo packet mode

Control packet mode

About this task

Restrictions and guidelines

Procedure

Configuring BFD sessions in echo packet mode

About BFD session creation methods

About this task

Restrictions and guidelines

Creating a static BFD session for multihop detection

About this task

Restrictions and guidelines

Configure detection time settings for single-hop BFD detection

About this task

Procedure

Configuring the session establishment mode

About this task

Procedure

Configuring the detection mode

About this task

Procedure

About this task

Restrictions and guidelines for static BFD session configuration

Creating a static BFD session for single-hop detection

Create a static BFD session for multihop detection

About this task

Restrictions and guidelines

Configure detection time settings for single-hop BFD detection

Configure detection time settings for multihop BFD detection

About this task

Configure the authentication mode for a single-hop BFD session

Configure the authentication mode for a multihop BFD session

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Procedure

Configuring a BFD template

About this task

Procedure

About this task

Procedure

Restrictions and guidelines

Procedure

Restrictions and guidelines

Procedure

Enabling SNMP notifications for BFD

About this task

Procedure

Echo packet mode

Control packet mode

About this task

Restrictions and guidelines

Procedure

About this task