https://docs.frrouting.org/en/stable-9.1/bfd.html#clicmd-minimum-ttl-1-254 Reads frr 9.1 enforces a min ttl of 254 if not otherwise specified. VyOS 1.3 uses frr 8.5.1 afair. https://docs.frrouting.org/en/stable-8.5/bfd.html#clicmd-minimum-ttl-1-254 You could opt for tweaking the min ttl on the frr side. Seams less intrusive, imo. 🤔 On Sat, 20 Jan 2024, 17.59 Alexander Zubkov via Bird-users, < bird-users@network.cz> wrote:
Hi Lukas,
Actually I saw support for TTL security in BFD code: https://gitlab.nic.cz/labs/bird/-/blob/master/proto/bfd/packets.c#L496
And I see in your config example that you use multihop BFD, but RFC you refer is talking about single-hop BFD usage. So it does not seem like a bug here. Maybe the other side does not consider this BFD sessions multihop and thus applying the TTL security policy?
Regards, Alexander
On Sat, Jan 20, 2024 at 11:18 AM Lukas Haase <lukashaase@gmx.at> wrote:
Hi,
After long debugging I finally figured out why Bird's bfd cannot
establish a session with FRR (VyOS): Packets are sent with TTL 64. However, according to https://datatracker.ietf.org/doc/rfc5881/, Section 5: "If BFD authentication is not in use on a session, all BFD Control packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255".
This is the reason why FRR just drops packets received from bird and the
session never establishes.
As a quick workaround, I could get it working with:
sysctl -w net.ipv4.ip_default_ttl="255"
However, bird should set TTL appropriately.
Is this something that was missed or is there an setting I am missing?
Thanks, Luke
Gesendet: Mittwoch, 17. Januar 2024 um 01:24 Uhr Von: "Lukas Haase via Bird-users" <bird-users@network.cz> An: "Alexander Zubkov" <green@qrator.net> Cc: bird-users@network.cz Betreff: Re: BFD sessions with FFR (VyOS) won't establish
Hi Alexander,
Thanks. I have tried
sysctl -w net.ipv4.ip_local_port_range="49152 65535"
but unfortunately no change. What I do not understand is that Interval and Timeout is wrong on the
non-working peer:
# birdc show bfd sess BIRD 2.0.8 ready. bfd1: IP address Interface State Since
Interval Timeout
172.20.215.130 --- Up 2024-01-16 0.100 0.500 172.20.215.131 --- Init 2024-01-16 1.000 10.000
Do these parameters need to be identical among peers, similar as with OSPF? Note, they are identical to my knowledge but could there be any implicit setting that causes discrepancy between the peers and would cause a connection being stuck in "Up"? For example, in bird I have "idle tx interval 500 ms" but I could not find a corresponding option in VyOS/FFR.
Could you think of any tcpdump/netcat debug?
Thanks, Luke
Gesendet: Mittwoch, 17. Januar 2024 um 00:35 Uhr Von: "Alexander Zubkov" <green@qrator.net> An: "Lukas Haase" <lukashaase@gmx.at> Cc: bird-users@network.cz Betreff: Re: BFD sessions with FFR (VyOS) won't establish
Hi,
There were reports here in the list that some BFD peers do not allow connections from non-standard ports and bird do not choose source port specifically. So you might need to tune your sysctl like that:
net.ipv4.ip_local_port_range = 49152 65535
Not sure if this is the case, but I would try that first.
Regards, Alexander
On Tue, Jan 16, 2024 at 9:15 AM Lukas Haase via Bird-users <bird-users@network.cz> wrote:
Hello,
My BFD session between bird work fine but the ones but the ones to
VyOS (which uses FFR) just won't connect:
# birdc show bfd sess BIRD 2.0.8 ready. bfd1: IP address Interface State Since Interval Timeout 172.20.215.131 --- Init 10:39:14.183 1.000 10.000 172.20.215.130 --- Up 10:42:03.901 0.100 0.500
172.20.215.131 is here a VyOS box and its FFR config looks like:
! bfd peer 172.20.215.129 multihop local-address 172.20.215.131 detect-multiplier 10 transmit-interval 100 receive-interval 100 exit ! exit ! end
For reference, my bird config is trivially:
protocol bfd { interface "local-ibgp" { min rx interval 100 ms; min tx interval 100 ms; idle tx interval 500 ms; multiplier 10; }; neighbor 172.20.215.130 local 172.20.215.129 multihop; neighbor 172.20.215.131 local 172.20.215.129 multihop; }
I have turned off firewall. What else could go wrong?
Thanks, Luke