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: <20170208182038.GA14683@splinter.mtl.com>
Date:   Wed, 8 Feb 2017 20:20:38 +0200
From:   Ido Schimmel <idosch@...lanox.com>
To:     David Ahern <dsa@...ulusnetworks.com>
CC:     Andy Gospodarek <andy@...yhouse.net>,
        Jiri Pirko <jiri@...nulli.us>, <netdev@...r.kernel.org>,
        <davem@...emloft.net>, <eladr@...lanox.com>, <mlxsw@...lanox.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [patch net-next 12/15] ipv4: fib: Notify about nexthop status
 changes

On Wed, Feb 08, 2017 at 11:05:54AM -0700, David Ahern wrote:
> On 2/8/17 8:32 AM, Ido Schimmel wrote:
> > 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.
> 
> It should get the motivation once the neigh entry is cleaned up. That
> can take a long time based on gc settings, but it can also happen from
> the remote side if it sends an arp message.

And when the remote side does that and the neighbour becomes valid we no
longer try to actively resolve it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ