Automatic source routing

[Emmanuel Thierry]

Hello,

Le 24 sept. 2013 à 23:44, Ole Troan a écrit :

> 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.

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).

Best regards
Emmanuel Thierry