crossbow discuss - Feb 2007 - Re: crossbow vnics...

David Edmondson wrote On 02/11/07 11:01 PM,:
>* Darren.Reed at Sun.COM [2007-02-12 00:16:07]
>  
>
>>Can I change which physical interface a VNIC is backed by without
>>destroying/unpluming it?
>>    
>>
>
>That''s not possible today.  It''s not on the feature list
for Nevada
>putback either.
>  
>
yep.
thus far, the physical NIC has been viewed as a defining property of the 
VNIC,
and, unlike other attributes, don''t change.

Now with Clearview link vanity naming, one could consider associating 
the bandwidth,
MAC address, etc ...) attributes to the user-chosen link name, and not
the underlying MAC (phys. or virt.) device.
In that case, when the name is re-assigned to a different MAC thing, it 
is intuitive that the attributes
follow.
But then, if we view the link name as just an alias for the link, then 
none of the attributes would be
carried forward when the name is reassigned to designate another link.

A similar question could actually be asked about other components that 
use the link name,
such as IPsec policies, or IPFiler rules.

    Kais.
>dme.
>  
>
(text of original question from Darren Reed)
Darren.Reed at sun.com wrote On 02/11/07 04:16 PM,:
> Can I change which physical interface a VNIC is backed by
> without destroying/unpluming it?
>
> If I can do that and I change the physical interface a VNIC is
> backed by, do all of the resource controls (descriptors, bandwidth
> limits, etc) carry forward or do they need to be re-established?

Kais Belgaied wrote:
> David Edmondson wrote On 02/11/07 11:01 PM,:
>
>> * Darren.Reed at Sun.COM [2007-02-12 00:16:07]
>>
>>> Can I change which physical interface a VNIC is backed by without
>>> destroying/unpluming it?
>>>   
>>
>>
>> That''s not possible today.  It''s not on the feature
list for Nevada
>> putback either.
>>  
>>
>
> yep.
> thus far, the physical NIC has been viewed as a defining property of 
> the VNIC,
> and, unlike other attributes, don''t change.
>
> Now with Clearview link vanity naming, one could consider associating 
> the bandwidth,
> MAC address, etc ...) attributes to the user-chosen link name, and not
> the underlying MAC (phys. or virt.) device.
> In that case, when the name is re-assigned to a different MAC thing, 
> it is intuitive that the attributes
> follow.
> But then, if we view the link name as just an alias for the link, then 
> none of the attributes would be
> carried forward when the name is reassigned to designate another link.

I think you see the problem - two names, one device.
Which one to use and which one will people expect to be used?

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?
> A similar question could actually be asked about other components that 
> use the link name,
> such as IPsec policies, or IPFiler rules.

Vanity naming should automatically activate/deactivate IP Filter
rules that have matching IP interface names that appear/disappear.

Bugs notwithstanding, IP Filter has always supported filter rules
containing names for interfaces that are not present and turning
them "on"/"off" as the come and go.

I can load "pass in on kais0 ..." because even if kais0
does not exist now, at some point in the future, it may...
What about typos/finger mistakes (ie having beg0 and not
bge0)?  Can''t save users from themselves >:-)

Darren

> 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