BFD Question

dppagcdppagc Member Posts: 293
Does BFD result in faster convergence?

Does it look for an alternative path if the link is down or does it just send an alert?

How is BFD different if the IGP also attempts to route through another path?

Comments

  • networker050184networker050184 Mod Posts: 11,962 Mod
    BFD just allows subsecond failure detection. Alternate paths in the routing/forwarding table are not the purpose of BFD.
    An expert is a man who has made all the mistakes which can be made.
  • atorvenatorven Member Posts: 319
    From what I've read and seen, BFD just sends out faster hellos and is less intensive than other protocols when it comes to failure detection at sub-second speeds. It doesn't do any routing, all it does is let the routing protocol know that the neighbor is down and the routing protocol will do what's necessary.
  • dppagcdppagc Member Posts: 293
    Ok in that case, how does the routing protocol know the link is down if bfd is NOT enabled?
  • atorvenatorven Member Posts: 319
    For the local link it would be a link down event, for a neighbor that is not directly attached it would be the absence of hellos/dead timers expiring.
  • EdTheLadEdTheLad Member Posts: 2,111 ■■■■□□□□□□
    Routing protocol can detect a link down by local physical layer failure i.e. loss or laser. For a remote physical fault that isn't detected by physical layer the routing protocol relies on its keepalives, once holddown expires neighbor is seen as unreachable. Keepalive timers can be process intensive when tuned low, this is why bfd is used.
    Networking, sometimes i love it, mostly i hate it.Its all about the $$$$
  • late_collisionlate_collision Member Posts: 146
    If it's a direct link failure, the port state changes to down/down, resulting in an immediate convergence event. If it's an indirect link failure, the routing protocol stops receiving hello's, reaches the hold down timer, and tears down the neighbor adjacency, resulting in a delayed convergence event when the timers expire.

    BFD is not a requirement, it's just another method of detecting a failed or malfunctioning link, faster. The routing protocol must support notifications from BFD in order to take advantage of it. RIP does not support BFD, but EIGRP, OSPF, IS-IS, and BGP all do.

    Edit: Wow, we all posted at once. That was a flood of replies.
  • dppagcdppagc Member Posts: 293
    EdTheLad wrote: »
    Routing protocol can detect a link down by local physical layer failure i.e. loss or laser. For a remote physical fault that isn't detected by physical layer the routing protocol relies on its keepalives, once holddown expires neighbor is seen as unreachable. Keepalive timers can be process intensive when tuned low, this is why bfd is used.

    I learnt something new today. I didnt know that keepalives were process intensive.
  • joetestjoetest Member Posts: 99 ■■□□□□□□□□
    BFD is meant to be Fast Hellos across layer 2 in hardware(mostly) instead of relying on Keepalives and Fast Hellos across layer 3 which is process-switched(software based) which can heat up your router CPU.

    BFD being switched in the data plane is the reason it's not causing the CPU to melt down(Routing protocols Hellos are purely process-switched through the control plane). All you have to figure out now is why people are bitching so much about it icon_biggrin.gif

    It doesn't have much to do with routing, it's basically just an up/down mechanism which is really sensitive but superfast without causing CPU meltdowns. Atleast that's how I understand it.
Sign In or Register to comment.