Peter Memishian writes: > > > Stepping back for a moment, I think that, though it was implemented > > within IP itself, IPMP was originally intended to protect against > > physical interface failure primarily and switch path to "the default > > router" as a second issue. Instead of trying to define how to run > > IPMP on virtual interfaces, and dealing with the confusion and broken > > programming interfaces that result, I think we should be looking at > > means to allow IPMP-like fail-over between the physical interfaces > > used by VNICs and some sort of common probing mechanism for those who > > need the switch path protection feature. > > I know you said "IPMP-like", but with respect to making IPMP do this, one > challenge is that the set of VNICs -- rather than the physical devices > they're atop -- define the precise set of hardware addresses that may be > tied to the IP addresses in the group. So, while the new IPMP model stops > hosting the IP addresses on the IP interfaces in the group, the IP > interfaces in the group still are important since they reflect the set of > available hardware addresses.
I don't think that's a significant barrier, because the underlying physical interfaces themselves will have addresses. There's certainly the potential for a bit of confusion with some VNICs borrowing those 'real' MAC addresses and others using ones of their own devising, but I don't think that really addresses the problem that the part being protected has different assumptions in the two cases. The inbound load-spreading aspect of shuffling IP addresses among MAC addresses, though, might be an interesting problem. I just don't want to see us rush into supporting IPMP on VNICs and then discover later that it has either strange deployment artifacts or unsolvable bugs. We've been bitten before. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
