Re: [libvirt] [PATCHv2] Configure native vlan modes on Open vSwitch ports
Date: Thu, 18 Apr 2013 14:14:32 -0400 From: Laine Stump <laine@laine.org> To: libvir-list@redhat.com Subject: Re: [libvirt] [PATCHv2] Configure native vlan modes on Open vSwitch ports Message-ID: <51703808.2000504@laine.org> Content-Type: text/plain; charset=ISO-8859-1
On 04/18/2013 01:44 PM, james robson wrote:
Hello, Has any one been able to review this yet? I realise that the 'Since 1.0.3' in the doc page is now out of date, but is the code itself acceptable?
I was hoping that someone with more knowledge of Open vSwitch and/or vlan tagging/trunking/native mode would repond to the message (Kyle?) but there was silence instead...
diff --git a/tests/networkxml2xmlin/openvswitch-net.xml b/tests/networkxml2xmlin/openvswitch-net.xml index a3d82b1..93c49d5 100644 --- a/tests/networkxml2xmlin/openvswitch-net.xml +++ b/tests/networkxml2xmlin/openvswitch-net.xml @@ -21,4 +21,13 @@ <parameters profileid='alice-profile'/> </virtualport> </portgroup> + <portgroup name='tagged'> + <vlan native_mode='tagged' native_tag='123'> + <tag id='555'/> + <tag id='444'/> + </vlan> + <virtualport> + <parameters profileid='tagged-profile'/> + </virtualport> + </portgroup>
As brought up again in a separate conversation today, we prefer to use camelCase rather than underscored in attribute and element names. So, if we were to use the layout you're proposing, the attributes should be called "nativeMode" and "nativeTag".
However, I'm wondering if there might be a better way to structure it. What about this?
<vlan trunk='yes'> <tag id='123' native='tagged|untagged'/> (or whatever values are appropriate) <tag id='555'/> <tag id='444'/> </vlan>
Do I understand correctly that native mode is telling what to do with packets that come in untagged, and that (using your nomenclature "native_mode='yes' native_tag='123'" means "when an untagged packet come in from this interface, it should be tagged as 123 before forwarding"?
That is correct, setting the native vlan changes how an untagged packet is handled when it enters the port. The difference between the 'tagged' and 'untagged' modes is in how packets on the native vlan are processed before exiting the port.
And what happens when native_mode='yes' but there is no native_tag?
In that case you configuration is invalid, and will get an error.
(that's what I was trying to describe with <tag id='123' native='untagged'/>, but I don't even know if that makes sense, because I don't know exactly what is the native vlan tag and what is done with it :-)
That arrangement would make sense, I chose the arrangement I did for two main reasons. There can only be one native vlan on a port, making it an attribute of the 'vlan' tag enforces this. Also, I wanted to keep the validation and processing separate rather than add 'if native' branches to the loops that operate on the vlan id list. I can see the advantage of having a single setting to configure the native vlan, rather than the two attributes I proposed. If the new suggestion is preferred I can rework my patch to use that format.
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'>".
</network> diff --git a/tests/networkxml2xmlout/openvswitch-net.xml b/tests/networkxml2xmlout/openvswitch-net.xml index a3d82b1..ab3d797 100644 --- a/tests/networkxml2xmlout/openvswitch-net.xml +++ b/tests/networkxml2xmlout/openvswitch-net.xml @@ -21,4 +21,13 @@ <parameters profileid='alice-profile'/> </virtualport> </portgroup> + <portgroup name='tagged'> + <vlan trunk='yes' native_mode='tagged' native_tag='123'> + <tag id='555'/> + <tag id='444'/> + </vlan> + <virtualport> + <parameters profileid='tagged-profile'/> + </virtualport> + </portgroup> </network>
Protected by Websense Hosted Email Security -- www.websense.com
(I'm not sure what you did differently when you sent this mail, but somehow your mailer botched the "In-Reply-To:" header, which broke the threaded display in Thunderbird. No big deal, but I thought you might want to know.) On 04/22/2013 12:51 PM, james robson wrote:
Date: Thu, 18 Apr 2013 14:14:32 -0400 From: Laine Stump <laine@laine.org> To: libvir-list@redhat.com Subject: Re: [libvirt] [PATCHv2] Configure native vlan modes on Open vSwitch ports Message-ID: <51703808.2000504@laine.org> Content-Type: text/plain; charset=ISO-8859-1
On 04/18/2013 01:44 PM, james robson wrote:
Hello, Has any one been able to review this yet? I realise that the 'Since 1.0.3' in the doc page is now out of date, but is the code itself acceptable? I was hoping that someone with more knowledge of Open vSwitch and/or vlan tagging/trunking/native mode would repond to the message (Kyle?) but there was silence instead...
diff --git a/tests/networkxml2xmlin/openvswitch-net.xml b/tests/networkxml2xmlin/openvswitch-net.xml index a3d82b1..93c49d5 100644 --- a/tests/networkxml2xmlin/openvswitch-net.xml +++ b/tests/networkxml2xmlin/openvswitch-net.xml @@ -21,4 +21,13 @@ <parameters profileid='alice-profile'/> </virtualport> </portgroup> + <portgroup name='tagged'> + <vlan native_mode='tagged' native_tag='123'> + <tag id='555'/> + <tag id='444'/> + </vlan> + <virtualport> + <parameters profileid='tagged-profile'/> + </virtualport> + </portgroup>
As brought up again in a separate conversation today, we prefer to use camelCase rather than underscored in attribute and element names. So, if we were to use the layout you're proposing, the attributes should be called "nativeMode" and "nativeTag".
However, I'm wondering if there might be a better way to structure it. What about this?
<vlan trunk='yes'> <tag id='123' native='tagged|untagged'/> (or whatever values are appropriate)
Sounds like this can be "native='yes'", since there is only the possiblity of a tag being the native tag, or *not* being the native tag.
<tag id='555'/> <tag id='444'/> </vlan>
Do I understand correctly that native mode is telling what to do with packets that come in untagged, and that (using your nomenclature "native_mode='yes' native_tag='123'" means "when an untagged packet come in from this interface, it should be tagged as 123 before forwarding"?
That is correct, setting the native vlan changes how an untagged packet is handled when it enters the port. The difference between the 'tagged' and 'untagged' modes is in how packets on the native vlan are processed before exiting the port.
And what happens when native_mode='yes' but there is no native_tag? In that case you configuration is invalid, and will get an error.
Okay, then doing the config the way I suggest would eliminate that possibility, so it has an upside :-)
(that's what I was trying to describe with <tag id='123' native='untagged'/>, but I don't even know if that makes sense, because I don't know exactly what is the native vlan tag and what is done with it :-) That arrangement would make sense, I chose the arrangement I did for two main reasons. There can only be one native vlan on a port, making it an attribute of the 'vlan' tag enforces this. Also, I wanted to keep the validation and processing separate rather than add 'if native' branches to the loops that operate on the vlan id list. I can see the advantage of having a single setting to configure the native vlan, rather than the two attributes I proposed. If the new suggestion is preferred I can rework my patch to use that format.
I think it's simpler, to do it that way, yes.
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> 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?)
(I'm not sure what you did differently when you sent this mail, but somehow your mailer botched the "In-Reply-To:" header, which broke the threaded display in Thunderbird. No big deal, but I thought you might want to know.) I expect this was a side affect of getting the digest emails from the
On Mon, 2013-04-22 at 17:08 -0400, Laine Stump wrote: list.
On 04/22/2013 12:51 PM, james robson wrote:
Date: Thu, 18 Apr 2013 14:14:32 -0400 From: Laine Stump <laine@laine.org> To: libvir-list@redhat.com Subject: Re: [libvirt] [PATCHv2] Configure native vlan modes on Open vSwitch ports Message-ID: <51703808.2000504@laine.org> Content-Type: text/plain; charset=ISO-8859-1
On 04/18/2013 01:44 PM, james robson wrote:
Hello, Has any one been able to review this yet? I realise that the 'Since 1.0.3' in the doc page is now out of date, but is the code itself acceptable? I was hoping that someone with more knowledge of Open vSwitch and/or vlan tagging/trunking/native mode would repond to the message (Kyle?) but there was silence instead...
diff --git a/tests/networkxml2xmlin/openvswitch-net.xml b/tests/networkxml2xmlin/openvswitch-net.xml index a3d82b1..93c49d5 100644 --- a/tests/networkxml2xmlin/openvswitch-net.xml +++ b/tests/networkxml2xmlin/openvswitch-net.xml @@ -21,4 +21,13 @@ <parameters profileid='alice-profile'/> </virtualport> </portgroup> + <portgroup name='tagged'> + <vlan native_mode='tagged' native_tag='123'> + <tag id='555'/> + <tag id='444'/> + </vlan> + <virtualport> + <parameters profileid='tagged-profile'/> + </virtualport> + </portgroup>
As brought up again in a separate conversation today, we prefer to use camelCase rather than underscored in attribute and element names. So, if we were to use the layout you're proposing, the attributes should be called "nativeMode" and "nativeTag".
However, I'm wondering if there might be a better way to structure it. What about this?
<vlan trunk='yes'> <tag id='123' native='tagged|untagged'/> (or whatever values are appropriate)
Sounds like this can be "native='yes'", since there is only the possiblity of a tag being the native tag, or *not* being the native tag.
<tag id='555'/> <tag id='444'/> </vlan>
Do I understand correctly that native mode is telling what to do with packets that come in untagged, and that (using your nomenclature "native_mode='yes' native_tag='123'" means "when an untagged packet come in from this interface, it should be tagged as 123 before forwarding"?
That is correct, setting the native vlan changes how an untagged packet is handled when it enters the port. The difference between the 'tagged' and 'untagged' modes is in how packets on the native vlan are processed before exiting the port.
And what happens when native_mode='yes' but there is no native_tag? In that case you configuration is invalid, and will get an error.
Okay, then doing the config the way I suggest would eliminate that possibility, so it has an upside :-)
(that's what I was trying to describe with <tag id='123' native='untagged'/>, but I don't even know if that makes sense, because I don't know exactly what is the native vlan tag and what is done with it :-) That arrangement would make sense, I chose the arrangement I did for two main reasons. There can only be one native vlan on a port, making it an attribute of the 'vlan' tag enforces this. Also, I wanted to keep the validation and processing separate rather than add 'if native' branches to the loops that operate on the vlan id list. I can see the advantage of having a single setting to configure the native vlan, rather than the two attributes I proposed. If the new suggestion is preferred I can rework my patch to use that format.
I think it's simpler, to do it that way, yes.
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'. 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.
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. Protected by Websense Hosted Email Security -- www.websense.com
On 04/23/2013 11:37 AM, james robson wrote:
(I'm not sure what you did differently when you sent this mail, but somehow your mailer botched the "In-Reply-To:" header, which broke the threaded display in Thunderbird. No big deal, but I thought you might want to know.) I expect this was a side affect of getting the digest emails from the
On Mon, 2013-04-22 at 17:08 -0400, Laine Stump wrote: list.
On 04/22/2013 12:51 PM, james robson wrote:
Date: Thu, 18 Apr 2013 14:14:32 -0400 From: Laine Stump <laine@laine.org> To: libvir-list@redhat.com Subject: Re: [libvirt] [PATCHv2] Configure native vlan modes on Open vSwitch ports Message-ID: <51703808.2000504@laine.org> Content-Type: text/plain; charset=ISO-8859-1
On 04/18/2013 01:44 PM, james robson wrote:
Hello, Has any one been able to review this yet? I realise that the 'Since 1.0.3' in the doc page is now out of date, but is the code itself acceptable? I was hoping that someone with more knowledge of Open vSwitch and/or vlan tagging/trunking/native mode would repond to the message (Kyle?) but there was silence instead...
diff --git a/tests/networkxml2xmlin/openvswitch-net.xml b/tests/networkxml2xmlin/openvswitch-net.xml index a3d82b1..93c49d5 100644 --- a/tests/networkxml2xmlin/openvswitch-net.xml +++ b/tests/networkxml2xmlin/openvswitch-net.xml @@ -21,4 +21,13 @@ <parameters profileid='alice-profile'/> </virtualport> </portgroup> + <portgroup name='tagged'> + <vlan native_mode='tagged' native_tag='123'> + <tag id='555'/> + <tag id='444'/> + </vlan> + <virtualport> + <parameters profileid='tagged-profile'/> + </virtualport> + </portgroup> As brought up again in a separate conversation today, we prefer to use camelCase rather than underscored in attribute and element names. So, if we were to use the layout you're proposing, the attributes should be called "nativeMode" and "nativeTag".
However, I'm wondering if there might be a better way to structure it. What about this?
<vlan trunk='yes'> <tag id='123' native='tagged|untagged'/> (or whatever values are appropriate)
Sounds like this can be "native='yes'", since there is only the possiblity of a tag being the native tag, or *not* being the native tag.
<tag id='555'/> <tag id='444'/> </vlan>
Do I understand correctly that native mode is telling what to do with packets that come in untagged, and that (using your nomenclature "native_mode='yes' native_tag='123'" means "when an untagged packet come in from this interface, it should be tagged as 123 before forwarding"?
That is correct, setting the native vlan changes how an untagged packet is handled when it enters the port. The difference between the 'tagged' and 'untagged' modes is in how packets on the native vlan are processed before exiting the port.
And what happens when native_mode='yes' but there is no native_tag? In that case you configuration is invalid, and will get an error.
Okay, then doing the config the way I suggest would eliminate that possibility, so it has an upside :-)
(that's what I was trying to describe with <tag id='123' native='untagged'/>, but I don't even know if that makes sense, because I don't know exactly what is the native vlan tag and what is done with it :-) That arrangement would make sense, I chose the arrangement I did for two main reasons. There can only be one native vlan on a port, making it an attribute of the 'vlan' tag enforces this. Also, I wanted to keep the validation and processing separate rather than add 'if native' branches to the loops that operate on the vlan id list. I can see the advantage of having a single setting to configure the native vlan, rather than the two attributes I proposed. If the new suggestion is preferred I can rework my patch to use that format.
I think it's simpler, to do it that way, yes.
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"?
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.
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@websense.com. Thank you.
Protected by Websense Hosted Email Security -- www.websense.com
participants (2)
-
james robson -
Laine Stump