Unexpected behavior of static routes

[Ondrej Zajicek]

On Wed, May 10, 2017 at 12:28:31PM +0200, Alexander Demenshin wrote:
> On 2017-05-10 03:01, Ondrej Zajicek wrote:
> 
> >It is expected behavior. It is not optimal, but it is how it works.
> 
> Is it limitation by design or just "not implemented"?

More or less by design. One could say that more elegant design would be
to just not distinguish between regular and recursive routes and instead
of have different 'tiers' of routes, where next hops of 'tier N' routes
are resolved through 'tier 0..N-1' routes and device routes are 'tier
0' routes.

But such design would bring plenty of issues w.r.t. multiple routing
tables - may next hops resolve just in the same routing table or also in
another routing table? If in another than who specify that, source
protocol, routing table or someone else?  What if the device route is
available, but not exported to kernel?


> >If you have a recursive route that is resolved to a device route,
> >then the original gateway is kept.
> 
> Yes, indeed, this works (to my surprise), though it starts to produce

Well, if you have a route specifying that to A you need to go through
router B and another that says to B you need to go through router C then
you deduce that to A you need to to through C. But if the second route
says instead that B is directly attached on eth0, then you deduce that
to A you still need through router B attached on eth0, not that A is
directly attached on eth0.


> "Received route with strange next-hop" errors on every scan (harmless,
> but too noisy and incorrect - there is nothing "strange" with that
> next-hop).
> 
> It does not look clean though - while it works, it looks not "natural"
> in configuration ("recursive" instead of "via").
> 
> Would it not be an option to implement "onlink" static routes,
> i.e. including both device and gateway addresses, or there are arguments
> against this?

Static onlink routes is something that probably could be implemented and
it is a good idea.

-- 
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."