[libvirt] [PATCHv2] Configure native vlan modes on Open vSwitch ports

[james robson]

On Tue, 2013-04-23 at 12:13 -0400, Laine Stump wrote:


> >>>
> >>>> Also, is it valid to have a native_mode/native_tag if trunk='no'? (right
> >>>> now trunk is automatically set to 'yes' if there is more than one vlan tag)
> >>> It isn't valid to have trunk='no' and the native settings. Therefore
> >>> "<vlan trunk='no' native_mode='tagged' native_tag='123'>" will get an
> >>> error if you try to enter it. 
> >>> If no "trunk" attribute is set explicitly then it will be set to 'yes'.
> >>> This means "<vlan native_mode='tagged' native_tag='123'>" is equivalent
> >>> to "<vlan trunk='yes' native_mode='tagged' native_tag='123'>".
> >> Likewise, if you have more than one <id tag='x'/> element, trunk will
> >> automatically be set to yes.
> >>
> >> So in the end, if you don't foresee any problems with it, I think I do
> >> prefer this:
> >>
> >>    <vlan trunk='yes'>
> >>      <tag id='123' native='yes|no'/> (default is 'no', only one allowed to be yes)
> >>      <tag id='555'/>
> >>      <tag id='444'/>
> >>    </vlan>
> > The only problem with that proposal is that there is no way to set the
> > mode to be 'tagged' or 'untagged'.
> 
> Ah. I had inferred from the discussion that (unlike what I'd originally
> assumed) there was only an off or an on. What does it mean to have 
> "tagged" native mode? I thought the purpose of native was to designate a
> tag that, when encountered on a packet, would be stripped from the
> packet before forwarding; is "tagged" intended to say "when you get an
> untagged packet to send out this port, tag it with this id", and
> "untagged" intended to mean "when you get a packet to send out this port
> that is tagged with id='x', untag it before forwarding it"?

Taking from the Open vSwitch documentation on this (specifically 'man
ovs-vswitchd.conf.db'):
    * native-tagged
      A native-tagged port resembles a trunk port, with the exception
that a packet without an 802.1Q header that ingresses on a native-tagged
port is in the ‘‘native VLAN’’ (specified in the tag column).

    * native-untagged
      A native-untagged port resembles a native-tagged port, with the
exception that a packet that egresses on a native-untagged port in the
native VLAN will not have an 802.1Q header.

The 'native-untagged' mode means that if a packet ingresses without a
vlan tag it gets put on the native vlan, and any packet on the native
vlan has the vlan header removed before it egresses the port. This
replicates the behaviour of the physical switches that I have
encountered with native vlan settings on a trunked port.

The native-tagged mode means that a packet on the native vlan does not
have the header striped before it egresses. So if an interface connected
to a native-tagged port sends a packet without a vlan header, it gets
put on the native vlan, but the response received by the will still have
the vlan header set to the native vlan's id. This behaviour seems a very
strange to me, but open vswitch supports it so seems reasonable to be
able to configure it through libvirt.

> 
> >  What about the following:
> >   <vlan trunk='yes'>
> >     <tag id='123' nativeMode='tagged|untagged|none'/> (default is none)
> >     ...
> >  </vlan>
> >
> > I think nativeMode would be more appropriate than simply 'native' for
> > choosing between tagged or untagged, because it more descriptive. 
> 
> 
> 
> Especially if you think there might be other "native-related" attributes
> later. Even if not, I don't see a problem with this naming.
> 
> 
> 
> >> Note that we'll be going into freeze for 1.0.5 soon, so if you are able
> >> to rework the patch within the next couple days, it should go into
> >> libvirt-1.0.5 (which *might* end up in Fedora 19?)
> > If nothing major goes wrong I should have this done before Friday.
> 
> 
> Okay. Sounds like DV is planning to freeze on Friday (which is very late
> Thursday night for most of us), so it would be good if there was some
> time for review before then.
> 
> 
>  To report this as spam, please forward to spam at websense.com.  Thank you.




 Protected by Websense Hosted Email Security -- www.websense.com