Message-ID: <5588BC38.4060207@miraclelinux.com>
Date:	Tue, 23 Jun 2015 10:54:00 +0900
From:	YOSHIFUJI Hideaki/吉藤英明 
	<hideaki.yoshifuji@...aclelinux.com>
To:	Matthias Schiffer <mschiffer@...verse-factory.net>,
	Steven Barth <steven@...link.org>
CC:	hideaki.yoshifuji@...aclelinux.com,
	Markus Stenberg <markus.stenberg@....fi>,
	"David S. Miller" <davem@...emloft.net>,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"YOSHIFUJI Hideaki (USAGI Project)" <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH] ipv6: Fixed source specific default route handling.

Matthias Schiffer wrote:
> 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?
> 

"src" is long-lived feature which is usually used with mutiple routing
tables by "ip rule".

--yoshfuji

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

-- 
吉藤英明 <hideaki.yoshifuji@...aclelinux.com>
ミラクル・リナックス株式会社 技術本部 サポート部
--
To unsubscribe from this list: send the line "unsubscribe netdev" in

Powered by blists - more mailing lists