Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
On 8 May 2013, at 10:45, Dave Taht dave.t...@gmail.com wrote: On Wed, May 8, 2013 at 2:29 AM, Tim Chown t...@ecs.soton.ac.uk wrote: On 7 May 2013, at 12:08, Markus Stenberg markus.stenb...@iki.fi wrote: Yet another implementation of interest might be: https://github.com/edderick/quagga_zOSPF/ [1]/[2] versions do not interoperate with it (but they interoperate with Arkko one); latest [3] version interoperates with it, but not Arkko..) Hi, So the github zOSPF iplementation above was done this year by an undergraduate project student of mine, Ed Seabrook. He has tested his code against both Ben's and Markus' implementations, using a netkit test environment, with pretty successful results overall. Ed has given some feedback to the draft authors based on his experience. It would be helpful if those comments were more public. Markus and Edward have discussed the issues arising from Edward's project work. There is a small number of open questions/ambiguities resulting. I agree these should be summarised and posted here for comment to help improve the relevant draft(s). Ed chose to build on Quagga because he knew the bird implementations existed, and wanted to show interoperability with a different platform. CeroWrt uses quagga-RE (for BGPpgp and babel support), and if it is possible to merge these patches into that branch, and the results useful, I'd be delighted to do so... It would be useful to get some code review... I'll email you off-list. Tim___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
Juliusz,
there is also a draft: http://tools.ietf.org/html/draft-troan-homenet-sadr-00
an implementation using Linux table support will require duplication of route
entries into multiple tables.
cheers,
Ole
On May 7, 2013, at 14:03 , Juliusz Chroboczek j...@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 (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.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
On Tue, May 7, 2013 at 5:03 AM, Juliusz Chroboczek
j...@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@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
--
Dave Täht
Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
On 08.05.2013 10:51, Dave Taht wrote: 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. Hmm I must admit I'm wondering about this for the OpenWrt stack as well. We have switched to RA-Handling in userspace for similar reasons already so I guess it's only the next logical step to create separate routing tables for each upstream interface to do source-based routing and filter out ULA-traffic on this layer instead of through iptables. Having one central userspace management daemon for routing and address / prefix delegation in general might not be the best or cleanest solution in the end but I guess there is no better way right now. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
[...] We have switched to RA-Handling in userspace for similar reasons already so I guess it's only the next logical step to create separate routing tables for each upstream interface to do source-based routing and filter out ULA-traffic on this layer instead of through iptables. don't do it per upstream interface, that wouldn't work. per next-hop might. the draft suggests a single table with source constrained routers and backtracking. Having one central userspace management daemon for routing and address / prefix delegation in general might not be the best or cleanest solution in the end but I guess there is no better way right now. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
[...] We have switched to RA-Handling in userspace for similar reasons already so I guess it's only the next logical step to create separate routing tables for each upstream interface to do source-based routing and filter out ULA-traffic on this layer instead of through iptables. don't do it per upstream interface, that wouldn't work. per next-hop might. the draft suggests a single table with source constrained routers and backtracking. Having one central userspace management daemon for routing and address / prefix delegation in general might not be the best or cleanest solution in the end but I guess there is no better way right now. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
On Wed, May 8, 2013 at 7:51 PM, Steven Barth cy...@openwrt.org wrote: if there would be multiple routers which I guess is unlikely in that situation. One could maybe attribute the prefix to the source address of the DHCPv6 server but that sounds problematic to me aswell. So you're talking about the case where you have ISP1 and ISP2 plugged into a switch together with your router? In that case I can't see any better way than attempting to match the link-local IPv6 address that you got the RA from to the link-local address of the DHCPv6 server you got the PD from. I can't think of a situation why these would be different, but perhaps there is. Can the DHCPv6 server be a global address? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
Dave Taht dave.taht at gmail.com writes: I don't know where the ietf 86 bird work on multihoming went. (?) Patterson's original work on ospf is here: https://github.com/paterben/bird-homenet and the ietf drafts are here http://tools.ietf.org/wg/homenet/ Patterson's work is mostly of historic interest. [1] https://github.com/fingon/hnet has 'super-repository' which has custom NetKit version, OpenWRT AA github link and everything else to get it running on a Linux desktop for playing with (with OpenWRT UML images running in a NetKit lab). [2] https://github.com/fingon/hnet-openwrt-feed contains just OWRT package feed for the stuff. [3] https://github.com/fingon/hnet-core contains most of the new code. I know it for a fact that people have gotten it running using any of those approaches ([1] contains [2] and [3], and [2] refers to [3]). Still, just for playing, [1] is probably the easiest choice (given correct Linux distro, just following the README should be enough). Yet another implementation of interest might be: https://github.com/edderick/quagga_zOSPF/ [1]/[2] versions do not interoperate with it (but they interoperate with Arkko one); latest [3] version interoperates with it, but not Arkko..) Cheers, -Markus P.S. [1] and [2] contain 'most recent tested' version, which as of now, is the post-IETF86-bugfixes one; bleeding edge development happens in [3] and it's sub-branch(es), but [1] and [2] refer just to stable points of [3]. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
[1] https://github.com/fingon/hnet has 'super-repository' which has custom NetKit version, OpenWRT AA github link and everything else to get it running on a Linux desktop for playing with (with OpenWRT UML images running in a NetKit lab). [2] https://github.com/fingon/hnet-openwrt-feed contains just OWRT package feed for the stuff. [3] https://github.com/fingon/hnet-core contains most of the new code. Just to clarify -- this does OSPF-based autoconf and prefix assignment, but not source-specific routing, right? If you're actually doing source-specific routing, please show me how you speak to the kernel. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
On 7.5.2013, at 14.46, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
[1] https://github.com/fingon/hnet has 'super-repository' which
has custom NetKit version, OpenWRT AA github link and everything
else to get it running on a Linux desktop for playing with
(with OpenWRT UML images running in a NetKit lab).
[2] https://github.com/fingon/hnet-openwrt-feed contains just
OWRT package feed for the stuff.
[3] https://github.com/fingon/hnet-core contains most of the new code.
Just to clarify -- this does OSPF-based autoconf and prefix
assignment, but not source-specific routing, right?
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. So I'm just using ip -6
{route,rule} to set up source-specific rules that map to destination tables.
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. Not pretty, but it _does_ work.
Cheers,
-Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
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 (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.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
On Sun, May 5, 2013 at 2:38 PM, Dave Taht dave.t...@gmail.com wrote: On Sun, May 5, 2013 at 1:05 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: It's not ECMP for ipv6 I'm looking to see solved for multiple routing protocols, but the multiple ipv6 prefixes/multiple exits source routing problem. As you well know, Dave, we've been working on that for the last fortnight or so. We've run into a limitation of the kernel: http://www.spinics.net/lists/netdev/msg235316.html Hmm. Given that this code path has only barely been exercised before and so many changes to the routing paths have happened in the last 2+ years, I'm not surprised its broken. Unfortunately, I've had no reply to my question: http://www.spinics.net/lists/netdev/msg235346.html So it looks like we're going to have to dynamically generate rule table entries... sigh. Well, given the work going into mptcp in particular, This was a very good overview of where that work stands. http://lwn.net/Articles/544399/ a better API for src specific routing for ipv6 than the ip rule system seems like a good idea. Widening the distribution a little bit... The homenet folk demonstrated this form of ipv6 multihoming working (using a version of OSPF and BIRD, I believe) at the last ietf. That is interesting. Would you happen to know how they're interfacing with the kernel? Or perhaps have a link to their code? I don't know where the ietf 86 bird work on multihoming went. (?) Patterson's original work on ospf is here: https://github.com/paterben/bird-homenet and the ietf drafts are here http://tools.ietf.org/wg/homenet/ -- Juliusz -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
