netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roopa Prabhu <roopa@cumulusnetworks.com>
To: David Ahern <dsa@cumulusnetworks.com>
Cc: netdev@vger.kernel.org, nicolas.dichtel@6wind.com
Subject: Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
Date: Mon, 30 Jan 2017 10:45:57 -0800	[thread overview]
Message-ID: <588F89E5.9060503@cumulusnetworks.com> (raw)
In-Reply-To: <d987faff-ced4-8791-8bdb-ba8a66aec6f5@cumulusnetworks.com>

On 1/30/17, 8:12 AM, David Ahern wrote:
> On 1/30/17 8:49 AM, Roopa Prabhu wrote:
>>> Single next hop delete will be around because IPv6 allows it -- and because IPv4 needs to support it.
>>>
>> understand single next hop delete for ipv6 will be around..and my only point was to leave it around but not optimize for that case.
>> I don't think we should support single nexthop delete in ipv4 (I have not seen a requirement for that)... ipv4 is good as it is right now.
>> the additional complexity is not needed.
>>
> IPv4 has a known bug -- delete a virtual interface in a multihop route and the entire route is deleted, including the nexthops for other devices. This does not happen for IPv6.
>
> Simple example of that bug:
>
> ip li add dummy1 type dummy
> ip li add dummy2 type dummy
> ip addr add dev dummy1 10.11.1.1/28
> ip li set dummy1 up
> ip addr add dev dummy2 10.11.2.1/28
> ip li set dummy2 up
> ip ro add 1.1.1.0/24 nexthop via 10.11.1.2 nexthop via 10.11.2.2
> ip li del dummy2
>
> --> the entire multipath route has been deleted.
>
>
> And, fixing this bug enables work to make IPv4 append to be sane -- appending a route should modify an existing route by adding the nexthop, not adding a new route that I believe can never actually be hit.
>
> Both cases mean modifying an IPv4 route -- adding or removing nexthops -- a capability that IPv6 allows so fixing this means closing another difference between the stacks.

good point on the bug you point out. agree the bug needs to be fixed ...but routing daemons react to this behavior pretty well...because they get a link notification and a route notification. I was ok with fixing ipv6 to be similar to ipv4...but I am not in favor of bringing in design choices that ipv6 made into ipv4 :).
In all cases, in my experience with routes, the update of ecmp route as a whole has always been ok (at-least not until now...maybe in the future
for new usecases)

In the case of the bug you point out, can the user be notified of the implicit update of the route in the kernel ...via replace flag or something ?.
regarding append..., ipv4 never really supported appending to an existing route......even in the case of a non-ecmp routes.
append just dictates the order where the route is added IIRC  (i maybe mistaken here..its been long i tried it).

  reply	other threads:[~2017-01-30 18:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-27 23:20 [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes David Ahern
2017-01-27 23:20 ` [PATCH net-next v3 1/4] net: ipv6: add NLM_F_APPEND in notifications when applicable David Ahern
2017-01-27 23:20 ` [PATCH net-next v3 2/4] net: ipv6: Allow shorthand delete of all nexthops in multipath route David Ahern
2017-01-27 23:20 ` [PATCH net-next v3 3/4] net: ipv6: Add support to dump multipath routes via RTA_MULTIPATH attribute David Ahern
2017-01-27 23:20 ` [PATCH net-next v3 4/4] net: ipv6: Use compressed IPv6 addresses showing route replace error David Ahern
2017-01-29  1:00 ` [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes Roopa Prabhu
2017-01-29 18:02   ` David Ahern
2017-01-29 23:55     ` Roopa Prabhu
2017-01-30  1:29       ` David Ahern
2017-01-30  2:20         ` Roopa Prabhu
2017-01-30  2:57           ` David Ahern
2017-01-30 11:13             ` Nicolas Dichtel
2017-01-30 15:59               ` David Ahern
2017-01-30 15:49             ` Roopa Prabhu
2017-01-30 16:12               ` David Ahern
2017-01-30 18:45                 ` Roopa Prabhu [this message]
2017-01-30 21:16                   ` Stephen Hemminger
2017-01-30 23:53                     ` David Ahern
2017-01-30 23:56                       ` Stephen Hemminger
2017-01-31  0:02                         ` David Ahern
2017-01-30 11:08       ` Nicolas Dichtel
2017-01-30 15:45         ` Roopa Prabhu
2017-01-30 16:41           ` Nicolas Dichtel
2017-01-30 11:07     ` Nicolas Dichtel
2017-01-30 15:23       ` David Ahern
2017-01-30 17:03         ` Nicolas Dichtel

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=588F89E5.9060503@cumulusnetworks.com \
    --to=roopa@cumulusnetworks.com \
    --cc=dsa@cumulusnetworks.com \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.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).