Re: [BUG] net/ipv4: inconsistent routing table

[Zang MingJie]

On Wed, Aug 12, 2015 at 4:52 AM, Alexander Duyck
<alexander.duyck@xxxxxxxxx> wrote:
> On 08/10/2015 04:50 AM, Hannes Frederic Sowa wrote:
>>
>> Hello,
>>
>> Zang MingJie <zealot0630@xxxxxxxxx> 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.

That's why I'm going to introduce a sysconf entry, with the entry
unset, keep compatibility; with the entry set, fix the bug.

>
>>> 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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/