|
Description
|
The fix for 4838049 added the following code to ip_rts.c:
ipif = ill->ill_ipif;
+ /*
+ * If this is replacement ipif, prevent a route from
+ * being added.
+ */
+ if (ipif->ipif_replace_zero) {
+ error = ENETDOWN;
+ goto bad;
+ }
match_flags |= MATCH_IRE_ILL;
Simply put, this code is bogus, for several reasons:
1. Unlike IFF_UP, the administrator or program has no direct
control over whether an interface has failed and thus is
being backed by a replacement ipif. Thus, they have no
control over whether the call to add a route will fail, and
no recourse if it does.
2. When an interface is in an IPMP group, adding a route for
an interface is the same as adding a route for *any* interface
in the group. Thus, if one interface has failed, we should
attempt to add the route to another (functioning) interface
in the group.
3. Even if there are no functioning interfaces in the group, the
route should still be added, since that's consistent with our
behavior in the non-IPMP case. That is, if an interface is
not in a group but has IFF_RUNNING cleared (e.g., because a
cable was pulled), you can still add a route out of it. Why
should it be any different with IPMP?
Thus while the original fix addresses the panic, I do not think it is
correct.
|
