When configuring a Micro-BFD session on a LAG, is it preferred/recommended to still also tie BFD to the OSPF adjacency that is established over that interface? I would think not as the BFD session for OSPF would be hashed over a single link, during a failure of that link in the bundle the OSPF adjacency would go down, but LAG would stay up (assuming other measures such as min-links is not met). Is it preferred recommended to only configure BFD tied to LAG and allow that failure to trigger the OSPF process?


Failover of a LAG connection means that the traffic would failover to the link(s) still up. It is much, much faster than STP failover. It is even faster than routing protocol failover.

Your BFD and OSPF session would remain up if there is at least one link of the LAG still up.

Don't confuse the LAG interface, which OSPF and BFD use, with the individual interfaces of the LAG links. As long as the LAG interface is still up, and it will be if even one of the LAG links is still up, then OSPF will continue to run on the interface. The LAG interface decides which link a flow will use, and it will shift flows to remaining links when any link goes down. This is invisible to the flow. This happens very, very fast, and there is no way that OSPF would miss enough Hellos to decide the neighbor is down.

  • I align that OSPF would not miss enough hellos to decide the neighbor is down but what if BFD was tied to the OSPF adjacency with timers of 300ms x 3 for instance. Seems there are scenarios without micro-bfd that LACP did not detect a failure faster than BFD on 'bad' member link. If the BFD session is hashed over that link the LAG would still remain up but wouldn't it be possible that BFD failed before the re-hash of traffic on the "bad" member link effectively dropping the OSPF adjacency. – 00_tlb_00 Oct 28 '16 at 3:00
  • Well, 300 ms is probably two orders of magnitude longer than it takes LAG to fail over. The LAG interface will never go down (as long as one link is still up), which would trigger OSPF to see an immediate failure. STP fail over is usually measured in seconds, routing protocol fail over is measured in hundreds of milliseconds, and LAG fail over is often measured in microseconds (depending on the vendor). – Ron Maupin Oct 28 '16 at 3:06
  • @00_tlb_00, all I can say about it is that we have never had a routing protocol (OSPF or BGP) or BFD detect a down condition when a link in a LAG interface fails, and this is from many thousands of LAG connections. If something enters a LAG connection where at least one interface is up, it will get sent to the other side. You are looking at the delay of what it takes to run the hash table, and, in any case, that would preclude BFD from running on a LAG. – Ron Maupin Oct 28 '16 at 3:21
  • I was also thinking of scenario where issue didn't occur at the phy level and rehash relied on default slow timers of 30s. If bfd was hashed over that link seems it could cause failure situation. appreciate the insight to into your experience too within the field. – 00_tlb_00 Oct 28 '16 at 13:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.