Bidirectional Forwarding Detection (BFD) – A Little About Timers

Two weeks ago I taught Routed Fast Convergence and High Availabilty at CiscoLive US in SanDiego.  it always surprises me how few hands get raised when I ask how many people know about BFD.  With BFD OTV coming out… and BFD MPLS options already available… and support of BFD with NSF/GR on some platforms…. and BFD with SVIs….. I’ve decided it was time to take my knowledge to the “next level” in preparation.  And, I might as well bring y’all along for the fun.  This post and my last post are to lay some necessary BFD ground work.  

By the way, in case you are newer to BFD please refer to Bidirectional Forwarding Detection (BFD) – A Beginning and an Introduction…. 

If you recall from my last BFD post we had 2 routers – one 7600 and one Nexus 7K, and they came up as BFD neighbors.  We are going to continue to use those two routers for this post as well.  

This post will review and explore

• the definition of the “primary” operating mode of BFD – “Asychronous mode”
• the format of the BFD control packet
• a look at the timer section of the BFD control packet

We will then 

• configure BFD intervals (Tx and Rx) of 50ms for the BFD control packets
• notice that we didn’t quite get the intervals for the BFD control packets that we thought we asked for
• sniffer trace the wire between R1 and R2 to better understand why we were seeing what we were seeing

(sorry…. no spoilers… you will have to read the post)

A Little RFC Reading

RFC5880 explains that there are two operating modes to BFD – Asynchronous and Demand.  It further goes on to say that there is an additional function (echo mode) that can be used in combination with either of the two operating modes. We are only going to be looking at Asynchronous mode.  So let’s see what the RFC says specifically about Asynchronous mode:

The primary mode is known as Asynchronous mode.  In this mode, the systems periodically send BFD Control packets to one another, and if a number of those packets in a row are not received by the other system, the session is declared to be down.

Simple enough.  BFD control packets used to bring the BFD neighbor up…. And BFD control packets used to declare the session down. So let’s look at the BFD control packet. 

RFC5880: BFD Control Packet

Obviously the RFC details what each of these is, so I’m not going to here.  Let’s just start looking at the timers for now.

Desired Min TX Interval: This is the minimum interval, in microseconds, that the local system would like to use when transmitting BFD Control packets, less any jitter applied (see section 6.8.2).  The value zero is reserved.    

Required Min RX Interval: This is the minimum interval, in microseconds, between received BFD Control packets that this system is capable of supporting, less any jitter applied by the sender (see section 6.8.2).  If this value is zero, the transmitting system does not want the remote system to send any periodic BFD Control packets.

We will keep it simple and reference the BFD configs already on the interfaces of R1 and R2 which were configured in Bidirectional Forwarding Detection (BFD) – A Beginning and an Introduction….  Since the BFD interface command for setting the timers was the same on the 7600 IOS and the NX-OS Nexus 7K, we will just look at command in more detail on the R1 side.

So, reverse engineering what we read above it looks like I’m configured to have my BFD control packets plug “50,000 microseconds” in the “desired Min Tx Interval and “50,000microseconds” as the “Required Min Rx Interval”.

Show BFD Neighbor Detail

Let’s go to R1 and do show bfd neighbors detail, but let’s just take a small snippet of it. 

So as we can see on R1, the MinTxInt is set to 1,000,000 microseconds.  Which is 1,000 milliseconds and not the 50 milliseconds we had configured.  Same thing with the MinRxInt.  So why?  Let’s look at a sniffer trace of this. 

Sniffer Trace

Confused?  Well it looks kinda confusing, but it really isn’t. So let me show you.  See all those BFD-echo frames? 

Reverse Engineering the Whole Thing

Let’s return to RFC5880 and see what it says about these bfd-echo frames. 

An adjunct to both modes is the Echo function.  When the Echo function is active, a stream of BFD Echo packets is transmitted in such a way as to have the other system loop them back through its forwarding path.  If a number of packets of the echoed data stream are not received, the session is declared to be down.  The Echo function may be used with either Asynchronous or Demand mode.

.

.

The Echo function may be enabled individually in each direction.  It is enabled in a particular direction only when the system that loops the Echo packets back signals that it will allow it, and when the system that sends the Echo packets decides it wishes to.

The Echo function has the advantage of truly testing only the forwarding path on the remote system.  This may reduce round-trip jitter and thus allow more aggressive Detection Times, as well as potentially detecting some classes of failure that might not otherwise be detected.   

Let’s relook at the show bfd neighbor detail result.  Notice something?  We ARE using the echo function!!!  BFD echo is actually enabled by default in the code on our 7600 and on the code in our N7K.  

More BFD to come.  But a caveat…. I’m also interested in doing some “ground work” for some other topics.  So who knows what will be next?