On Wed, Jun 21, 2017 at 05:11:55PM +0200, Vincent Bernat wrote:
Hey
in netlink.c, there is this piece of code: ... In turns, it calls neigh_find2() which delegates the decision to if_connected(). if_connected() will return an error if it thinks that the gateway is not part of the prefix of one of the configured IP addresses.
This means that if I have the following setup:
ip route add 203.0.113.4/32 dev vnet2 ip route add 203.0.113.15/32 via 203.0.113.4 dev vnet2
BIRD will complain about "strange next-hop" while the setup is perfectly valid. I don't need an IP address on an interface to route traffic on it.
Hi It is expected behavior. Next hops are validated against interface prefixes reported by OS, not against device routes in routing table. See e.g. https://www.mail-archive.com/bird-users@network.cz/msg01896.html Which discusses the same issue just in context of Static protocol instead of Kernel protocol. Note that when learning route from the kernel you could workaround it by using 'onlink' route flag.
I would think the check should just be removed. If the kernel says this is a valid gateway, it likely is.
Well, that would work in an ideal world, but in practice kernel can give you inconsistent or invalid results. E.g., if you have these two routes and remove the first, the second stays in kernel alone. But if you start from empty table and try to add just the second one, it is rejected.
However, I can't find the reason the check was added.
Each protocol (including Kernel protocol) is expected to send only routes with valid next-hops. BIRD does recursive resolution of next-hops only for recursive routes. For regular routes next-hops are validated against interface prefixes. So the check was added to be consistent with these assumptions.
In the past, this was just a warning:
Commit message says "Fixes some problems related to link-local routes in KRT interface". Does this ring any bell?
The patch primarily added interface as a part of neighbor resolution, the change from a warning to an error was a secondary change, probably just to be consistent with other protocols. -- 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."