Messages in this thread | | | From | Matthias Schiffer <> | Subject | Re: [PATCH] ipv6: Fixed source specific default route handling. | Date | Mon, 22 Jun 2015 19:51:14 +0200 |
| |
On 06/22/2015 07:58 AM, Steven Barth wrote: > On 22.06.2015 00:35, Matthias Schiffer wrote: >> Could you explain in detail what you mean with "If you want specific SA, >> add same route with higher metric and/or (more) specific src match."? >> Routes aren't bound to specific addresses except via the "src" attribute >> (which is called prefsrc in the kernel), which is exactly what it not >> working. I can't control the chosen source address at all when >> source-specific routes are involved. > Except that prefsrc and src are two different beasts and usually ip route from transates to > RTA_SRC instead of RTA_PREFSOURCE when used with a prefix length. > > Try adding two routes to the same destination with the same metric but different source values with PREFSRC (e.g. IPv4) and then > try doing the same with SRC (e.g. IPv6). The former will fail but the latter will succeed.
Ah sorry, I didn't know that "src" and "prefsrc" were distinct concepts. I meant to refer to "src" whenever I wrote "prefsrc". What are the precise semantics of the "src" attribute? Any RFC I can read, or is this a Linux-specific concept?
> > > https://tools.ietf.org/html/draft-troan-homenet-sadr-01 > was the original draft for source-address dependent routing IIRC so might be a good read.
Thanks for the link, that helps a bit.
> > >> >> Even though the source-specific route has a higher metric than the >> generic one, the source-specific one shadows the generic route. > > (was a bit ago since I read into this so please correct me if I am wrong) > IIRC this is intentional since longest-prefix-match beats metric here > and the source-address match counts to being more-specific here. See also above difference between PREFSRC and SRC.
Ah, that would explain the metric issue. I looks like the source of my confusion is that for source-specific routes *all* addresses are in the candidate set, not only the addresses of the outgoing interface (which makes sense as ip6_route_get_saddr() is called with a NULL rt6_info in the source-specific case).
I'm not sure if this can be fixed in a sane way (as there seems to be a dependency cycle: source address should depend on outgoing interface, which depends on the chosen route, which depends on the source address), but it leads to highly unintuitive source address selection :(
Markus suggested in the commit message not to call ip6_route_output at all before the source address has been selected. Wouldn't this make it impossible to choose the source address depending on the outgoing interface in the non-source-specific case as well?
> Cheers, > > Steven
Thanks for the explanation, Matthias
[unhandled content-type:application/pgp-signature] | |