While testing the Clearview IPMP DHCP support, I came across an
interesting corner case: if one uses DHCP to obtain a test address on an
interface, and then uses if_mpadm(1M) to offline the interface, if_mpadm
will bring the test address down since (per the definition of offline),
offline interfaces cannot be used to send or receive packets (even probe
traffic).  Bringing the address down triggers the "abandon" logic in the
DHCP client to trigger (since it assumes the admin is messing with the
interface) and thus the DHCP client drops the lease.  This lease is never
restored when the interface is brought back online.

Exploring this a bit, one plausible way to address this would be to change
the DHCP client to not do anything special when the address is brought
down, but instead wait for an actual change to the address (it already
does this as well).  Thus, even if the address is down, the DHCP client
would continue to maintain the lease.  If it is unable to do so (e.g.,
because all the addresses on the interface are down), then the lease would
expire naturally and the client would drop the lease then.  In the case of
DHCP-acquired test addresses, we'll generally recommend[1] use of infinite
leases, so this would be sufficient to address the if_mpadm problem.

So this all seems OK, but in dhcpagent(1M), we state:

     For IPv4,  if  the  configured  interface  is  found  to  be
     unplumbed,  marked  down, or to have a different IP address,
                 ^^^^^^^^^^^^
     subnet mask, or broadcast address from those  obtained  from
     DHCP, the interface is abandoned by DHCP control.

... and in general the interface stability of the manpage is listed as
"committed".  Given that DHCP has never worked with IPMP, we are free to
define new semantics for IPMP, but I think changing this generally makes
sense and would prefer not to introduce more IPMP-specific logic than
necessary.  However, strictly speaking, a general change would break
compatibility (though it's not clear to me anyone would have been relying
on the old behavior).

Thoughts?

[1] We'll recommend infinite leases since otherwise if the test addresses
    expire during a group failure, in.mpathd will revert to link-based
    failure detection and thus possibly trigger erroneous interface
    recovery.  Raoul: we'll want to document this.

-- 
meem

Reply via email to