> Can we define the vnic by its ethernet address and not mention > the link name, so that if the card moves slots, then the resource > definition(s) will follow the card?
Yuck. Ethernet addresses are unmemorable and reflect an implementation detail rather than intent. Also, if a card dies and you need to swap it with a new one, you shouldn't have to recreate your network configuration. This is one of the problems that vanity naming is designed to solve -- just swap in a new card, give it the same linkname, and drive on. > Vanity naming should automatically activate/deactivate IP Filter > rules that have matching IP interface names that appear/disappear. No, it shouldn't. As covered in the Vanity Naming architectural document, the design center of Vanity Naming is to isolate the system's network configuration from underlying changes in the networking hardware and topology -- e.g., seamless replacement of a bge card with an rge card, seamless upgrade to link aggregation -- by preserving the link name. Using vanity naming to *cause* changes in network configuration (rather than to isolate the system from changes) is not a design center precisely because it's not dladm's responsibility or architectural place to concern itself with updating non-link-layer network configuration when a rename occurs. That's the job of layered software -- e.g., something like NWAM could do that, and it would use dladm as part of its solution. Again, all of this is covered in the PSARC inception materials, along with many other important issues. -- meem
