Static routes and BFD

[Ondrej Zajicek]

On Wed, Oct 26, 2016 at 04:23:08PM +0200, J. Kendzorra wrote:
> Hello all,
> 
> I am trying to make use of BFD for default gateway failover (in my BFD test
> bed). I used multiple variations, but according to the documentation (if I
> get it right), I should be fine using something like this:
> 
> ,-- on client:
> # empty BFD config
> protocol bfd {
>         #debug all;
> }
> 
> # simple default route with BFD driven failover
> protocol static {
>     debug all;
>       route 0.0.0.0/0 via 192.168.1.1 {
>         bfd on;
>     };
>     route 0.0.0.0/0 via 192.168.1.2 {
>         bfd on;
>     };
> };

Hi

There is one issue - static protocol cannot have two routes with one
network prefix. Could be workarounded by having two static protocols.

> ,-- on gateways:
> protocol bfd {
>         interface "vlan*" {
>                 passive;
>         };
>         debug all;
> }

I think that if there is no explicit 'requestor' for BFD session (like
static protocol on client), you have to explicitly add neighbors
in BFD protocol on gateways:

protocol bfd {
	interface "vlan*" {
		passive;
	};
	neighbor 192.168.1.3;
}

> Whenever I omit the "passive" statement, I can see "BFDv1 Control State
> Down" going on the wire; not sure why this appears to be the default on how
> to change this to "up":

I don't know how this could be connected - client (192.168.1.3) does not
know whether there is 'passive' on gateways, so it has to behave in the
same way regardless of that. Perhaps you configured 'passive' also on
client?

Seeing packets with state Down is expected - that is the state of BFD
session when no packets were received from the other side (due to missing
'neighbor' statements).


> Any clues on how to debug this further?

There is useful command: show bfd sessions


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20161027/407a3d36/attachment.asc>