In looking to implement Bidirectional Forwarding Detection (BFD) it seems to be very flexible in terms of timer tuning, light weight regarding any overhead and it's flexibility in terms of overall application appears very impressive.

So if for example it can be applied to detect link failure over Ethernet, MPLS over multiple hops, at the network edge, for IGP convergence, for tunnels etc etc - why would it not be used in certain scenarios perhaps and are there other emerging alternatives to be aware of?

4 Answers 4


I am only directly aware of one issue with BFD, which is CPU demand. I am currently investigating an issues with a Cisco 7301 which when pushing more traffic during our peak hours, compared to the rest of the day, BFD is sometimes timing out and routing trips over to the next link.

It seems that under high traffic volumes the router CPU usage is rising (which isn't unusual) but at about 40-50% CPU BFD packets aren't receiving enough resources.

However I have found the following information which suggests additional issues with BFD (From this NANOG presentation, there is more in the presentation, it's a good one, give it a read!)

What are the caveats?

  • Two main ones:
    1. BFD can have high resource demands depending on your scale.
    2. BFD is not visible to Layer 2 bundling protocols. (Ethernet LAGs or POS bundles)

BFD Resource Demands

  • The number of BFD sessions on each linecard or router can impact how well BFD scales for you. -Each unique platform has its own limits.
  • Bundled interfaces supporting min tx/rx of 250ms or 2 seconds have been seen.
  • In some cases, BFD instances on a router may need to be operated on the route-processor depending on the implementation (non-adjacency based BFD sessions).
  • Test your platform first before deploying BFD. Attempt to put load on the RP or LC CPU with your configured settings. This can be done by:
  • Executing CPU-heavy commands
  • Flooding packets to TTL expire on the destination

BFD Resource Demands (cont’d)

  • What values are safe to try?
  • Based upon speaking to several operators, 300ms with a multiplier of 3 (900ms detection) appears to be a safe value that works on most equipment fairly well.
  • This is a significant improvement over some of the alternatives.

BFD and L2 link-bundling

  • BFD is unaware of underlying L2 link bundle members.
  • A 4x10GigE L2 bundle (802.3ad) would appear as a single L3 adjacency. BFD packets would be transmitted on a single member link, rather than out all 4 links.
  • A failure of the link with BFD on it would result in the entire L3 adjacency failing.
  • However, in some scenarios the failed member link may result in only a single BFD packet being dropped. Subsequent packets may route over working member links.
  • 1
    Another thing to note is that some platforms do not support BFD on every type of interface. Most famous (to me): Cisco 7600 does not support BFD on SVI (Vlan) interfaces until very, very recently (15.something required). May 20, 2013 at 21:26
  • 1
    Good point, the 7301 issue I am working on, it should, but it still isn't running as smoothly as I'd like, and it's on a very new 12 IOS. Where as some other 7301s and 7206s are fine. Sebastian is right, it's defiantly worth mentioning that it's not as well supports as we'd probably all like to be in these common hardware platforms.
    – Baldrick
    May 20, 2013 at 21:41
  • 1
    Note that there is an IETF draft to address running BFD over LAGs: tools.ietf.org/html/draft-mmm-bfd-on-lags. It is not really implemented anywhere yet, but hopefully this issue will eventually be solved, since it's a very common scenario. May 25, 2013 at 20:10

I have seen two reasons why BFD hasn't been implemented:

  1. Ignorance of it (I was guilty of this for some time).

  2. Cost, if you're a Cisco shop. Although possibly negligible depending on the size of your organization, there is now an associated licensing cost to implement BFD.

As of the ISR G2/ASR timeframe, BFD is no longer in the "IP Base" licensing package. You have to upgrade to at least the "Data" licensing level to unlock BFD. See this white paper from Cisco.

This licensing requirement may not be an issue, as you may already be purchasing a higher licensing level for other features, but it is something to be aware of.

  • +1 Excellent, I was only thinking of technical reasons, but cost is an obvious one, good point! Also simply not knowing, I have been the first to tell someone about BFD also. Two great points!
    – Baldrick
    May 20, 2013 at 21:39

A few things to round out javano's answer:

  • Remember that 40g and 100g ethernet can be considered bundles, albeit not the same as LACP, but 4x10, 4x25 & 10x10
  • On some hardware (Some of the higher end Juniper's for example) BFD is handled on the line card which can be a benefit (no loss under high RE load) or a deficit (no immediate loss if the RE dies)
  • Running BFD over a link/path that's already a SPOF (eg, single fibre bundle) can be worse than just upping carrier-delay

BFD is a feature that was invented to detect L2 connectivity issue when there is some intermediary device in between two peers. So BFD is a failure detection feature.

Typically we need BFD if we have 2 routers interconnected via L2 switch 9or any other L2 cloud). In this case if single router goes down, link state won't be reflected on another router, as switch would keep the link up. If it were just P2P link (single cable) between the routers, interface would go down right on peer's failure and IGP would reconverge in sub-second interval.

So, the reasson not to use BFDs are: - BFD is not supported on the box[es]; - BFD is not needed, as you have no intermediate device (use udld and carrier-delay instead).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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