Two weeks ago I taught Routed Fast Convergence and High Availabilty at CiscoLive US in SanDiego. \u00a0it always surprises me how few hands get raised when I ask how many people know about BFD. \u00a0With BFD OTV coming out\u2026 and BFD MPLS options already available\u2026 and support of BFD with NSF\/GR on some platforms\u2026. and BFD with SVIs..... I've decided it was time to take my knowledge to the \u201cnext level\u201d in preparation.\u00a0 And, I might as well bring y'all along for the fun. \u00a0This post and my last post are to lay some necessary BFD ground work. \u00a0By the way, in case you are newer to BFD please refer to\u00a0Bidirectional Forwarding Detection (BFD) \u2013 A Beginning and an Introduction....\u00a0If you recall from my last BFD post we had 2 routers - one 7600 and one Nexus 7K, and they came up as BFD neighbors. \u00a0We are going to continue to use those two routers for this post as well. \u00a0This post will review and explorethe definition of the "primary" operating mode of BFD - "Asychronous mode"the format of the BFD control packeta look at the timer section of the BFD control packetWe will then\u00a0configure BFD intervals (Tx and Rx) of 50ms for the BFD control packetsnotice that we didn't quite get the intervals for the BFD control packets that we thought we asked forsniffer 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 ReadingRFC5880 explains that there are two operating modes to BFD \u2013 Asynchronous and Demand.\u00a0 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.\u00a0We are only going to be looking at Asynchronous mode.\u00a0 So let\u2019s see what the RFC says specifically about Asynchronous mode:The primary mode is known as Asynchronous mode.\u00a0 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.\u00a0 BFD control packets used to bring the BFD neighbor up\u2026. And BFD control packets used to declare the session down.\u00a0So let\u2019s look at the BFD control packet.\u00a0RFC5880: BFD Control PacketObviously the RFC details what each of these is, so I\u2019m not going to here.\u00a0 Let\u2019s 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).\u00a0 The value zero is reserved.\u00a0 \u00a0\u00a0Required 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).\u00a0 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) \u2013 A Beginning and an Introduction....\u00a0\u00a0Since 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\u2019m configured to have my BFD control packets plug \u201c50,000 microseconds\u201d in the \u201cdesired Min Tx Interval and \u201c50,000microseconds\u201d as the \u201cRequired Min Rx Interval\u201d.Show BFD Neighbor DetailLet\u2019s go to R1 and do show bfd neighbors detail, but let\u2019s just take a small snippet of it.\u00a0So as we can see on R1, the MinTxInt is set to 1,000,000 microseconds.\u00a0 Which is 1,000 milliseconds and not the 50 milliseconds we had configured.\u00a0 Same thing with the MinRxInt. \u00a0So why?\u00a0 Let\u2019s look at a sniffer trace of this.\u00a0Sniffer TraceConfused?\u00a0 Well it looks kinda confusing, but it really isn\u2019t. So let me show you.\u00a0 See all those BFD-echo frames?\u00a0Reverse Engineering the Whole ThingLet\u2019s return to RFC5880 and see what it says about these bfd-echo frames.\u00a0An adjunct to both modes is the Echo function.\u00a0 When the Echo\u00a0function is active, a stream of BFD Echo packets is transmitted in\u00a0such a way as to have the other system loop them back through its\u00a0forwarding path.\u00a0 If a number of packets of the echoed data stream\u00a0are not received, the session is declared to be down.\u00a0 The Echo\u00a0function may be used with either Asynchronous or Demand mode...The Echo function may be enabled individually in each direction.\u00a0 It\u00a0is enabled in a particular direction only when the system that loops\u00a0the Echo packets back signals that it will allow it, and when the\u00a0system that sends the Echo packets decides it wishes to.The Echo function has the advantage of truly testing only the\u00a0forwarding path on the remote system.\u00a0 This may reduce round-trip\u00a0jitter and thus allow more aggressive Detection Times, as well as\u00a0potentially detecting some classes of failure that might not\u00a0otherwise be detected.\u00a0\u00a0\u00a0 Let\u2019s relook at the show bfd neighbor detail result.\u00a0 Notice something?\u00a0 We ARE using the echo function!!! \u00a0BFD echo is actually enabled by default in the code on our 7600 and on the code in our N7K. \u00a0More BFD to come. \u00a0But a caveat.... I'm also interested in doing some "ground work" for some other topics. \u00a0So who knows what will be next?