All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsa@cumulusnetworks.com>
To: nicolas.dichtel@6wind.com, David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, roopa <roopa@cumulusnetworks.com>
Subject: Re: [PATCH net-next v2 0/2] net: ipv6: Improve user experience with multipath routes
Date: Fri, 27 Jan 2017 09:36:49 -0700	[thread overview]
Message-ID: <582674ce-ed9e-9c9d-d88c-a7bfe6691d89@cumulusnetworks.com> (raw)
In-Reply-To: <f30ab203-47f9-e333-3552-bf5e2dbeaaf9@6wind.com>

On 1/27/17 9:29 AM, Nicolas Dichtel wrote:
> Le 26/01/2017 à 19:00, David Miller a écrit :
>> From: David Ahern <dsa@cumulusnetworks.com>
> [snip]
>>> Quagga does not properly handle IPv6 multipath routes received from
>>> the kernel. I checked this with debian/jessie version and our
>>> version, and Donald reviewed the source. It is broken.
>>
>> If this is true, quagga is asbolutely not an argument for this "breaking"
>> something.  It doesn't break anything.
> Ok, my tests also shows that quagga is buggy.
> Let's change the way to advertise these routes.
> 
> It would be great to also use RTA_MULTIPATH when a route is deleted (like in
> your patch 1/2).

I have updated notifications to use RTA_MULTIPATH. Working on the multipath add/delete/replace permutations now and what the notification looks like. Add/replace is easy and the notifications use RTA_MULTIPATH. Notifications for the delete path are complicated given that a delete could remove only a subset of nexthops. Given that, we might have to settle for a notification for each nexthop delete.

> 
> Note that there is still a difference between ipv4 and ipv6: in ipv4 when a
> nexthop is added/updated/removed, the whole route must be deleted and added
> again. In IPv6, nexthop can be managed one by one.
> It means that in ipv4, the full route is always dumped, which is not the case in
> ipv6.
> 

Yes. I have been working on how to delete a nexthop within an IPv4 route. It is much more complicated given how the route is stored compared to IPv6.

  reply	other threads:[~2017-01-27 16:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-20  6:10 [PATCH net-next v2 0/2] net: ipv6: Improve user experience with multipath routes David Ahern
2017-01-20  6:10 ` [PATCH net-next v2 1/2] net: ipv6: Allow shorthand delete of all nexthops in multipath route David Ahern
2017-01-20  6:10 ` [PATCH net-next v2 2/2] net: ipv6: Add option to dump multipath routes via RTA_MULTIPATH attribute David Ahern
2017-01-20 19:31 ` [PATCH net-next v2 0/2] net: ipv6: Improve user experience with multipath routes David Ahern
2017-01-24 16:06   ` David Miller
2017-01-26 14:58     ` Nicolas Dichtel
2017-01-26 17:26       ` David Ahern
2017-01-26 18:00         ` David Miller
2017-01-27 16:29           ` Nicolas Dichtel
2017-01-27 16:36             ` David Ahern [this message]
2017-01-27 16:45               ` 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=582674ce-ed9e-9c9d-d88c-a7bfe6691d89@cumulusnetworks.com \
    --to=dsa@cumulusnetworks.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    --cc=roopa@cumulusnetworks.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 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.