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
signature.asc
Description: Message signed with OpenPGP using GPGMail
