Skip to content

Other bfd systems

JakeMont edited this page Nov 14, 2011 · 1 revision

Notes on Interoperability With Other BFD Systems

About this page

bfdd-beacon communicates with a "remote" system. Since the BFD specification was, until recently, in the draft stage, and many implementations may have not been fully exercised, this page provides a location for notes about various BFD implementations.

JUNOS 8.5S4

  • This platform does not handle a remote "Required Minimum Receive Interval" of 0. It treats it as an actual 0 value and proceeds to spew control packets at the fastest possible rate. This is contrary to the bfd.RequiredMinRxInterval clause in Section 6.8.1 of RFC 5880. Therefore it is advisable not to set "Required Minimum Receive Interval" to 0 with this system.

  • This platform does not set bfd.RemoteDiscr to 0 after a Detection time has elapsed, as mandated by the bfd.RemoteDiscr clause in Section 6.8.1 of RFC 5880. It maintains bfd.RemoteDiscr for 2 detection times. Without the "wrokaround" the result is that is a session is removed, either intentionally, or from a timeout on our end, the remote system will continue to send packets with a non-zero "Your Discriminator", preventing us from starting a new session. A "workaround" for this has been added. Passive sessions are now not deleted (and so the discriminator is maintained) for at least 3 times the remote detection time.

  • This platform,in some cases, delays sending a packet when its state changes from Down to Init. This is contrary to Section 6.8.7 paragraph 10 of RFC 5880. This section does refer to "SHOULD", not "MUST", so this is not technically a bug. It can be seen when the local system goes from Up->AdminDown->Up. If the period spent in AdminDown is relatively short compared with the "Local Desired Min Rx Interval", then the Local state will transition from AdminDown->Down and the Remote system will immediately transition to the Init state, but it will delay sending a packet, despite the state change, until the next scheduled transmit. This can delay the Local systems transition to the Up state. A workaround has been added, and is enabled by default. This consists of setting the Poll bit on the packet for the transition from AdminDown->Down. This will force the remote system to respond immediately. See session set admin_up_poll in the bfdd-control manpage.

Clone this wiki locally