Next-hop check not needed?

[Ondrej Zajicek]

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 at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20170628/4472573a/attachment.asc>