> > Yes, that was something that crossed my mind too. However, > > if we are going to allow some of these settings from ipadm > > (e.g., the nofailover flag), then in the interest of being > > symmetric, it would be nice to have some basic information > > displayed in the corresponding ipadm show-* sub-command. > > I'd be tempted to draw the line at the flags, otherwise you're on > a slipperly slope whereby future work on IPMP needs to be done > on both tools. > > If this were to be remodeled, would things like the nofailover flag > be a part of the generic flags for an interface or would they belong > in a sub structure/field that was owned by IPMP?
To be clear, the IFF_NOFAILOVER flag is an address flag, not an interface flag. The name is a remnant from the old model that we got stuck with; it should really be IFF_TESTADDR since it indicates that the address is only for use in sending and receiving ICMP probes via in.mpathd. Nonetheless, the address belongs in ipadm/ifconfig because it is one of the IP addresses the system will recognize as its own. However, it needs to be specially marked (ideally in a manner more obvious than IFF_NOFAILOVER is) that the IP address is not suitable for general use. There are no other IPMP things like the IFF_NOFAILOVER flag; all other IPMP-specific flags are phyint flags. More generally, IPMP is a core part of IP and should be managed via ipadm, in the same manner that link aggregation is a core part of L2 and managed via dladm. One of the advantages of the new IPMP model is that each group has its own IP interface and thus any per-group properties can be administered as IP properties on that group's IPMP IP interface -- and indeed, we intentionally avoided creating ipmpadm since the plan was for ipadm to fill this need. -- meem
