Summary of BFD Configuration Tasks
This section describes BFD session establishment modes, two detection modes, single- and multi-hop BFD, dynamic parameter modification, and binding of a BFD session to a VPN instance.
BFD can be used by multiple protocols. This section describes BFD features supported by the NetEngine 8000 F.
BFD Session Establishment Modes
- Static BFD sessions with manually specified discriminators
The local and remote discriminators must be set manually.
- Static BFD sessions with automatically negotiated discriminators
BFD monitors a static route and helps a node communicate with a remote node on which a dynamic BFD session is established. No local or remote discriminator needs to be set.
- BFD sessions dynamically triggered by protocols.No local or remote discriminator needs to be set. BFD sessions are further classified into the following types:
- BFD sessions with dynamically allocated local discriminators
- BFD sessions with self-learned remote discriminators
- In a static BFD session, if the discriminators on the local end are manually specified, the discriminators on the remote end must also be manually specified.
- If the static discriminators on the local end are automatically negotiated, the discriminators on the remote end can be automatically negotiated or a dynamic BFD session can be established on the remote end.
- On the local end, if a static BFD session with the automatically negotiated discriminators and a dynamic BFD session are established, the following principles are applicable:
- If a dynamic BFD session and a static BFD session with automatically negotiated discriminators are configured with the same quintuple set (the source and destination addresses, outbound interface, VPN index, and VS identifier), the NetEngine 8000 F uses the shared BFD session to which both the dynamic BFD session and static BFD session with automatically negotiated discriminators belong.
- If the dynamic BFD session named DYN_local discriminator is configured and then the static BFD session with automatically negotiated discriminators is configured, the name of the shared BFD session is updated as the name of the static BFD session.
- The smaller values of parameters between two BFD sessions are adopted.
Detection Modes
The NetEngine 8000 F supports the asynchronous detection mode. Each system sends BFD control packets at negotiated intervals. If a system does not receive packets from the peer within a detection period, the BFD session goes Down.
Echo is also supported in asynchronous mode. When the echo function is activated, the local system sends a BFD control packet and the remote system loops back the packet through the forwarding channel. If several consecutive echo packets are not received, the session is declared to be Down.
Single- and Multi-hop BFD
The NetEngine 8000 F supports single- and multi-hop BFD. Single- and multi-hop BFD monitors IP route continuity.
Layer 3 physical interfaces
Ethernet sub-interfaces including Eth-Trunk sub-interfaces
If a physical Ethernet interface has multiple sub-interfaces, BFD sessions can be established separately on the physical Ethernet interface and each of its sub-interfaces.
Layer 3 Eth-Trunk
Eth-Trunks consist of multiple member links, which provide high bandwidth or enhance reliability.
A trunk remains Up only when a certain number of member links are Up.
Dynamically Modifying BFD Parameters
After a BFD session is set up, you can modify BFD parameters, such as the minimum intervals at which BFD packets are sent and received and detection mode. This modification does not affect the current session status.
Binding a BFD Session to a VPN Instance
On the NetEngine 8000 F, a BFD session can be bound to a VPN instance to allow BFD control packets to be sent over a specified VPN.
Usage Scenario of BFD
BFD for everything |
Usage Scenario |
Configuration Reference |
|---|---|---|
BFD for default-ip |
A single-hop BFD session rapidly detects faults on direct links over a network. If the link interface is a Layer 3 physical interface or Layer 2 interface that does not have an IP address, configure static BFD for default-ip for link detection. |
|
BFD for Static Route |
Different from dynamic routing protocols, static routes do not have a detection mechanism. As a result, if a fault occurs on the network, the administrator needs to handle it. By binding IP static routes to BFD sessions, you can use BFD sessions to provide link detection for IP static routes on the public network. The routing management (RM) module determines whether static routes are available based on the BFD session status. |
Configuring Dynamic BFD for IPv4 Static Routes Configuring Dynamic BFD for IPv6 Static Routes |
BFD for OSPF |
OSPF enables a device to periodically send Hello packets to a neighboring router for fault detection. Detecting a fault takes more than 1s. As technologies develop, voice, video, and other VOD services are widely used. These services are quite sensitive to packet loss and delays. When traffic is transmitted at gigabit rates, long-time fault detection will cause packet loss. This cannot meet high reliability requirements of the carrier-class network. BFD for OSPF is introduced to resolve this problem. After BFD for OSPF is configured in a specified process or on a specified interface, the link status can be rapidly detected and fault detection can be completed in milliseconds. This speeds up OSPF convergence when the link status changes. |
|
BFD for OSPFv3 |
To increase the convergence speed of OSPFv3 when the link status changes, you can configure BFD on OSPFv3 links. BFD keeps track of liveliness of network links and detects any faults in the links much faster than the normal keep-alive protocols. When OSPFv3 is associated with BFD sessions, link failures are notified immediately to OSPFv3 by BFD and OSPFv3 can take actions to perform route calculation and converge in the new network topology. |
|
BFD for BGP |
As technologies develop, voice and video services are widely applied. These services are quite sensitive to the packet loss and delay. BGP periodically sends Keepalive packets to its peers to detect the status of its peers. The detection mechanism, however, takes more than one second. When the data transmission rate reaches the level of Gbit/s, such slow detection will cause a large amount of data to be lost. As a result, the requirement for high reliability of carrier-class networks cannot be met. To address this problem, configure BFD for BGP. BFD for BGP detects faults on links between BGP peers within 50 ms. The fast detection speed ensures fast BGP route convergence and minimizes traffic loss. |
|
BFD for BGP4+ |
BFD can rapidly detect IPv6 forwarding failures. By adopting the BFD fast detection mechanism, an IPv6 network can transmit voice services, video services, and VoD services with high QoS. This enables service provides to provide their customers with highly available and reliable VoIP and other real-time services. BGP periodically sends Keepalive messages to the peer to detect faults on the neighbor. This mechanism, however, takes more than one second to detect a fault. When the data rate is up to Gbit/s, the detection mechanism causes a great packet loss. This mechanism fails to meet the requirement on the reliability of core networks. To address this problem, configure BFD for BGP4+. BFD for BGP4+ detects faults on links between BGP4+ peers within milliseconds. If a fault is detected, it notifies BGP of the fault. Therefore, BGP4+ routes can undergo fast convergence. |
|
BFD for LDP LSP |
With BFD for LDP LSP, failure detection speeds up and the workload of configuring decreases. In addition, LDP FRR is well supported for the LSP for providing better services. |
|
BFD for LDP Tunnel |
Dynamic BFD can be configured to establish a dynamic BFD session to monitor both primary and backup LDP LSPs in an LDP tunnel. If BFD detects a fault, BFD instructs a specific LDP upper-layer application to perform a protection switchover. |
|
BFD for BGP Tunnel |
BFD for BGP tunnel rapidly detects faults in E2E BGP tunnels. |
|
BFD for RSVP |
If BFD is disabled and a Layer 2 device exists between RSVP neighbors, the neighboring node cannot rapidly detect the fault after the link fails, resulting in a great loss of data. BFD detects faults at millisecond level in protected links or nodes. BFD for RSVP rapidly detects faults in an RSVP neighbor, allowing packets to switch to a backup LSP rapidly. BFD for RSVP is applied to a scenario where TE FRR is used and a Layer 2 device exists on the primary LSP between a PLR and its downstream neighbors. On a network where GR is enabled on the PLR and MP, BFD for RSVP is also recommended. |
|
BFD for CR-LSP |
BFD monitors CR-LSPs. After BFD detects a fault in a CR-LSP, the BFD module immediately instructs the forwarding plane to trigger a rapid traffic switchover. BFD for CR-LSP is used together with a hot-standby CR-LSP or TE FRR. |
|
BFD for TE tunnel |
BFD for TE allows applications such as VPN FRR or VLL FRR to fast switch traffic if the primary tunnel fails, preventing service interruption. |
|
BFD for IS-IS |
Connection status between an IS-IS device and its neighbors can be monitored by exchanging Hello packets at intervals. The minimum allowable sending interval is 3s, and a neighbor is declared Down after at least three intervals during which no response Hello packet is received from the neighbor. IS-IS takes more than one second to detect that a neighbor becomes Down, resulting in loss of a large amount of high-speed data. To solve this problem, BFD must be configured for IS-IS. IPv4 BFD provides millisecond-level fault detection. After detecting a link or node failure, BFD will notify IS-IS of the failure, accelerating the IS-IS route convergence speed. |
Configuring Static BFD for IS-IS |
BFD for RIP |
Generally, RIP uses timers to receive and send Update messages to maintain neighbor relationships. If a RIP device does not receive an Update message from a neighbor after the Age timer expires, the RIP device will announce that this neighbor goes Down. The default value of the Age timer is 180s. If a link fault occurs, RIP can detect this fault after 180s. If high-rate data services are deployed on a network, a great deal of data will be lost during the aging time. BFD provides millisecond-level fault detection. It can rapidly detect faults in protected links or nodes and report them to RIP. This speeds up RIP processes' response to network topology changes and achieves rapid RIP route convergence. |
|
BFD for PIM |
Generally, if the current DR in a shared network segment is faulty, other PIM neighbors triggers a new round of DR election only after the neighbor relationship times out. The duration that data transmission is interrupted is not shorter than the timeout period of the neighbor relationship. Generally, it is of second level. BFD features fast detection of faults, and is up to the millisecond level. BFD can detect statuses of PIM neighbors in the shared network segment. When BFD detects that a peer is faulty, BFD immediately reports it to PIM. PIM then triggers a new round of DR election without waiting for the timeout of the neighbor relationship. This shortens the duration of interruption of data transmission and enhances the reliability of the network. |
Configuring BFD for IPv4 PIM |
BFD for PW |
If provider edge devices (PEs) on a Multiprotocol Label Switching (MPLS) Layer 2 virtual private network (L2VPN) communicate over pseudo wires (PWs), service protection can be enhanced by configuring static BFD to detect PW connectivity. |
|
BFD for VSI PW (default-ip) |
In the VPLS convergence MAN solution, you can establish multiple service VSI PWs and bind them to an mVSI PW. In this manner, if a BFD session is bound to the mVSI PW, you can monitor the service VSI only by monitoring the status of the mVSI PW. |
Configuring Static BFD to Detect the Connectivity of a VPLS SS-PW |
BFD for VRRP |
Bidirectional Forwarding Detection (BFD) can rapidly detect faults in links or IP routes. BFD for VRRP enables a master/backup VRRP switchover to be completed within 1 second, preventing user traffic loss. A BFD session is established between the master and backup devices in a VRRP group and is bound to the VRRP group. BFD immediately detects communication faults in the VRRP group and instructs the VRRP group to perform a master/backup switchover, minimizing service interruptions. |
|
BFD for E-Trunk |
An E-Trunk implements inter-device link aggregation. After a BFD session is bound to an E-Trunk, BFD can rapidly detect the changes in the protocol link between devices with the E-Trunk deployed. If the protocol link fails, the status of the BFD session goes Down. Two devices with the E-Trunk deployed can use BFD to rapidly detect faults and change the master/backup status, ensuring proper traffic forwarding. |
Configuring an E-Trunk for Backup in a Link Aggregation Group |
BFD for Multicast VPLS |
To meet the reliability requirements of multicast services, configure BFD for multicast VPLS to monitor multicast VPLS links. When a link or node fails, BFD on the leaf nodes can rapidly detect the fault and trigger protection switching so that the leaf nodes receive traffic from the backup multicast tunnel. |
|
BFD for link-bundle |
When two devices are directly connected over a Layer 3 Eth-Trunk, you can configure a BFD for link-bundle session to detect link faults. After a BFD for link-bundle session is bound to an Eth-Trunk interface, the system creates a dynamic unicast BFD sub-session for each Eth-Trunk member interface. Each sub-session independently negotiates and monitors the link status and reports the monitored link status. The system also creates a main session, which processes the link status reported by the sub-sessions and reports its status to the APP. The main session goes Down only when all sub-sessions go Down. |
Configuring a BFD for Link-Bundle Session to Detect Eth-Trunk Member Link Faults |
SBFD for SR-MPLS TE Policy |
SBFD for SR-MPLS TE Policy can quickly detect segment list faults. If all the segment lists of a candidate path are faulty, SBFD triggers a candidate path switchover to reduce impacts on services. |
|
SBFD for SRv6 TE Policy |
SBFD for SRv6 TE Policy can quickly detect segment list faults. If all the segment lists of a candidate path are faulty, SBFD triggers a candidate path switchover to reduce impacts on services. |