[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55CA608B.1070302@gmail.com>
Date: Tue, 11 Aug 2015 13:52:27 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>,
Zang MingJie <zealot0630@...il.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] net/ipv4: inconsistent routing table
On 08/10/2015 04:50 AM, Hannes Frederic Sowa wrote:
> Hello,
>
> Zang MingJie <zealot0630@...il.com> writes:
>
>> Here comes several options:
>>
>> 1. reject local next hop w/ EINVAL
>> 2. delete route when local next hop removed
> Will also cause some people to complain.
>
>> 3. transition between RT_SCOPE_HOST amd RT_SCOPE_LINK
> I don't understand the scope transition. I know Alex mentioned it for
> the first time. Maybe he can explain?
If I am not mistaken part of the issue in terms of the behaviour being
seen is due to the fact that the nexthop scope is recorded only when the
route is added, and there is code in place in rt_set_nexthop which will
only use the gateway if the scope is RT_SCOPE_LINK. So what we would
probably need to do is go through and audit any routes on a given
interface every time an address is added or removed and if the nh_gw is
equal to the address added or removed would would need to transition
between RT_SCOPE_LINK and RT_SCOPE_HOST since the gateway is
transitioning between the local system and somewhere on the other side
of the link.
The problem is that this would still be a behaviour change and there may
be somebody that has heartburn about it.
>> 4. document it
> I prefer that one :)
Yeah, me too. The fact is things have worked this way up until now and
I suspect the reason why this hasn't been reported until now is simply
because in many cases it works since routes are usually updated if you
are moving the gateway onto the local system.
- Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists