Peter Memishian writes: > > > Seems like a good precaution. My biggest concern when looking at this > > is for applications that expect the name obtained from > > if_indextoname() to be that of a physical device. One example in ON is > > ifconfig when it's dealing with usesrc. So in a zone: > > Presumably "physical interface" is meant above -- the name may have no > correlation to a physical device (e.g., an IPMP IP interface). But more > broadly, the expectation you state above seems quite reasonable, as an > index identifies a physical interface, not a logical interface. I wonder > if the cure is worse than the disease here.
It seems like a limited enough case that we could just wink at it. After thinking about this for a bit, the situation is limited just to shared IP stack non-global zones. The translation mechanism isn't wanted or needed for the global zone or for any exclusive IP stack non-global zone. The "winking" would consist of behaving as though all logical interfaces put into a shared IP stack non-global zone are actually physical interfaces that happen to have slightly funny names. We'd report them the same way and (to the extent possible) try to include them in the games that physical interfaces play (such as routing socket messages). For bonus points, we could still fix up the interface naming for the limited case of non-global zones and remove the ugly ":N" stuff from the API, as it seems to be a sore point among some users. But since the folks who support this code seem to assert that we're slowly moving away from shared IP stack non-global zones, perhaps it doesn't matter enough to bother. (I'm not sure how this would interact with branding. That is something to think about ...) The other solution, as I think you're suggesting, is to do nothing. Again, if we assume that the move away from shared IP stack zones is a committed direction for the networking community and one that substantially all of our customers/users agree with, then you might be right that we shouldn't try to fix the problem. (This question gets back to the original design center for Kevlar, which was to be able to aggregate multiple systems on the same network, similar to BSD Jails, and *NOT* going anywhere near as far as Xen, VMWare, or other such strict isolation schemes. Think "100 customer-owned public web servers" instead of "finance and HR on separate networks." Andy Tucker was quite clear on the functional space that was being filled, and why it was important to distinguish from the other possible products. I still think that if we're saying that shared IP stack is not important, then we're saying that the original design center doesn't hold, and it's worth looking at whether we're polishing something that's really just a pale copy of a better product, and if we couldn't do better by pouring more effort into one solution.) -- James Carlson, Solaris Networking <[email protected]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
