[homenet] Source-specific routes in Linux [was: atomic updates...]

[Juliusz Chroboczek]

>       http://www.spinics.net/lists/netdev/msg235316.html
>       http://www.spinics.net/lists/netdev/msg235346.html

> One thing that bugs me about hacks and workarounds like this is that Linux (as
> well as openwrt) are intensely mutable systems, and it's totally possible to
> improve linux rather than limp around in userspace.

I can only agree with you.

Now, as mentioned in my second message linked above, source-specific
routing for IPv6 in a single table appears to be supposed to work with
CONFIG_IPV6_SUBTREES.  My tests indicate it doesn't, at least in
recent kernels.

I've tried to look at the relevant code (in ipv6/ipv6_fib.c and
ipv6/route.c), and this code is way beyond my grokking abilities.
Should a friendly kernel hacker choose to fix this, we can switch our
implementation to using that simpler API with little effort.
(Acutally deleting a bunch of code -- Matthieu is going to hate me.)

> I have long disliked the ip rule system in its primary use prior to now
> (vpns), as buggy, arbitrary, and subject to race conditions, so if a better
> api and methods for injecting/managing source address dependent routing

My preference goes towards dumping all routes into a single routing
table.  This applies both to source-specific routes, to
input-interface specific routes (which is what Steven Barth was
referring to), as well as to any future extensions to the model
(TOS-specific routes, flow-id-specific routes, evil-bit-specific
routes, etc.)

The semantics of such an API is ambiguous, but userspace can work
around that by injecting extra routes into the FIB.  The number of
such routes is at worst proportional to r^s, where r is the number of
"real" routes and s is the number of selection mechanisms, but (1)
this worst case is unlikely to happen in practice, and (2) this number
can be greatly reduced by having reasonable default disambiguation
rules in the kernel (use the destination as the primary key, the
source as the secondary key, and any other selectors as the tertiary key).

-- Juliusz