On Tue, Jun 02, 2015 at 10:03:23PM -0700, Scott Feldman wrote: > On Tue, Jun 2, 2015 at 8:07 PM, Andy Gospodarek > <go...@cumulusnetworks.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
