Static routes and BFD
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; }; }; `-- ,-- on gateways: protocol bfd { interface "vlan*" { passive; }; debug all; } `-- 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": ,-- tcpdump: 08:11:41.732031 IP 192.168.1.3.23863 > 192.168.1.2.3784: BFDv1, Control, State Down, Flags: [none], length: 24 08:11:41.732033 ethertype IPv4, IP 192.168.1.3.23863 > 192.168.1.2.3784: BFDv1, Control, State Down, Flags: [none], length: 24 08:11:41.732034 ethertype IPv4, IP 192.168.1.3.23863 > 192.168.1.2.3784: BFDv1, Control, State Down, Flags: [none], length: 24 `-- What puzzles me is that I'd now expect the client to initiate a BFD connection to both gateways, however I do not see a single packet (except when not using passive I see what's pasted above). The config appears to get active however: ,-- 2016-10-26 08:07:37 <INFO> Reconfiguring 2016-10-26 08:07:37 <TRACE> bfd1: Session to 192.168.1.1 reconfigured 2016-10-26 08:07:37 <TRACE> bfd1: Session to 192.168.1.2 reconfigured 2016-10-26 08:07:37 <TRACE> bfd1: Reconfigured 2016-10-26 08:07:37 <TRACE> static1: Reconfigured 2016-10-26 08:07:37 <INFO> Reconfigured `-- This is what I see when BFD is not configured to be passive: ,-- 2016-10-26 08:11:58 <TRACE> bfd1: Sending CTL to 192.168.1.2 [Down] 2016-10-26 08:11:58 <TRACE> bfd1: Sending CTL to 192.168.1.1 [Down] (...) `-- Any clues on how to debug this further? Thanks, J.
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@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."
Ondrej Zajicek:
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; }
Unfortunately, this doesn't change the outcome me not getting BFD to work at all. There's multiple ways I tried making it work, but this is the current config: # explicit neighbor config on gateway protocol bfd { interface "vlan*" { }; neighbor 192.168.1.6; debug all; } # explicit neighbor config on client protocol bfd { interface "vlan*" { }; neighbor 192.168.1.1; debug all; } # birdc sh bfd session BIRD 1.6.0 ready. bfd1: IP address Interface State Since Interval Timeout 192.168.1.6 vlan11 Down 01:58:34 1.000 0.000 # birdc sh bfd sess BIRD 1.6.0 ready. bfd1: IP address Interface State Since Interval Timeout 192.168.1.1 vlan11 Down 01:44:06 1.000 0.000 In can see in a tcpdump that both are sending "Down" messages back and forth: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan11, link-type EN10MB (Ethernet), capture size 65535 bytes 02:35:17.378336 IP 192.168.1.1.15324 > 192.168.1.6.3784: BFDv1, Control, State Down, Flags: [none], length: 24 02:35:17.529751 IP 192.168.1.6.56135 > 192.168.1.1.3784: BFDv1, Control, State Down, Flags: [none], length: 24 ,-- This is what the logs say on 192.168.1.1: 2016-10-31 02:38:04 -0600 <TRACE> bfd1: Sending CTL to 192.168.1.6 [Down] 2016-10-31 02:38:04 -0600 <TRACE> bfd1: Sending CTL to 192.168.1.6 [Down] `-- ,-- This is what the logs say on 192.168.1.6: 2016-10-31 02:39:29 <TRACE> bfd1: Sending CTL to 192.168.1.1 [Down] 2016-10-31 02:39:29 <TRACE> bfd1: Sending CTL to 192.168.1.1 [Down] `-- On both nodes: birdc sh proto | grep bfd: bfd1 BFD master up 2016-10-26 birdc sh proto | grep bfd: bfd1 BFD master up 01:44:05 Thanks, J.
On Mon, Oct 31, 2016 at 09:44:25AM +0100, J. Kendzorra wrote:
In can see in a tcpdump that both are sending "Down" messages back and forth:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan11, link-type EN10MB (Ethernet), capture size 65535 bytes 02:35:17.378336 IP 192.168.1.1.15324 > 192.168.1.6.3784: BFDv1, Control, State Down, Flags: [none], length: 24 02:35:17.529751 IP 192.168.1.6.56135 > 192.168.1.1.3784: BFDv1, Control, State Down, Flags: [none], length: 24
,-- This is what the logs say on 192.168.1.1: 2016-10-31 02:38:04 -0600 <TRACE> bfd1: Sending CTL to 192.168.1.6 [Down] 2016-10-31 02:38:04 -0600 <TRACE> bfd1: Sending CTL to 192.168.1.6 [Down] `--
,-- This is what the logs say on 192.168.1.6: 2016-10-31 02:39:29 <TRACE> bfd1: Sending CTL to 192.168.1.1 [Down] 2016-10-31 02:39:29 <TRACE> bfd1: Sending CTL to 192.168.1.1 [Down]
So packets are sent in both directions, they can be observed by tcpdump, but they are neither reported as received-accepted nor received-rejected by receiving BIRDs. Are there no errors in log messages (e.g. cannot open linstening socket when BFD is started)? Is there no other software listening on 3784 port (try netstat -apn --ip)? How do you have configured BIRD logging, would it log warning / errors? Could you try to use tcpdump -vv to see BFD packet content (discriminator values)? Is there no other factor like firewall, NAT? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On 31.10.2016 16:02, Ondrej Zajicek wrote:
Is there no other factor like firewall, NAT?
*sigh* Thanks for pointing me there, this apparently was the factor I forgot myself. Yes, the BFD traffic was blocked by a packet filter. Sincere apologies for the noise, and great software, by the way :) Thanks, J.
participants (2)
-
J. Kendzorra -
Ondrej Zajicek