netdev - Re: [PATCH net-next] net: change fib behavior based on interface link status

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 3 Jun 2015 11:12:09 -0400
From:	Andy Gospodarek <gospo@...ulusnetworks.com>
To:	Scott Feldman <sfeldma@...il.com>
Cc:	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>, ddutt@...ulusnetworks.com
Subject: Re: [PATCH net-next] net: change fib behavior based on interface
 link status

On Tue, Jun 02, 2015 at 10:03:23PM -0700, Scott Feldman wrote:
> On Tue, Jun 2, 2015 at 8:07 PM, Andy Gospodarek
> <gospo@...ulusnetworks.com> wrote:
> > This patch adds the ability to have the Linux kernel track whether or
> > not a particular route should be used based on the link-status of the
> > interface associated with the next-hop.
> >
> > Before this patch any link-failure on an interface that was serving as a
> > gateway for some systems could result in those systems being isolated
> > from the rest of the network as the stack would continue to attempt to
> > send frames out of an interface that is actually linked-down.  When the
> > kernel is responsible for all forwarding, it should also be responsible
> > for taking action when the traffic can no longer be forwarded -- there
> > is no real need to outsource link-monitoring to userspace anymore.
> 
> Hi Andy, how does this work for the hardware offload case?  I'm not
> seeing how hardware gets updated when the software route is updated.
> Seems hardware isn't updated and would send frames out the downed nh
> interface.

Scott, you are correct that this does not currently address the hardware
offload case.  If one wanted offloaded hardware to reflect this change,
then there needs to be either:

- The ability to communicate the flag changes down to offload devices in
  the event that they want some action to take place
  switchdev_fib_ipv4_modify(), maybe? (Not to derail this convo too much
  but it will soon be time to consider what to do at the switchdev layer
  when route flags are modified like when the RTNH_F_OFFLOAD flag is
  removed by the user if they feel the route does not need to be
  offloaded for any reason.)

- Register a register_netdevice_notifier and take action at the
  switchdev layer to make sure that routes can be removed or marked as
  inactive when link goes down.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html