Contents
This post is a second blog post in a series. For the series, click here
BFD Asynchronous mode (based on control packets only), discussed in the previous post already provides a lightweight, standardized and unified method of detecting failure between two devices. On advanced routing platforms, the ASICs on the receiving ports can be programmed to process the BFD control packets and no CPU interrupts are required. But this may not be true for more basic routing platforms where the CPU may have to process every control packet. This is one of the problems, amongst others, that the Echo function serves to resolve.
The other issue with using only Control packets for BFD is that they may not traverse the actual forwarding path taken by data packets. Since they do not travel the actual forwarding path, they cannot be relied upon to test the forwarding plane itself. The Echo function also resolves this issue by allowing the testing of the actual forwarding path and forwarding engine of the remote peer.
To understand the Echo function, a discussion of the layer 2 and layer 3/4 aspects of the BFD Control packets becomes a prerequisite.
BFD and IP
BFD RFC 5880 does not discuss the layer 3/4 specifics of a BFD packet. In other words, BFD was designed independent of TCP/IP. A separate RFC (5881) documents how IP packets must carry BFD. Very simply, unicast IP packets carry BFD in UDP segments with a standard destination port (3784). The source and destination IP addresses are provided by the routing protocol responsible for neighbor discovery.
For Control packets, the source and destination IP addresses will usually correspond to the IP addresses configured on the physical interfaces that connect the source and the receiver. Ergo, the BFD peer receiving the Control packet detects its own IP address as the destination address. On primitive platforms, this packet must be punted to the CPU for further processing. Furthermore, the control packets addressed as such may or may not test the actual forwarding path that the data packets traverse. This is due to the fact that they are being sent by the control plane of the device and therefore are fundamentally different than packets that traverse “through the box”.
BFD Echo Function
This function is designed to supplement the other BFD modes. It provided the added benefit of testing of the actual forwarding engine of the remote peer. The Echo function is extremely rudimentary in nature and one should realize that it does not eliminate or replace the functionality of Control packets. Echo function allows the remote BFD peer to loop the received packets back to the sender, using the exact forwarding path that is used for data packets. The key to this lies in the addressing of Echo packets.
Echo packets use the same source IP (by default) as the Control packets. The difference lies in the destination address. To allow the remote peer to loop the packet back to the sender, the sender simply uses its own IP address (identical to the one in the source IP address field) in the destination IP address field. When the remote peer receives this packet, it forwards the packet like any others traversing it – using the forwarding engine. If the packet is forwarded correctly, it loops back successfully and the sender is able to verify that the forwarding path on the remote peer is functional.
BFD Echo Packet Format
Since the BFD Echo packet is not processed by the remote peer, it does not need to carry any of the values of the Control packet. The only stipulation for the format of the Echo packet is that it should have enough information to allow the sender to demultiplex it to the correct BFD session.
As an example, some Cisco devices use the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Essentially, the sender populates the 12 bytes with some data that it can tie to the BFD session in question.
For IP, the following value are typically used:
- Source IP address – Sender’s outgoing interface IP
- Destination IP address – Same as Source IP
- Source UDP Port – 3784, 49152 or a ever changing number for bundled interfaces
- Destination UDP Port – 3784
BFD Asynchronous Mode with the Echo Function
Since the Echo packets do not get processed by the remote peer, the Control packets must still be exchanged to negotiate the session timers. What the Echo function does allow the BFD peers to do is to rely on the Control packets solely for timer negotiation. Since the function of the Control packets is markedly different with the Echo function, they are sent far less frequently (about once every 2 seconds). This allows the peers to use the Control packets for pure negotiation and use the Echo packets (sent in the range of ms) to detect forwarding path failures. The following diagram approximates this visually (only one direction):
Echo Function Caveats
There are a few caveats associated with the Echo function that should be considered before implementation.
ICMP Redirects
ICMP redirects on the interface looping the packets back should be disabled. If not disabled, there is a potential that the device receiving the Echo packet generates an ICMP redirect packet per echo packet received.
uRPF Check
Unicast Reverse Path Forwarding check will also break the Echo functionality on the device receiving the looped packet (the original sender). This is because on the packet has a source IP address that belongs to the device receiving the looped packet and therefore fails the uRPF check.
The next post wraps up this series with a practical example of BFD on Cisco IOS.