[Jumping back to the start ...]
Peter Memishian writes:
> However, in the common case with e.g. two interfaces together in an IPMP
> group that has DHCP data addresses, when the group fails, the IPMP IP
> interface's IFF_RUNNING flag will be cleared and thus its routes removed
> by dhcpagent. At that point, if probe-based failure detection is enabled,
> in.mpathd will fallback to multicast targets. For sites configured not to
I did some thinking after talking with meem about this yesterday, and
it seems to me that there are at least two distinct issues that are
somewhat related:
1. IPMP needs to have a list of "desirable probe targets" for each
subnet on which it's running probes. That probably doesn't have
to be just the output of "netstat -nr -f inet -f flags:+G" --
in.mpathd could keep around a cache of "known router-like
entities," and perhaps even allow manual configuration of the
list (rather than relying on the obscure host-route hack). But
it'd be nice to minimize the amount of extra redesign here.
2. There are sometimes lingering, invisible routes in the table
that pose a system administration hazard. For example, if I do
this:
ifconfig nge0 10.0.0.1/24 broadcast + up
route add 11.0/24 10.0.0.2 -ifp nge0
I'll get a static route in the table. If I take nge0 down with
"ifconfig nge0 down", the route goes away. If I bring nge0 back
up, it mysteriously comes back. What's worse is that while nge0
is down, I can't get rid of that hidden route without just
unplumbing, and unless I just happen to "know" that it's there,
it'll surprise me by its return -- there's no way to view such
routes other than dumping kernel structures with mdb.
_Perhaps_ that's an argument for allowing routes to exist in another
state -- "down." A "down" route doesn't participate in forwarding,
and isn't returned for RTM_GET, but does exist in the table if the
interface it would use is either down or not running.
Perhaps. It means rework and some *very* careful thought for routing
protocols, but I think it could be done. (For example, aggregation
would be affected by this. If you aggregate a long prefix route into
a lower metric shorter prefix route, then the longer one won't be in
the table, and having the shorter one fail on its own would leave the
longer one unreachable. You'd have to change things so that the
shorter one isn't deleted on ~IFF_RUNNING, but the longer one *is*
added.)
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
