How are you configuring BFD timers?

Jason Lixfeld jason+nanog at lixfeld.ca
Thu Mar 22 12:17:33 UTC 2018


Thanks to everyone who has responded so far.  Enlightening!

My understanding around the origins of BFD is that it was developed in part to try and bring SONET like switchover times to an Ethernet world.  What I’m reading is for those who do run BFD, no one seems to be dialing it down to try and achieve those times.  Some folks explained why they chose the values they did, but others didn’t.  So my follow up question is “Why don’t you dial them down?”.  Are achieving those switchover times not important for your use case?  Do you not trust that it won’t be reliable based on the gear you’re using, or the quality/reliability of the underlying circuit you’re trying to protect?  Something else?

Also, interesting to read about why some folks don’t care much about BFD at all.

> On Mar 21, 2018, at 9:10 AM, Jason Lixfeld <jason+nanog at lixfeld.ca> wrote:
> 
> Hey,
> 
> For those running BFD on your land-based point-to-point links, I’m interested in hearing about what factors you consider when deciding how to configure your timers and multiplier.
> 
> On paper, BFD between two devices over a local or metro dark fibre or wave seems pretty trivial:  Assuming your gear can a) support echo mode b) hardware offloads echo processing c) automatically treats echos as vital and puts them into the appropriate high priority queue, then setting the timers down to their lowest possible values (3ms on some of the gear that I’ve seen) and some low multiplier seems more than reasonable.  But?
> 
> From another angle, your link isn’t dark fibre or a wave but, for example, ethernet over some sort of IP based L2 Transport, and is still a low (sub 1ms) one-way latency local or metro link.  How do you set your timers, and what do you base that on?
> 
> From yet another angle, what if your link is a long-haul wave, or for that matter a wave of any distance that imposes a one-way latency that is higher than the minimum tx and rx timers that are supported by your gear?  We’ll assume an unprotected wave, because I’m sure if it’s protected, you have no choice but to consider the one-way latency of the longest of the two segments.
> 
> I made some assumptions above about support for echo mode and hardware offload, but what if (some of) your gear doesn’t support some or all of that stuff?  How do you factor your configuration decisions?
> 
> Thanks!




More information about the NANOG mailing list