From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: Andy Gospodarek <gospo@cumulusnetworks.com>,
Scott Feldman <sfeldma@gmail.com>
Cc: Netdev <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
ddutt@cumulusnetworks.com,
Alexander Duyck <alexander.duyck@gmail.com>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
"stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: Re: [PATCH net-next 1/3 v3] net: track link-status of ipv4 nexthops
Date: Thu, 11 Jun 2015 07:50:54 -0700 [thread overview]
Message-ID: <5579A04E.2060400@redhat.com> (raw)
In-Reply-To: <20150611112313.GA588@gospo.home.greyhouse.net>
On 06/11/2015 04:23 AM, Andy Gospodarek wrote:
> On Wed, Jun 10, 2015 at 11:07:28PM -0700, Scott Feldman wrote:
>> On Wed, Jun 10, 2015 at 7:37 PM, Andy Gospodarek
>> <gospo@cumulusnetworks.com> wrote:
>>> Add a fib flag called RTNH_F_LINKDOWN to any ipv4 nexthops that are
>>> reachable via an interface where carrier is off. No action is taken,
>>> but additional flags are passed to userspace to indicate carrier status.
>> Andy, it seems now RTNH_F_LINKDOWN and RTNH_F_DEAD are very similar
>> and I'm wondering if this could be done without introducing a new flag
>> and just use RTNH_F_DEAD. The link change event would set RTNH_F_DEAD
>> on nh on dev link down, and clear on link up. The sysctl knob would
>> be something like "nexthop_dead_on_linkdown", default off. So
>> basically expanding the ways RTNH_F_DEAD can be set. That would
>> simplify the patch set quite a bit and require no changes to iproute2.
>>
> You are absolutely correct that what you describe would be less churn to
> userspace. From a functionality standpoint that is close to what was
> originally proposed, but Alex specifically did not like the behavioral
> change to what having RTNH_F_DEAD set (at least that was what I
> understood).
>
> That was what made me make the move to add this additional flag that was
> exported to userspace, so it was possible to differentiate the old dead
> routes/nexthop functionality from those that were not going to be dead
> due to link being down.
> this point I think I prefer the additional data provided by the new
> flag exported to userspace.
I preferred the 2 flag solution as the original solution still required
2 flags, it just only exposed 1 to user-space. As a result it was much
more error prone since it was fairly easy to get into a confused state
about why the link was dead.
With the 2 flag solution it becomes much easier to sort out why the
route is not functional and it is much easier to isolate for things like
the sysctl which only disables the use of LINKDOWN and not DEAD.
- Alex
next prev parent reply other threads:[~2015-06-11 14:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 2:37 [PATCH net-next 0/3 v3] changes to make ipv4 routing table aware of next-hop link status Andy Gospodarek
2015-06-11 2:37 ` [PATCH net-next 1/3 v3] net: track link-status of ipv4 nexthops Andy Gospodarek
2015-06-11 2:53 ` Scott Feldman
2015-06-11 3:28 ` Andy Gospodarek
2015-06-11 4:14 ` Scott Feldman
2015-06-11 6:07 ` Scott Feldman
2015-06-11 11:23 ` Andy Gospodarek
2015-06-11 14:47 ` Scott Feldman
2015-06-11 14:50 ` Alexander Duyck [this message]
2015-06-11 15:25 ` Scott Feldman
2015-06-11 16:53 ` Dinesh Dutt
2015-06-11 2:37 ` [PATCH net-next 2/3 v3] net: ipv4 sysctl option to ignore routes when nexthop link is down Andy Gospodarek
2015-06-11 2:57 ` YOSHIFUJI Hideaki
2015-06-11 3:00 ` Scott Feldman
2015-06-11 3:36 ` Andy Gospodarek
2015-06-11 4:32 ` David Miller
2015-06-11 19:35 ` Andy Gospodarek
2015-06-11 2:37 ` [PATCH net-next 3/3 v3] iproute2: add support to print 'linkdown' nexthop flag Andy Gospodarek
2015-06-11 3:02 ` Scott Feldman
2015-06-11 3:13 ` Andy Gospodarek
2015-06-11 3:07 ` [PATCH net-next 0/3 v3] changes to make ipv4 routing table aware of next-hop link status Scott Feldman
2015-06-11 3:19 ` Andy Gospodarek
2015-06-11 3:33 ` Andy Gospodarek
2015-06-11 15:44 ` Scott Feldman
2015-06-11 18:17 ` Andy Gospodarek
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=5579A04E.2060400@redhat.com \
--to=alexander.h.duyck@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=ddutt@cumulusnetworks.com \
--cc=gospo@cumulusnetworks.com \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@gmail.com \
--cc=stephen@networkplumber.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.