From: Alexander Duyck <alexander.duyck@gmail.com>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>,
Zang MingJie <zealot0630@gmail.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] net/ipv4: inconsistent routing table
Date: Tue, 11 Aug 2015 13:52:27 -0700 [thread overview]
Message-ID: <55CA608B.1070302@gmail.com> (raw)
In-Reply-To: <87y4hjgy6p.fsf@stressinduktion.org>
On 08/10/2015 04:50 AM, Hannes Frederic Sowa wrote:
> Hello,
>
> Zang MingJie <zealot0630@gmail.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
next prev parent reply other threads:[~2015-08-11 20:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAOrge3qi=7YPRO+VeCDvHsm_7SFC4Y=+JpwQtwAV3zk_q4fEAw@mail.gmail.com>
2015-08-05 9:06 ` [BUG] net/ipv4: inconsistent routing table Daniel Borkmann
2015-08-05 17:45 ` Alexander Duyck
2015-08-06 10:13 ` Zang MingJie
2015-08-06 19:43 ` Alexander Duyck
2015-08-07 8:23 ` Zang MingJie
2015-08-07 16:08 ` Alexander Duyck
2015-08-07 17:00 ` Hannes Frederic Sowa
[not found] ` <CAOrge3qxOb_XrspuvYjV0pDDxUUoqGE3690KUQGoxZMxuD-NRQ@mail.gmail.com>
2015-08-08 10:36 ` Zang MingJie
2015-08-10 9:16 ` Hannes Frederic Sowa
2015-08-10 10:51 ` Zang MingJie
2015-08-10 11:50 ` Hannes Frederic Sowa
2015-08-11 20:52 ` Alexander Duyck [this message]
2015-08-11 21:15 ` David Miller
2015-08-12 8:14 ` Zang MingJie
2015-08-12 15:23 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55CA608B.1070302@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=hannes@stressinduktion.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=zealot0630@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).