BFD Technology White Paper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Contents

Overview·· 1

Background· 1

Benefits· 1

BFD implementation· 1

Concepts· 1

Mechanism·· 1

BFD session in echo packet mode· 2

Echo packets· 2

Session establishment 3

Detection mechanism·· 3

BFD session in control packet mode· 3

Control packets· 3

BFD session creation methods· 4

BFD session establishment process· 5

Timer negotiation· 6

Detection mechanism·· 8

BFD echo function· 8

SBFD implementation· 8

Mechanism·· 8

Restrictions· 9

BFD for SRv6 implementation· 9

Feature overview· 9

SRv6 BE detection· 9

Introduction· 9

Mechanism·· 9

SRv6 TE policy detection· 10

Introduction· 10

Mechanism·· 10

Comware implementation of hardware BFD·· 12

Background· 12

Mechanism·· 12

Echo-packet-mode hardware BFD·· 12

Control-packet-mode hardware BFD·· 12

Restrictions· 13

Application scenarios· 13

Configuring BFD for routing protocols· 13

Configuring BFD for fast reroute· 13

Configuring BFD for VRRP· 14

Configuring BFD for MPLS L3VPN over SRv6 FRR· 15

Configuring SBFD for SR-MPLS TE policy· 16

References· 17

 

Overview

Background

To protect key applications, a network is usually designed with redundant links. Devices need to quickly detect communication failures and restore communication through backup links as soon as possible. On some links, such as POS links, devices detect link failures by sending hardware detection signals. However, some other links, such as Ethernet links, provide no hardware detection mechanism. In that case, devices can use the hello mechanism of a protocol for failure detection, which has a failure detection rate of more than one second. Such a rate is too slow for some applications. Some routing protocols, such as OSPF and IS-IS, provide a fast hello mechanism for failure detection, but this mechanism has a failure detection rate of at least one second and is protocol-dependent.

Benefits

BFD provides a general-purpose, standard, medium- and protocol-independent fast failure detection mechanism. It has the following benefits:

·     Detecting failures on any bidirectional forwarding paths, such as direct physical link, SRv6 BE forwarding path, SRv6 TE policy forwarding path, MPLS LSP, multi-hop path, and unidirectional link, between network devices.

·     Providing consistent fast fault detection time for upper-layer applications.

·     Providing a failure detection time in milliseconds for faster network convergence, short application interruptions, and enhanced network reliability.

BFD implementation

Concepts

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

·     Single-hop detection—Detects the IP connectivity between two directly connected systems.

·     Multihop detection—Detects any of the paths between two systems. These paths might have multiple hops.

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, both ends of the session will periodically send BFD packets to each other. 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

 

Based on the packet types used for detection, BFD sessions are divided into the following types:

·     BFD session in echo packet mode. An echo-packet-mode BFD session does not require BFD feature support or BFD configuration on the peer device. This type of session applies when only one end requires fault detection.

·     BFD session in control packet mode. A control-packet-mode BFD session requires BFD configuration on both ends. This type of session applies when both ends require fault detection.

BFD session in echo packet mode

Echo packets

BFD echo packets are encapsulated in UDP packets. The packet contains destination port 3785, a destination IP address (transmitting interface's IP address), and a configured source IP address (make sure it does not cause ICMP redirection).

BFD does not define the echo packet format. The transmitting end must be able to identify sessions by packet contents.

Echo-packet mode BFD sessions support multihop detection only for tunnels. In other applications, it supports only single-hop detection.

Session establishment

The local end of the link sends echo packets to establish BFD sessions and monitor link status. The peer end only forwards the packets back to the local end.

Detection mechanism

The local end sends BFD echo packets. The peer returns received BFD echo packets back without processing them. If the local end does not receive echo packets from the peer end within the detection time, it considers the session down.

BFD session in control packet mode

Control packets

BFD control packets adopt the UDP encapsulation with a source port in the range of 49152 to 65535. The destination port is 3784 for single-hop detection and 4784 for multihop detection.

A BFD control packet contains the required fields and the optional authentication fields, as shown in Figure 3.

Figure 3 BFD control packet format

 

Table 1 BFD control packet field description

Field	Description
Vers	BFD version. The current version is 1.
Diag	This bit indicates the reason for the last transition of the local protocol from up to some other state.
Sta	Current BFD session state: ·     0—AdminDown. ·     1—Down. ·     2—Init. ·     3—Up.
P	If it is set to 1, the transmitting system requests the connection acknowledgement or acknowledges a parameter change.
F	If it is set to 1, the transmitting system responds to a received BFD control packet that has the Poll (P) bit set.
C	If set to 1, it means the BFD implementation for the transmitting system is independent of its control plane.
A	If it is set to 1, the control packet contains the authentication field and the session is authenticated.
D	If set to 1, it means the transmitting system wishes to operate in the demand mode; if set to 0, it means the transmitting system ignores the demand mode or cannot operate in the demand mode.
R	Reserved. It is set to 0 during transmission and ignored during reception.
Detect Mult	Detection time multiplier.
Length	BFD control packet length, in bytes.
My Discriminator	A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions between the same pair of systems.
Your Discriminator	This field reflects back the received value of My Discriminator or is 0 if that value is unknown.
Desired Min TX Interval	Minimum interval at which the local protocol wishes to send BFD control packets, in milliseconds.
Required Min RX Interval	Minimum interval at which the local system can receive BFD control packets, in milliseconds.
Required Min Echo RX Interval	This is the minimum interval, in microseconds, between received BFD Echo packets that this system is capable of supporting. If this value is zero, the transmitting system does not support the receipt of BFD echo packets.
Auth Type	Authentication type used by BFD control packets.
Auth Len	Authentication field length, including authentication type field and authentication length field, in bytes.

 

BFD session creation methods

A control-packet-mode BFD session can be created in the following ways:

·     Manually created with a command.

·     Dynamically created when upon association between an application program with BFD.

BFD uses the local discriminator (My Discriminator) and remote discriminator (Your Discriminator) in control packets to distinguish sessions. 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.

·     You can configure the local discriminator and remote discriminator of a static BFD session as follows:

¡     Specify the local discriminator and remote discriminator when manually creating the static BFD session.

¡     Manually specify the local discriminator and remote discriminator when associating the application program with BFD.

·     The local discriminator of a dynamic BFD session is assigned by the device, and the remote discriminator is obtained during BFD session negotiation.

BFD session establishment process

BFD state machine

Typically, a BFD session can be in the following states:

·     DOWN—The local 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 an appropriate action, such as primary/backup path switchover.

·     INIT—The local end can communicate with the remote end and requires the BFD session to transition to UP state.

·     UP—The BFD session has been established on the local end. This state indicates that the forwarding path is available.

The ADMIN DOWN state is a special state. When the local system proactively prevents BFD session establishment, the BFD session is administratively shut down. The ADMIN DOWN state in the state machine is also the DOWN state. The state machine transition mechanism is as shown in Figure 4.

Figure 4 BFD state machine

 

Session establishment process

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.

BFD uses a three-way handshake for session establishment. The local system adds its session state to the State (Sta) field in a BFD control packet. Upon receiving the BFD control packet, the remote system performs state transitions based on the received session state in combination with the local session state.

Figure 5 shows the packet exchange and state transitions during session establishment between two routers operating in active mode.

Figure 5 Session establishment process

 

1.     Upon receipt of a notification from an upper-layer application, Routers A and B send a BFD control packet in DOWN state to the peer.

2.     When Router B receives the BFD control packet in DOWN state, the local session state transits from DOWN to INIT. In the BFD control packet sent subsequently, the Sta field is filled with a value of 2 (indicating the session state is INIT). Router A experiences the same BFD state transition as Router B.

3.     When Router A receives the BFD control packet in INIT state from the peer, the local session state transits from INIT to UP. In the BFD control packet sent subsequently, the Sta field is filled with a value of 3 (indicating the session state is UP). Router B experiences the same BFD state transition as Router A.

4.     Both BFD peers are UP. A session is established successfully and BFD starts to detect link failures.

5.     When the local session state is DOWN, the local ends sends a BFD control packet with the Sta field set to 1. Upon receiving the packet, the remote end also sets the session state to DOWN.

Timer negotiation

About timers

The following timers can be negotiated during the establishment of a BFD session:

·     BFD control packet transmission interval—Before establishing a BFD session, each device sends BFD control packets at a specific interval. After establishing a BFD session, the devices send BFD control packets at the negotiated interval for fast detection.

Before session establishment, the minimum BFD control packet transmission interval is one second, and the interval varies by device model. Some devices requiring large numbers of sessions use longer transmission intervals to reduce traffic.

·     Detection time—Each time a BFD control packet is received, the device resets the detection timer so that the session remains up. If no BFD control packet is received within the detection time, the BFD session state transits to DOWN, and BFD notifies the failure to the associated upper-layer application. The upper-layer application then takes proper measures.

Timer negotiation mechanism

The timers are calculated as follows:

·     The BFD control packet transmission interval is the greater value of the following parameters:

¡     Desired Min TX Interval of the local end.

¡     Required Min RX Interval of the peer end.

·     The detection timer is the Detect Mult of the BFD control packets transmitted by the peer multiplied the greater value of the following parameters:

¡     Required Min RX Interval of the local end.

¡     Desired Min TX Interval of the peer end.

If a BFD session is valid, these timers can be negotiated and modified without affecting session state.

The timers for different BFD session directions are negotiated independently of each other and can be different.

·     If the Desired Min TX Interval of the local end increases, the actual BFD control packet transmit interval of the local end cannot be changed until the local end receives a packet with the F bit set from the peer. This ensures that the peer has increased the detection timer before the BFD control packet transmit interval increases on the local end, thus avoiding detection timer timeout errors on the peer.

·     If the Required Min RX Interval of the local end decreases, the detection timer of the local end cannot be changed until the local end receives a packet with the F bit set from the peer. This ensures that the peer has decreased the BFD control packet transmit interval before the local end decreases the detection timer, thus avoiding detection timer timeout errors on the local end.

·     If the Desired Min TX Interval decreases, so does the BFD control packet transmit interval on the local end immediately. If the Required Min RX Interval increases, so does the detection timer on the local end immediately.

The following describes the timer negotiation process after a parameter change. As shown in Figure 6, a BFD session is established between Router A and Router B. Both routers have the same Desired Min TX Interval (hereinafter referred to as TX) and Required Min RX Interval (hereinafter referred to as RX) of 100 milliseconds and the same Detect Mult of 3. According to timer negotiation rules, the BFD control packet transmit interval is Router A's TX or Router B's RX, whichever is greater (both are 100 milliseconds). Router B's transmit interval is also 100 milliseconds, and both routers have a detection timer of 300 milliseconds.

If TX and RX of Router A increase to 150 milliseconds:

1.     Router A compares its RX (150 milliseconds) with Router B's TX (100 milliseconds) and changes the detection timer of the local end to 450 milliseconds. Meanwhile, Router A sends a BFD control packet (with a TX and RX of 150 milliseconds) whose P bit is set to the peer.

2.     Upon receipt of the packet, Router B compares the RX in the received packet with the TX of the local end. As RX is greater, Router B's transmit interval is changed to 150 milliseconds. After comparing the RX of the local end with the TX of the peer, Router B also changes its detection timer to 450 milliseconds. Then, Router B replies to Router A with a BFD control packet whose F bit is set (with a TX and RX of 100 milliseconds).

3.     Router A receives the BFD control packet with the F bit set from the peer. After comparing the RX in the received packet and the TX of the local end, Router A calculates the new transmit interval as 150 milliseconds.

4.     The timer negotiation is complete. The BFD control packet transmit interval and detection timer for the routers are 150 milliseconds and 450 milliseconds, respectively.

Figure 6 BFD detection timer negotiation

 

Detection mechanism

After BFD session establishment and timer negotiation, both ends start to transmit BFD control packets at the negotiated interval.

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. By default, the two ends of the session operate in Asynchronous mode.

·     Demand mode—When a large number of BFD sessions exist in the system, 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.

¡     If the peer end is operating in Demand mode, both ends stop sending BFD control packets after establishing a BFD session. When the connectivity to another system needs to be verified explicitly, a system sends several BFD control packets with the Poll (P) bit set. If no response with F bit set is received within the detection interval, the session is considered down. If a response with F bit set is received within the detection interval, the connectivity is up. No more BFD control packets are sent until the next command is issued.

BFD echo function

When using the BFD session in Asynchronous mode to detect directly-connected subnet connectivity, you can use the echo function to help detect failures.

A device enabled with echo function periodically sends BFD echo packets and reduces the transmission rate of control packets. The peer device returns the received BFD echo packets without processing them. If the sending device receives no BFD echo packet from the peer within the BFD interval, the session is considered down.

SBFD implementation

Mechanism

Seamless BFD (SBFD) is a unidirectional failure detection mechanism that provides shorter detection time than BFD. SBFD supports only the UP and DOWN state, which simplifies BFD state machine and reduces the session negotiation time. SBFD is used in scenarios where only one end of a link requires failure detection.

An SBFD session uses the following roles:

·     Initiator—Initiates SBFD sessions and maintains SBFD session state. It periodically sends SBFD control packets.

·     Reflector—Listens for incoming SBFD control packets on local entities and replies with response SBFD control packets. It does not need to maintain SBFD session state.

Figure 7 shows the operating mechanism of an SBFD session. In an SR-based MPLS TE tunnel, the SRLSP from Router A to Router E is considered available if Router A (initiator) can receive response SBFD control packets from Router E (reflector).

Figure 7 Initiator and reflector in SBFD

 

Restrictions

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.

BFD for SRv6 implementation

Feature overview

BFD can fast detect failures on the SRv6 BE forwarding paths and SRv6 TE policy forwarding paths and monitor path connectivity. When a failure occurs, an SRv6 BE or SRv6 TE policy path switchover is performed to enhance network availability.

SRv6 BE detection

Introduction

In an SRv6 BE network, you can use static BFD sessions to detect locator reachability, improving switchover performance upon failures.

Mechanism

As shown in Figure 8, Device A, Device B, and Device C are SRv6 nodes. Set up an SRv6 BE forwarding path from Device A to Device C. The locator prefix for Device A is 100:1::/120. The locator prefix for Device B is 200:1::/120. The locator prefix for Device C is 300:1::/120. Create a static BFD session on Device A and Device C, respectively. Specify the source and destination addresses for the static BFD sessions on Device A and Device C as follows:

·     Specify the source address as 100:1::0 and destination address as 300:1::0 for the static BFD session on Device A.

·     Specify the source address as 300:1::0 and destination address as 100:1::0 for the static BFD session on Device C.

After you creating the static BFD sessions, Device A and Device C periodically send BFD control packets through the shortest path of the IPv6 route. If Device A and Device C receive the BFD control packets sent from the peer within the detection time, they determine that the SRv6 BE forwarding path is normal. If not, they determine that the SRv6 BE forwarding path is faulty.

Figure 8 SRv6 BE network

 

SRv6 TE policy detection

Introduction

Both SBFD and echo-packet-mode BFD can be used to detect the connectivity of SRv6 TE policy paths. They provide millisecond-level fault detection and implement fast switchover upon detecting a failure.

Mechanism

Using SBFD for SRv6 TE policy detection

In an SRv6 TE policy, the valid path with the highest priority is the primary path, and the valid path with the second highest priority is the backup path. SBFD can detect the primary and backup paths for the SRv6 TE policy. If multiple SID lists exist in the primary and backup paths, the SRv6 TE policy establishes separate BFD sessions to monitor the forwarding path corresponding to each SID list. If all the SID lists for the primary path are faulty, SBFD notifies the SRv6 TE policy to perform a primary-to-backup path switchover.

As shown in Figure 9, configure an SRv6 TE policy on Device A and use SBFD to detect the SRv6 TE policy paths. SBFD detects the SRv6 TE policy paths as follows:

The source node (the initiator) sends SBFD packets that encapsulate the SID lists of the primary and backup candidate paths of the SRv6 TE policy. If multiple SID lists exist, the SRv6 TE policy encapsulates the SID lists in multiple packets.

After the endpoint node (the reflector) receives an SBFD packet, it checks whether the remote discriminator carried the packet is the same as the local discriminator. If yes, the reflector sends the SBFD response packet to the initiator by using the IPv6 routing table. If not, the reflector drops the SBFD packet.

If the source node can receive the SBFD response within the detection timeout time, it determines the corresponding SID list (forwarding path) of the SRv6 TE policy is available. If no response is received, the source node determines that the SID list is faulty. If all SID lists of the primary path are faulty, SBFD triggers a primary/backup path switchover.

Figure 9 SBFD for SRv6 TE policy detection process

 

Using echo-packet-mode BFD sessions for SRv6 TE policy detection

In an SRv6 TE policy, the valid path with the highest priority is the primary path, and the valid path with the second highest priority is the backup path. You can use echo-packet-mode BFD to detect the primary and backup paths of the SRv6 TE policy. If multiple SID lists exist in the primary and backup paths, the SRv6 TE policy establishes separate BFD sessions to monitor the forwarding path corresponding to each SID list. If all the SID lists for the primary path are faulty, BFD notifies the SRv6 TE policy to perform a primary-to-backup path switchover.

As shown in Figure 10, configure an SRv6 TE policy on Router A and use echo-packet-mode BFD to detect the SRv6 TE policy paths as follows:

The source node sends BFD echo packets that encapsulate the SID lists of the SRv6 TE policy to detect the primary and backup paths. If multiple SID lists exist, the SRv6 TE policy encapsulates the SID lists in multiple packets.

Upon the BFD echo packets, the endpoint node sends the packets back to the source node through the shortest path of the IPv6 route.

If the source node can receive the returned BFD echo packets within the detection timeout time, it determines the corresponding SID list (forwarding path) of the SRv6 TE policy is available. If no response is received, the source node determines that the SID list is faulty. If all SID lists of the primary path are faulty, BFD triggers a primary/backup path switchover.

Figure 10 Using echo-packet-mode BFD sessions for SRv6 TE policy detection

 

Comware implementation of hardware BFD

Background

In software BFD, the device uses the CPU to receive and send BFD packets and to maintain the BFD state machine. Software BFD greately consumes CPU resources and cannot support a large number of BFD sessions.

In hardware BFD, the device uses the chips to process those BFD-related tasks and can support a large number of BFD sessions.

Mechanism

Echo-packet-mode hardware BFD

For a BFD session in echo packet mode, the device attempts to forward the BFD session to the chip after receiving the first echo packet looped back.

·     If the chip supports BFD, the system notifies the software and the software no longer maintains the BFD session.

·     If the chip does not support BFD, the system notifies the software and the software still maintains the BFD session.

Control-packet-mode hardware BFD

For a BFD session in control packet mode, the chip cannot perform session negotiation. Before the BFD session comes up, the device uses the CPU to perform session negotiation. After the BFD session comes up, the device attempts to transfer the BFD session to the chip.

·     If the chip supports BFD, the system notifies the software and the software no longer maintains the BFD session.

·     If the chip does not support BFD, the system notifies the software and the software still maintains the BFD session.

To support session negotiation for a large number of BFD sessions, hardware BFD negotiates timers as follows:

1.     A BFD session comes up when the local end receives a BFD control packet signaling INIT state in DOWN state or receives a BFD control packet signaling UP state in INIT state. After the BFD session comes up, the device sends a BFD control packet with the P bit set to the peer. The transmission interval, receiving interval, and detection time multiplier carried in the packet are the maximum values supported by the local end.

2.     The peer replies with a BFD control packet with the F bit set after receiving the BFD control packet with the P bit set.

3.     The local end reduces the transmission interval, receiving interval, and detection time multiplier to the configured values, and sends a new BFD control packet with the P bit set to the peer. The transmission interval, receiving interval, and detection multiplier carried in the packet are the configured values on the local end. The transmission interval of the local end is the greater of the configured transmission interval and the transmission interval in the last received BFD control packet. The detection time is the detection time multiplier multiplied by the greater of the maximum receiving interval and the receiving interval in the last received BFD control packet.

4.     The peer replies with a BFD control packet with the F bit set.

5.     The local ends changes the detection time to the detection time multiplier multiplied by the greater of the configured receiving interval and the receiving interval in the last received BFD control packet.

6.     If the local end does not receive a BFD control packet with the F bit set, it will continuously sends BFD control packets with the P bit set until it receives that packet.

Restrictions

Hardware BFD has the following restrictions:

·     The chip has some restrictions on the transmission interval, receiving interval, and detection time multiplier. For example, the transmission interval and receiving interval might be required to be a multiple of 10 milliseconds.

·     BFD packet authentication is not supported.

·     The negotiation process for hardware BFD is more complex than that for software BFD and takes a longer negotiation time. If a link fails before the negotiation is complete, the detection time might be longer.

Application scenarios

Configuring BFD for routing protocols

As shown in Figure 11, Router A and Router B are interconnected through a Layer 2 switch. Both routers run a routing protocol.

When link between Router A and Router B interconnected through a Layer 2 switch fails, BFD can fast detect the failure and notify OSPF. Upon receiving the notification from BFD, OSPF immediately recalculates routes for fast convergence.

Figure 11 Application scenario where BFD works with routing protocols

 

Configuring BFD for fast reroute

Many delay-sensitive services on the Internet, such as audio and video services, require fast route convergence. Configuring BFD for routing protocols or using the fast route convergence technologies can greatly speeds up convergence but cannot fully meet the failover requirements of audio and video services.

Configuring BFD for fast reroute can satisfy such requirements. As shown in Figure 12, a backup path is calculated in advance. When the primary path fails, the device can immediately detect the failure and switch traffic directly to the backup path at the forwarding plane, ensuring service continuity.

Figure 12 Application scenario where BFD is configured for fast reroute

 

Configuring BFD for VRRP

With the Virtual Router Redundancy Protocol (VRRP) enabled, when the master device fails, the backup device can quickly take over the forwarding task from the master, thus minimizing user data flow interruptions. When the master fails, if the backup receives no packet from the master within the preemption delay timer, the backup becomes the new master, with a switchover time of over one second. As shown in Figure 13, after BFD is configured for the backup to monitor the master, failures of the master can be detected more quickly to shorten user data flow interruptions.

VRRP also monitors the status of the master's uplink. When the master works normally but its uplink fails, user packets cannot be forwarded correctly. VRRP determines whether an uplink is available by monitoring the uplink interface status. When the monitored interface is down, the master reduces its priority to initiate a switchover. However, this mechanism depends on the protocol status; if the uplink fails but the protocol status of the interface remains up, the failure cannot be detected through VRRP. Configuring BFD for the VRRP master to monitor its uplink can solve this problem.

Figure 13 BFD for VRRP

 

Configuring BFD for MPLS L3VPN over SRv6 FRR

MPLS L3VPN over SRv6 Fast Reroute (FRR) is applicable to a CE dualhomed scenario (a CE is connected to two PEs). You can specify a backup path for the primary path used for traffic forwarding, and use static BFD to detect the primary link status. When the primary path fails, traffic is immediately switched over to the backup path to minimize the interruption time. When using the backup path to forward packets, FRR performs optimal route reselection again. After that, it uses the selected optimal route to forward packets.

Figure 14 shows an example for VPNv4 route backup. Specify the FRR backup next hop as PE 3 for VPN 1 on ingress node PE 1. Upon receiving VPNv4 routes advertised by PE 2 and PE 3 to CE 2, PE 1 records the two VPNv4 routes. Then it uses the VPNv4 route advertised by PE 2 as the primary path, and uses the VPNv4 route advertised by PE 3 as the backup path.

Configure static BFD on PE 1 to detect the status of the public network tunnel between PE 1 and PE 2. PE 1 is responsible for traffic switchover. When the public network tunnel is operating correctly, CE 1 and CE 2 communicate through the primary path CE 1—PE 1—PE 2—CE 2. Upon detecting a fault of the public network tunnel, PE 1 forwards traffic from CE 1 to CE 2 through the backup path CE 1—PE 1—PE 3—CE 2.

Figure 14 MPLS L3VPN over SRv6 FRR

 

Configuring SBFD for SR-MPLS TE policy

An SR-MPLS TE policy does not maintain its status through message exchange between devices. It uses SBFD to detect path failures.

As shown in Figure 15, with SR-MPLS TE policy and SBFD collaboration enabled, the source node Router A uses the endpoint address as the remote discriminator of SBFD. In the SR-MPLS TE policy, if the path with the highest priority has multiple SID lists, the SR-MPLS TE policy establishes separate SBFD sessions to monitor the forwarding path corresponding to each SID list. All SBFD sessions have the same remote discriminator.

SBFD detects the SR-MPLS TE policy paths as follows:

1.     The source node (Router A) sends SBFD packets that encapsulate the SID lists of the SR-MPLS TE policy.

2.     Upon receiving the SBFD packets, the endpoint node (Router E) sends response packets through the shortest path based on routing table lookup.

3.     Upon receiving the SBFD response packets, the source node (Router A) determines that the forwarding path associated with the SID list is normal. If no SBFD response packet is received, the source node determines that the forwarding path associated with the SID list is faulty. If the forwarding paths associated with all SID lists of the candidate path are faulty, SBFD triggers a primary/backup path switchover.

Figure 15 SBFD for SR-MPLS TE policy

 

References

·     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 7880: Seamless Bidirectional Forwarding Detection (S-BFD)

·     RFC 7881: Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS

·     RFC 7882: Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases