BFD for SR-MPLS TE
An SR-MPLS TE LSP can be successfully established after a label stack is delivered. Moreover, it does not encounter the protocol down event, except for situations where the label stack is withdrawn. Therefore, bidirectional forwarding detection (BFD) needs to be deployed to help detect SR-MPLS TE LSP faults, which, if detected, triggers a primary/backup SR-MPLS TE LSP switchover. BFD for SR-MPLS TE is an E2E detection mechanism that rapidly detects SR-MPLS TE LSP/tunnel faults.
BFD for SR-MPLS TE
BFD for SR-MPLS TE provides the following functions:
BFD for SR-MPLS TE LSP
- Static BFD session: established by manually specifying local and remote discriminators. The local discriminator of the local node must be equal to the remote discriminator of the remote node, and vice versa. After such a session is established, the intervals at which BFD packets are received and sent can be modified.
- Dynamic BFD session: The local and remote discriminators do not need to be manually specified. After an SR-MPLS TE tunnel goes up, a BFD session is triggered. The devices on both ends of the BFD session negotiate the local discriminator, remote discriminator, and intervals at which BFD packets are received and sent.
A BFD session is bound to an SR-MPLS TE LSP, meaning that the session is established between the ingress and egress. In this session, the ingress sends a BFD packet to the egress through the LSP. After receiving the packet, the egress replies, enabling the ingress to quickly detect the link status of the LSP.
If a link fault is detected, BFD notifies the forwarding plane of the fault. The forwarding plane then searches for a backup SR-MPLS TE LSP and switches traffic to the LSP.
BFD for SR-MPLS TE Tunnel
- BFD for SR-MPLS TE LSP determines whether a primary/backup LSP switchover needs to be performed, whereas BFD for SR-MPLS TE tunnel checks the actual tunnel status.
If BFD for SR-MPLS TE tunnel is not configured, a device cannot detect the actual tunnel status because the tunnel status is up by default.
If BFD for SR-MPLS TE tunnel is configured but BFD is administratively down, the tunnel interface status is unknown because BFD is not working in this case.
If BFD for SR-MPLS TE tunnel is configured and BFD is not administratively down, the tunnel interface status is the same as the BFD status.
The interface status of an SR-MPLS TE tunnel is consistent with the status of BFD for SR-MPLS TE tunnel. As BFD negotiation needs to be performed, it takes time for BFD to go up. In general, if a new label stack is delivered for a tunnel in the down state, it takes approximately 10 to 20 seconds for BFD to go up. This consequently slows down hard convergence when other protection functions are not configured for the tunnel.
BFD for SR-MPLS TE (One-Arm Mode)
If the egress does not support BFD for SR-MPLS TE, BFD sessions cannot be created. To address this issue, configure one-arm BFD for SR-MPLS TE.
On the ingress, enable BFD and specify the one-arm mode to establish a BFD session. After the BFD session is established, the ingress sends BFD packets to the egress through transit nodes along an SR-MPLS TE tunnel. After receiving the BFD packets, the forwarding plane of the egress removes MPLS labels, searches for a route based on the destination IP address of the BFD packets, and then directly loops back the BFD packets to the ingress for processing, thereby achieving detection in one-arm mode.
BFD for SR-MPLS TE packets are forwarded along a path specified using label stacks in the forward direction, whereas their return packets are forwarded along the shortest IP path in the reverse direction. This means that the return path of the packets is not fixed. Furthermore, if the route of BFD return packets is unreachable, the involved tunnel may go down. Therefore, you need to ensure that the route of BFD return packets is reachable. Additionally, BFD does not need to be configured for the backup SR-MPLS TE LSP. This is because the involved route re-recurses to the primary LSP after the primary LSP recovers and the tunnel goes up again.
Application of BFD for SR-MPLS TE
The following uses the network shown in Figure 1 as an example to describe how BFD for SR-MPLS TE LSP is implemented in a scenario where VPN traffic recurses to an SR-MPLS TE LSP.
Devices A, CE1, CE2, and E are deployed on the same VPN. CE2 advertises a route to E. PE2 assigns a VPN label to E and advertises the route to PE1. PE1 installs the route to E and the VPN label. The SR-MPLS TE LSP from PE1 to PE2 is PE1 -> P4 -> P3 -> PE2, which is the primary LSP with the label stack <9004, 9003, 9005>.
After PE1 receives a packet sent from A to E, it finds the outbound interface of the packet based on label 9004 and adds label 9003, label 9005, and the innermost VPN label to the packet. If BFD is configured and a link or P device on the primary SR-MPLS TE LSP fails, PE1 can rapidly detect the fault and switch traffic to the backup SR-MPLS TE LSP PE1 -> P1 -> P2 -> PE2.