Automatic source routing
Ole Troan
otroan at employees.org
Wed Sep 25 11:40:09 CEST 2013
Emmanuel,
>>>>> The problem is really annoying if you want to use autoconfiguration
>>>>> in a multihoming scenario without the need for an external daemon.
>>>>> But maybe i missed a sysctl flag or something like that.
>>>>
>>>> Maybe, maybe not. What system are you using to manage your networking - for example, are you on a recent desktop distro using NetworkManager, which behaves badly in this case?
>>>
>>> I'd say "of course" not. ;) Nothing which could have an effect on the network stack. This is a development system (running on debian wheezy) with only base tools.
>>>
>>> The goal is to have a platform which acts has a multihomed router (with forwarding enabled) but automatically configures its addresses and default routers from RAs (accept_ra set to 2). For this test, the forwarding were disabled in order to limit potential side effects. I also tested with different kernels, it seams the linux kernel always behave like this...
>>>
>>> (...)
>>
>> you need source address dependent routing (e.g. http://tools.ietf.org/html/draft-troan-homenet-sadr-01)
>> I think the latest kernel has SADR working. enable CONFIG_IPV6_SUBTREES.
>
> I didn't know this draft, interesting.
> About CONFIG_IPV6_SUBTREES, i already use it to mitigate this problem, but it is all but automatic. You need to implement an external daemon to listen to RAs and dynamically add source routing entries in order to enforce the kernel not to route on the bad interface.
if you are brave (in a month or so you can be a little less brave) you can run this
https://github.com/fingon
on openwrt. supports SADR.
I'm doing the same as you are with a Cisco IOS router. which also has some shortcomings that I'm working on ironing out.
> What puzzles me is that the nexthop selection in the linux kernel:
> * doesn't prefer a router which announces the prefix from which the source address has been generated (when i do a ping6 -I <slaac_eth2> <dest> )
> * doesn't enforce the interface we bound to (when i do a ping6 -I eth2 <dest> )
> ...whereas two equivalent routes exists ("default via <router1> dev eth1" and "default via <router2> dev eth2" ). Only the expiration time differs between these routes.
>
> Surprisingly, even the following ping doesn't succeed to enforce the output interface on my setup:
> $ ping6 -r -I "<slaac_eth2>%eth2" <dest>
>
> This is what sounds weird to me. If this is the actual kernel behaviour, i think we might need to enforce the nexthop selection to prefer the interface corresponding to the source address of the packet (when the packet is locally generated).
isn't that the great thing with Linux, just get your coding hat on. ;-)
cheers,
Ole
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130925/c96413a2/attachment.sig>
More information about the ipv6-ops
mailing list