On Fri, Apr 01, 2022 at 03:57:12PM +0200, Alexander Zubkov wrote: > Not exactly. Yes, the session is handled by the kernel. But it should > be possible to set the TTL before listening to the socket. Looks like > bird just do not use the TTL for the listening BGP sessions before it > gets incoming connection. And it somewhat OK for the case when bird > listens a single socket on 0.0.0.0 for all connections - it can not > determine the TTL beforehand.
Hi As Matthew Walster wrote, we just listen on common socket, then after the connection is accepted we associate it with a session and then see expected TTL (1 for direct EBGP, more for multihop sessions) and set it for the new TCP connection. I think that this behavior is okay and should work, i do not know why it failed for Rumen Telbizov with 'ICMP time exceeded in-transit' error, as by the IPs (100.64.0.4 > 100.64.0.5) it is a direct connection. It would be better if we could apriori configure per-remote-IP TTL on listening socket, like we can do for MD5 auth, but i do not think that is possible with Linux API. > But in case one use strict bind for BGP > sockets, I think it would be better to set TTL. Although even in that > case it can have several sessions with the same source IP and various > TTLs. I tried to made some quick patch, which set ttl for strict bind > sessions, but it does not handle the case with mixed TTLs on the same > socket, otherwise it should work. Let's see what bird's developers say > about it. That is an interesting idea. It need not be restricted to 'strict bind', just each listening socket could be set to use maximum TTL value from BGP instances bound to that socket. So if all these BGP instances are direct EBGP, it would be 1. It would need to be done correctly w.r.t. reconfigurations and also handle the case that for multihop session we do not explicitly handle the TTL value, we use system default. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."