On 06/11/2015 04:23 AM, Andy Gospodarek wrote:
On Wed, Jun 10, 2015 at 11:07:28PM -0700, Scott Feldman wrote:
On Wed, Jun 10, 2015 at 7:37 PM, Andy Gospodarek
<go...@cumulusnetworks.com> wrote:
Add a fib flag called RTNH_F_LINKDOWN to any ipv4 nexthops that are
reachable via an interface where carrier is off. No action is taken,
but additional flags are passed to userspace to indicate carrier status.
Andy, it seems now RTNH_F_LINKDOWN and RTNH_F_DEAD are very similar
and I'm wondering if this could be done without introducing a new flag
and just use RTNH_F_DEAD. The link change event would set RTNH_F_DEAD
on nh on dev link down, and clear on link up. The sysctl knob would
be something like "nexthop_dead_on_linkdown", default off. So
basically expanding the ways RTNH_F_DEAD can be set. That would
simplify the patch set quite a bit and require no changes to iproute2.
You are absolutely correct that what you describe would be less churn to
userspace. From a functionality standpoint that is close to what was
originally proposed, but Alex specifically did not like the behavioral
change to what having RTNH_F_DEAD set (at least that was what I
understood).
That was what made me make the move to add this additional flag that was
exported to userspace, so it was possible to differentiate the old dead
routes/nexthop functionality from those that were not going to be dead
due to link being down.
this point I think I prefer the additional data provided by the new
flag exported to userspace.
I preferred the 2 flag solution as the original solution still required
2 flags, it just only exposed 1 to user-space. As a result it was much
more error prone since it was fairly easy to get into a confused state
about why the link was dead.
With the 2 flag solution it becomes much easier to sort out why the
route is not functional and it is much easier to isolate for things like
the sysctl which only disables the use of LINKDOWN and not DEAD.
- Alex
--
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
