[ovs-discuss] How to round robin a single UDP flow to different ports?
Hello, Is it possible to round robin a single UDP flow to different ports? I was looking into port groups, multipath, bundle... But couldn't find a way for it. Regards, Marcos Schwarz Coordenador de P | R Coordinator Gerência de Redes para Experimentos (GRE) / Management of Network for Experiments Diretoria de Pesquisa & Desenvolvimento (DPD) / Research & Development Department RNP – Rede Nacional de Ensino e Pesquisa http://www.rnp.br | Telefone: +55 (19) 3787 3386 | Skype: marcos.f.sch Campinas - SP - Brasil | E-mail: marcos.schw...@rnp.br ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS 2.8.0
Thanks for the suggestion Aaron.
Follows below the revised patch for the current master using Aaron and Timothy
contributions. May I submit the patch as is or are there any further
suggestions?
I've tested it in the following conditions:
1) Fedora 27, ovs_user root:root, vfio-uio driver: Fixed by this patch
2) Fedora 27, ovs_user root:root, uio-pci-generic driver: Fixed by this patch
3) Fedora 27, ovs_user openvswitch:hugetlbfs, vfio-uio driver: Continues working
4) Fedora 27, ovs_user openvswitch:hugetlbfs, uio-pci-generic driver: Continues
broken, for kernel 4.0 and newer since the user is missing the CAP_SYS_ADMIN
capability. Ref: https://www.kernel.org/doc/Documentation/vm/pagemap.txt
diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
index adb549c98..06528e9ab 100644
--- a/lib/daemon-unix.c
+++ b/lib/daemon-unix.c
@@ -1047,5 +1047,6 @@ daemon_set_new_user(const char *user_spec)
}
}kernel
-switch_user = true;
+if (!uid_verify(uid) || !gid_verify(gid))
+switch_user = true;
}
diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
index c6d9aa1b8..9b01c9271 100644
--- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
+++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
@@ -14,7 +14,7 @@ Environment=HOME=/var/run/openvswitch
EnvironmentFile=/etc/openvswitch/default.conf
EnvironmentFile=-/etc/sysconfig/openvswitch
@begin_dpdk@
-ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages
+ExecStartPre=-/bin/sh -c '/usr/bin/chown :${OVS_USER_ID##*:} /dev/hugepages'
ExecStartPre=-/usr/bin/chmod 0775 /dev/hugepages
@end_dpdk@
ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
Regards,
Marcos Schwarz
- Original Message -
From: "Aaron Conole" <acon...@redhat.com>
To: "Marcos Felipe Schwarz" <marcos.schw...@rnp.br>
Cc: "Timothy Redaelli" <tredae...@redhat.com>, ovs-discuss@openvswitch.org
Sent: Wednesday, January 10, 2018 6:54:24 PM
Subject: Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS
2.8.0
Marcos Felipe Schwarz <marcos.schw...@rnp.br> writes:
> Thanks for the suggestion Timothy, didn't knew that worked. Just
> fixing some little things, it should be:
> ExecStartPre=-/usr/bin/chown :${OVS_USER_ID##*:} /dev/hugepages
>
> Regarding the daemon-unix.c patch, any suggestions on how to improve
> it? I tested it is working, but currently, I'm not aware if the new
> capability should be set separeted as I did or using any of the
> current blocks of code.
One thing that might work is to not attempt switching users and
capabilities if the current user is the target user.
ex:
@@ -1047,5 +1047,6 @@ daemon_set_new_user(const char *user_spec)
}
}
-switch_user = true;
+if (!uid_verify(uid) || !gid_verify(gid))
+switch_user = true;
}
NOTE: this isn't compile or runtime tested, just a thought.
> Regards,
>
> Marcos Schwarz
>
> - Original Message -
> From: "Timothy Redaelli" <tredae...@redhat.com>
> To: "Marcos Felipe Schwarz" <marcos.schw...@rnp.br>
> Cc: "Ben Pfaff" <b...@ovn.org>, ovs-discuss@openvswitch.org
> Sent: Monday, January 8, 2018 9:20:17 AM
> Subject: Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since
> OVS 2.8.0
>
> On Sat, Jan 6, 2018 at 2:41 AM, Marcos Felipe Schwarz
> <marcos.schw...@rnp.br> wrote:
>> Got it fixed.
>>
>> The problem was related to not setting the CAP_SYS_ADMIN capability at
>> daemon-unix.c. Follows the patch bellow to set the capability and
>> dynamically extract the group from OVS_USER_ID instead of forcing it to
>> :hugetlbfs.
>>
>> diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
>> index 839114f3e..3b94164ea 100644
>> --- a/lib/daemon-unix.c
>> +++ b/lib/daemon-unix.c
>> @@ -818,6 +818,9 @@ daemon_become_new_user_linux(bool access_datapath
>> OVS_UNUSED)
>> ret = capng_update(CAPNG_ADD, cap_sets, CAP_NET_ADMIN)
>>|| capng_update(CAPNG_ADD, cap_sets, CAP_NET_RAW);
>> }
>> +if (!ret) {
>> +ret = capng_update(CAPNG_ADD, cap_sets, CAP_SYS_ADMIN);
>> +}
>> } else {
>> ret = -1;
>> }
>> diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>> b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>> index c6d9aa1b8..94290a847 100644
>> --- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>> +++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>> @@ -14,7 +14,7 @@ Environment=HOME=/var/run/openvswitch
>> EnvironmentFile=/etc/openvswitch/default.conf
>> EnvironmentFile=-/etc/sysconfig/ope
Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS 2.8.0
Thanks for the suggestion Timothy, didn't knew that worked. Just fixing some
little things, it should be:
ExecStartPre=-/usr/bin/chown :${OVS_USER_ID##*:} /dev/hugepages
Regarding the daemon-unix.c patch, any suggestions on how to improve it? I
tested it is working, but currently, I'm not aware if the new capability should
be set separeted as I did or using any of the current blocks of code.
Regards,
Marcos Schwarz
- Original Message -
From: "Timothy Redaelli" <tredae...@redhat.com>
To: "Marcos Felipe Schwarz" <marcos.schw...@rnp.br>
Cc: "Ben Pfaff" <b...@ovn.org>, ovs-discuss@openvswitch.org
Sent: Monday, January 8, 2018 9:20:17 AM
Subject: Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS
2.8.0
On Sat, Jan 6, 2018 at 2:41 AM, Marcos Felipe Schwarz
<marcos.schw...@rnp.br> wrote:
> Got it fixed.
>
> The problem was related to not setting the CAP_SYS_ADMIN capability at
> daemon-unix.c. Follows the patch bellow to set the capability and dynamically
> extract the group from OVS_USER_ID instead of forcing it to :hugetlbfs.
>
> diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
> index 839114f3e..3b94164ea 100644
> --- a/lib/daemon-unix.c
> +++ b/lib/daemon-unix.c
> @@ -818,6 +818,9 @@ daemon_become_new_user_linux(bool access_datapath
> OVS_UNUSED)
> ret = capng_update(CAPNG_ADD, cap_sets, CAP_NET_ADMIN)
>|| capng_update(CAPNG_ADD, cap_sets, CAP_NET_RAW);
> }
> +if (!ret) {
> +ret = capng_update(CAPNG_ADD, cap_sets, CAP_SYS_ADMIN);
> +}
> } else {
> ret = -1;
> }
> diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
> b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
> index c6d9aa1b8..94290a847 100644
> --- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
> +++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
> @@ -14,7 +14,7 @@ Environment=HOME=/var/run/openvswitch
> EnvironmentFile=/etc/openvswitch/default.conf
> EnvironmentFile=-/etc/sysconfig/openvswitch
> @begin_dpdk@
> -ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages
> +ExecStartPre=-/bin/sh -c 'chown :$(echo $OVS_USER_ID | tr ":" "\n" | tail
> -1) /dev/hugepages'
I think it's better to avoid using multiple useless forks, shell
script parameter expansion are better in this case:
ExecStartPre=-/bin/sh -c '/usr/bin/chown $${OVS_USER_ID##*:} /dev/hugepages'
> ExecStartPre=-/usr/bin/chmod 0775 /dev/hugepages
> @end_dpdk@
> ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
>
> Regards,
>
> Marcos Schwarz
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS 2.8.0
Hi Ben,
I couldn't find a working solution for supporting running ovs as root and as
another user.
There seems to be some difference when running ovs-vswithd without the --user
parameter and with --user=root:root which affects the permission to use UIO.
Only without --user I'm able to use UIO.
So my current fix includes to remove "--ovs-user=${OVS_USER_ID} \" from
ovs-vswitchd.service.
Comparing the logs from each execution the difference is that when using --user
the following error appears:
2018-01-05T19:33:08.285Z|00012|dpdk|ERR|EAL: Cannot obtain physical addresses:
No such file or directory. Only vfio will function.
My guess is that when the daemon is switch from native root:root to the --user
root:root it looses some permission related to /proc/self/pagemap. Do you have
any suggestion on how to move forward? One way around would be to define an
exception to not try to switch the user when the value is root:root.
Regards,
Marcos Schwarz
- Original Message -
From: "Ben Pfaff" <b...@ovn.org>
To: "Marcos Felipe Schwarz" <marcos.schw...@rnp.br>
Cc: ovs-discuss@openvswitch.org
Sent: Monday, November 27, 2017 6:31:39 PM
Subject: Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS
2.8.0
On Tue, Nov 21, 2017 at 12:08:51PM -0200, Marcos Felipe Schwarz wrote:
> Hi,
>
> The current solution for running OVS with non-root user in Fedora makes it
> not possible to support UIO drivers [1].
> Setting the user to root:root via /etc/sysconfig/openvswitch should be a
> solution, but it is also currently broken, since the systemd
> ovs-vswitchd.service is forcing the group :hugetlbfs to /dev/hugepages [2],
> which breaks root access to it.
> Would it be possible to change the permissions only if the user in not root?
> Currently I can only make UIO work on fedora removing this hardcoded
> permissions on the systemd files. I believe that either root:root should not
> conflict with the systemd script or be explicitly unsupported.
>
> [1] For Linux kernel 4.0 and newer, the ability to obtain physical page frame
> numbers for unprivileged users from /proc/self/pagemap was removed.
> Source.
> http://dpdk.org/browse/dpdk/commit/?id=cdc242f260e766bd95a658b5e0686a62ec04f5b0
> [2] ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages.
> https://github.com/openvswitch/ovs/blob/master/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
Are you able to submit a patch to solve the problem? It sounds like you
have a specific idea about what should be done.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS 2.8.0
Hi, The current solution for running OVS with non-root user in Fedora makes it not possible to support UIO drivers [1]. Setting the user to root:root via /etc/sysconfig/openvswitch should be a solution, but it is also currently broken, since the systemd ovs-vswitchd.service is forcing the group :hugetlbfs to /dev/hugepages [2], which breaks root access to it. Would it be possible to change the permissions only if the user in not root? Currently I can only make UIO work on fedora removing this hardcoded permissions on the systemd files. I believe that either root:root should not conflict with the systemd script or be explicitly unsupported. [1] For Linux kernel 4.0 and newer, the ability to obtain physical page frame numbers for unprivileged users from /proc/self/pagemap was removed. Source. http://dpdk.org/browse/dpdk/commit/?id=cdc242f260e766bd95a658b5e0686a62ec04f5b0 [2] ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages. https://github.com/openvswitch/ovs/blob/master/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in Regards, Marcos Schwarz Coordenador de P | R Coordinator Gerência de Redes para Experimentos (GRE) / Management of Network for Experiments Diretoria de Pesquisa & Desenvolvimento (DPD) / Research & Development Department RNP – Rede Nacional de Ensino e Pesquisa http://www.rnp.br | Telefone: +55 (19) 3787 3386 | Skype: marcos.f.sch Campinas - SP - Brasil | E-mail: marcos.schw...@rnp.br ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Can't match on CVLAN
Hi Eric, I resumed the testing today and found my error. I was applying other-config:vlan-limit=2 to the Bridge table and not to Open_vSwitch table. That made it work. 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: Tuesday, May 9, 2017 10:42:47 AM Subject: 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=3
Re: [ovs-discuss] Can't match on CVLAN
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? 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, > > 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
Re: [ovs-discuss] Can't match on CVLAN
I confirmed that the problem I reported applies to the the latest commit from yesterday on the master branch. 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 > in_port=1,dl_vlan=3217,actions=pop_vlan,set_field:3217->metadata,goto_table:1 > > ovs-ofctl -O OpenFlow13 add-flow br-oper0 > table=1,metadata=3204,in_port=1,dl_vlan=10,actions=pop_vlan,output:2 > ovs-ofctl -O OpenFlow13 add-flow br-oper0 > table=1,metadata=3204,in_port=1,dl_vlan=20,actions=pop_vlan,output:3 > ovs-ofctl -O OpenFlow13 add-flow br-oper0 > table=1,metadata=3217,in_port=1,dl_vlan=10,actions=pop_vlan,output:4 > ovs-ofctl -O OpenFlow13 add-flow br-oper0 > table=1,metadata=3217,in_port=1,dl_vlan=20,actions=pop_vlan,output:5 > > But as shown below, no flow is matching the rules from table 1. I created > some temporary flows to isolate the issue, and I figured that I can match the > CVLAN on table 1. > > cookie=0x0, duration=3435.754s, table=0, n_packets=788, n_bytes=67476, > in_port=1,dl_vlan=3204 actions=pop_vlan,set_field:0xc84->metadata,goto_table:1 > cookie=0x0, duration=3435.754s, table=0, n_packets=788, n_bytes=67476, > in_port=1,dl_vlan=3217 actions=pop_vlan,set_field:0xc91->metadata,goto_table:1 > > cookie=0x0,
Re: [ovs-discuss] Can't match on CVLAN
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 in_port=1,dl_vlan=3217,actions=pop_vlan,set_field:3217->metadata,goto_table:1 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3204,in_port=1,dl_vlan=10,actions=pop_vlan,output:2 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3204,in_port=1,dl_vlan=20,actions=pop_vlan,output:3 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3217,in_port=1,dl_vlan=10,actions=pop_vlan,output:4 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3217,in_port=1,dl_vlan=20,actions=pop_vlan,output:5 But as shown below, no flow is matching the rules from table 1. I created some temporary flows to isolate the issue, and I figured that I can match the CVLAN on table 1. cookie=0x0, duration=3435.754s, table=0, n_packets=788, n_bytes=67476, in_port=1,dl_vlan=3204 actions=pop_vlan,set_field:0xc84->metadata,goto_table:1 cookie=0x0, duration=3435.754s, table=0, n_packets=788, n_bytes=67476, in_port=1,dl_vlan=3217 actions=pop_vlan,set_field:0xc91->metadata,goto_table:1 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc84,in_port=1,dl_vlan=10 actions=pop_vlan,output:2 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc84,in_port=1,dl_vlan=20 actions=pop_vlan,output:2 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc91,in_port=1,dl_vlan=10 actions=pop_vlan,output:4 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc91,in_port=1,dl_vlan=20 actions=pop_vlan,output:5 Temporary Flows: cookie=0x0, duration=6.097s,table=1, n_packets=0, n_bytes=0, in_port=1,dl_vlan=10 actions=output:2 cookie=0x0, duration=6.883s,table=1, n_packets=4, n_bytes=356, metadata=0xc84,in_port=1 actions=output:2 All my ports are DPDK, and I'm working with OVS from master branch (april 29th) and DPDK 16.11. But have confirmed this issue with previous versions as 2.7.0 and 2.6.1. Follows the parameters from my setup. ovs-vsctl add-br br-oper0 -- set bridge br-oper0 datapath_type=netdev fail-mode=secure ovs-vsctl add-port br-oper0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk options:dpdk-devargs=:00:14.0 mtu_request=9600 ofpor
Re: [ovs-discuss] Can't match inner vlan
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: disc...@openvswitch.org Sent: Friday, May 5, 2017 7:24:09 PM Subject: Can't match inner vlan 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 in_port=1,dl_vlan=3217,actions=pop_vlan,set_field:3217->metadata,goto_table:1 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3204,in_port=1,dl_vlan=10,actions=pop_vlan,output:2 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3204,in_port=1,dl_vlan=20,actions=pop_vlan,output:3 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3217,in_port=1,dl_vlan=10,actions=pop_vlan,output:4 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3217,in_port=1,dl_vlan=20,actions=pop_vlan,output:5 But as shown below, no flow is matching the rules from table 1. I created some temporary flows to isolate the issue, and I figured that I can match the CVLAN on table 1. cookie=0x0, duration=3435.754s, table=0, n_packets=788, n_bytes=67476, in_port=1,dl_vlan=3204 actions=pop_vlan,set_field:0xc84->metadata,goto_table:1 cookie=0x0, duration=3435.754s, table=0, n_packets=788, n_bytes=67476, in_port=1,dl_vlan=3217 actions=pop_vlan,set_field:0xc91->metadata,goto_table:1 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc84,in_port=1,dl_vlan=10 actions=pop_vlan,output:2 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc84,in_port=1,dl_vlan=20 actions=pop_vlan,output:2 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc91,in_port=1,dl_vlan=10 actions=pop_vlan,output:4 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc91,in_port=1,dl_vlan=20 actions=pop_vlan,output:5 Temporary Flows: cookie=0x0, duration=6.097s,table=1, n_packets=0, n_bytes=0, in_port=1,dl_vlan=10 actions=output:2 cookie=0x0, duration=6.883s,table=1, n_packets=4, n_bytes=356, metadata=0xc84,in_port=1 actions=output:2 All my ports are DPDK, and I'm working with OVS from master branch (april 29th) and DPDK 16.11. But have confirmed this issue with previous versions as 2.7.0 and 2.6.1. Follows the parameters from my setup. ovs-vsctl add-br br-oper0 -- set bridge br-oper0 datapath_type=netdev fail-mode=secure ovs-vsctl add-port br-oper0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk options:dpdk-devargs=:00:14.0 mtu_request=9600 ofport=1 ovs-vsctl add-port br-oper0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk opti
[ovs-discuss] 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 in_port=1,dl_vlan=3217,actions=pop_vlan,set_field:3217->metadata,goto_table:1 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3204,in_port=1,dl_vlan=10,actions=pop_vlan,output:2 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3204,in_port=1,dl_vlan=20,actions=pop_vlan,output:3 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3217,in_port=1,dl_vlan=10,actions=pop_vlan,output:4 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3217,in_port=1,dl_vlan=20,actions=pop_vlan,output:5 But as shown below, no flow is matching the rules from table 1. I created some temporary flows to isolate the issue, and I figured that I can match the CVLAN on table 1. cookie=0x0, duration=3435.754s, table=0, n_packets=788, n_bytes=67476, in_port=1,dl_vlan=3204 actions=pop_vlan,set_field:0xc84->metadata,goto_table:1 cookie=0x0, duration=3435.754s, table=0, n_packets=788, n_bytes=67476, in_port=1,dl_vlan=3217 actions=pop_vlan,set_field:0xc91->metadata,goto_table:1 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc84,in_port=1,dl_vlan=10 actions=pop_vlan,output:2 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc84,in_port=1,dl_vlan=20 actions=pop_vlan,output:2 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc91,in_port=1,dl_vlan=10 actions=pop_vlan,output:4 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc91,in_port=1,dl_vlan=20 actions=pop_vlan,output:5 Temporary Flows: cookie=0x0, duration=6.097s,table=1, n_packets=0, n_bytes=0, in_port=1,dl_vlan=10 actions=output:2 cookie=0x0, duration=6.883s,table=1, n_packets=4, n_bytes=356, metadata=0xc84,in_port=1 actions=output:2 All my ports are DPDK, and I'm working with OVS from master branch (april 29th) and DPDK 16.11. But have confirmed this issue with previous versions as 2.7.0 and 2.6.1. Follows the parameters from my setup. ovs-vsctl add-br br-oper0 -- set bridge br-oper0 datapath_type=netdev fail-mode=secure ovs-vsctl add-port br-oper0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk options:dpdk-devargs=:00:14.0 mtu_request=9600 ofport=1 ovs-vsctl add-port br-oper0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk options:dpdk-devargs=:00:14.1 mtu_request=9600 ofport=2 ovs-vsctl add-port br-oper0 dpdk-p2 -- set Interface dpdk-p2 type=dpdk options:dpdk-devargs=:00:14.2 mtu_request=9600 ofport=3 ovs-vsctl add-port br-oper0 dpdk-p3 -- set Interface dpdk-p3 type=dpdk options:dpdk-devargs=:00:14.3 mtu_request=9600 ofport=4 ovs-vsctl add-port br-oper0 dpdk-p4 -- set Interface dpdk-p4 type=dpdk options:dpdk-devargs=:01:00.0 mtu_request=9600 ofport=5 I've also attached a pcap from the host at port 2, just to show that there is traffic with the CVLAN tag reaching there. Please let me know if there is a better way I can achieve this. Regards, Marcos Schwarz ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Can't match inner vlan
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 in_port=1,dl_vlan=3217,actions=pop_vlan,set_field:3217->metadata,goto_table:1 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3204,in_port=1,dl_vlan=10,actions=pop_vlan,output:2 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3204,in_port=1,dl_vlan=20,actions=pop_vlan,output:3 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3217,in_port=1,dl_vlan=10,actions=pop_vlan,output:4 ovs-ofctl -O OpenFlow13 add-flow br-oper0 table=1,metadata=3217,in_port=1,dl_vlan=20,actions=pop_vlan,output:5 But as shown below, no flow is matching the rules from table 1. I created some temporary flows to isolate the issue, and I figured that I can match the CVLAN on table 1. cookie=0x0, duration=3435.754s, table=0, n_packets=788, n_bytes=67476, in_port=1,dl_vlan=3204 actions=pop_vlan,set_field:0xc84->metadata,goto_table:1 cookie=0x0, duration=3435.754s, table=0, n_packets=788, n_bytes=67476, in_port=1,dl_vlan=3217 actions=pop_vlan,set_field:0xc91->metadata,goto_table:1 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc84,in_port=1,dl_vlan=10 actions=pop_vlan,output:2 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc84,in_port=1,dl_vlan=20 actions=pop_vlan,output:2 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc91,in_port=1,dl_vlan=10 actions=pop_vlan,output:4 cookie=0x0, duration=3471.941s, table=1, n_packets=0, n_bytes=0, metadata=0xc91,in_port=1,dl_vlan=20 actions=pop_vlan,output:5 Temporary Flows: cookie=0x0, duration=6.097s,table=1, n_packets=0, n_bytes=0, in_port=1,dl_vlan=10 actions=output:2 cookie=0x0, duration=6.883s,table=1, n_packets=4, n_bytes=356, metadata=0xc84,in_port=1 actions=output:2 All my ports are DPDK, and I'm working with OVS from master branch (april 29th) and DPDK 16.11. But have confirmed this issue with previous versions as 2.7.0 and 2.6.1. Follows the parameters from my setup. ovs-vsctl add-br br-oper0 -- set bridge br-oper0 datapath_type=netdev fail-mode=secure ovs-vsctl add-port br-oper0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk options:dpdk-devargs=:00:14.0 mtu_request=9600 ofport=1 ovs-vsctl add-port br-oper0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk options:dpdk-devargs=:00:14.1 mtu_request=9600 ofport=2 ovs-vsctl add-port br-oper0 dpdk-p2 -- set Interface dpdk-p2 type=dpdk options:dpdk-devargs=:00:14.2 mtu_request=9600 ofport=3 ovs-vsctl add-port br-oper0 dpdk-p3 -- set Interface dpdk-p3 type=dpdk options:dpdk-devargs=:00:14.3 mtu_request=9600 ofport=4 ovs-vsctl add-port br-oper0 dpdk-p4 -- set Interface dpdk-p4 type=dpdk options:dpdk-devargs=:01:00.0 mtu_request=9600 ofport=5 I've also attached a pcap from the host at port 2, just to show that there is traffic with the CVLAN tag reaching there. Please let me know if there is a better way I can achieve this. Regards, Marcos Schwarz out.pcap Description: Binary data ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
