Hello, I've just spent a while trying to debug a BGP session not coming up with bird, it turns out I had mistakenly set the multihop setting to "1" instead of "2" -- my fault. However, the reason it took me so long to realise this error was because the TCP session is established, with default connection parameters, THEN the TTL limit is assigned to the skb. As far as I'm aware, with TCP sockets in both Linux and BSD, the connections are already established when accept() returns a new connection. As I understand it, that's why inbound connections can't be filtered by the incoming source address either until the TCP session is already established, which usually means iptables/pf rules on the box synced with whoever the configured peers are. Which tends to lead to log spam when [known security company] does yet another scan of global address space for open BGP neighbours and fires a bunch of alerts... This may be a case of "that's just what you have to live with" but I was wondering if there's an alternative? Obviously libwrap0 (tcp-wrappers) won't help here because that also just processes a rule-set after accept() -- it's presumably something that needs to be addressed in the kernel. In any case, you can't set the TTL on a listen() for the SYN-ACK that is returned on a SYNC as far as I'm aware, unless you modify the default TTL for all TCP connections, you can't even set it with "ip route" or "route" on a per-destination basis. How do other people handle this situation? Do they create iptables/pf/whatever rules dynamically generated from their bird.conf for neighbor access control? How about ebgp multihop -- or does everyone just set it to 16/64 and forget about it? Or do people largely not care? M