BIRD incorrectly(?) detects whether a peer is directly connected
Good evening! When configuring BGP on a site BIRD fails to recognize whether an IP is directly connected. It appears to scan over the list of interfaces and check whether their subnets contain the target IP instead of relying on the route table and checking whether the resulting route has a gateway attribute. This does not work in some edge cases (such as, in our case, the machine being configured for a /128 + a LAN route to avoid some Linux autoconfiguration) Perhaps a mechanism like [1] is preferable, where BIRD would query a route from the kernel and check if it has a gateway on it. This is, at least semantically, more correct, as the routing table (at least on Linux) reflects on how addresses are reached exactly, whereas the addresses associated with interfaces serve for autoconfiguration purposes. [1]: https://github.com/shemminger/iproute2/blob/a38d305d15c6a27084d5ebc1c79a831d... PS: I'm unsure if my assessment of what currently happens is correct, I apologize if I got it wrong, but at any rate, it definitely fails to recognize that the peer is connected properly in our case. Thanks in advance, -- Arsen Arsenović
On Wed, Feb 16, 2022 at 03:32:55AM +0100, Arsen Arsenović wrote:
Good evening!
When configuring BGP on a site BIRD fails to recognize whether an IP is directly connected. It appears to scan over the list of interfaces and check whether their subnets contain the target IP instead of relying on the route table and checking whether the resulting route has a gateway attribute. This does not work in some edge cases (such as, in our case, the machine being configured for a /128 + a LAN route to avoid some Linux autoconfiguration)
Hello That is true, but it is not limited to BGP peers, it also affects other issues like next hop validation. Unfortunately it is not easily fixable. It would require redesigning whole internal neighbor processing, which is something that we plan to do, but there are currently tasks with higher priority. Also, for BGP peers, it can be workarounded by setting BGP as multihop 1. -- 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."
That is true, but it is not limited to BGP peers, it also affects other issues like next hop validation. Unfortunately it is not easily fixable. It would require redesigning whole internal neighbor processing, which is something that we plan to do, but there are currently tasks with higher priority. I see. Is there a channel, such as an RSS feed, where I can stay up to date with BIRD updates?
Also, for BGP peers, it can be workarounded by setting BGP as multihop 1. Yep, we already did that.
Thanks, -- Arsen Arsenović
participants (2)
-
Arsen Arsenović -
Ondrej Zajicek