Re: [ovs-discuss] Lost connectivity when having multiple ports

[Ben Pfaff]

On Mon, Jul 24, 2017 at 01:04:34PM +0200, Pablo Pousada wrote:
> I've been encountering an error on the testbed I'm building, where having
> multiple ports added to a ovs bridge blocks all outwards communication.
> 
> Example: Having the following setup, i have connectivity through the eth0.3
> port:
> 
> root@LEDE:~# ovs-vsctl show
> 41ae4f8f-55db-4cd0-8dd1-3e7b001d8f54
> Bridge "br0"
> Controller "tcp:192.168.1.151"
> Port "br0"
> Interface "br0"
> type: internal
> Port "eth0.3"
> Interface "eth0.3"
> 
> Whenever I add another port to that bridge, inward packages are received,
> but outward packages are never sent. The problem persists with or without
> controller.
> 
> ¿Does anyone have any info on where the problem might be?
> 
> I'm using Open vSwitch version 2.5.0 over LEDE.

This sounds like the second question here:
http://docs.openvswitch.org/en/latest/faq/issues/
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

[Joe Stringer]

On 8 August 2017 at 09:26, Darrell Ball  wrote:
>
>
>
>
> From:  on behalf of James Page
> 
> Date: Tuesday, August 8, 2017 at 2:49 AM
> To: "b...@openvswitch.org" 
> Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213
> 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
>
>
>
> Hi
>
>
>
> I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release
> for Ubuntu; we build and test two sets of binaries - a vanilla one and one
> with dpdk enabled.
>
>
>
> I see test failures on all of the "ofproto-dpif - conntrack" tests with the
> DPDK build and with the ovn ACL test (see attached logs).  Vanilla build is
> fine.
>
>
>
> James
>
>
>
> These are generic tests and should not be run with-dpdk set.
>
> If you run these tests --with-dpdk, some tests will consider the packets
> coming an actual dpdk interface, which they are not.
>
> In this case, the packets will be marked with a bad checksum.
>
>
>
> Are you able to run these tests as we do without “–with-dpdk” ?

Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly
just enables another netdevice implementation. Why would this affect
input/output with netdev-dummy devices?

For what it's worth, I tried a run of the testsuite with OVS built
"--with-dpdk" on branch-2.7 and it worked fine:
https://travis-ci.org/joestringer/openvswitch/jobs/262439494

The test failures for the first few are hard-failures (ie ovs uses
WAIT_UNTIL for something that never succeeds), examples below where
OVS was waiting to receive packets that never arrive:

../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2
'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
../../tests/ofproto-dpif.at:9018: hard failure

---

Some of the later failures are a bit more interesting:

../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2
'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid |
filter_flow_install
--- - 2017-08-08 09:39:36.051525087 +
+++ 
/build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout
2017-08-08 09:39:36.046218819 +
@@ -1,5 +1,4 @@
-ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
actions:drop
-ct_state(-new+est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:1
+ct_state(-new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
actions:drop
 
recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:ct(commit),2
 
recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:ct,recirc(0x1)

---

../../tests/ofproto-dpif.at:9738: ovs-appctl netdev-dummy/receive p1
'505400095054000a08004528258e40004006ff3d0a0101020a01010100020001396bb55e8cadbf8a501a5ec1'
../../tests/ofproto-dpif.at:9740: ovs-appctl revalidator/purge
../../tests/ofproto-dpif.at:9744: cat ofctl_monitor.log
--- /dev/null 2017-04-26 10:10:32.404961898 +
+++ 
/build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1225/stdout
2017-08-08 09:40:40.454215126 +
@@ -0,0 +1,22 @@
+NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54
ct_state=inv|trk,in_port=1 (via action) data_len=54 (unbuffered)
+tcp,vlan_tci=0x,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=ack
tcp_csum:629b
+NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=55
ct_state=inv|trk,in_port=1 (via action) data_len=55 (unbuffered)
+tcp,vlan_tci=0x,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=psh|ack
tcp_csum:5892
+NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54
ct_state=inv|trk,in_port=2 (via action) data_len=54 (unbuffered)

---

Perhaps the activation of DPDK code is somehow adding extra checks on
things like packet checksums, but the packet passing through are not
fully formed so they get marked as invalid?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

[Darrell Ball]

-Original Message-
From: Joe Stringer 
Date: Tuesday, August 8, 2017 at 3:43 PM
To: Darrell Ball 
Cc: James Page , "b...@openvswitch.org" 

Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 
1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

On 8 August 2017 at 09:26, Darrell Ball  wrote:
>
>
>
>
> From:  on behalf of James Page
> 
> Date: Tuesday, August 8, 2017 at 2:49 AM
> To: "b...@openvswitch.org" 
> Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213
> 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
>
>
>
> Hi
>
>
>
> I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 
release
> for Ubuntu; we build and test two sets of binaries - a vanilla one and one
> with dpdk enabled.
>
>
>
> I see test failures on all of the "ofproto-dpif - conntrack" tests with 
the
> DPDK build and with the ovn ACL test (see attached logs).  Vanilla build 
is
> fine.
>
>
>
> James
>
>
>
> These are generic tests and should not be run with-dpdk set.
>
> If you run these tests --with-dpdk, some tests will consider the packets
> coming an actual dpdk interface, which they are not.
>
> In this case, the packets will be marked with a bad checksum.
>
>
>
> Are you able to run these tests as we do without “–with-dpdk” ?

Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly
just enables another netdevice implementation. Why would this affect
input/output with netdev-dummy devices?

For what it's worth, I tried a run of the testsuite with OVS built
"--with-dpdk" on branch-2.7 and it worked fine:

https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262439494=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=2rYtIAwBngD_iZxhgs9_RxL9aNIlVqYJNRfdSppMEKw=j1JxZ5I8Yj0xapAPLtfpPqwTHiqQEUmUf2ZBdqdJkOo=
 

The test failures for the first few are hard-failures (ie ovs uses
WAIT_UNTIL for something that never succeeds), examples below where
OVS was waiting to receive packets that never arrive:

../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2

'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
../../tests/ofproto-dpif.at:9018: hard failure

---

Some of the later failures are a bit more interesting:

../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2

'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid |
filter_flow_install
--- - 2017-08-08 09:39:36.051525087 +
+++ 
/build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout
2017-08-08 09:39:36.046218819 +
@@ -1,5 +1,4 @@

-ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
actions:drop

-ct_state(-new+est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:1

+ct_state(-new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
actions:drop
 
recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:ct(commit),2
 
recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:ct,recirc(0x1)

---

../../tests/ofproto-dpif.at:9738: ovs-appctl netdev-dummy/receive p1

'505400095054000a08004528258e40004006ff3d0a0101020a01010100020001396bb55e8cadbf8a501a5ec1'
../../tests/ofproto-dpif.at:9740: ovs-appctl revalidator/purge
../../tests/ofproto-dpif.at:9744: cat ofctl_monitor.log
--- /dev/null 2017-04-26 10:10:32.404961898 +
+++ 
/build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1225/stdout
2017-08-08 09:40:40.454215126 +
@@ -0,0 +1,22 @@
+NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54
ct_state=inv|trk,in_port=1 (via action) data_len=54 (unbuffered)

+tcp,vlan_tci=0x,dl_src=50:54:00:00:00:0a,dl_dst=50:54:00:00:00:09,nw_src=10.1.1.2,nw_dst=10.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=2,tp_dst=1,tcp_flags=ack
tcp_csum:629b
+NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=55

Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

[Ben Pfaff]

On Tue, Aug 08, 2017 at 10:52:36PM +, Darrell Ball wrote:
> 
> 
> -Original Message-
> From: Joe Stringer 
> Date: Tuesday, August 8, 2017 at 3:43 PM
> To: Darrell Ball 
> Cc: James Page , "b...@openvswitch.org" 
> 
> Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 
> 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
> 
> On 8 August 2017 at 09:26, Darrell Ball  wrote:
> >
> >
> >
> >
> > From:  on behalf of James Page
> > 
> > Date: Tuesday, August 8, 2017 at 2:49 AM
> > To: "b...@openvswitch.org" 
> > Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 
> 1213
> > 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
> >
> >
> >
> > Hi
> >
> >
> >
> > I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 
> release
> > for Ubuntu; we build and test two sets of binaries - a vanilla one and 
> one
> > with dpdk enabled.
> >
> >
> >
> > I see test failures on all of the "ofproto-dpif - conntrack" tests with 
> the
> > DPDK build and with the ovn ACL test (see attached logs).  Vanilla 
> build is
> > fine.
> >
> >
> >
> > James
> >
> >
> >
> > These are generic tests and should not be run with-dpdk set.
> >
> > If you run these tests --with-dpdk, some tests will consider the packets
> > coming an actual dpdk interface, which they are not.
> >
> > In this case, the packets will be marked with a bad checksum.
> >
> >
> >
> > Are you able to run these tests as we do without “–with-dpdk” ?
> 
> Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly
> just enables another netdevice implementation. Why would this affect
> input/output with netdev-dummy devices?
> 
> For what it's worth, I tried a run of the testsuite with OVS built
> "--with-dpdk" on branch-2.7 and it worked fine:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262439494=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=2rYtIAwBngD_iZxhgs9_RxL9aNIlVqYJNRfdSppMEKw=j1JxZ5I8Yj0xapAPLtfpPqwTHiqQEUmUf2ZBdqdJkOo=
>  
> 
> The test failures for the first few are hard-failures (ie ovs uses
> WAIT_UNTIL for something that never succeeds), examples below where
> OVS was waiting to receive packets that never arrive:
> 
> ../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2
> 
> 'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
> ../../tests/ofproto-dpif.at:9018: hard failure
> 
> ---
> 
> Some of the later failures are a bit more interesting:
> 
> ../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2
> 
> 'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
> ../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid |
> filter_flow_install
> --- - 2017-08-08 09:39:36.051525087 +
> +++ 
> /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout
> 2017-08-08 09:39:36.046218819 +
> @@ -1,5 +1,4 @@
> 
> -ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
> actions:drop
> 
> -ct_state(-new+est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
> actions:1
> 
> +ct_state(-new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
> actions:drop
>  
> recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
> actions:ct(commit),2
>  
> recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
> actions:ct,recirc(0x1)
> 
> ---
> 
> ../../tests/ofproto-dpif.at:9738: ovs-appctl netdev-dummy/receive p1
> 
> '505400095054000a08004528258e40004006ff3d0a0101020a01010100020001396bb55e8cadbf8a501a5ec1'
> ../../tests/ofproto-dpif.at:9740: ovs-appctl revalidator/purge
> ../../tests/ofproto-dpif.at:9744: cat ofctl_monitor.log
> --- /dev/null 2017-04-26 10:10:32.404961898 +
> +++ 
> /build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1225/stdout
> 2017-08-08 09:40:40.454215126 +
> @@ -0,0 +1,22 @@
> +NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54
> 

Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

[Darrell Ball]

-Original Message-
From: Ben Pfaff 
Date: Tuesday, August 8, 2017 at 4:07 PM
To: Darrell Ball 
Cc: Joe Stringer , "b...@openvswitch.org" 
Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 
1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

On Tue, Aug 08, 2017 at 10:52:36PM +, Darrell Ball wrote:
> 
> 
> -Original Message-
> From: Joe Stringer 
> Date: Tuesday, August 8, 2017 at 3:43 PM
> To: Darrell Ball 
> Cc: James Page , "b...@openvswitch.org" 

> Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 
1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
> 
> On 8 August 2017 at 09:26, Darrell Ball  wrote:
> >
> >
> >
> >
> > From:  on behalf of James Page
> > 
> > Date: Tuesday, August 8, 2017 at 2:49 AM
> > To: "b...@openvswitch.org" 
> > Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 
1212 1213
> > 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
> >
> >
> >
> > Hi
> >
> >
> >
> > I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 
release
> > for Ubuntu; we build and test two sets of binaries - a vanilla one 
and one
> > with dpdk enabled.
> >
> >
> >
> > I see test failures on all of the "ofproto-dpif - conntrack" tests 
with the
> > DPDK build and with the ovn ACL test (see attached logs).  Vanilla 
build is
> > fine.
> >
> >
> >
> > James
> >
> >
> >
> > These are generic tests and should not be run with-dpdk set.
> >
> > If you run these tests --with-dpdk, some tests will consider the 
packets
> > coming an actual dpdk interface, which they are not.
> >
> > In this case, the packets will be marked with a bad checksum.
> >
> >
> >
> > Are you able to run these tests as we do without “–with-dpdk” ?
> 
> Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly
> just enables another netdevice implementation. Why would this affect
> input/output with netdev-dummy devices?
> 
> For what it's worth, I tried a run of the testsuite with OVS built
> "--with-dpdk" on branch-2.7 and it worked fine:
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262439494=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=2rYtIAwBngD_iZxhgs9_RxL9aNIlVqYJNRfdSppMEKw=j1JxZ5I8Yj0xapAPLtfpPqwTHiqQEUmUf2ZBdqdJkOo=
 
> 
> The test failures for the first few are hard-failures (ie ovs uses
> WAIT_UNTIL for something that never succeeds), examples below where
> OVS was waiting to receive packets that never arrive:
> 
> ../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2
> 
'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
> ../../tests/ofproto-dpif.at:9018: hard failure
> 
> ---
> 
> Some of the later failures are a bit more interesting:
> 
> ../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2
> 
'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
> ../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid |
> filter_flow_install
> --- - 2017-08-08 09:39:36.051525087 +
> +++ 
/build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout
> 2017-08-08 09:39:36.046218819 +
> @@ -1,5 +1,4 @@
> 
-ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
> actions:drop
> 
-ct_state(-new+est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
> actions:1
> 
+ct_state(-new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
> actions:drop
>  
recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
> actions:ct(commit),2
>  
recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
> 

Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

[Ben Pfaff]

On Tue, Aug 08, 2017 at 04:26:38PM +, Darrell Ball wrote:
> 
> 
> From:  on behalf of James Page 
> 
> Date: Tuesday, August 8, 2017 at 2:49 AM
> To: "b...@openvswitch.org" 
> Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 
> 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
> 
> Hi
> 
> I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release 
> for Ubuntu; we build and test two sets of binaries - a vanilla one and one 
> with dpdk enabled.
> 
> I see test failures on all of the "ofproto-dpif - conntrack" tests with the 
> DPDK build and with the ovn ACL test (see attached logs).  Vanilla build is 
> fine.
> 
> James
> 
> These are generic tests and should not be run with-dpdk set.
> If you run these tests --with-dpdk, some tests will consider the packets 
> coming an actual dpdk interface, which they are not.
> In this case, the packets will be marked with a bad checksum.

All of the tests in the testsuite should always pass, or be skipped,
regardless of configuration, so if some of the tests are inappropriate
for a given configuration then they need AT_SKIP_IF([...]) to ensure
that they get skipped.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Strange behaviour with VLANs and Bridges and ARP.

[Ricky]

I have run into a similar problem myself and have not found the 
solution. The ARP traffic from one direction makes it to OVS, but does 
not get sent to device it needs to go to. It my case OVS pretty much 
isn't sending any ARP packets out from itself except to the other OVS 
instances I have a GRE tunnel with. I'm running version 2.5.0.


Please let me know if you made any progress on your issue.

On 08/07/2017 07:19 PM, Schlacta, Christopher wrote:

Ping.  Anybody?  Hello?

On Wed, Aug 2, 2017 at 10:32 PM, Schlacta, Christopher
 wrote:

So this is a bit hard to explain, but I hope you'll follow.  I have
two hosts, density and densetsu.  they each host VMs and CEPH nodes
using libvirt and ceph and they're connected to a smart switch using
openvswitch and there are a bunch of VLANs.  5, 6, 10, 20, and 30.
Most "normal" traffic goes along VLAN 10.  That's just the LAN VLAN.
So here's what the ovs-vsctl show looks like on each host:


density:
aarcane@density:~$ sudo ovs-vsctl show
YubiKey for `aarcane':
f2ae0266-6cae-44f0-8ca5-9d6f66562ff4
 Bridge "br0"
 Port lan
 tag: 10
 Interface lan
 type: internal
 Port "vnet0"
 trunks: [5, 6, 10, 20, 30]
 Interface "vnet0"
 Port "eth1"
 Interface "eth1"
 Port "vnet1"
 trunks: [5, 6, 10, 20, 30]
 Interface "vnet1"
 Port "br0"
 Interface "br0"
 type: internal
 ovs_version: "2.7.0"


densetsu:
aarcane@densetsu:~$ sudo ovs-vsctl show
2d6843ee-2bb6-48b8-a979-ba7f64bf5ebc
 Bridge "br0"
 Port "eth0"
 Interface "eth0"
 Port lan
 tag: 10
 Interface lan
 type: internal
 Port "br0"
 Interface "br0"
 type: internal
 ovs_version: "2.7.0"


The problem is when I try to ping the opposite machine (densetsu to
density or vice versa), the ARP packets get sent with appropriate
information through BR0 and out the eth device all tagged with VLAN
10, but the *inbound* arp packet is never sent to the lan interface.
I see it at the br0 and the eth interface, but not the destination
host's lan interface.  Furthermore, the destination never seems to see
this or respond to it, so it's then impossible for the to initiate
contact without adding entries to the ethers file.

This is well and good, but it also means that other systems on the
network also cannot connect to them for purposes of administration and
management, and this is very problematic.

I've not made any changes to openflow.  They've been able to
communicate with each other for a long time.  This change happened
with a recent kernel upgrade.  Not sure how to fix it or if it's a
bug.  Again, note:  All IP traffic seems to work fine.  ICMP works
without issue, TCP, etc.  It's only the ARP protocol that seems to not
be passing inward when it should be.

___
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] Regarding CFM/OAM support in Openvswitch

[Ben Pfaff]

On Wed, Aug 09, 2017 at 03:12:22AM +, ankaiah.nallamek...@wipro.com wrote:
> Both BFD and CFM (CCM) can be used to monitor connectivity between a
> pair of Ethernet devices., Could you please share the major
> differences between BFD & CFM CCM in openvswitch.

They're both about the same.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] RSTP: ARP frames not flooded to internal interfaces when RSTP is enabled before virtual interfaces are created

[Matthias May]

Hi
I'm observing some strange behaviour when configuring RSTP in combination with 
internal interfaces other than the br
interface itself.

I have 3 interfaces (eth0, 1, 2)
eth1 and eth2 are used with other devices to form a ring (hence rstp is in use).
Since eth1 and eth2 are connected to a hardware switch which offloads unicast 
forwarding they have the protected flag
set to prevent duplication of broadcast/multicast frames.
eth0 is not connected.

I use the following commands to configure the bridge:

ovs-vsctl add-br br0
ovs-vsctl -- set bridge br0 other-config:hwaddr=00:14:5a:03:52:05
ovs-vsctl -- set Bridge br0 other_config:rstp-priority=32768
ovs-vsctl -- set Bridge br0 other_config:rstp-forward-delay=15
ovs-vsctl -- set Bridge br0 other_config:rstp-max-age=20
ovs-vsctl -- set Bridge br0 other_config:rstp-transmit-hold-count=6
ovs-vsctl -- set Bridge br0 rstp_enable=true
ip l s br0 down

ovs-vsctl add-port br0 eth0
ovs-vsctl -- set port eth0 trunks=[]
ovs-vsctl -- set port eth0 tag=[]
ovs-vsctl -- set port eth0 vlan_mode=trunk
ovs-vsctl -- set port eth0 protected=false
ovs-vsctl -- set Interface eth0 ofport_request=100
ovs-vsctl -- set Port eth0 other_config:rstp-port-priority=128
ovs-vsctl -- set Port eth0 other_config:rstp-port-auto-edge=true
ovs-vsctl -- remove Port eth0 other_config rstp-path-cost
ovs-vsctl -- set Port eth0 other_config:rstp-enable=true
ip l s eth0 up

ovs-vsctl add-port br0 eth1
ovs-vsctl -- set port eth1 trunks=[]
ovs-vsctl -- set port eth1 tag=[]
ovs-vsctl -- set port eth1 vlan_mode=trunk
ovs-vsctl -- set port eth1 protected=true
ovs-vsctl -- set Interface eth1 ofport_request=101
ovs-vsctl -- set Port eth1 other_config:rstp-port-priority=128
ovs-vsctl -- set Port eth1 other_config:rstp-port-auto-edge=false
ovs-vsctl -- remove Port eth1 other_config rstp-path-cost
ovs-vsctl -- set Port eth1 other_config:rstp-enable=true
ip l s eth1 up

ovs-vsctl add-port br0 eth2
ovs-vsctl -- set port eth2 trunks=[]
ovs-vsctl -- set port eth2 tag=[]
ovs-vsctl -- set port eth2 vlan_mode=trunk
ovs-vsctl -- set port eth2 protected=true
ovs-vsctl -- set Interface eth2 ofport_request=102
ovs-vsctl -- set Port eth2 other_config:rstp-port-priority=128
ovs-vsctl -- set Port eth2 other_config:rstp-port-auto-edge=false
ovs-vsctl -- remove Port eth2 other_config rstp-path-cost
ovs-vsctl -- set Port eth2 other_config:rstp-enable=true
ip l s eth2 up

ovs-vsctl add-port br0 br0.vlan0
ovs-vsctl -- set interface br0.vlan0 type=internal
ovs-vsctl -- set port br0.vlan0 tag=0
ovs-vsctl -- set interface br0.vlan0 "mac=\"00:14:5a:03:52:05\""
ip l s br0.vlan0 up
ip a a 192.168.1.20/24 brd + dev br0.vlan0

RSTP is enabled directly when creating the bridge to prevent a look before the 
interfaces are added to the bridge.

Resulting in:
root@RM4:~# ovs-dpctl show
system@ovs-system:
lookups: hit:190 missed:84 lost:
flows: 5
masks: hit:268 total:3 hit/pkt:0.98
port 0: ovs-system (internal)
port 1: br0 (internal)
port 2: eth0
port 3: eth1
port 4: eth2
port 5: br0.vlan0 (internal: open failed (File exists))

Notice that br0 is down and the IP is on br0.vlan0.
Now if I try to ping 192.168.1.20 ARP requests are not answered.
and I see in the datapath dump:

root@RM4:~# ovs-dpctl dump-flows
recirc_id(0),in_port(4),eth(dst=01:80:c2:00:00:00),eth_type(0/0x), 
packets:46, bytes:2760, used:1.417s,
actions:userspace(pid=4192251794,slow_path(stp))
recirc_id(0),in_port(3),eth(src=e8:39:35:34:d4:60,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.1.2,tip=192.168.1.20,op=1/0xff),
packets:70, bytes:4200, used:0.633s, actions:1
recirc_id(0),in_port(3),eth(src=00:14:5a:09:15:7c,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(frag=no),
 packets:31,
bytes:10602, used:0.225s, actions:1
recirc_id(0),in_port(3),eth(dst=01:80:c2:00:00:00),eth_type(0/0x), 
packets:47, bytes:2820, used:0.069s,
actions:userspace(pid=4192251794,slow_path(stp))

For some reason the ARP frames are not flooded to all ports as they should but 
only to port 1.


As a workaround I moved
ovs-vsctl -- set Bridge br0 rstp_enable=true
to the end and is executed after br0.vlan0 is created.
With this everything works as expected.
However this allows for a short window where the interfaces are already in the 
bridge but RSTP is not enabled yet.

--> commands:
ovs-vsctl add-br br0
ovs-vsctl -- set bridge br0 other-config:hwaddr=00:14:5a:03:52:05
ovs-vsctl -- set Bridge br0 other_config:rstp-priority=32768
ovs-vsctl -- set Bridge br0 other_config:rstp-forward-delay=15
ovs-vsctl -- set Bridge br0 other_config:rstp-max-age=20
ovs-vsctl -- set Bridge br0 other_config:rstp-transmit-hold-count=6
ip l s br0 down

ovs-vsctl add-port br0 eth0
ovs-vsctl -- set port eth0 trunks=[]
ovs-vsctl -- set port eth0 tag=[]
ovs-vsctl -- set port eth0 vlan_mode=trunk
ovs-vsctl -- set port eth0 protected=false
ovs-vsctl -- set Interface eth0 ofport_request=100
ovs-vsctl -- set Port eth0 

Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

[Darrell Ball]

From:  on behalf of James Page 

Date: Tuesday, August 8, 2017 at 2:49 AM
To: "b...@openvswitch.org" 
Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 
1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

Hi

I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release for 
Ubuntu; we build and test two sets of binaries - a vanilla one and one with 
dpdk enabled.

I see test failures on all of the "ofproto-dpif - conntrack" tests with the 
DPDK build and with the ovn ACL test (see attached logs).  Vanilla build is 
fine.

James

These are generic tests and should not be run with-dpdk set.
If you run these tests --with-dpdk, some tests will consider the packets coming 
an actual dpdk interface, which they are not.
In this case, the packets will be marked with a bad checksum.

Are you able to run these tests as we do without “–with-dpdk” ?

Thanks Darrell


Also tracking this in Ubuntu under [0].

Cheers

James

[0] https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1709272
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Regarding CFM/OAM support in Openvswitch

[Ben Pfaff]

On Tue, Aug 08, 2017 at 02:07:25PM +, ankaiah.nallamek...@wipro.com wrote:
> Ethernet CFM/OAM supports Loopback protocol(LBM) and Link Trace
> protocol(LTM), Is ovs is supporting these two protocols as well, if so
> could you please describe how to use these two protocols.

OVS doesn't support those.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] How does OVS ensure only the first packet of a flow is upcalled?

[Ben Pfaff]

On Fri, Jul 14, 2017 at 04:14:29PM +0800, 张克尧 wrote:
> The document of ovs says the datapath is a flow-based software
> switch. A flow consists of many packets. Datapath needs to handle
> every packet. When it does't match any datapath flows, it will do
> upcall. Vswitchd needs to handle upcalls and send netlink messages to
> datapath to install the datapath flows. But before the datapath flows
> are added, another packet of the same flow arrived, will the packet be
> upcalled? That means if I send packets at faster rate, more upcalls
> will be expected?

Yes, more than one packet in a flow can go through an upcall.  It's
unusual, though, because most flows start out with a single packet and
do not continue until they receive a response.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss