Re: [ovs-discuss] VLAN mode=dot1q-tunnel and tags in OVS
On Mon, Nov 19, 2018 at 07:32:46AM -0800, Sim Paul wrote:
> >
> >
> > > I am still trying to understand the test case behavior that i pasted in
> > my
> > > previous email.
> > > In my first test case when vlan-limit=1, the ping worked because
> > > only the outside VLAN tag (36) was inspected ??
> > > But in second case when i set vlan-limit=2, ping stopped working because
> > > both tags 36 and 120 were inspected ?
> > >
> > > Shouldn't the ping work even in second test case ?
> >
> > I'm not sure. Your configuration is a big odd. dot1q-tunnel should only
> > be configured at the ends, but it sounds like you've added it to the
> > patch ports as well.
> >
> > Are you saying you are able to ping a virtual machine sitting on a
> neighboring ovs bridge
> by simply configuring dot1q-tunnel at the end points (VM NICs) ? Plz
> confirm.
> For me, if i don't configure all 4 ports(two VM VNICs and two patch ports)
> as dot1q-tunnel,
> VM1 sitting on ovsbr1 CANNOT ping VM2 sitting on ovsbr2.
Sorry for the delay. I was on holiday and traveling.
I took another look. Using dot1q-tunnel on an already double tagged
packet will not work if vlan-limit == 2 or if vlan-limit == 0.
During the xlate phase the dot1q-tunnel temporarily pushes another VLAN
tag to the internal xlate structures - think of it as an implicit
push_vlan. Because the flow already has two tags it shifts the VLANs to
the right and the right most VLAN is lost. On the other-end the
dot1q-tunnel VLAN is stripped leaving a single VLAN.
i.e.
ingress input: [VLAN 36] [VLAN 100]
ingress output: [VLAN xx] [VLAN 36]
egress input: [VLAN xx] [VLAN 36]
egress output: [VLAN 36]
where "xx" is your dot1q-tunnel tag.
So why does it work with vlan-limit=1 ?
Recall that with vlan-limit=1 the second VLAN is _not_ parsed as a VLAN
(it'll be the dl_type). The xlate structure has slots for 2 VLANs
regardless of the value of vlan-limit. This means the temporary/internal
shift of the VLAN works as there is room (only one VLAN was parsed).
Possible fix:
I think struct xvlan could be of size FLOW_MAX_VLAN_HEADERS + 1 to allow
the temporary/internal shift caused by dot1q-tunnel. Although I'm not
sure if this would cause a regression elsewhere.
Can you try this untested patch?
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 507e14dd0d00..4f86e7704a50 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -418,7 +418,8 @@ struct xvlan_single {
};
struct xvlan {
-struct xvlan_single v[FLOW_MAX_VLAN_HEADERS];
+ /* Add 1 to the size to allow temporary/internal shift for dot1q-tunnel. */
+struct xvlan_single v[FLOW_MAX_VLAN_HEADERS + 1];
};
const char *xlate_strerror(enum xlate_error error)
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VLAN mode=dot1q-tunnel and tags in OVS
On Fri, Nov 16, 2018 at 11:46:22AM -0800, Sim Paul wrote: > On Fri, Nov 16, 2018 at 6:00 AM Eric Garver wrote: > > > On Thu, Nov 15, 2018 at 03:49:53PM -0800, Sim Paul wrote: > > [..] > > > My concerns are: > > > 1. Shouldn't setting vlan-limit=0, tag=10 push tag=10 on all packets > > > leaving VM1 and i should see tag=10 in tcpdump. > > > 2. Does setting vlan-limit=0 mean i can push unlimited tags on the > > packet ? > > > How can i test this ? > > > > No. That's not what it means. You can't push more than the datapath > > supports. > > > > See "vlan-limit" in the ovs-vswitchd.conf man page: > > > > > Ok. That means , currently the "maximum" number of VLAN tags supported are 2 > which is what the OpenvSwitch userspace currently supports. Correct. > I am still trying to understand the test case behavior that i pasted in my > previous email. > In my first test case when vlan-limit=1, the ping worked because > only the outside VLAN tag (36) was inspected ?? > But in second case when i set vlan-limit=2, ping stopped working because > both tags 36 and 120 were inspected ? > > Shouldn't the ping work even in second test case ? I'm not sure. Your configuration is a big odd. dot1q-tunnel should only be configured at the ends, but it sounds like you've added it to the patch ports as well. > Pardon my ignorance about vlan tag matching inside the kernel here, but > can someone explain how the packet matching would occur if packet has >= 2 > tags. If packet has 2 tags, then both tags are parsed and dl_type is the Ethertype of the payload (e.g. 0x0800 for IP). If packet has > 2 tags, then only the first two tags are parsed as VLANs and dl_type is the VLAN TPID of the third VLAN tag (e.g. 0x8100). > If another tag is forced onto the packet, would that third tag be > dropped or would it replace an existing tag ? It won't let you push another VLAN if the flow already has two. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VLAN mode=dot1q-tunnel and tags in OVS
On Thu, Nov 15, 2018 at 03:49:53PM -0800, Sim Paul wrote: [..] > My concerns are: > 1. Shouldn't setting vlan-limit=0, tag=10 push tag=10 on all packets > leaving VM1 and i should see tag=10 in tcpdump. > 2. Does setting vlan-limit=0 mean i can push unlimited tags on the packet ? > How can i test this ? No. That's not what it means. You can't push more than the datapath supports. See "vlan-limit" in the ovs-vswitchd.conf man page: http://www.openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.html "Value 0 means unlimited. The actual number of supported VLAN headers is the smallest of vlan-limit, the number of VLANs sup‐ ported by Open vSwitch userspace (currently 2), and the number supported by the datapath." ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] [PATCH v2] [PATCH] QinQ: support more vlan headers.
On Tue, Sep 11, 2018 at 01:10:09AM +, Lilijun (Jerry, Cloud Networking) wrote: > Thanks for your reply. > > In my use case, it's OVS userspace datapath with dpdk. > > My detail case was a bit complicated as follows: > 1. Start the OVS userspace datapath with dpdk in my host server. > 2. A VM was running and the VNIC's vhostuser port on the userspace datapath > is configured as QinQ mode, qinq-ethtype 802.1q. > 3. Another kernel OVS is running in that VM to switch packets of some > containers. Then the container's VNIC port on the kernel datapath is also > configured as QinQ Mode, qinq-ethtype=802.1q . > 4. So when the container sends a packet with VLAN tag, the OVS running in > the host will receive a packet with 2 VLANS from the VM. > 5. Here the QinQ is not worked when we need 3 VLANs. > > Yes, VXLAN or PBB can work but we need change our basic network topology and > push/pop for every packets. That maybe the last choice if QinQ can't support > triple VLAN. There is still a push/pop for the third VLAN tag. I'm not sure it makes sense to support the extra VLANs in upstream OVS. This is non-standard and there are alternatives such as VXLAN. If it wasn't splitting the MPLS labels across cache lines then it would be a harmless change. > > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Tuesday, September 11, 2018 3:33 AM > To: Eric Garver ; Lilijun (Jerry, Cloud Networking) > ; d...@openvswitch.org; ovs-discuss@openvswitch.org > Subject: Re: [ovs-discuss] [PATCH v2] [ovs-dev] [PATCH] QinQ: support more > vlan headers. > > On Mon, Sep 10, 2018 at 03:15:21PM -0400, Eric Garver wrote: > > On Mon, Sep 10, 2018 at 03:03:19AM +, Lilijun (Jerry, Cloud Networking) > > wrote: > > > Hi Eric, > > > > > > Yes, I agree with that effect. > > > But how about this issue of QinQ that we can only support at most 2 VLANs > > > ? Do you have any ideas? > > > > I was not NACKing the idea. Just wanted everyone to understand the > > implications of increasing the VLAN field size. > > > > I tried playing with the fields, but didn't come with a reasonable way > > to rearrange them to make room for the extra VLANs. > > > > I'm curious what you're use case is for triple VLAN. I wonder if VXLAN > > or PBB (802.1ah) is a better solution. > > I'd also like to know what datapath we're talking about. The Linux kernel > datapath only supports 2 VLANs in any case. > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [PATCH v2] [ovs-dev] [PATCH] QinQ: support more vlan headers.
On Mon, Sep 10, 2018 at 03:03:19AM +, Lilijun (Jerry, Cloud Networking)
wrote:
> Hi Eric,
>
> Yes, I agree with that effect.
> But how about this issue of QinQ that we can only support at most 2 VLANs ?
> Do you have any ideas?
I was not NACKing the idea. Just wanted everyone to understand the
implications of increasing the VLAN field size.
I tried playing with the fields, but didn't come with a reasonable way
to rearrange them to make room for the extra VLANs.
I'm curious what you're use case is for triple VLAN. I wonder if VXLAN
or PBB (802.1ah) is a better solution.
>
> Thanks.
>
> -Original Message-
> From: Eric Garver [mailto:e...@garver.life]
> Sent: Friday, September 07, 2018 10:14 PM
> To: Lilijun (Jerry, Cloud Networking)
> Cc: Ben Pfaff ; d...@openvswitch.org;
> ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] [PATCH v2] [ovs-dev] [PATCH] QinQ: support more
> vlan headers.
>
> On Fri, Sep 07, 2018 at 09:53:44AM +, Lilijun (Jerry, Cloud Networking)
> wrote:
> > In my test, vlan-limit is set to 0 that means unlimited the count of
> > vlan headers.
> > ovs-vsctl set Open_vSwitch . other_config:vlan-limit=0
> >
> > But in fact the macro FLOW_MAX_VLAN_HEADERS is defined as 2, so we can
> > only support max two vlan headers. It doesn't work as the config
> > vlan-limit's description.
> >
> > So, when VM sends a packet already with two vlan headers, the vport
> > configured with qinq mode can't add another s-vlan headers.
> > FLOW_MAX_VLAN_HEADERS need to be larger to support more vlan headers.
> >
> > Change-Id: I8449e308d406ce3757b43a2636ff0f326ca12a9d
> > Signed-off-by: Lilijun
> > ---
> > include/openvswitch/flow.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
> > index 5d2cf09..a09650c 100644
> > --- a/include/openvswitch/flow.h
> > +++ b/include/openvswitch/flow.h
> > @@ -72,7 +72,7 @@ const char *flow_tun_flag_to_string(uint32_t flags);
> > *
> > * We require this to be a multiple of 2 so that vlans[] in struct flow is
> > a
> > * multiple of 64 bits. */
> > -#define FLOW_MAX_VLAN_HEADERS 2
> > +#define FLOW_MAX_VLAN_HEADERS 4
>
> This change splits the MPLS labels and ct_ipv6_src across cache lines and 64
> byte boundary which affects the miniflow. This change may have a performance
> impact for scenarios that use these fields.
>
> On the plus side it pushes all the nsh fields into the same cache line.
> Previously they were split.
>
> With this patch:
>
> $ pahole -C flow lib/flow.o
> struct flow {
> struct flow_tnltunnel; /* 0 344 */
> /* --- cacheline 5 boundary (320 bytes) was 24 bytes ago --- */
> ovs_be64 metadata; /* 344 8 */
> uint32_t regs[16]; /* 35264 */
> /* --- cacheline 6 boundary (384 bytes) was 32 bytes ago --- */
> uint32_t skb_priority; /* 416 4 */
> uint32_t pkt_mark; /* 420 4 */
> uint32_t dp_hash; /* 424 4 */
> union flow_in_port in_port; /* 428 4 */
> uint32_t recirc_id;/* 432 4 */
> uint8_tct_state; /* 436 1 */
> uint8_tct_nw_proto; /* 437 1 */
> uint16_t ct_zone; /* 438 2 */
> uint32_t ct_mark; /* 440 4 */
> ovs_be32 packet_type; /* 444 4 */
> /* --- cacheline 7 boundary (448 bytes) --- */
> ovs_u128 ct_label; /* 44816 */
> uint32_t conj_id; /* 464 4 */
> ofp_port_t actset_output;/* 468 4 */
> struct eth_addrdl_dst; /* 472 6 */
> struct eth_addrdl_src; /* 478 6 */
> ovs_be16 dl_type; /* 484 2 */
> uint8_tpad1[2]; /* 486 2 */
> union flow_vlan_hdrvlans[4]; /* 48816 */
> ovs_be32 mpls_lse[4]; /* 50416 */
> /* --- cacheline 8 boundary (512 bytes) was 8 bytes ago --- */
> ovs_be32 nw_src; /*
Re: [ovs-discuss] [PATCH v2] [ovs-dev] [PATCH] QinQ: support more vlan headers.
On Fri, Sep 07, 2018 at 09:53:44AM +, Lilijun (Jerry, Cloud Networking)
wrote:
> In my test, vlan-limit is set to 0 that means unlimited the count of vlan
> headers.
> ovs-vsctl set Open_vSwitch . other_config:vlan-limit=0
>
> But in fact the macro FLOW_MAX_VLAN_HEADERS is defined as 2, so we can
> only support max two vlan headers. It doesn't work as the config vlan-limit's
> description.
>
> So, when VM sends a packet already with two vlan headers, the vport
> configured with
> qinq mode can't add another s-vlan headers. FLOW_MAX_VLAN_HEADERS need to
> be larger to support more vlan headers.
>
> Change-Id: I8449e308d406ce3757b43a2636ff0f326ca12a9d
> Signed-off-by: Lilijun
> ---
> include/openvswitch/flow.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
> index 5d2cf09..a09650c 100644
> --- a/include/openvswitch/flow.h
> +++ b/include/openvswitch/flow.h
> @@ -72,7 +72,7 @@ const char *flow_tun_flag_to_string(uint32_t flags);
> *
> * We require this to be a multiple of 2 so that vlans[] in struct flow is a
> * multiple of 64 bits. */
> -#define FLOW_MAX_VLAN_HEADERS 2
> +#define FLOW_MAX_VLAN_HEADERS 4
This change splits the MPLS labels and ct_ipv6_src across cache lines
and 64 byte boundary which affects the miniflow. This change may have a
performance impact for scenarios that use these fields.
On the plus side it pushes all the nsh fields into the same cache line.
Previously they were split.
With this patch:
$ pahole -C flow lib/flow.o
struct flow {
struct flow_tnltunnel; /* 0 344 */
/* --- cacheline 5 boundary (320 bytes) was 24 bytes ago --- */
ovs_be64 metadata; /* 344 8 */
uint32_t regs[16]; /* 35264 */
/* --- cacheline 6 boundary (384 bytes) was 32 bytes ago --- */
uint32_t skb_priority; /* 416 4 */
uint32_t pkt_mark; /* 420 4 */
uint32_t dp_hash; /* 424 4 */
union flow_in_port in_port; /* 428 4 */
uint32_t recirc_id;/* 432 4 */
uint8_tct_state; /* 436 1 */
uint8_tct_nw_proto; /* 437 1 */
uint16_t ct_zone; /* 438 2 */
uint32_t ct_mark; /* 440 4 */
ovs_be32 packet_type; /* 444 4 */
/* --- cacheline 7 boundary (448 bytes) --- */
ovs_u128 ct_label; /* 44816 */
uint32_t conj_id; /* 464 4 */
ofp_port_t actset_output;/* 468 4 */
struct eth_addrdl_dst; /* 472 6 */
struct eth_addrdl_src; /* 478 6 */
ovs_be16 dl_type; /* 484 2 */
uint8_tpad1[2]; /* 486 2 */
union flow_vlan_hdrvlans[4]; /* 48816 */
ovs_be32 mpls_lse[4]; /* 50416 */
/* --- cacheline 8 boundary (512 bytes) was 8 bytes ago --- */
ovs_be32 nw_src; /* 520 4 */
ovs_be32 nw_dst; /* 524 4 */
ovs_be32 ct_nw_src;/* 528 4 */
ovs_be32 ct_nw_dst;/* 532 4 */
struct in6_addripv6_src; /* 53616 */
struct in6_addripv6_dst; /* 55216 */
struct in6_addrct_ipv6_src; /* 56816 */
/* --- cacheline 9 boundary (576 bytes) was 8 bytes ago --- */
struct in6_addrct_ipv6_dst; /* 58416 */
ovs_be32 ipv6_label; /* 600 4 */
uint8_tnw_frag; /* 604 1 */
uint8_tnw_tos; /* 605 1 */
uint8_tnw_ttl; /* 606 1 */
uint8_tnw_proto; /* 607 1 */
struct in6_addrnd_target;/* 60816 */
struct eth_addrarp_sha; /* 624 6 */
struct eth_addrarp_tha; /* 630 6 */
ovs_be16 tcp_flags;/* 636 2 */
ovs_be16 pad2; /* 638 2 */
/* --- cacheline 10 boundary (640 bytes) --- */
struct
Re: [ovs-discuss] [PATCH] [ovs-dev] [PATCH] QinQ: support more vlan headers.
On Fri, Sep 07, 2018 at 09:58:16AM +, Lilijun (Jerry, Cloud Networking) wrote: > We can remove the unlimited words. Maybe like this: > > Value 0 means the max number of VLANs supported by Open > vSwitch userspace (currently 2), or the number > supported by the datapath. This is still tricky wording. It may be read as the maximum value supported by OVS userspace or the maximum value supported by the datapath. Really it's min( max(OVS userspace), max(datapath) ). I suggest: Value 0 means the least common value of maximum supported VLANs in; the Open vSwitch userpsace (currently 2), and the datapath. > > > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Friday, September 07, 2018 12:13 PM > To: Lilijun (Jerry, Cloud Networking) > Cc: ovs-discuss@openvswitch.org; d...@openvswitch.org; Eric Garver > > Subject: Re: [ovs-discuss] [PATCH] [ovs-dev] [PATCH] QinQ: support more vlan > headers. > > On Fri, Sep 07, 2018 at 02:51:25AM +, Lilijun (Jerry, Cloud Networking) > wrote: > > In my test, vlan-limit is set to 0 that means unlimited the count of > > vlan headers. > > ovs-vsctl set Open_vSwitch . other_config:vlan-limit=0 > > > > But in fact the macro FLOW_MAX_VLAN_HEADERS is defined as 2, so we can > > only support max two vlan headers. It doesn't work as the config > > vlan-limit's description. > > The following is the description. Please explain how it can be made clearer. > >other_config : vlan-limit: optional string, containing an integer, at >least 0 > Limits the number of VLAN headers that can be matched to the > specified number. Further VLAN headers will be treated as pay‐ > load, e.g. a packet with more 802.1q headers will match Ethernet > type 0x8100. > > Value 0 means unlimited. The actual number of supported VLAN > headers is the smallest of vlan-limit, the number of VLANs sup‐ > ported by Open vSwitch userspace (currently 2), and the number > supported by the datapath. > > If this value is absent, the default is currently 1. This main‐ > tains backward compatibility with controllers that were designed > for use with Open vSwitch versions earlier than 2.8, which only > supported one VLAN. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] fix the mod_vlan_vid actions with OpenFlow13.
On Tue, Aug 21, 2018 at 02:23:33AM +, wangyunjian wrote: > > > > -Original Message- > > From: Eric Garver [mailto:e...@erig.me] > > Sent: Monday, August 20, 2018 9:15 PM > > To: wangyunjian > > Cc: d...@openvswitch.org; ovs-discuss@openvswitch.org; Zhoulei (stone, > > Cloud Networking) ; thomasfherb...@gmail.com > > Subject: Re: [ovs-discuss] [ovs-dev] fix the mod_vlan_vid actions with > > OpenFlow13. > > > > On Mon, Aug 20, 2018 at 02:17:34AM +, wangyunjian wrote: > > > > > > > > [..] > > > > > On Fri, Aug 17, 2018 at 12:15:30PM +, wangyunjian wrote: > > > > > > The datapath flow which pushs double vlan was found using > > > > > > ovs-appctl dpctl/dump-flows, but the flow was set mod_vlan_vid > > actions. > > > > > > This problem is discovered from "Add support for 802.1ad (QinQ > > > > tunneling)". > > > > > > > > > > Thanks for reporting. Can you say what version of OVS you're using? > > > > > Including any extra patches you may have applied. > > > > > > > > The version of OVS is master branch(git log " > > > > be5e6d6822e60b5b84ac65dcd1b249145356a809 > > > > ofp-ed-props: Fix hang for crafted OpenFlow encap/decap properties".). > > > > > > > > > > > > > > > My test steps: > > > > > > > > > > > > 1) ovs-vsctl add-br ovsbr0 -- set bridge ovsbr0 datapath_type=netdev > > > > > >ovs-vsctl add-port ovsbr0 eth2 -- set Interface eth2 > > > > > > type=dpdk > > > > > options:dpdk-devargs=:03:00.0 > > > > > >ovs-ofctl -O OpenFlow13 add-flow ovsbr0 " > > > > > > table=0,priority=2,in_port=1 > > > > > actions=mod_vlan_vid:3,NORMAL" > > > > What happens if you add a wildcard VLAN match here? > > e.g. vlan_tci=0x1000/0x1000 > > The packet is set vlan_vid ok with adding the wildcard VLAN match. > > linux-jrWzwZ:/data/wyj/git/ovs # ovs-ofctl -O OpenFlow13 add-flow ovsbr0 > "cookie=0xb043f0d196265635,table=0,priority=2,in_port=1,vlan_tci=0x1000/0x1000 > actions=mod_vlan_vid:2,NORMAL" > linux-jrWzwZ:/data/wyj/git/ovs # tcpdump -i ovsbr0 -ne > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ovsbr0, link-type EN10MB (Ethernet), capture size 65535 bytes > 10:06:53.284556 90:17:ac:b0:0a:ff > Broadcast, ethertype 802.1Q (0x8100), > length 64: vlan 2, p 0, ethertype ARP, Request who-has 3.3.3.18 tell > 3.3.3.17, length 46 > 10:06:54.286542 90:17:ac:b0:0a:ff > Broadcast, ethertype 802.1Q (0x8100), > length 64: vlan 2, p 0, ethertype ARP, Request who-has 3.3.3.18 tell > 3.3.3.17, length 46 > 10:06:56.283594 90:17:ac:b0:0a:ff > Broadcast, ethertype 802.1Q (0x8100), > length 64: vlan 2, p 0, ethertype ARP, Request who-has 3.3.3.18 tell > 3.3.3.17, length 46 The mod_vlan_vid will implicitly insert a PUSH_VLAN action if the match/flow does not qualify a vlan regardless of the specified OF version. This is done on the ovs-ofctl side before the flow is sent over to ovs-vswitchd - long before any packets are involved. You have two options: 1) qualify the VLAN as you've done above 2) Use set_vlan_vid action with "-O OpenFlow11" or greater. It will _not_ attempt to push a VLAN. This worked before 802.1ad/QinQ support only by accident because the PUSH_VLAN action blindly overwrote the existing VLAN. Hope that helps. Eric. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Openvswitch dual tagged VLAN help
On Thu, Jan 25, 2018 at 10:22:55PM +, David Ramdayal via discuss wrote: > Hello guys > > I am F5 networks employee and have implemented OpenSTack with > openVswitch on network node, however I am having some issues getting > the external tag traffic to route through OVS as my floating IP > traffic to me VMs. Please can you point me to someone that can assist > with this config/setup? Please ask your questions on the list. That way others can benefit from the discussion. > > Regards > > David R. > Sr. ENE > > [signature_713158842] ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] 802.1ad (QinQ) Support
On Thu, Jul 27, 2017 at 02:25:46PM +0530, Sudhanshu Gupta wrote: > Thanks Eric, for replying. > > Is there any tentative date for release of OVS 2.8? I don't think there is a set date, but I believe the branch for 2.8 is due to be created "soon". > > Regards, > Sudhanshu > > On Mon, Jul 24, 2017 at 6:08 PM, Eric Garver <e...@erig.me> wrote: > > > On Tue, Jul 18, 2017 at 12:42:38PM +0530, Sudhanshu Gupta wrote: > > > Hi, > > > > > > I want to know whether double vlan tagged packets are supported in OVS > > > release 2.7.1 ? > > > > No. Not in the 2.7.x stream. > > > > > > > > If not, which version of OVS supports double vlan tagged packets? > > > > The next minor release, 2.8, will have support. > > > > > > > > Thanks, > > > Sudhanshu > > > > > ___ > > > discuss mailing list > > > disc...@openvswitch.org > > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] 802.1ad (QinQ) Support
On Tue, Jul 18, 2017 at 12:42:38PM +0530, Sudhanshu Gupta wrote: > Hi, > > I want to know whether double vlan tagged packets are supported in OVS > release 2.7.1 ? No. Not in the 2.7.x stream. > > If not, which version of OVS supports double vlan tagged packets? The next minor release, 2.8, will have support. > > Thanks, > Sudhanshu > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Cannot match correct ethertype after POP vlan and GOTO table
On Tue, Jul 04, 2017 at 03:27:50PM +0800, Dickens Yeh wrote: > Hi, > I have an question, and I haven't found any OpenFlow Spec to defined it , > please give me a help. > > I am trying to work with 3 vlan tags, but it cannot match correct ethertype > after pop 1 vlan tag. > OVS Bridge already set with vlan-limit = 0, and it can watch over 2 vlan > and match the correct ethertype like ARP. > > My question is: the packet have 3 vlan tags, pop 1 vlan tag and goto-table > 1. In table 1, will it match with the new packet (modified) or the original > packet like in table 0? Original packet as in table 0. dl_type would be the 3rd VLAN tag in the packet. goto_table does not cause the packet to be reparsed. Currently OVS supports/parses 2 VLAN tags. > > Thanks for answering my question. > > best wishes, > Dickens Yeh > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Can't match on CVLAN
On Tue, May 09, 2017 at 07:33:53AM -0300, Marcos Felipe Schwarz wrote: > Hi Eric, > > I was aware of the vlan-limit=2 parameter, and tested with "0" also, but got > everytime the same result. > Reading the documentation one explanation would be that the dpdk datapth only > supports matching on 1 vlan tag, is this assumption correct? DPDK/userspace datapath should support 2 VLAN tags. Have you tried it without DPDK or with the kernel datapath? Please verify that the frames actually have two tags when they ingress in_port=1. Are the frames originating from another server? If so, I've seen some NICs misbehave with VLAN TX hardware offload and double stacked 0x8100 (they _replace_ the inner tag instead of adding another). You may want to try disabling txvlan on the sender: $ ethtool -K tvxlan off > > Regards, > > Marcos Schwarz > > ----- Original Message - > From: "Eric Garver" <e...@erig.me> > To: "Marcos Felipe Schwarz" <marcos.schw...@rnp.br> > Cc: ovs-discuss@openvswitch.org > Sent: Monday, May 8, 2017 9:25:34 PM > Subject: Re: [ovs-discuss] Can't match on CVLAN > > On Mon, May 08, 2017 at 05:10:08PM -0300, Marcos Felipe Schwarz wrote: > > I confirmed that the problem I reported applies to the the latest commit > > from yesterday on the master branch. > > I expect you need to set vlan-limit=2. See [0], it affects how many VLAN > tags are parsed on ingress. This option is new with QinQ support. > > I assume you have vlan-limit=1 as it's the default. When your double > tagged packet arrives only the outer VLAN is parsed. So after the > pop_vlan action you're left with zero tags and dl_vlan will never match. > > Your zero and single tagged cases work because you're explicitly pushing > multiple tags. > > Hope that helps. > Eric. > > [0] > https://github.com/openvswitch/ovs/blob/c847a84c4a11489910319d93ef22dfeef8e1b1f8/vswitchd/vswitch.xml#L363 > > > > > Thanks, > > > > Marcos Schwarz > > > > - Original Message - > > From: "Eric Garver" <e...@erig.me> > > To: "Marcos Felipe Schwarz" <marcos.schw...@rnp.br> > > Cc: ovs-discuss@openvswitch.org > > Sent: Sunday, May 7, 2017 10:26:23 AM > > Subject: Re: [ovs-discuss] Can't match on CVLAN > > > > Hi Marcos, > > > > Thanks for reporting this. I believe it should work (at least with > > current master branch). I will take a closer tomorrow. > > > > Are your packets double tagged with TPIDs 0x88a8 and 0x8100, or are both > > tags 0x8100? > > > > Thanks. > > Eric. > > > > On Fri, May 05, 2017 at 09:05:46PM -0300, Marcos Felipe Schwarz wrote: > > > Hi, > > > > > > Found some inconsistencies while further troubleshooting the issue,maybe > > > there is a bug. > > > > > > I'm sending the same packet in three ways to OVS at port 1: > > > 1) Untagged > > > 2) Tagged with single VLAN 10 > > > 3) Double tagged with CVLAN 10 and SVLAN 3204 > > > > > > Then I match and mark each flow with a different metadata, adding tags to > > > 1) and 2) to make them equivalent to 3), send them to the same rule on > > > table 1, and try to match them by the CVLAN on table 2. 1) and 2) work as > > > expected, but the double tagged packet can't match on the CVLAN 10. > > > > > > cookie=0x0, duration=493.174s, table=0, n_packets=318, n_bytes=25758, > > > in_port=1,vlan_tci=0x/0x1fff > > > actions=set_field:0x1->metadata,push_vlan:0x8100,set_field:4106- > > > >vlan_vid,push_vlan:0x8100,set_field:7300->vlan_vid,goto_table:1 > > > cookie=0x0, duration=493.167s, table=0, n_packets=318, n_bytes=27030, > > > in_port=1,dl_vlan=10 > > > actions=set_field:0x2->metadata,push_vlan:0x8100,set_field:7300->vlan_vid,go > > > to_table:1 > > > cookie=0x0, duration=493.163s, table=0, n_packets=318, n_bytes=28302, > > > in_port=1,dl_vlan=3204 actions=set_field:0x3->metadata,goto_table:1 > > > > > > cookie=0x0, duration=493.158s, table=1, n_packets=954, n_bytes=81090, > > > in_port=1,dl_vlan=3204 actions=pop_vlan,goto_table:2 > > > > > > cookie=0x0, duration=493.153s, table=2, n_packets=318, n_bytes=25758, > > > metadata=0x1,in_port=1,dl_vlan=10 actions=pop_vlan,output:2 > > > cookie=0x0, duration=493.148s, table=2, n_packets=318, n_bytes=27030, > > > metadata=0x2,in_port=1,dl_vlan=10 actions=pop_vlan,output:2 > > > cookie=0x0, duration=491.905s, table=2, n_packets=0, n_bytes=0, > > >
Re: [ovs-discuss] Can't match on CVLAN
On Mon, May 08, 2017 at 05:10:08PM -0300, Marcos Felipe Schwarz wrote: > I confirmed that the problem I reported applies to the the latest commit from > yesterday on the master branch. I expect you need to set vlan-limit=2. See [0], it affects how many VLAN tags are parsed on ingress. This option is new with QinQ support. I assume you have vlan-limit=1 as it's the default. When your double tagged packet arrives only the outer VLAN is parsed. So after the pop_vlan action you're left with zero tags and dl_vlan will never match. Your zero and single tagged cases work because you're explicitly pushing multiple tags. Hope that helps. Eric. [0] https://github.com/openvswitch/ovs/blob/c847a84c4a11489910319d93ef22dfeef8e1b1f8/vswitchd/vswitch.xml#L363 > > Thanks, > > Marcos Schwarz > > - Original Message ----- > From: "Eric Garver" <e...@erig.me> > To: "Marcos Felipe Schwarz" <marcos.schw...@rnp.br> > Cc: ovs-discuss@openvswitch.org > Sent: Sunday, May 7, 2017 10:26:23 AM > Subject: Re: [ovs-discuss] Can't match on CVLAN > > Hi Marcos, > > Thanks for reporting this. I believe it should work (at least with > current master branch). I will take a closer tomorrow. > > Are your packets double tagged with TPIDs 0x88a8 and 0x8100, or are both > tags 0x8100? > > Thanks. > Eric. > > On Fri, May 05, 2017 at 09:05:46PM -0300, Marcos Felipe Schwarz wrote: > > Hi, > > > > Found some inconsistencies while further troubleshooting the issue,maybe > > there is a bug. > > > > I'm sending the same packet in three ways to OVS at port 1: > > 1) Untagged > > 2) Tagged with single VLAN 10 > > 3) Double tagged with CVLAN 10 and SVLAN 3204 > > > > Then I match and mark each flow with a different metadata, adding tags to > > 1) and 2) to make them equivalent to 3), send them to the same rule on > > table 1, and try to match them by the CVLAN on table 2. 1) and 2) work as > > expected, but the double tagged packet can't match on the CVLAN 10. > > > > cookie=0x0, duration=493.174s, table=0, n_packets=318, n_bytes=25758, > > in_port=1,vlan_tci=0x/0x1fff > > actions=set_field:0x1->metadata,push_vlan:0x8100,set_field:4106- > > >vlan_vid,push_vlan:0x8100,set_field:7300->vlan_vid,goto_table:1 > > cookie=0x0, duration=493.167s, table=0, n_packets=318, n_bytes=27030, > > in_port=1,dl_vlan=10 > > actions=set_field:0x2->metadata,push_vlan:0x8100,set_field:7300->vlan_vid,go > > to_table:1 > > cookie=0x0, duration=493.163s, table=0, n_packets=318, n_bytes=28302, > > in_port=1,dl_vlan=3204 actions=set_field:0x3->metadata,goto_table:1 > > > > cookie=0x0, duration=493.158s, table=1, n_packets=954, n_bytes=81090, > > in_port=1,dl_vlan=3204 actions=pop_vlan,goto_table:2 > > > > cookie=0x0, duration=493.153s, table=2, n_packets=318, n_bytes=25758, > > metadata=0x1,in_port=1,dl_vlan=10 actions=pop_vlan,output:2 > > cookie=0x0, duration=493.148s, table=2, n_packets=318, n_bytes=27030, > > metadata=0x2,in_port=1,dl_vlan=10 actions=pop_vlan,output:2 > > cookie=0x0, duration=491.905s, table=2, n_packets=0, n_bytes=0, > > metadata=0x3,in_port=1,dl_vlan=10 actions=pop_vlan,output:2 > > > > Regards, > > > > Marcos Schwarz > > > > - Original Message - > > From: "Marcos Felipe Schwarz" <marcos.schw...@rnp.br> > > To: ovs-discuss@openvswitch.org > > Sent: Friday, May 5, 2017 8:55:56 PM > > Subject: Can't match on CVLAN > > > > Sorry for the duplicate post, but it seems I posted on someone elses thread, > > > > Hi, > > > > I'm trying to work with double tagged packets in OVS. But I can't match on > > the inner VLAN (CVLAN), even after poping the SVLAN and using a different > > table. > > In this setup I'm receiving on port 1 SVLANs 3204 and 3217 both > > transporting CVLANs 10 and 20, what I want to achieve is to steer each flow > > (SVLAN + CVLAN combination) to a different outport. > > > > I came up with two set of rules, using two tables. > > On table 0 I match on in_port, SVLAN, pop it, save the SVLAN VID to the > > metadata field then send to table 1. > > On table 1 I match on the metadata to restore the information of wich SVLAN > > this flow is from, mach on in_port and CVLAN, pop the CVLAN and send to the > > outputport. > > Below are the flows I used: > > > > ovs-ofctl -O OpenFlow13 add-flow br-oper0 > > in_port=1,dl_vlan=3204,actions=pop_vlan,set_field:3204->metadata,goto_table:1 > > ovs-ofctl -O OpenFlow13 add-flow br-oper0 > > i
Re: [ovs-discuss] match ethertype when packet with multiple vlan tags
On Tue, Apr 18, 2017 at 12:22:56PM +0800, Dickens Yeh wrote: > Yes, I use the master branch and set with vlan-limit=0. > The line 362 says "e.g. a packet with more 802.1q headers will match > Ethernet type 0x8100." This applies if the number of VLAN tags exceeds the value of vlan-limit. For example, vlan-limit == 2 and the frame has 3 VLAN tags then the dl_type will be 0x8100 because OVS can only look at the first two tags. Anything after that is considered payload. > Is that means OVS will keep match 0x8100 that not the defined from OpenFlow > spec or maybe will be fixed with maybe next version? I'm not sure I understand what you're asking here. Hopefully my comment above helps. > > best wishes, > Dickens Yeh > > > 2017-04-17 22:51 GMT+08:00 Eric Garver <e...@erig.me>: > > > On Mon, Apr 17, 2017 at 01:26:37PM +0800, Dickens Yeh wrote: > > > Hello, > > > I have a problem with matching ethertype when the packet with vlan tags. > > > My testing environment is Ubuntu 16 in vmware fusion, mininet 2.2.2rc1, > > > openvswitch 2.7.90 > > > > > > With these cases: > > > case 1: packet with vlan=100,ethertype=arp > > > case 2: packet with vlan=2000,vlan=100,ethertype=arp > > > > > > The result of cases: > > > case 1 can be matched by vlan=100 and ethertype=arp fields in a flow > > entry > > > case 2 can be matched only by vlan=2000 and ethertype=0x8100 fields in a > > > flow entry > > > > > > But I read some informations from OpenFlow Spec 1.1, that says about > > "match > > > ethertype after all vlan tags". > > > Is the resulf of case 2 should be matched vlan=2000 and ethertype=arp? > > > > Until very recently openvswitch only supported a single VLAN tag. > > Current master branch has support for 802.1ad/QinQ and can match the ARP > > EtherType as you wish in case 2 above. > > > > To use it you'll have to build from master and set vlan-limit=2 or > > vlan-limit=0. > > See https://github.com/openvswitch/ovs/blob/master/ > > vswitchd/vswitch.xml#L362 > > > > > > > > > > > Thanks for your reply. > > > > > > best wishes, > > > Dickens Yeh > > > > > ___ > > > discuss mailing list > > > disc...@openvswitch.org > > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
