Seb,
While sanity-testing the merged Cleaview IPMP bits, I stumbled on an
odd problem: in.mpathd repeatedly offlined all but one interface in the
group, stating:
Apr 25 03:34:59 whitestar1-2.East.Sun.COM in.mpathd[100049]: IP interface
ce0 has a hardware address which is not unique in group a; offlining
Some digging around revealed the problem: the Nevada DL_NOTE_PHYS_ADDR
mechanism has been expanded to also report changes to point-to-point
destination addresses via MAC_NOTE_DEST. Thus, when in.mpathd enables
DL_NOTIFY_INDs for DL_NOTE_PHYS_ADDR (via dlpi_enabnotify()), the
DL_NOTIFY_REQ leads to DL_NOTIFY_INDs being generated for both
DL_CURR_PHYS_ADDR and DL_CURR_DEST_ADDR (via dld_str_notify_ind()).
Further, the dlpi_notifyinfo_t generated for these two events by libdlpi
cannot be differentiated, as the dl_data information is lost in
translation. Thus, the DL_CURR_DEST_ADDR message looks like a
notification that the hardware address has become zero, leading to
in.mpathd believing that all interfaces have a hardware address of zero.
Needless to say, this needs some work. Minimally, it seems libdlpi needs
to be enhanced to allow callbacks to tell the difference between
DL_CURR_PHYS_ADDR and DL_CURR_DEST_ADDR. Going further, it's unclear to
me if there are consumers that care about both DL_CURR_PHYS_ADDR and
DL_CURR_DEST_ADDR. That is, does it make sense to have both of these
show up as DL_NOTE_PHYS_ADDR, or would it be better to have a new
DL_NOTE_DEST_ADDR message type? (With such a change, the libdlpi change
would no longer be mandatory, but would still probably be worthwhile.)
PS. Given that this needs to be resolved before the IPMP bits can be
used, I'm holding off on publishing new archives just yet.
--
meem
