lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170208153226.GA24185@splinter.mtl.com>
Date:   Wed, 8 Feb 2017 17:32:26 +0200
From:   Ido Schimmel <idosch@...lanox.com>
To:     Andy Gospodarek <andy@...yhouse.net>
CC:     Jiri Pirko <jiri@...nulli.us>, <netdev@...r.kernel.org>,
        <davem@...emloft.net>, <eladr@...lanox.com>, <mlxsw@...lanox.com>,
        "Roopa Prabhu" <roopa@...ulusnetworks.com>,
        David Ahern <dsa@...ulusnetworks.com>
Subject: Re: [patch net-next 12/15] ipv4: fib: Notify about nexthop status
 changes

On Wed, Feb 08, 2017 at 09:56:00AM -0500, Andy Gospodarek wrote:
> On Wed, Feb 08, 2017 at 11:16:39AM +0100, Jiri Pirko wrote:
> > From: Ido Schimmel <idosch@...lanox.com>
> > 
> > When a multipath route is hit the kernel doesn't consider nexthops that
> > are DEAD or LINKDOWN when IN_DEV_IGNORE_ROUTES_WITH_LINKDOWN is set.
> > Devices that offload multipath routes need to be made aware of nexthop
> > status changes. Otherwise, the device will keep forwarding packets to
> > non-functional nexthops.
> > 
> > Add the FIB_EVENT_NH_{ADD,DEL} events to the fib notification chain,
> > which notify capable devices when they should add or delete a nexthop
> > from their tables.
> 
> This looks good -- thanks for doing this.
> 
> IIUC the hardware forwarding use case for your hardware covered by David
> Ahern's patch[1] to the ipv4 software path selection is already covered,
> so this is probably the last known link/neighbor forwarding issue for
> ipv4 that needs coverage.
> 
> 1. a6db449 net: ipv4: Consider failed nexthops in multipath routes

Yep, it aligns the kernel's datapath with what we already implemented in
mlxsw. In case the neighbour can't be resolve, then the nexthop isn't
reflected to the device (we need the MAC...).

In the case of multipath routes, if some of the nexthops can be
reflected, then we do so, but periodically ask the kernel to try and
resolve the others. Otherwise, these nexthops will never be resolved, as
the kernel doesn't see the packets hitting the multipath route and
therefore lacks the motivation to resolve its nexthops.

> > Cc: Roopa Prabhu <roopa@...ulusnetworks.com>
> > Cc: David Ahern <dsa@...ulusnetworks.com>
> > Cc: Andy Gospodarek <andy@...yhouse.net>
> 
> Reviewed-by: Andy Gospodarek <gospo@...adcom.com>

Thanks for reviewing!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ