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

Dave Taht dave.taht at gmail.com
Wed May 8 04:51:00 EDT 2013


On Tue, May 7, 2013 at 5:03 AM, Juliusz Chroboczek <
jch at pps.univ-paris-diderot.fr> wrote:

> > > If you're actually doing source-specific routing, please show me how
> > > you speak to the kernel.
>
> > Most of that code is in Lua, and while I could have included
> > C extension module that did similar things as ip -6 does, I didn't
> > bother.
>
> We're doing pretty the same in our prototype code (saying
> system("ip...") rather than speaking the netlink dialect of the day).
> Could you point us at the relevant code, please?
>
> > So I'm just using ip -6 {route,rule} to set up source-specific rules
> > that map to destination tables.
>
> Ah, okay.  So you're using rules, just as we found out (the hard way)
> that we need to do.
>
>   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 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
information could be designed I'm pretty sure there would be much
enthusiasm across the vpn, mptcp/sctp, and routing worlds for getting it
into linux itself.



>
> > One (destination-based) routing table is maintained by routing
> > protocol, and the rest by Lua code which figures external defaults
> > based on routes within routing protocol implementation.
>
> Nice hack.
>

Except that probably it interacts badly with existing vpn manipulation of
these tables.


>
> -- Juliusz
> _______________________________________________
> homenet mailing list
> homenet at ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat-devel/attachments/20130508/ff0e966e/attachment-0002.html>


More information about the Bloat-devel mailing list