Bingo! As soon as I the system TTL to 255, the session went up. Thanks a lot! Now that we know where to look, we started to dig a bit in the code to not have to change the TTL system wide but only for Bird. It seems like there a TODO to make the TTL value customizable: https://github.com/BIRD/bird/blob/master/proto/bfd/packets.c#L453 And in some (so far unknown) cases, it sets the TTL to 255 https://github.com/BIRD/bird/blob/master/proto/bfd/packets.c#L456 -- Arzhel On Sun, Mar 10, 2019, at 19:10, Ondrej Zajicek wrote:
On Thu, Mar 07, 2019 at 07:13:58PM -0500, Arzhel Younsi wrote:
Thanks for your reply Ondrej,
I changed the port range as suggested, confirmed that BFD packets were leaving from a correct port, but the BFD session still stays down.
208.80.153.77 Down 0.000 1.000 3 Client BGP, TX interval 0.300, RX interval 0.300 Local diagnostic None, remote diagnostic None Remote state AdminDown, version 1 Replicated Session type: Multi hop BFD Min async interval 0.300, min slow interval 1.000 Adaptive async TX interval 2.000, RX interval 2.000 Local min TX interval 2.000, minimum RX interval 0.300, multiplier 3 Remote min TX interval 0.000, min RX interval 0.000, multiplier 0 Local discriminator 3556, remote discriminator 0 Echo mode disabled/inactive, no-absorb, no-refresh Multi-hop min-recv-TTL 254, route table 0, local-address 208.80.153.192
Perhaps there is an issue with 'min-recv-TTL 254'. For single-hop BFD sessions, the RFC 5880 requires TTL security mechanism and therefore BIRD specifies outgoing TTL 255. For multi-hop BFD there is no such requirement and therefore BIRD uses OS default TTL, which is AFAIK 64 on Linux.
You can check that with tcpdump and perhaps disable the check on Juniper or set /proc/sys/net/ipv4/ip_default_ttl on Linux.
-- 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."