BFD echo mode vs. none echomode

[chintan-shah]

Hi ,

As I understand BFD with Asynchronous mode support Echo and non Echo mode.

In my opinion, Echo mode is more recommonded due to fact that it will include forwarding path and so that it will send control packets at  high interval says 2 sec - reduce CPU on controlplane and thus more scalable...

Is there any disadvantage of Echo mode over non Echo mode ?

Which is more widely being implmented in IOS-XR ?

Regards,

Chintan

[Laurent Aubert]

Hi,

Your understanding is correct. Don't forget, BFD echo packets which are sent back to the peer are subject to egress QoS so be sure they will not be dropped during congestion time.

I see one corner case other than echo mode not supported by one side is if your IGP is ISIS. ISIS Hello are directly encapsulated in Layer 2 but BFD tests L3 forwarding plane. So when a router boot up or a link comes up, BFD session could fail due to forwarding issue but ISIS adj could still be establish as those packets don't follow the same path.

The following draft addressed this corner case but is not implemented yet: http://tools.ietf.org/id/draft-ietf-isis-bfd-tlv-02.txt

HTH

Laurent.

[chintan-shah]

Hi Laurent,

The corner case you mentioned for ISIS is I guess only for echo mode or even for non echo mode ?

In echo mode self directed packets will have same destination IP but destination mac-address would be remote peer's interface so what you mentioned is before this packets come back , ISIS could be still up as not use IP but BFD could be down since that involves IP forwarding plane. If that is a case, Will this bring down IS-IS (i.e. change path during that time ).

Regards,

Chintan

[Laurent Aubert]

BFD will be used for peer/link failure detection ony if the session come up at least once. Before that the IGP will try to bring its own adj and if it succeeds, IGP hello will be used instead of BFD. It allows you to configure BFD without breaking your current adj.

If there is an issue with the IP forwarding plane, OSPF hello will have the same issue as BFD so it's OK. But with ISIS, the adj could come UP and the router could start sending traffic to a black hole.

As you can see, it's a corner case so you should consider it more than a caveat.

HTH

Laurent.

[pardeepk]

BFD apparently started out based on a polling (“asynchronous”) approach using control packets. One router polls the other and get a quick response back. The challenge with this is delay in waking up the BFD process to send a reply, causing variable jitter in response. If the other end is slow responding and BFD triggers a link down, that’s not good. Backing off on aggressive timers to prevent that  from being a problem somewhat defeats the intent of BFD. 

BFD echo solves that, and provides a clever way to take some delay out of the above process. The newer Cisco code defaults to using BFD Echo mode to verify bidirectional connectivity, to take advantage of this. 

The BFD echo function sends echo packets from the forwarding engine to the remote BFD neighbor. The BFD neighbor forwards the echo packet back along the same path in order to perform detection; the BFD neighbor does not participate in the actual forwarding of the echo packets.