BFD for MPLS LSPs

BFD for MPLS LSPs

Bidirectional Forwarding Detection (BFD - RFC 5880) is used to track the IPv4/6 connectivity between directly connected systems. RFC 5884 introduces BFD for MPLS LSPs. The objective is to use BFD to detect failure in Data plane of an MPLS LSP. Currently, LSP Ping is used to detect the failures in MPLS LSP Control and Data planes. The RFC document provides a way to use BFD in conjunction with LSP Ping. First, an overview of BFD and LSP Ping.

BFD: An Overview

BFD is intended to provide a method to detect faults in the bidirectional paths between two systems. It's function is independent of data plane technologies or protocols. BFD is a lightweight Hello protocol that operates in-band with data and allows the end systems of a connection to monitor the bidirectional connectivity of a link.

BFD has two modes: Asynchronous mode and Demand mode. In Async mode, the systems periodically send BFD Control packets to one another. If a number of Control packets are lost in a row, the session is declared to be down. In Demand mode, it is assumed that the system has an independent way of verifying that it has connectivity to the other system. Once a BFD session is established, the transmission of Control packets is on a need-basis. BFD Control packets are carried in UDP packet inside IPv4/6. The destination port is set to 3784 while the source port is in the range 49152 through 65535. The following packet capture shows the BFD Control packet.

My Discriminator is a unique, non-zero value generated by the originating system and Your Discriminator is the discriminator value received from remote system. The Your Discriminator value basically reflects back the My Discriminator value. The values are used to demultiplex multiple sessions between two systems.

With either mode, a BFD Echo function can be used. When Echo function is active, BFD Echo packets are transmitted in such a way that the remote system loops them back to the originating system. The source IP address is part of the subnet bound to the interface over which BFD Echo packets are sent. The destination IP address is set to the originating system's own IP address. If a number of Echo packets are not received in a row, the session is declared down. For BFD Echo function, the destination port is set to 3785.

Figure 1 shows the BFD Echo function. R1 sends Echo packets to R2 with its own IP address but R2's MAC address as the destination MAC address.

LSP Ping: An Overview

RFC 4379 introduces LSP Ping which is an OAM mechanism for MPLS LSP. LSP Ping is a new method for failure detection in MPLS as IP Ping is not capable of testing the LSP failure. In figure 2, if LDP session is not established between P2 and P3 routers, IP Ping still works as the packet continues its journey as pure IP packet and the failure is not detected.

The following output shows that P2 router has no LDP session with P3 router. However, the IP Ping from PE1 router to PE4 router's Loopback IP address is still successful.

P2# show mpls ldp neighbor

Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0

TCP connection: 1.1.1.1.646 - 2.2.2.2.63152

State: Oper; Msgs sent/rcvd: 11520/11516; Downstream

Up time: 6d23h

LDP discovery sources:

FastEthernet1/0, Src IP addr: 10.1.1.1

Addresses bound to peer LDP Ident:

1.1.1.1 10.1.1.1

PE1# ping 4.4.4.4

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 108/125/140 ms

LSP Ping is similar to IP Ping where it uses probe packets called MPLS Echo Requests (UDP packet) and expects to receive back MPLS Echo Replies (UDP packet). LSP Ping provides a way to -

a) validate the forwarding of traffic in data plane

b) verify the data plane state with control plane state

LSP Ping verifies that a packet that belongs to a particular FEC actually ends its MPLS path on the LSR that is the egress for that FEC. In figure 2, the FEC is PE4's Loopback IP address (4.4.4.4). If LSP fails at P2 router, the MPLS path ends at P2 router. Since P2 router is not the egress for the FEC, the check fails.

LSP Ping key points-

i) the probes follow the same path as the data packets. The probe packets are forwarded using the same label stack as the data packets.

ii) the probes are delivered to the Control plane of the LSR on which they end their MPLS path for verification. To force an LSR to process the probe packets in the Control plane, the Router Alert option in IP header is set to 1. The destination IP address of the probe packets is a random IP address from the range 127.0.0.0/8. The reason for choosing a (non-routeable) 127/8 range is that the FEC might not always be an IP address of the egress LSR. The source IP address is the route-able IP address of the originating system of the probe which is used by the egress LSR of the FEC to inform about the result of the test. The source and destination UDP ports are 3503. The TTL of IP header is always set to 1.

iii) the probes contain enough information about the FEC to allow the receiving LSR to determine if it is indeed the correct egress LSR. This necessary information is carried in the probe UDP packet and is encoded as a set of TLVs. The TLV information depends on the type of FEC and hence, TLVs are defined for each type of FECs; LDP, RSVP, L3VPN, Pseudowire, etc.

In Cisco IOS, LSP Ping can be initiated using ping mpls command. The following shows an example of LSP Ping for LDP IPv4 FEC.

LSP Ping in Cisco IOS

PE1# ping mpls ipv4 4.4.4.4/32

The following packet capture shows an MPLS Echo Request for LDP IPv4 FEC. Note the Target FEC TLV contains the IP address and prefix-length of the egress LSR.

The following output shows unsuccessful LSP Ping result from PE1 router to PE4 router's Loopback IP address due to LSP failure between P2 and P3 routers in figure 2.

PE1# ping mpls ipv4 4.4.4.4/32 verbose

Sending 5, 100-byte MPLS Echos to 4.4.4.4/32,

timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

B size 100, reply addr 10.1.1.2, return code 9

Success rate is 0 percent (0/5)

Return Code 9 implies that there is no further MPLS forwarding available. This is returned by P2 router. If LSP Ping is successful, the return code is 3. The following packet capture shows MPLS Echo Reply.

LSP Ping Summary

LSP Ping Echo request tests the traffic flow in one direction only. The return path can be IP forwarded. Also, the requirement for LSP Ping is that the probe packets be validated by Control plane. It is possible that the Control plane is busy and cannot process the echo requests resulting in false failure detection. Echo requests test only one path of the possible paths to destination. To test all possible paths, multiple probes must be sent. This requires that the destination IP address of each probe be different from the range 127/8. Echo replies are sent back as UDP packets which when lost can result in false failure detection too.

BFD for MPLS LSP

Since BFD has smaller Control packets, the RFC document proposes to using BFD in conjunction with LSP Ping to detect faster MPLS data plane failures only. The RFC proposal only applies to BFD Async mode without Echo function.

Operation

The ingress LSR initiates an LSP Ping for an LSP using MPLS Echo Request packets which includes the BFD local discriminator (My Discriminator) assigned by the ingress LSR for a BFD session. Upon receipt of MPLS Echo Request packet, the egress LSR sends a BFD Control packet to the ingress LSR. This BFD Control packet sets the Your Discriminator field which reflects back the My Discriminator value in MPLS Echo Request packet. As the ingress LSR sees its own discriminator value in the BFD Control packet, it establishes the BFD session.

The egress LSR may respond to MPLS Echo Request packets with MPLS Echo Reply packets. These MPLS Echo Reply packets must include the egress LSR's local discriminator value assigned for the BFD session. Again, it is carried in MPLS Echo Reply packets as My Discriminator.

As per RFC document, a new sub-TLV called BFD Discriminator sub-TLV is introduced to carry local discriminator value in the MPLS Echo Request/Reply packets.

Once the BFD session is established, the BFD Control packets sent by the ingress LSR are encapsulated in MPLS label stack for that particular FEC being tested. Figure 4 shows the encapsulation. The BFD Control packet is encapsulated within UDP packet with destination port set to 3784 (as in normal BFD-IP). The source port is from the range 49152 through 65535. The source IP address is set to the routeable IP address of the ingress LSR while the destination IP address is chosen from the range 127/8. The TTL of IP header is set to 1.

The BFD Control packets sent by egress LSR may not always be sent back to ingress LSR over an LSP; it could be routed based on the destination IP address. These BFD Control packets are also encapsulated within UDP packet with the destination port set to 4784 if routed, or 3784 if forwarded using MPLS label stack. The source port is set from the range 49152 through 65535.

Cisco IOS (upto release 15.0) and ALU TiMOS (upto release 8) do not support BFD for MPLS LSP. However, Junos (as of release 9.3) supports BFD for MPLS LSPs (RSVP and LDP).

Summary

Because LSP Ping validates the control plane against data plane for MPLS LSP, it is quite processor intensive. But BFD is a lightweight protocol with very less overhead. Thus, combining BFD and LSP Ping provides a scalable solution to verify the data plane of MPLS LSP. The RFC document does not mention about P2MP LSPs.