Peter Memishian wrote:
As another example, with current Fishworks bits we need the clustering failover between nodes to be as efficient and simple as possible. Right now that's done by configuring both nodes with identical configurations, except that half of the addresses on one node are IFF_UP on one node, and half are IFF_UP on the other node. When one node fails and the other takes over, the act of "importing" those addresses to the surviving node does the IFF_UP. If the surviving node instead needs to do all of the configuration in addition to setting the IFF_UP this will add significant complexity to the state replication model between nodes and to the actual act of failing over.
I trying to categorize the reasons for this, and I see three unless I'm misreading.
1. The assumption that a SIOCSLIFFLAGS with IFF_UP for a logical interface is faster/more efficient than a SIOCSLIFADDIF. (Which I doubt is the case.) Perhaps the performance reason is about avoiding to dig through the SMF repo to find the information before passing it to SIOCSLIFADDIF?
2. The convenience of using the kernel as a repository for inactive information. I don't know how far we want to push in that direction.
3. The fact that services that do failover (Oracle might be another one) have gotten used to doing #2 for IP addresses and being able to enable and disable those IP addresses separately.
The third one might be a suffficient reason to add an optional ipadm enable-address/disable-address, and some corresponding status (a "disabled" status).
Note however that enabled/disabled is an administrative notion has in my mind it has nothing to do with recovering from DAD failures!
Initial ipadm implementation can presumably use the overloaded IFF_UP too represent this in the kernel, but we should move away from that.
I suspect the kernel needs some work before we fully endorse the disable-address. For instance, today IPv6 assumes that the link-local lives on :0, but what happens when :0 is disabled? (I guess some kernel code just blasts along using that disabled address.)
Erik _______________________________________________ networking-discuss mailing list [email protected]
