From: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
To: Dave Taht <dave.taht@gmail.com>
Cc: homenet@ietf.org, Markus Stenberg <markus.stenberg@iki.fi>,
bloat-devel <bloat-devel@lists.bufferbloat.net>,
boutier@pps.univ-paris-diderot.fr
Subject: Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
Date: Thu, 09 May 2013 00:46:47 +0200 [thread overview]
Message-ID: <8738txgkdk.wl%jch@pps.univ-paris-diderot.fr> (raw)
In-Reply-To: <CAA93jw6KPxb-wsTLNsLMixGtVmwFkzmi8SvU2EwnhajCL_rC2g@mail.gmail.com>
> 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
prev parent reply other threads:[~2013-05-08 22:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-05 21:38 Dave Taht
2013-05-05 22:23 ` Dave Taht
[not found] ` <loom.20130507T130051-512@post.gmane.org>
[not found] ` <87vc6vgghx.wl%jch@pps.univ-paris-diderot.fr>
[not found] ` <8F7177E4-6212-4A74-8A7C-A2D1703A59BF@iki.fi>
[not found] ` <87sj1zgfot.wl%jch@pps.univ-paris-diderot.fr>
2013-05-08 8:51 ` [homenet] " Dave Taht
2013-05-08 9:48 ` Steven Barth
2013-05-08 10:28 ` Ole Troan
2013-05-08 10:51 ` Steven Barth
2013-05-08 10:58 ` Ole Troan
2013-05-08 12:54 ` Steven Barth
2013-05-08 11:06 ` Lorenzo Colitti
2013-05-08 22:46 ` Juliusz Chroboczek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8738txgkdk.wl%jch@pps.univ-paris-diderot.fr \
--to=jch@pps.univ-paris-diderot.fr \
--cc=bloat-devel@lists.bufferbloat.net \
--cc=boutier@pps.univ-paris-diderot.fr \
--cc=dave.taht@gmail.com \
--cc=homenet@ietf.org \
--cc=markus.stenberg@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox