crossbow discuss - Mar 2007 - Design for virtual switching with VNICs

Folks,

A first draft of the design document for virtual switching with VNICs  
is now available at:

http://www.opensolaris.org/os/project/crossbow/Docs/virtualswitch.pdf

This document will be part of the larger VNIC design document which  
I''m currently working on.

Enjoy,
Nicolas.

-- 
Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

Hi Nicholas,

So, why wouldn''t a person want to interact with a switch?

Managed switches seem to have a nice price premium over
unmanaged switches - is there a reason why we would choose
to not implement a ''managed switch'' or at least one that has
some sort of MIB support?  Or could that be a future project?

In the bullet points, you mention that broadcast packets from
a VNIC are sent to all other VNICs but no mention of them
being sent to the NIC?

I suppose I should ask, are you intending for there to be
anything special for the purposes of packet filtering or is
this something you feel should be handled by another
project (such as one to do layer 2 filtering) ?

With some physical switches today I can turn one port into
a "monitor port".  Do you see that as being part of the
forward evolution of the vswitch in Solaris?

Or to refine that feature, have you given any thought to
how packet sniffing would work with the vswitch?

On the whole, I like it...it seems quite decent and
straight forward design.

Darren

Hi Darren,

On Mar 28, 2007, at 7:13 PM, Darren.Reed at Sun.COM wrote:
> Hi Nicholas,
>
> So, why wouldn''t a person want to interact with a switch?
>
> Managed switches seem to have a nice price premium over
> unmanaged switches - is there a reason why we would choose
> to not implement a ''managed switch'' or at least one that
has
> some sort of MIB support?  Or could that be a future project?
The current design does not prevent this from being done as a future  
project, it''s simply not a goal right now.
> In the bullet points, you mention that broadcast packets from
> a VNIC are sent to all other VNICs but no mention of them
> being sent to the NIC?
That''s an omission in the document (the code does this :-) will add  
it to the bullet point.
>
> I suppose I should ask, are you intending for there to be
> anything special for the purposes of packet filtering or is
> this something you feel should be handled by another
> project (such as one to do layer 2 filtering) ?
The VNICs are layer 2 entities and currently depend on IP filter for  
filtering. There is also a need for layer 2 filtering where the  
global zone/dom0 wants to have control on the traffic allowed through  
a data-link assigned to a non-global zone/domain. This is something  
which should be addressed by a separate project. Such project is on  
the roadmap, it needs to be properly staffed for success, and of  
course kicked off on OpenSolaris :-)
> With some physical switches today I can turn one port into
> a "monitor port".  Do you see that as being part of the
> forward evolution of the vswitch in Solaris?
Yes absolutely, it''s something I''d like to see being added as
VNICs
evolve, however not as part of the initial release. I''ll make a note  
of it in the document.
> Or to refine that feature, have you given any thought to
> how packet sniffing would work with the vswitch?
Right now I see this controlled through an attribute of a VNIC. If  
that "monitor" attribute is set, the VNIC would receive all multicast
and unicast traffic going through the virtual switch. That traffic  
could then be picked up by the MAC clients of that VNIC (one of which  
could be snoop via dls.)
> On the whole, I like it...it seems quite decent and
> straight forward design.
Great! Thanks for the feedback.

Nicolas.
>
> Darren
>
-- 
Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

Hi
Nicolas,

This is great work. I like this doc. it has decent coverage that further 
enables me
to know more about it.

I picture, vswitching could particularly help zones-virtualization in 
case where -
we do application isolation using different zones and can further 
isolate it at L3 using
exclusive  ip instances and bound those zone with exclusive access to 
vnics and those
vnics can also further have IP address on different subnets.

afai understand, such configs currently require data traffic between 2 
non-global zone
in same box, to go on wire and then return interrupting cpu.
so, can such traffic be helped to stay inside box, by vswitch layer 
between vnics
that you are designing? if not scoped for this release, could it be in 
future releases?

regards,
-deepti

Nicolas Droux wrote:
> Folks,
>
> A first draft of the design document for virtual switching with VNICs 
> is now available at:
>
> http://www.opensolaris.org/os/project/crossbow/Docs/virtualswitch.pdf
>
> This document will be part of the larger VNIC design document which 
> I''m currently working on.
>
> Enjoy,
> Nicolas.
>
> --Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
> droux at sun.com - http://blogs.sun.com/droux
>
>
>
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss

Hi Deepti,

On Mar 28, 2007, at 10:41 PM, deepti dhokte wrote:
> I picture, vswitching could particularly help zones-virtualization  
> in case where -
> we do application isolation using different zones and can further  
> isolate it at L3 using
> exclusive  ip instances and bound those zone with exclusive access  
> to vnics and those
> vnics can also further have IP address on different subnets.
Yes, that''s one of the main goals. The VNICs can be configured to be  
on the same subnet as well in this case, BTW.
> afai understand, such configs currently require data traffic  
> between 2 non-global zone
> in same box, to go on wire and then return interrupting cpu.
> so, can such traffic be helped to stay inside box, by vswitch layer  
> between vnics
> that you are designing? if not scoped for this release, could it be  
> in future releases?
That is part of the core VNIC virtual switching functionality, as  
described by this document. BTW, that functionality is already in the  
project gate (except for the anchor VNICs which currently live in my  
workspace) and will be part of our initial putback to ONNV.

Thanks,
Nicolas.

-- 
Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

Nicolas Droux wrote:
> A first draft of the design document for virtual switching with VNICs is 
> now available at:
> 
> http://www.opensolaris.org/os/project/crossbow/Docs/virtualswitch.pdf
Nicolas, this is great, thanks!

To what extent do anchor VNICs continue to behave as normal MAC 
providers?  For example, what will happen if I attempt to open one using 
a DLPI application or plumb it under IP?

Similarly, what is the right way to snoop all of the packets flowing 
through the switch - would I do that by putting a member VNIC in 
promiscuous mode or is there something else?

dme.

David,

David Edmondson wrote:
> Nicolas Droux wrote:
>> A first draft of the design document for virtual switching with VNICs 
>> is now available at:
>>
>> http://www.opensolaris.org/os/project/crossbow/Docs/virtualswitch.pdf
> 
> Nicolas, this is great, thanks!
Thanks.
> 
> To what extent do anchor VNICs continue to behave as normal MAC 
> providers?  For example, what will happen if I attempt to open one using 
> a DLPI application or plumb it under IP?
You can access them through DLPI, but since they don''t have any
hardware
underneath, they are of limited use when used this way. The scenario 
where this is useful is for snooping, which brings us to your other 
question...
> Similarly, what is the right way to snoop all of the packets flowing 
> through the switch - would I do that by putting a member VNIC in 
> promiscuous mode or is there something else?
Snooping on the underlying NIC will show all the inbound and outbound 
traffic going through that NIC (none for leaf VNICs), plus the traffic 
exchanged between the VNICs defined on top of that NIC. This is similar 
to snooping on the monitoring port of a physical switch. Individual 
VNICs will see only the multicast and unicast traffic they ought to 
receive. In the future we could provide an option to enable monitoring 
on individual VNICs.

Nicolas.
> 
> dme.
-- 
Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

Nicolas Droux wrote:
> In the future we could provide an option to enable monitoring 
> on individual VNICs.
Given that the VNICs may be "given away" to non-global zones, it would
be best if this were not enabled by default. The "snoop on the 
underlying NIC" approach seems good to me.

dme.

David Edmondson wrote:
> Nicolas Droux wrote:
>> In the future we could provide an option to enable monitoring on 
>> individual VNICs.
> 
> Given that the VNICs may be "given away" to non-global zones, it
would
> be best if this were not enabled by default. 
Absolutely, that''s the plan.

Nicolas.

-- 
Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux