Re: [ovs-discuss] OVS Faucet tutorial broken
On Fri, 10 Aug 2018, 19:15 Matthias Ableidinger, wrote: > Hey all! > > I just tried the OVS Faucet tutorial > http://docs.openvswitch.org/en/latest/tutorials/faucet/ but since Faucet > 1.8.3 this does not work anymore. > From https://github.com/faucetsdn/faucet/releases/tag/1.8.3 : > * Only provision flows for ports that are known to be up (fixes stacking > when redundant links are down on initialization, among other cases) > which makes it that most of the rules discussed in the tutorial won't be > created. The tutorial works with 1.8.2. > > Also, the Dockerfile was renamed so > docker build -t faucet/faucet . > should be > docker build -t faucet/faucet -f Dockerfile.faucet . > Hi Matthias, Did you try mailing the faucet users list (faucet-us...@lists.geant.org)? They might be the best positioned to provide the steps necessary to have this work with newer faucet versions. Cheers, Joe ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Q: Using netfilter to classify packets in OVS ?
On 29 August 2017 at 07:32, sougol gheissi wrote: > Hello, > I have tried to implement something like the above issue, I want to use > netfilter to capture UDP packets, modify them and then send them to the OVS. > As you said you tried it and it works. My problem is, I send SIP packets to > the OVS, but when I try to print the destination port, as it is 5060, I get > 53, which is a DNS port. How did you do that? It sounds like you're received DNS traffic as well as your SIP traffic. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Conntrack issue in OVS (2.6)+DPDK
On 23 August 2017 at 03:03, Rohith Basavaraja wrote: > Hi, > > > > I see that if I have following rules, i.e not allow any new connections and > allow only established and related flows, > > > > cookie=0x691, duration=2819.230s, table=244, n_packets=2, n_bytes=196, > priority=50, ct_state=+new+trk,metadata=0x1a5300/0x1f00 > actions=drop > > cookie=0x690, duration=15546.577s, table=244, n_packets=0, n_bytes=0, > priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,220) > > cookie=0x690, duration=15546.552s, table=244, n_packets=3819, > n_bytes=431050, priority=62020,ct_state=-new+est-rel-inv+trk > actions=resubmit(,220) > > > > We are still seeing that new connections are getting allowed, we see this > behavior/issue only OVS + DPDK and not in OVS kernel mode. > > > > Wanted to check if this issue is already reported elsewhere or it’s new > issue. I haven't heard any reports like this before; could you come up with a minimal test case that exhibits this behaviour? It's hard to get a good sense of what's going on without the full set of rules being hit. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] [dpdk-dev] [ovs-dpdk-tests] where is ovs-dpdk test case?
On 17 August 2017 at 05:07, Kavanagh, Mark B wrote: > >>From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Sam >>Sent: Thursday, August 17, 2017 7:31 AM >>To: ovs-discuss@openvswitch.org; ovs-...@openvswitch.org; d...@dpdk.org > > Hi Sam, > > Just a heads-up that d...@dpdk.org is strictly for DPDK development threads - > I've removed it from this thread. > > Also, responses to your queries are inline. > > Thanks! > Mark > > >>Subject: [dpdk-dev] [ovs-dpdk-tests] where is ovs-dpdk test case? >> >>Hi all, >> >>I'm working with ovs-dpdk, I want to run ovs-dpdk test case. But I found >>there is no test case for 'netdev' type bridge and no test case for >>ovs-dpdk datapath(which is pmd_thread_main). > > Do you mean unit tests (as in OvS autotests), or integration tests? > > If the former, then unfortunately there are none at present within OvS (but > feel free to add some!); if you'd like to run integration tests, you could > take a look at VSPERF: https://etherpad.opnfv.org/p/vSwitchIntegrationTests. "make check" runs unit tests against the userspace datapath, and it should work with a DPDK-enabled build of OVS. I don't know how much it tests the DPDK-specific portions of this, however. For example, it won't use DPDK devices. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS megaflows
On the first point - it's a little more subtle than that. A traffic flow (eg, a connection) must arrive at OVS, the first packet is sent through userspace, which causes userspace to install a megaflow into the datapath. Subsequently, if any traffic which matches that megaflow arrives, it will directly 'hit' the megaflow entry and execute the associated actions without going to userspace. Typically we use "microflow" to refer to a packet headers description which exact-matches all known fields, while "megaflow" allows a mask to be applied in addition to this, which allows the traffic which would otherwise be handled by multiple microflows to instead be handled by a single megaflow. There is no dependency between megaflows and microflows. Cheers, Joe ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] getting build errors while building ovs2.7.0
On 11 August 2017 at 11:52, Prem Shankar Sharma via discuss wrote: > Hi, > I'm getting some build errors while trying to build ovs2.7.0 on redhat 7.2. > I cloned 2.7.0 from git and tried to run - make and make modules_install (to > build kernel module). The output of both of them is reporting some issues > like: Hi Prem, The kernel module that comes with OVS 2.7.0 doesn't support Redhat 7.2 - RHEL7.2 is newer than OVS 2.7. You can use the module that is distributed with RHEL (and not compile the version from OVS tree), or wait for the upcoming OVS 2.8 release that is expected later this month. Alternatively if you are happy running on the master version of OVS, you might consider just cloning and building the top of tree from github. Cheers, Joe ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS megaflows
The FAQ is referring to megaflows as well, the reasons are the same. Neither microflows nor megaflows can be pre-populated. On 14 August 2017 at 00:35, Sara Gittlin wrote: > I understand that this citation refers to the kernel microflows tables. > the kernel megaflows table *can be* pre-populated. Correct ? > Sara > > On Mon, Aug 14, 2017 at 9:31 AM, Sara Gittlin wrote: >> Thanks you Joe >> the following citation is in a contradiction to the idea of >> pre-populating megaflows in kernel datapath . >> this is from http://docs.openvswitch.org/en/latest/faq/design/ >> >> "Q: Can OVS populate the kernel flow table in advance instead of in >> reaction to packets? >> >> A: No. There are several reasons: >> >> Kernel flows are not as sophisticated as OpenFlow flows, which means >> that some OpenFlow policies could require a large number of kernel >> flows. The “conjunctive match” feature is an extreme example: the >> number of kernel flows it requires is the product of the number of >> flows in each dimension. >> With multiple OpenFlow flow tables and simple sets of actions, the >> number of kernel flows required can be as large as the product of the >> number of flows in each dimension. With more sophisticated actions, >> the number of kernel flows could be even larger. >> Open vSwitch is designed so that any version of OVS userspace >> interoperates with any version of the OVS kernel module. This forward >> and backward compatibility requires that userspace observe how the >> kernel module parses received packets. This is only possible in a >> straightforward way when userspace adds kernel flows in reaction to >> received packets." >> >> Thanks in advance - Sara >> >> On Mon, Jul 24, 2017 at 10:58 PM, Joe Stringer wrote: >>> On 23 July 2017 at 06:37, Sara Gittlin wrote: >>>> Hello, >>>> I understand that there is a support for megaflows in the kernel and >>>> netlink. >>>> I also understand that there is no megaflow implementation in ofproto. >>>> i.e. there is no implementation of compressing (if possible) all flows >>>> in ofproto table to megaflows and installing it in the datapath. is >>>> that correct ? >>> >>> That's right - rather than pre-populating a representation of the >>> entire OpenFlow state, the ofproto-dpif implementation uses an >>> "upcall" model where the datapath acts as a cache for forwarding >>> behaviour, and the cache is populated on-demand as traffic arrives. ___ 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
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] OVS megaflows
On 23 July 2017 at 06:37, Sara Gittlin wrote: > Hello, > I understand that there is a support for megaflows in the kernel and netlink. > I also understand that there is no megaflow implementation in ofproto. > i.e. there is no implementation of compressing (if possible) all flows > in ofproto table to megaflows and installing it in the datapath. is > that correct ? That's right - rather than pre-populating a representation of the entire OpenFlow state, the ofproto-dpif implementation uses an "upcall" model where the datapath acts as a cache for forwarding behaviour, and the cache is populated on-demand as traffic arrives. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Q: Using netfilter to classify packets in OVS ?
On 7 July 2017 at 15:20, Jean Tourrilhes wrote: > Hi, > > I want to classify/match packets in OVS based on some TCP > options, this is currently not supported by OVS but it is supported by > netfilter. The support for ConnTrack left me wondering if I could use > netfilter to match that field and then use the result of that in OVS. > Thanks in advance... Hi Jean, There's no native integration, but I could imagine that if Netfilter ran on the packets first then modified the skb mark field, then OVS ran later on that packet then plausibly you could match on the pkt_mark. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] error with openvswitch (dpif(handler2)|WARN|system@ovs-system: failed to put[create] (Invalid argument) ufid:)
Please don't drop the list. Does dmesg list any messages from the OVS module? Which versions of ovs-vswitchd and the openvswitch.ko module are you using? On 6 July 2017 at 03:06, Saroj Pandey wrote: > Hi sir, > > Below the detail Logs > > dpif(handler2)|WARN|system@ovs-system: failed to put[create] (Invalid > argument) ufid:68a252c5-eb36-4b01-b63e-a6bcd503 > skb_priority(0x6/0),in_port(1),skb_mark(0/0),eth(src=fa:16:3e:e8:e8:68,dst=01:00:5e:00:00:12),eth_type(0x0800),ipv4(src=169.254.192.2/0.0.0.0,dst=224.0.0.18/0.0.0.0,proto=112/0,tos=0xc0/0x3,ttl=255/0,frag=no), > actions:set(tunnel(tun_id=0x25,src=192.168.12.5,dst=192.168.12.4,ttl=64,tp_dst=4789,flags(df|key))),9,push_vlan(vid=1,pcp=0),3 > > > > dpif(handler2)|WARN|system@ovs-system: execute > set(tunnel(tun_id=0x25,src=192.168.12.5,dst=192.168.12.4,ttl=64,tp_dst=4789,flags(df|key))),9,push_vlan(vid=1,pcp=0),3 > failed (Invalid argument) on packet > ip,vlan_tci=0x,dl_src=fa:16:3e:e8:e8:68,dl_dst=01:00:5e:00:00:12,nw_src=169.254.192.2,nw_dst=224.0.0.18,nw_proto=112,nw_tos=192,nw_ecn=0,nw_ttl=255 > > > Thanks:- > S PANDEY > > On Thu, Jul 6, 2017 at 3:25 PM, Joe Stringer wrote: >> >> On 5 July 2017 at 23:44, Saroj Pandey wrote: >> > Dear Sir Kindly suggest me.How can resolve below the error? >> > >> > dpif(handler2)|WARN|system@ovs-system: failed to put[create] (Invalid >> > argument) ufid: >> >> The above line by itself doesn't provide much context. Are there any >> further lines below it? > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] error with openvswitch (dpif(handler2)|WARN|system@ovs-system: failed to put[create] (Invalid argument) ufid:)
On 5 July 2017 at 23:44, Saroj Pandey wrote: > Dear Sir Kindly suggest me.How can resolve below the error? > > dpif(handler2)|WARN|system@ovs-system: failed to put[create] (Invalid > argument) ufid: The above line by itself doesn't provide much context. Are there any further lines below it? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Issue with connection tracking for packets modified in pipeline
On 22 June 2017 at 16:08, Numan Siddique wrote: > > > On Jun 23, 2017 1:31 AM, "Joe Stringer" wrote: > > On 22 June 2017 at 04:16, Numan Siddique wrote: >> >> >> On Thu, Jun 22, 2017 at 5:45 AM, Joe Stringer wrote: >>> >>> On 21 June 2017 at 04:19, Numan Siddique wrote: >>> > >>> > >>> > On Tue, Jun 20, 2017 at 3:11 AM, Joe Stringer wrote: >>> >> >>> >> On 19 June 2017 at 00:37, Numan Siddique wrote: >>> >> > >>> >> > >>> >> > On Fri, Jun 16, 2017 at 11:22 PM, Joe Stringer wrote: >>> >> >> >>> >> >> On 15 June 2017 at 22:20, Numan Siddique >>> >> >> wrote: >>> >> >> > >>> >> >> > >>> >> >> > On Thu, Jun 15, 2017 at 5:06 PM, Aswin S >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> >>> >> >> >> Adding some more info here, Thanks Numan! for pointing to this. >>> >> >> >> >>> >> >> >> The issue I am facing looks similar to the one described in [1] >>> >> >> >> and >>> >> >> >> [2]. >>> >> >> >> But it seems the issue is not yet fixed. Is there a plan to fix >>> >> >> >> this >>> >> >> >> soon? >>> >> >> >> In Opendaylight security groups is implemented using >>> >> >> >> ovs-conntrack. >>> >> >> >> So >>> >> >> >> the >>> >> >> >> flow based router ping responder and floating IP translations >>> >> >> >> hits >>> >> >> >> this >>> >> >> >> issue. >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> [1]https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329542.html >>> >> >> >> [2]https://patchwork.ozlabs.org/patch/739796/ >>> >> >> >> >>> >> >> > >>> >> >> > The same issuse is also seen in OVN as pointed by Aswin. >>> >> >> > >>> >> >> > Joe - If you remember, we had a chat about this same issue during >>> >> >> > the >>> >> >> > Openstack Boston summit. >>> >> >> >>> >> >> Hi Numan, yeah I recall we had this discussion. I didn't have much >>> >> >> clarity on where we're at with this. Looking at patchwork, I >>> >> >> provided >>> >> >> some feedback on the RFC. The most straightforward approach seems >>> >> >> to >>> >> >> be adding a nf_ct_set(skb, NULL, 0); call for each of the 5tuple >>> >> >> "set" >>> >> >> actions in the datapath. >>> >> > >>> >> > >>> >> > Thanks. I will try it out and let you know how it went. >>> >> > I remember, I was suppose to provide more clarity after our >>> >> > discussion. >>> >> > My >>> >> > apologies. It slipped out of my head. >>> >> >>> >> No worries, let me know how you go. >>> > >>> > >>> > I tried this and it didn't work. In fact the function set_ipv4 (in >>> > datapath/actions.c) is not even called. >>> > >>> > Below is the flow which responds to ICMP request packet >>> > >>> > cookie=0x64913aa, duration=566.801s, table=17, n_packets=3, >>> > n_bytes=294, >>> > idle_age=144, >>> > >>> > priority=90,icmp,metadata=0x3,nw_dst=192.168.0.1,icmp_type=8,icmp_code=0 >>> > >>> > >>> > actions=push:NXM_OF_IP_SRC[],push:NXM_OF_IP_DST[],pop:NXM_OF_IP_SRC[],pop:NXM_OF_IP_DST[],load:0xff->NXM_NX_IP_TTL[],load:0->NXM_OF_ICMP_TYPE[],load:0x1->NXM_NX_REG10[0],resubmit(,18) >>> > >>> > Thanks >>> > Numan >>> >>> Hi Numan, >>> >>> How are you going about making these changes and testing them? Could >>> you double-check that the correct module was load
Re: [ovs-discuss] Nfqueue Support
On 23 June 2017 at 01:22, sougol gheissi wrote: > -- Forwarded message -- > From: "sougol gheissi" > Date: Jun 23, 2017 11:30 AM > Subject: Re: [ovs-discuss] Nfqueue Support > To: "Joe Stringer" > Cc: > >> Hello Joe, > >> Yes I have seen the presentation, but my question is what is the layer7 >> port that is mentioned there? The "actoon=output:1" just sends out the >> packet to the port number 1, how this can sent the packet to user-space?! I >> really need help on this. >> Actually how the packets are sent to user space? >> I would appreciate it, if you help me. >> Thanks. I imagine that you could achieve something like this with a tap device, or by having a regular device where you open an AF_PACKET socket. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Nfqueue Support
On 22 June 2017 at 14:15, sougol gheissi wrote: > Hello, > In another conference the Qosmos company claimed to process the packet for > DPI purpose, without adding any patch and just using conntrack, but the > question is how to do this, if it doesn't uses nfqueue?! :-? > Thanks. Please don't drop the list. If you're referring to the presentation at the OVS fall conference 2015, then the presentation describes how this works. Slides and video are available here: http://openvswitch.org/support/ovscon2015/ ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Issue with connection tracking for packets modified in pipeline
On 22 June 2017 at 04:16, Numan Siddique wrote: > > > On Thu, Jun 22, 2017 at 5:45 AM, Joe Stringer wrote: >> >> On 21 June 2017 at 04:19, Numan Siddique wrote: >> > >> > >> > On Tue, Jun 20, 2017 at 3:11 AM, Joe Stringer wrote: >> >> >> >> On 19 June 2017 at 00:37, Numan Siddique wrote: >> >> > >> >> > >> >> > On Fri, Jun 16, 2017 at 11:22 PM, Joe Stringer wrote: >> >> >> >> >> >> On 15 June 2017 at 22:20, Numan Siddique >> >> >> wrote: >> >> >> > >> >> >> > >> >> >> > On Thu, Jun 15, 2017 at 5:06 PM, Aswin S >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> Adding some more info here, Thanks Numan! for pointing to this. >> >> >> >> >> >> >> >> The issue I am facing looks similar to the one described in [1] >> >> >> >> and >> >> >> >> [2]. >> >> >> >> But it seems the issue is not yet fixed. Is there a plan to fix >> >> >> >> this >> >> >> >> soon? >> >> >> >> In Opendaylight security groups is implemented using >> >> >> >> ovs-conntrack. >> >> >> >> So >> >> >> >> the >> >> >> >> flow based router ping responder and floating IP translations >> >> >> >> hits >> >> >> >> this >> >> >> >> issue. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> [1]https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329542.html >> >> >> >> [2]https://patchwork.ozlabs.org/patch/739796/ >> >> >> >> >> >> >> > >> >> >> > The same issuse is also seen in OVN as pointed by Aswin. >> >> >> > >> >> >> > Joe - If you remember, we had a chat about this same issue during >> >> >> > the >> >> >> > Openstack Boston summit. >> >> >> >> >> >> Hi Numan, yeah I recall we had this discussion. I didn't have much >> >> >> clarity on where we're at with this. Looking at patchwork, I >> >> >> provided >> >> >> some feedback on the RFC. The most straightforward approach seems to >> >> >> be adding a nf_ct_set(skb, NULL, 0); call for each of the 5tuple >> >> >> "set" >> >> >> actions in the datapath. >> >> > >> >> > >> >> > Thanks. I will try it out and let you know how it went. >> >> > I remember, I was suppose to provide more clarity after our >> >> > discussion. >> >> > My >> >> > apologies. It slipped out of my head. >> >> >> >> No worries, let me know how you go. >> > >> > >> > I tried this and it didn't work. In fact the function set_ipv4 (in >> > datapath/actions.c) is not even called. >> > >> > Below is the flow which responds to ICMP request packet >> > >> > cookie=0x64913aa, duration=566.801s, table=17, n_packets=3, n_bytes=294, >> > idle_age=144, >> > priority=90,icmp,metadata=0x3,nw_dst=192.168.0.1,icmp_type=8,icmp_code=0 >> > >> > actions=push:NXM_OF_IP_SRC[],push:NXM_OF_IP_DST[],pop:NXM_OF_IP_SRC[],pop:NXM_OF_IP_DST[],load:0xff->NXM_NX_IP_TTL[],load:0->NXM_OF_ICMP_TYPE[],load:0x1->NXM_NX_REG10[0],resubmit(,18) >> > >> > Thanks >> > Numan >> >> Hi Numan, >> >> How are you going about making these changes and testing them? Could >> you double-check that the correct module was loaded when you ran the >> test? Given that the IP src and dst are being modified from the flow >> you described above, I think that the set_ipv4 function should be >> called for such flows. >> >> Some sanity checks: >> # modinfo openvswitch >> # find /lib/modules -name openvswitch.ko* | xargs ls -l >> >> Might want to double-check that your depmod.d settings are set >> correctly so it loads the new module instead of the one that comes >> with your kernel. >> # man depmod.d >> >> Of course, the above doesn't necessarily
Re: [ovs-discuss] Nfqueue Support
On 21 June 2017 at 21:51, Deepak S wrote: > Hello, > > > Does OVS support Nfqueue? I'm using version 2.7.0 and I did quite a bit of > search and didn't find any nfqueue related actions. Not at this stage. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Issue with connection tracking for packets modified in pipeline
On 21 June 2017 at 04:19, Numan Siddique wrote: > > > On Tue, Jun 20, 2017 at 3:11 AM, Joe Stringer wrote: >> >> On 19 June 2017 at 00:37, Numan Siddique wrote: >> > >> > >> > On Fri, Jun 16, 2017 at 11:22 PM, Joe Stringer wrote: >> >> >> >> On 15 June 2017 at 22:20, Numan Siddique wrote: >> >> > >> >> > >> >> > On Thu, Jun 15, 2017 at 5:06 PM, Aswin S >> >> > wrote: >> >> >> >> >> >> >> >> >> Adding some more info here, Thanks Numan! for pointing to this. >> >> >> >> >> >> The issue I am facing looks similar to the one described in [1] and >> >> >> [2]. >> >> >> But it seems the issue is not yet fixed. Is there a plan to fix >> >> >> this >> >> >> soon? >> >> >> In Opendaylight security groups is implemented using ovs-conntrack. >> >> >> So >> >> >> the >> >> >> flow based router ping responder and floating IP translations hits >> >> >> this >> >> >> issue. >> >> >> >> >> >> >> >> >> >> >> >> [1]https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329542.html >> >> >> [2]https://patchwork.ozlabs.org/patch/739796/ >> >> >> >> >> > >> >> > The same issuse is also seen in OVN as pointed by Aswin. >> >> > >> >> > Joe - If you remember, we had a chat about this same issue during the >> >> > Openstack Boston summit. >> >> >> >> Hi Numan, yeah I recall we had this discussion. I didn't have much >> >> clarity on where we're at with this. Looking at patchwork, I provided >> >> some feedback on the RFC. The most straightforward approach seems to >> >> be adding a nf_ct_set(skb, NULL, 0); call for each of the 5tuple "set" >> >> actions in the datapath. >> > >> > >> > Thanks. I will try it out and let you know how it went. >> > I remember, I was suppose to provide more clarity after our discussion. >> > My >> > apologies. It slipped out of my head. >> >> No worries, let me know how you go. > > > I tried this and it didn't work. In fact the function set_ipv4 (in > datapath/actions.c) is not even called. > > Below is the flow which responds to ICMP request packet > > cookie=0x64913aa, duration=566.801s, table=17, n_packets=3, n_bytes=294, > idle_age=144, > priority=90,icmp,metadata=0x3,nw_dst=192.168.0.1,icmp_type=8,icmp_code=0 > actions=push:NXM_OF_IP_SRC[],push:NXM_OF_IP_DST[],pop:NXM_OF_IP_SRC[],pop:NXM_OF_IP_DST[],load:0xff->NXM_NX_IP_TTL[],load:0->NXM_OF_ICMP_TYPE[],load:0x1->NXM_NX_REG10[0],resubmit(,18) > > Thanks > Numan Hi Numan, How are you going about making these changes and testing them? Could you double-check that the correct module was loaded when you ran the test? Given that the IP src and dst are being modified from the flow you described above, I think that the set_ipv4 function should be called for such flows. Some sanity checks: # modinfo openvswitch # find /lib/modules -name openvswitch.ko* | xargs ls -l Might want to double-check that your depmod.d settings are set correctly so it loads the new module instead of the one that comes with your kernel. # man depmod.d Of course, the above doesn't necessarily apply if you're making changes directly in your kernel tree and loading the module from there (for example, using insmod, or make modules_install into the original module path). Cheers, Joe ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Can you match on packet length?
On 19 June 2017 at 14:08, Keith Holleman via discuss wrote: > > Went to add a match rule based on packet length and couldn't find the right > term or syntax. Then I searched the ovs-ofctl man page and couldn't find > anything. Even more surprising was that I couldn't find an example of this > previously being asked on any OVS discussion groups. Couldn't find it in > the FAQ either. I know in stating so many places looked I will inevitably > get proven wrong but I did try. > > So.can you add a rule via ovs-ofctl to match on a packet's length? > Probably tricky because it would have to have greater-than and less-than > semantics and that doesn't play well with the fixed-length matches of > OpenFlow. Are there any extensions that enable this? Or any pointers to > previous discussions about it? I don't think there's any such support. The matching in the datapath is based on unique bit patterns and masks, so if you wanted to render range semantics into that then you would practically end up generating several matches, one for each bitpattern within the range. I could imagine that if the packet length were matchable then worst case we could end up generating a different datapath flow for each possible packet length (or at least one per power-of-two bit up to the argument for lt/gt). Perhaps in more limited situations, you could avoid massive microflow explosion, for example if you only wanted to match packets of size 1024-2043: pkt_size=0x0400/0xfc00 That is to say, match the packet size bit 2^10 (ie, 1024), match zero-value for bits 2^11 and up, and mask out (ignore) bits for 2^0 up to 2^9. To also match anything from 512 upwards, you would also need a match like this: pkt_size=0x0200/0xfe00 But if the match didn't align with power-of-two boundaries then the matching would get quite complicated. Cheers, Joe ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Issue with connection tracking for packets modified in pipeline
On 19 June 2017 at 00:37, Numan Siddique wrote: > > > On Fri, Jun 16, 2017 at 11:22 PM, Joe Stringer wrote: >> >> On 15 June 2017 at 22:20, Numan Siddique wrote: >> > >> > >> > On Thu, Jun 15, 2017 at 5:06 PM, Aswin S wrote: >> >> >> >> >> >> Adding some more info here, Thanks Numan! for pointing to this. >> >> >> >> The issue I am facing looks similar to the one described in [1] and >> >> [2]. >> >> But it seems the issue is not yet fixed. Is there a plan to fix this >> >> soon? >> >> In Opendaylight security groups is implemented using ovs-conntrack. So >> >> the >> >> flow based router ping responder and floating IP translations hits >> >> this >> >> issue. >> >> >> >> >> >> [1]https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329542.html >> >> [2]https://patchwork.ozlabs.org/patch/739796/ >> >> >> > >> > The same issuse is also seen in OVN as pointed by Aswin. >> > >> > Joe - If you remember, we had a chat about this same issue during the >> > Openstack Boston summit. >> >> Hi Numan, yeah I recall we had this discussion. I didn't have much >> clarity on where we're at with this. Looking at patchwork, I provided >> some feedback on the RFC. The most straightforward approach seems to >> be adding a nf_ct_set(skb, NULL, 0); call for each of the 5tuple "set" >> actions in the datapath. > > > Thanks. I will try it out and let you know how it went. > I remember, I was suppose to provide more clarity after our discussion. My > apologies. It slipped out of my head. No worries, let me know how you go. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Issue with connection tracking for packets modified in pipeline
On 15 June 2017 at 22:20, Numan Siddique wrote: > > > On Thu, Jun 15, 2017 at 5:06 PM, Aswin S wrote: >> >> >> Adding some more info here, Thanks Numan! for pointing to this. >> >> The issue I am facing looks similar to the one described in [1] and [2]. >> But it seems the issue is not yet fixed. Is there a plan to fix this soon? >> In Opendaylight security groups is implemented using ovs-conntrack. So the >> flow based router ping responder and floating IP translations hits this >> issue. >> >> [1]https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329542.html >> [2]https://patchwork.ozlabs.org/patch/739796/ >> > > The same issuse is also seen in OVN as pointed by Aswin. > > Joe - If you remember, we had a chat about this same issue during the > Openstack Boston summit. Hi Numan, yeah I recall we had this discussion. I didn't have much clarity on where we're at with this. Looking at patchwork, I provided some feedback on the RFC. The most straightforward approach seems to be adding a nf_ct_set(skb, NULL, 0); call for each of the 5tuple "set" actions in the datapath. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Issue with connection tracking for packets modified in pipeline
On 1 June 2017 at 05:23, Aswin S wrote: > Hi, > When SG is implemented using conntrack rules , TCP connection via FIP > between vms in the same compute is failing What is SG? Is FIP "floating IP"? > In my topology I have two vm on the same compute both having floating ip > associated with it and the fip translation is done using openflow rules. > > When using vm internal network ip it is working fine and I can ssh to the > other vm. > > The conntrack event logs are as follows (Src ip 10.100.5.5 Dest Ip > 10.100.5.12 >[NEW] tcp 6 120 SYN_SENT src=10.100.5.5 dst=10.100.5.12 sport=43724 > dport=22 [UNREPLIED] src=10.100.5.12 dst=10.100.5.5 sport=22 dport=43724 > zone=5001 > [UPDATE] tcp 6 60 SYN_RECV src=10.100.5.5 dst=10.100.5.12 sport=43724 > dport=22 src=10.100.5.12 dst=10.100.5.5 sport=22 dport=43724 zone=5001 > [UPDATE] tcp 6 432000 ESTABLISHED src=10.100.5.5 dst=10.100.5.12 > sport=43724 dport=22 src=10.100.5.12 dst=10.100.5.5 sport=22 dport=43724 > [ASSURED] zone=5001 > > > But when I use FIP(the TCP packets are marked as Invalid and dropped. > The SYN reaches the second vm which sends back the SYN ack and the status of > conntrack entry is updated at the destination. Though the SYN-ACK reaches > vm1 the conntrack state still remain UNREPLIED and the ack packet send to > vm2 is marked as invalid and dropped. In the pipeline the packet is > submitted to the conntrack both at egress and ingress side. The packet is > submitted to conntrack after the fip modification. > > The conntrack event logs (Vm1 10.100.5.5, 192.168.56.29, Vm2 10.100.5.12, > 192.168.56.23) > > [NEW] tcp 6 120 SYN_SENT src=10.100.5.12 dst=192.168.56.29 > sport=58218 dport=22 [UNREPLIED] src=192.168.56.29 dst=10.100.5.12 sport=22 > dport=58218 zone=5001 > [NEW] tcp 6 120 SYN_SENT src=192.168.56.23 dst=10.100.5.5 > sport=58218 dport=22 [UNREPLIED] src=10.100.5.5 dst=192.168.56.23 sport=22 > dport=58218 zone=5001 > [UPDATE] tcp 6 60 SYN_RECV src=192.168.56.23 dst=10.100.5.5 > sport=58218 dport=22 src=10.100.5.5 dst=192.168.56.23 sport=22 dport=58218 > zone=5001 It looks like you're modifying the destination address on traffic from VM1->VM2 before submitting to conntrack and modifying the source address on traffic from VM2->VM1 before submitting to conntrack, which means that conntrack is not seeing bidirection traffic between two physical IPs, nor is it seeing bidirectional traffic between floating IPs.. rather, it is seeing two unidirectional connections between either VM1's physical IP and VM2's FIP, or VM1's FIP and VM2's physical IP. The Linux connection tracker, when it sees unidirectional SYNACK, will classify it as invalid, leading to your drop. > The issue is not limited to TCP, if try with ICMP with FIP, the ping packet > from vm1 to vm2 will be always new state in the connection tracker. This > works(both TCP and ICMP) fine if the vm are two compute nodes. So is this an > issue when a modified packet in the pipeline is submitted to connection > tracker? Does netfilter/ovs conntrack check for any other field than src ip/ > port dest ip/port for marking a packet as reply pakcet? It deals with the actual packet contents when you execute the ct() action. > I am using ovs 2.7.0. I have reported an issue a while ago[1] which still > exsits and this seems to be related > > [1]https://mail.openvswitch.org/pipermail/ovs-discuss/2016-December/043228.html It looks like you're seeing events corresponding to modified packets according to your output above, so I don't see the relation to this other thread. Cheers, Joe ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] vxlan offload via dpif
On 1 June 2017 at 01:19, Santhosh Alladi wrote: > Hi Joe, > > Thank you for your reply. > In our solution, we are not using the linux vxlan driver, rather we are > having our own vxlan driver in our accelerator. So, for an accelerator which > is connected via dpif, how can we get the tunnel information for > decapsulating the packets? > > Also, can you brief me how will the vxlan device get the tunnel information > to decap the packet if the COLLECT_METADATA mode is enabled? Based on what I see in the Linux implementation, I'd expect that your vxlan driver's receive path should receive encapsulated vxlan packets so should have direct access to the relevant information. It is then responsible for extracting the metadata, decapsulating the packet, then providing it to the OVS processing path in the form it expects. If you're plugging into regular OVS kernel module, this should be metadata_dst attached to skb. By the time it gets up to the dpif layer, it should appear as a list of ovs_tunnel_key_attrs in the netlink-formatted key. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] vxlan offload via dpif
On 31 May 2017 at 06:27, Santhosh Alladi wrote: > Hi all, > > > > We are trying to configure our hardware accelerator using ovs via dpif. We > could achieve L2 forwarding using this setup. > > Now, we are trying to offload complete functionality of vxlan. In this > sense, how does vxlan processing take place in ovs-kernel. How can we get > the tunnel information to our hardware via dpif? The Linux kernel provides flow-based tunneling by attaching "metadata_dst" to the packet. For instance, when OVS kernel module wants to send a packet out a vxlan device, it attaches the metadata_dst to the skbuff and transmits on the vxlan device. The Linux stack then takes over in terms of encapsulating the packet with the provided metadata and performing a route lookup to determine the next (underlay) hop for the packet. On receive side, the vxlan device must be set up in COLLECT_METADATA mode and this sets up a receiver on the UDP socket which can receive the packet, decap, and attach the tunnel metadata as a metadata_dst before calling the device receive path. Then the packet is received in a similar way to any OVS-attached device, but OVS will check whether metadata_dst is set prior to performing flow table lookup. If there is metadata_dst, this needs to be received into the flow key. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Use the Open VSwitch to control a switch that doesn t support Open Flow
On 22 May 2017 at 04:43, Simone Aglianò wrote: > Hello, > > I would like to use Open vSwitch like a middleware between one SDN > Controller and my old switch that does not support the Open Flow Protocol. > > Do you think it is possibile? If yes, do you know which part of the Open > vSwitch I can change to parse the Open Flow Messages to commands for the > switch? There are switches which use Open vSwitch as an OpenFlow agent for controlling them. However, upstream OVS does not support this at all, so you'd have to make the modifications yourself to support some hardware. This document describes some details about porting OVS to other platforms: http://docs.openvswitch.org/en/latest/topics/porting/ ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Anyway to move/load data between ct_mark/ct_label and field/register ?
On 12 May 2017 at 01:32, Zang MingJie wrote: > The node is behind several load balancing nodes, I want to track which lb > node the connection is from by storing the Mac address of the lb node into > conntrack, and send the response packets to the same lb node by loading the > saved Mac into dest Mac. There are examples in tests/system-traffic.at that use ct(exec(move:...)). ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS conntrack
On 11 May 2017 at 19:46, Matt Warner wrote: > > On Thu, May 11, 2017 at 4:28 PM, Joe Stringer wrote: >> >> On 11 May 2017 at 13:38, Matt Warner wrote: >> > Good afternoon. I've been experimenting with OVS and the conntrack >> > feature. >> > I'd like to be able to use conntrack to maintain state. Specifically, in >> > the >> > man pages it says that this configuration should allow traffic to flow >> > only >> > one way. >> > >> > I was testing 2.5.x and hit problems, so I compiled and installed 2.7.0 >> > on >> > Ubuntu 16.04.2 LTS, but the problem persists. >> > >> > In testing, these rules don't seem to allow any traffic at all. I'd like >> > to >> > be able to pass traffic unidirectionally, in a stateful way, per the man >> > page: >> > >> > table=0,priority=1,action=drop >> > table=0,priority=10,arp,action=normal >> > table=0,priority=100,ip,ct_state=-trk,action=ct(table=1) >> > table=1,in_port=1,ip,ct_state=+trk+new,action=ct(commit),2 >> > table=1,in_port=1,ip,ct_state=+trk+est,action=2 >> > table=1,in_port=2,ip,ct_state=+trk+new,action=drop >> > table=1,in_port=2,ip,ct_state=+trk+est,action=1 >> > >> > >> > The conntrack kernel module is loaded, and on startup OVS indicates that >> > CT >> > is available: >> > >> > 2017-05-11T20:23:31Z|1|vlog|INFO|opened log file >> > /usr/local/var/log/openvswitch/ovsdb-server.log >> > 2017-05-11T20:23:31Z|1|vlog|INFO|opened log file >> > /usr/local/var/log/openvswitch/ovs-vswitchd.log >> > 2017-05-11T20:23:31Z|2|ovs_numa|INFO|Discovered 4 CPU cores on NUMA >> > node >> > 0 >> > 2017-05-11T20:23:31Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes and 4 >> > CPU >> > cores >> > >> > 2017-05-11T20:23:31Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock: >> > connecting... >> > >> > 2017-05-11T20:23:31Z|5|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock: >> > connected >> > 2017-05-11T20:23:31Z|6|ofproto_dpif|INFO|system@ovs-system: Datapath >> > supports recirculation >> > 2017-05-11T20:23:31Z|7|ofproto_dpif|INFO|system@ovs-system: MPLS >> > label >> > stack length probed as 1 >> > 2017-05-11T20:23:31Z|8|ofproto_dpif|INFO|system@ovs-system: Datapath >> > does not support truncate action >> > 2017-05-11T20:23:31Z|9|ofproto_dpif|INFO|system@ovs-system: Datapath >> > supports unique flow ids >> > 2017-05-11T20:23:31Z|00010|ofproto_dpif|INFO|system@ovs-system: Datapath >> > supports ct_state <- >> > 2017-05-11T20:23:31Z|00011|ofproto_dpif|INFO|system@ovs-system: Datapath >> > supports ct_zone >> > 2017-05-11T20:23:31Z|00012|ofproto_dpif|INFO|system@ovs-system: Datapath >> > supports ct_mark >> > 2017-05-11T20:23:31Z|00013|ofproto_dpif|INFO|system@ovs-system: Datapath >> > supports ct_label >> > 2017-05-11T20:23:31Z|00014|ofproto_dpif|INFO|system@ovs-system: Datapath >> > does not support ct_state_nat >> > 2017-05-11T20:23:31Z|1|ofproto_dpif_upcall(handler1)|INFO|received >> > packet on unassociated datapath port 0 >> > 2017-05-11T20:23:31Z|00015|bridge|INFO|bridge matt_bridge: added >> > interface >> > ens33 on port 1 >> > 2017-05-11T20:23:31Z|00016|bridge|INFO|bridge matt_bridge: added >> > interface >> > ens34 on port 2 >> > 2017-05-11T20:23:31Z|00017|bridge|INFO|bridge matt_bridge: added >> > interface >> > matt_bridge on port 65534 >> > 2017-05-11T20:23:31Z|00018|bridge|INFO|bridge matt_bridge: using >> > datapath ID >> > 00900b2aec9b >> > 2017-05-11T20:23:31Z|00019|connmgr|INFO|matt_bridge: added service >> > controller "punix:/usr/local/var/run/openvswitch/matt_bridge.mgmt" >> > >> > root@demo:~# lsmod |egrep 'open|conn' >> > openvswitch98304 4 >> > nf_defrag_ipv6 36864 1 openvswitch >> > nf_conntrack 106496 1 openvswitch >> > libcrc32c 16384 2 raid456,openvswitch >> > >> > >> > Here's the ruleset applied: >> > >> > root@demo:~# ovs-appctl bridge/dump-flows matt_bridge >> > duration=18s, n_packets=4, n_bytes=406, >> > priority=100,ct_state=-trk,ip,actions=ct(table=1) >> > duration=18s, n_packets=2, n_bytes=120, priority=10,arp,actions=NORMAL >
Re: [ovs-discuss] OVS conntrack
On 11 May 2017 at 13:38, Matt Warner wrote: > Good afternoon. I've been experimenting with OVS and the conntrack feature. > I'd like to be able to use conntrack to maintain state. Specifically, in the > man pages it says that this configuration should allow traffic to flow only > one way. > > I was testing 2.5.x and hit problems, so I compiled and installed 2.7.0 on > Ubuntu 16.04.2 LTS, but the problem persists. > > In testing, these rules don't seem to allow any traffic at all. I'd like to > be able to pass traffic unidirectionally, in a stateful way, per the man > page: > > table=0,priority=1,action=drop > table=0,priority=10,arp,action=normal > table=0,priority=100,ip,ct_state=-trk,action=ct(table=1) > table=1,in_port=1,ip,ct_state=+trk+new,action=ct(commit),2 > table=1,in_port=1,ip,ct_state=+trk+est,action=2 > table=1,in_port=2,ip,ct_state=+trk+new,action=drop > table=1,in_port=2,ip,ct_state=+trk+est,action=1 > > > The conntrack kernel module is loaded, and on startup OVS indicates that CT > is available: > > 2017-05-11T20:23:31Z|1|vlog|INFO|opened log file > /usr/local/var/log/openvswitch/ovsdb-server.log > 2017-05-11T20:23:31Z|1|vlog|INFO|opened log file > /usr/local/var/log/openvswitch/ovs-vswitchd.log > 2017-05-11T20:23:31Z|2|ovs_numa|INFO|Discovered 4 CPU cores on NUMA node > 0 > 2017-05-11T20:23:31Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes and 4 CPU > cores > 2017-05-11T20:23:31Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock: > connecting... > 2017-05-11T20:23:31Z|5|reconnect|INFO|unix:/usr/local/var/run/openvswitch/db.sock: > connected > 2017-05-11T20:23:31Z|6|ofproto_dpif|INFO|system@ovs-system: Datapath > supports recirculation > 2017-05-11T20:23:31Z|7|ofproto_dpif|INFO|system@ovs-system: MPLS label > stack length probed as 1 > 2017-05-11T20:23:31Z|8|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support truncate action > 2017-05-11T20:23:31Z|9|ofproto_dpif|INFO|system@ovs-system: Datapath > supports unique flow ids > 2017-05-11T20:23:31Z|00010|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_state <- > 2017-05-11T20:23:31Z|00011|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_zone > 2017-05-11T20:23:31Z|00012|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_mark > 2017-05-11T20:23:31Z|00013|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_label > 2017-05-11T20:23:31Z|00014|ofproto_dpif|INFO|system@ovs-system: Datapath > does not support ct_state_nat > 2017-05-11T20:23:31Z|1|ofproto_dpif_upcall(handler1)|INFO|received > packet on unassociated datapath port 0 > 2017-05-11T20:23:31Z|00015|bridge|INFO|bridge matt_bridge: added interface > ens33 on port 1 > 2017-05-11T20:23:31Z|00016|bridge|INFO|bridge matt_bridge: added interface > ens34 on port 2 > 2017-05-11T20:23:31Z|00017|bridge|INFO|bridge matt_bridge: added interface > matt_bridge on port 65534 > 2017-05-11T20:23:31Z|00018|bridge|INFO|bridge matt_bridge: using datapath ID > 00900b2aec9b > 2017-05-11T20:23:31Z|00019|connmgr|INFO|matt_bridge: added service > controller "punix:/usr/local/var/run/openvswitch/matt_bridge.mgmt" > > root@demo:~# lsmod |egrep 'open|conn' > openvswitch98304 4 > nf_defrag_ipv6 36864 1 openvswitch > nf_conntrack 106496 1 openvswitch > libcrc32c 16384 2 raid456,openvswitch > > > Here's the ruleset applied: > > root@demo:~# ovs-appctl bridge/dump-flows matt_bridge > duration=18s, n_packets=4, n_bytes=406, > priority=100,ct_state=-trk,ip,actions=ct(table=1) > duration=18s, n_packets=2, n_bytes=120, priority=10,arp,actions=NORMAL > duration=99s, n_packets=9, n_bytes=1124, priority=0,actions=NORMAL > duration=18s, n_packets=0, n_bytes=0, priority=1,actions=drop > table_id=1, duration=18s, n_packets=0, n_bytes=0, > ct_state=+new+trk,ip,in_port=1,actions=ct(commit),output:2 > table_id=1, duration=18s, n_packets=0, n_bytes=0, > ct_state=+new+trk,ip,in_port=2,actions=drop > table_id=1, duration=18s, n_packets=0, n_bytes=0, > ct_state=+est+trk,ip,in_port=1,actions=output:2 > table_id=1, duration=18s, n_packets=0, n_bytes=0, > ct_state=+est+trk,ip,in_port=2,actions=output:1 > table_id=254, duration=99s, n_packets=0, n_bytes=0, > priority=2,recirc_id=0,actions=drop > table_id=254, duration=99s, n_packets=0, n_bytes=0, > priority=0,reg0=0x1,actions=controller(reason=) > table_id=254, duration=99s, n_packets=4, n_bytes=406, > priority=0,reg0=0x2,actions=drop > table_id=254, duration=99s, n_packets=0, n_bytes=0, > priority=0,reg0=0x3,actions=drop > > > Trying to initiate traffic from either connected device increments counters > in table 0, but nothing seems to get to table 1: > > root@demo:~# ovs-ofctl dump-flows matt_bridge > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=127.968s, table=0, n_packets=25, n_bytes=2402, > idle_age=7, priority=100,ct_state=-trk,ip actions=ct(table=1) > cookie=0x0, duration=127.982s, table=0, n_packets=4, n_bytes=240, > idle_age=
Re: [ovs-discuss] huge amount of flows in datapath cache
On 27 April 2017 at 07:48, Avi Cohen (A) wrote: > Hello, > I want to run some stress tests with huge amount of flows in the datapath > cache. > I've tried to do it using openstack - and sdn controller - but not really > succeeded - eventually every time the system crashed That doesn't sound ideal. > Alternatively - I can create many namespaces and connect to OVS , > How to populate the datapath cache with many flows ? One method you can use is to disable megaflows, then use something like netperf TCP_CRR or run something like nmap to port scan through OVS. Each new connection would establish a separate flow. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Create ovs br0 failed using command "ovs-vsctl add-br br0"
On 26 April 2017 at 23:51, fukaige wrote: > Hi all, > > I use command "ovs-vsctl add-br br0" to create a bridge, but got below log: > > ovs-vsctl: Error detected while setting up 'br0'. See ovs-vswitchd log for > details. > > Then, I check the ovs-vswitched log for details: > > 2017-03-30T01:23:49.324Z|00056|ofproto_dpif|INFO|system@ovs-system: Datapath > supports recirculation > 2017-03-30T01:23:49.324Z|00057|ofproto_dpif|INFO|system@ovs-system: MPLS > label stack length probed as 1 > 2017-03-30T01:23:49.324Z|00058|ofproto_dpif|INFO|system@ovs-system: Datapath > supports unique flow ids > 2017-03-30T01:23:49.324Z|00059|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_state > 2017-03-30T01:23:49.324Z|00060|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_zone > 2017-03-30T01:23:49.325Z|00061|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_mark > 2017-03-30T01:23:49.325Z|00062|ofproto_dpif|INFO|system@ovs-system: Datapath > supports ct_label > 2017-03-30T01:23:49.400Z|1|ofproto_dpif_upcall(handler386)|INFO|received > packet on unassociated datapath port 0 > 2017-03-30T01:23:49.404Z|00063|netdev_linux|WARN|ethtool command > ETHTOOL_GFLAGS on network device br0 failed: No such device > 2017-03-30T01:23:49.404Z|00064|dpif|WARN|system@ovs-system: failed to add br0 > as port: No such device > 2017-03-30T01:23:49.404Z|00065|bridge|INFO|bridge br0: using datapath ID > 36dab10ee643 > 2017-03-30T01:23:49.404Z|00066|connmgr|INFO|br0: added service controller > "punix:/var/run/openvswitch/br0.mgmt" > > I delete the br0, then try to add it. But, got same error as above. > > Finally, I restart the thread ovs-vswitchd and ovsdb-server. Then, the error > disappear and ovs-vsctl add-br br0 work well. > > My question: > 1. Is any one meet with the same error? > 2. Is any one can offer some suggestions to reproduce the error? Are you able to reliably reproduce this with upstream OVS? Can you provide a list of commands that always hits this? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] GRE interfaces with OvS - what is gre0?
On 19 April 2017 at 11:19, Mick Tarsel wrote: > greetings, > > When I create a GRE port on my ovs bridge using ovs-vsctl add-port, lets say > I call the port gre1, the add-port command will execute successfully but it > will only create a gre0 interface (due to ip_gre kernel module). I have to > use iproute2 commands to first create the gre1 interface and _then_ add it > to my bridge with add-port command. Once I create the gre1 interface then > add it to my bridge, I still see the gre0 interface. This doesn't seem like > proper behavior. This gets somewhat into the details, but there are two ways to handle tunnel devices on Linux: One tunnel per netdevice or flow-based tunnelling where one device is used for all tunnels. OVS typically uses the flow-based tunnelling approach, where there is one gre_sys device that handles encap/decap. OVS will pass tunnel metadata with the packet when sending, or retreive tunnel metadata with the packet when receiving from that device. This method is more efficient when managing a large number of tunnels. You might also want to look at the output of 'ovs-dpctl show' for a view on how the OVS kernel module is configured by ovs-vswitchd. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] MAC in MAC support in openvswitch
On 17 April 2017 at 10:53, Bochra Boughzala wrote: > Hi, > > I haven't use openvswitch for a while and I was wondering if there is a > support to add rules for pushing an extra MAC header and create MAC in MAC > encapsulation as defined for example in PBB (IEEE 802.1ah). No-one has contributed a PBB implementation to OVS. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] disable flow-cache doesn't work
On 13 April 2017 at 09:22, f 62 wrote: > Hi, > > >This command "sudo ovs-appctl upcall/set-flow-limit 0" seems has no > effect to disable flow cache. > > Checked code to set may_put =0 to achieve same, > (https://mail.openvswitch.org/pipermail/ovs-dev/2014-January/279447.html), > but seems the patch is removed. That commit isn't a generic disable of datapath flows, it's determining to not insert flows based on some basic criteria (like, for instance, there is already such a flow). ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Packet drop when output to multiple VXLAN tunnel
On 13 April 2017 at 08:58, f 62 wrote: > Hi , > > OVS is dropping packet when packet is output to multiple VXLAN tunnel. I > see following error: > > 2017-04-13T15:49:30.112Z|03577|dpif(handler15)|WARN|system@ovs-system: > failed to put[create] (Invalid argument) > ufid:7e404481-148c-4cee-9495-237bdc62383d > recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(10),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=fa:16:3e:c0:5a:48,dst=fa:16:3e:4c:54:07),eth_type(0x0800),ipv4(src=51.0.0.8,dst=51.0.0.5,proto=6,tos=0/0xfc,ttl=64,frag=no),tcp(src=41564,dst=80),tcp_flags(0/0), > actions:set(eth(src=fa:16:3e:c0:5a:48,dst=fa:16:3e:db:81:44)),set(tunnel(tun_id=0x2,src=192.168.2.91,dst=192.168.2.177,ttl=64,flags(df|key))),push_mpls(label=511,tc=0,ttl=255,bos=1,eth_type=0x8847),8,set(tunnel(tun_id=0x2,src=192.168.2.91,dst=192.168.2.141,ttl=64,flags(df|key))),8,pop_mpls(eth_type=0x800),recirc(0x7) > 2017-04-13T15:49:30.112Z|03578|dpif(handler15)|WARN|system@ovs-system: > execute > set(eth(src=fa:16:3e:c0:5a:48,dst=fa:16:3e:db:81:44)),set(tunnel(tun_id=0x2,src=192.168.2.91,dst=192.168.2.177,ttl=64,flags(df|key))),push_mpls(label=511,tc=0,ttl=255,bos=1,eth_type=0x8847),8,set(tunnel(tun_id=0x2,src=192.168.2.91,dst=192.168.2.141,ttl=64,flags(df|key))),8,pop_mpls(eth_type=0x800),recirc(0x7) > failed (Invalid argument) on packet Hmm, once the push_mpls() happens, you should be able to output fine but I'm not sure if the subsequent set(tunnel(...)) would know how to change the tunnel attributes since it's now an MPLS packet. Maybe the userspace translation code needs to be taught to be a bit smarter to generate better actions for this case, eg something more like: set(eth(...)),set(tunnel(...)),push_mpls(...),output(...),pop_mpls(...),set(tunnel(...)),push_mpls(...),output(...),... ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Packet drop when output to multiple VXLAN tunnel
On 13 April 2017 at 08:58, f 62 wrote: > Hi , > > OVS is dropping packet when packet is output to multiple VXLAN tunnel. I > see following error: > > 2017-04-13T15:49:30.112Z|03577|dpif(handler15)|WARN|system@ovs-system: > failed to put[create] (Invalid argument) > ufid:7e404481-148c-4cee-9495-237bdc62383d > recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(10),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=fa:16:3e:c0:5a:48,dst=fa:16:3e:4c:54:07),eth_type(0x0800),ipv4(src=51.0.0.8,dst=51.0.0.5,proto=6,tos=0/0xfc,ttl=64,frag=no),tcp(src=41564,dst=80),tcp_flags(0/0), > actions:set(eth(src=fa:16:3e:c0:5a:48,dst=fa:16:3e:db:81:44)),set(tunnel(tun_id=0x2,src=192.168.2.91,dst=192.168.2.177,ttl=64,flags(df|key))),push_mpls(label=511,tc=0,ttl=255,bos=1,eth_type=0x8847),8,set(tunnel(tun_id=0x2,src=192.168.2.91,dst=192.168.2.141,ttl=64,flags(df|key))),8,pop_mpls(eth_type=0x800),recirc(0x7) > 2017-04-13T15:49:30.112Z|03578|dpif(handler15)|WARN|system@ovs-system: > execute > set(eth(src=fa:16:3e:c0:5a:48,dst=fa:16:3e:db:81:44)),set(tunnel(tun_id=0x2,src=192.168.2.91,dst=192.168.2.177,ttl=64,flags(df|key))),push_mpls(label=511,tc=0,ttl=255,bos=1,eth_type=0x8847),8,set(tunnel(tun_id=0x2,src=192.168.2.91,dst=192.168.2.141,ttl=64,flags(df|key))),8,pop_mpls(eth_type=0x800),recirc(0x7) > failed (Invalid argument) on packet > tcp,vlan_tci=0x,dl_src=fa:16:3e:c0:5a:48,dl_dst=fa:16:3e:4c:54:07,nw_src=51.0.0.8,nw_dst=51.0.0.5,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=41564,tp_dst=80,tcp_flags=syn > tcp_csum:e1d6 > mtu 0 > > > These are 2 flows which classifies packet: > > cookie=0x0, duration=91.547s, table=5, n_packets=4, n_bytes=296, > idle_age=63, priority=0,ip,dl_dst=fa:16:3e:db:81:44 > actions=push_mpls:0x8847,load:0x1ff->OXM_OF_MPLS_LABEL[],set_mpls_ttl(255),mod_vlan_vid:3,output:2,resubmit(8,7) > > cookie=0x0, duration=72.231s, table=7, n_packets=4, n_bytes=296, > idle_age=60, in_port=8 > actions=strip_vlan,pop_mpls:0x0800,move:NXM_NX_REG0[]->NXM_OF_ETH_DST[0..31],move:NXM_NX_REG1[0..9]->NXM_OF_ETH_DST[32..41],push_mpls:0x8847,load:0x1fe->OXM_OF_MPLS_LABEL[],set_mpls_ttl(254),mod_vlan_vid:3,output:2 > > > However, when output to single tunnel, traffic is fine. Are there any further log messages or details in 'dmesg' output? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Slowness on neighbour learning
On 6 April 2017 at 11:57, Mika Väisänen wrote: > Hello, > > Is it normal OVS behaviour that neighbour update (MAC moving from OVS switch > port to another) can cause 100-500 ms break to traffic? Is there any way to > configure it to be faster? > > In my case a Linux host is connected with two bonded Ethernets to server > running OVS 2.5.2 switch. When I change the active bonding slave from the > Linux host, it causes 100-500 ms break to traffic between the Linux host and > other hosts on the network. In case I run the same test with HW switch, there > is no noticeable traffic break at all. > > While investigating this, I found some strangeness in the way how MAC is > learned by OVS. In the following example I have moved the active slave from > interface eno3 to eno4. It seems correct (hander51), but then revalidator56 > updates the MAC to be found from the old port again: > > 2017-04-06T09:51:25.179Z|00339|ofproto_dpif_xlate(handler51)|DBG|bridge swu0: > learned that 02:11:61:61:70:25 is on port eno4 in VLAN 4 > 2017-04-06T09:51:25.179Z|00344|ofproto_dpif_xlate(handler51)|DBG|bridge swu0: > learned that 02:11:61:61:70:25 is on port eno4 in VLAN 5 > 2017-04-06T09:51:25.179Z|00349|ofproto_dpif_xlate(handler51)|DBG|bridge swu0: > learned that 02:11:61:61:70:25 is on port eno4 in VLAN 64 > 2017-04-06T09:51:25.247Z|00065|ofproto_dpif_xlate(revalidator56)|DBG|bridge > swu0: learned that 02:11:61:61:70:25 is on port eno3 in VLAN 4 > 2017-04-06T09:51:25.247Z|00066|ofproto_dpif_xlate(revalidator56)|DBG|bridge > swu0: learned that 02:11:61:61:70:25 is on port eno3 in VLAN 5 > 2017-04-06T09:51:25.249Z|00067|ofproto_dpif_xlate(revalidator56)| DBG |bridge > swu0: learned that 02:11:61:61:70:25 is on port eno4 in VLAN 4 > > Why is revalidator refreshing old neighbour information? Could it be causing > the slowness or is it totally irrelevant? I wonder if there's a race that happens here. Let's say that at T0, revalidator runs, forwarding is all correct, and the datapath flows are all fine. At T1, a packet arrives for eno3 VLAN 4, and is forwarded correctly. There's now one packet attributed to the datapath flow which revalidator will need to translate and attribute stats for. At T2, the active slave is shifted from eno3 to eno4. Traffic starts to flow over eno4, so you see the handler threads setting up new flows to handle this traffic (correctly). At T3, the revalidator thread wakes up, and starts dumping all of the datapath flows. When it finds the flow that was hit in T1, it will translate this flow, attribute stats, and execute side effects such as learning the MAC. If it learnt the MAC at the exact moment that the packet arrived, then it would have correctly learned that the mac existed on eno3. However, it's not aware that the traffic has since shifted to eno4, so it attributes and learns on eno3. The revalidator thread continues to dump the datapath flows and finds the one that handles the traffic now on eno4, and translates that one which also has traffic. This makes the learning happen again on eno4. Thereafter, I'm guessing that you don't send the traffic on eno3 so there will be no packets to attribute, no MAC should be learnt, and eventually the revalidator will time out the flow. It may be possible to mitigate this is if there were to be some sort of 'learning ratelimit' where a MAC that shifts to a new interface cannot be relearnt for X seconds. It could try to be smart and track the previous interface, then if the MAC shifts to a new interface we don't perform learning for the previous interface, or it could be something a bit more general as just 'don't learn a particular MAC more than once a second'. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] IPFIX crash
On 5 April 2017 at 22:24, Neelakantam Gaddam wrote: > While testing the IPFIX feature with openvswitch-2.6.1, observed the below > crash when traffic is on. > > [ 347.143417] BUG: unable to handle kernel NULL pointer dereference at > (null) > [ 347.143452] IP: [] dst_cache_get_ip4+0xc/0x50 > [openvswitch] > [ 347.143484] PGD 0 > [ 347.143493] Oops: [#1] SMP > [ 347.143506] Modules linked in: vhost_net vhost macvtap macvlan > vport_geneve(OE) vport_gre(OE) vport_vxlan(OE) openvswitch(OE) > nf_conntrack_ipv6 nf_nat_ipv6 nf_defrag_ipv6 geneve gre libcrc32c > xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat > nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack > nf_conntrack ipt_REJECT tun bridge stp llc ebtable_filter ebtables > ip6table_filter ip6_tables iptable_filter fuse dm_mirror dm_region_hash > dm_log dm_mod intel_powerclamp coretemp intel_rapl kvm_intel ixgbe(OE) kvm > iTCO_wdt crc32_pclmul ipmi_ssif ipmi_devintf iTCO_vendor_support ses > ghash_clmulni_intel enclosure ipmi_si vxlan ip6_udp_tunnel udp_tunnel > aesni_intel mei_me sg sb_edac dcdbas edac_core lpc_ich mei shpchp wmi > mfd_core acpi_power_meter lrw gf128mul glue_helper > [ 347.143809] ablk_helper cryptd pcspkr ipmi_msghandler nfsd auth_rpcgss > nfs_acl lockd grace sunrpc ip_tables ext4 mbcache jbd2 sr_mod cdrom sd_mod > crc_t10dif crct10dif_generic mgag200 syscopyarea sysfillrect sysimgblt > drm_kms_helper ttm crct10dif_pclmul drm crct10dif_common ahci crc32c_intel > libahci igb dca libata i2c_algo_bit ptp i2c_core megaraid_sas pps_core [last > unloaded: liquidio_ovs] > [ 347.143960] CPU: 4 PID: 3818 Comm: vhost-3811 Tainted: G OE > 3.10.0-327.el7.x86_64 #1 > [ 347.143993] Hardware name: Dell Inc. PowerEdge T630/0W9WXC, BIOS 1.1.4 > 11/04/2014 > [ 347.144019] task: 880847ec1700 ti: 8808516f8000 task.ti: > 8808516f8000 > [ 347.144043] RIP: 0010:[] [] > dst_cache_get_ip4+0xc/0x50 [openvswitch] > [ 347.144079] RSP: 0018:8808516fb5d8 EFLAGS: 00010246 > [ 347.144097] RAX: RBX: 880849023210 RCX: > 880849023208 > [ 347.144120] RDX: RSI: 880849023210 RDI: > > [ 347.144144] RBP: 8808516fb5e8 R08: 0a04a8c0 R09: > 880849023210 > [ 347.144167] R10: 880849023e00 R11: 8808516fb890 R12: > > [ 347.144190] R13: 8800784d8c00 R14: R15: > 8808514568f8 > [ 347.144214] FS: () GS:88085e48() > knlGS: > [ 347.144240] CS: 0010 DS: ES: CR0: 80050033 > [ 347.144259] CR2: CR3: 00081c865000 CR4: > 001427e0 > [ 347.144283] DR0: DR1: DR2: > > [ 347.144306] DR3: DR6: 0ff0 DR7: > 0400 > [ 347.144329] Stack: > [ 347.144337] 880849023210 8808516fb658 > a04f6b0a > [ 347.144365] 0a04a8c04d5e1de0 8800 8808516fb658 > 81524289 > [ 347.144393] 020e0e0e6400 030e0e0e 80da67a9 > 880849023208 > [ 347.144421] Call Trace: > [ 347.144436] [] vxlan_get_route.isra.41+0xea/0x130 > [openvswitch] > [ 347.144464] [] ? __skb_get_hash+0x39/0x160 > [ 347.144487] [] ovs_vxlan_fill_metadata_dst+0x170/0x1e0 > [openvswitch] > [ 347.144517] [] ovs_dev_fill_metadata_dst+0x9e/0xd0 > [openvswitch] > [ 347.144544] [] output_userspace+0xfe/0x180 > [openvswitch] > [ 347.144569] [] do_execute_actions+0x63d/0x8f0 > [openvswitch] > [ 347.144594] [] ovs_execute_actions+0x41/0x130 > [openvswitch] > [ 347.145578] [] ovs_dp_process_packet+0x94/0x140 > [openvswitch] > [ 347.146549] [] ovs_vport_receive+0x73/0xd0 > [openvswitch] > [ 347.147510] [] ? enqueue_task_fair+0x402/0x6c0 > [ 347.148470] [] ? sched_clock_cpu+0x85/0xc0 > [ 347.149432] [] ? check_preempt_curr+0x75/0xa0 > [ 347.150378] [] ? ttwu_do_wakeup+0x19/0xd0 > [ 347.151316] [] ? > ttwu_do_activate.constprop.84+0x5d/0x70 > [ 347.152249] [] ? try_to_wake_up+0x1b6/0x300 > [ 347.153168] [] ? __wake_up+0x44/0x50 > [ 347.154090] [] internal_dev_xmit+0x24/0x60 > [openvswitch] > [ 347.155012] [] dev_hard_start_xmit+0x171/0x3b0 > [ 347.155919] [] sch_direct_xmit+0x104/0x200 > [ 347.156800] [] dev_queue_xmit+0x236/0x570 > [ 347.157662] [] macvlan_start_xmit+0x3c/0xc0 [macvlan] > [ 347.158503] [] dev_hard_start_xmit+0x171/0x3b0 > [ 347.159327] [] sch_direct_xmit+0x104/0x200 > [ 347.160127] [] dev_queue_xmit+0x236/0x570 > [ 347.160901] [] macvtap_get_user+0x414/0x720 [macvtap] > [ 347.161658] [] macvtap_sendmsg+0x2b/0x30 [macvtap] > [ 347.162391] [] handle_tx+0x2fc/0x550 [vhost_net] > [ 347.163111] [] handle_tx_kick+0x15/0x20 [vhost_net] > [ 347.163807] [] vhost_worker+0xfb/0x1e0 [vhost] > [ 347.164489] [] ? vhost_dev_reset_owner+0x50/0x50 > [vhost] > [ 347.165165] [] kthread+0xcf/0xe0 > [ 347.165
Re: [ovs-discuss] Cannot set MTU > 1500 on OVS port with kernel 4.10
On 31 March 2017 at 14:46, Ian Pilcher wrote:
> BZ here - https://bugzilla.redhat.com/show_bug.cgi?id=1438069
>
> Wondering, though, if this is expected behavior, and I need to do
> something specific to enable larger frames on an OVS bridge with kernel
> 4.10.
I suspect this was fixed in upstream net-next commit 425df17ce3a2
("openvswitch: Set internal device max mtu to ETH_MAX_MTU.").
Not sure what the backporting status of this patch is, or whether
Fedora picked it up yet.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Userspace match+action Revalidation
On 28 March 2017 at 00:05, Advith Nagappa wrote: > I am sorry, I should have been more specific. > > I meany Userspace ovs without a Kernel module.. Yes, this is what the datapath does. It doesn't make a difference if using kernel or userspace datapath. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Userspace match+action Revalidation
On 25 March 2017 at 03:05, Advith Nagappa wrote: > Hello, > > > Is there a mechanism in OVS which ensures that actions for a particular rule > need not be translated each time. Yes, this is what the datapath does. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] RSTP for OVS in mininet
On 21 March 2017 at 13:43, Haitham Ghalwash wrote: > Hi all, > > I am trying to test RSTP on a mininet topology. when running > > sudo ovs-vsctl set Bridge s1 rstp_enable=true > > I am getting the following error > > ovs-vsctl: Bridge does not contain a column whose name matches "rstp_enable" > > the STP is running OK, but I am unable to set the RSTP. > > any suggestions? > > could the problem be due to the type of switch I am using? I tried both > cls=OVSKernelSwitch and cls=OVSSwitch, while adding my switches. > > my OVS is version 2.0 which is installed by default with mininet 2.1.1 OVS 2.0 is ancient and does not include RSTP. You'll need to use newer OVS. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [openvswitch 2.7.90] testsuite: 2180 failed
Hi Nick, Looks like there's another report of trouble with this test below. Would you be able to take a look? On 20 March 2017 at 07:44, Aynur Shakirov wrote: > For latest master the OVS build of deb package unsuccessfully ends because > test "flush the fdb and mdb when topology changed" is fail. Test added to > git in commit 427e9751f30067357262f58fdf5af55df4b6debf > > Env: Ubuntu 16.04.1 with latest updates, compiler is gcc 5.3.1, dpdk > enabled. > > Log: http://paste.ubuntu.com/24215426/ > > Thanks. > > -- > Sincerely, > Aynur Shakirov, 26. > TIONIX RUS. > Planet Earth, Solar System, Milky Way. > > ___ > 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] OVS 2.7 on Ubuntu
On 16 March 2017 at 10:23, Guru Shetty wrote: > > > On 15 March 2017 at 10:58, Shivaram Mysore > wrote: >> >> Does anyone know where I can get OVS 2.7 packages for Ubuntu 16.10 or when >> they would be available? > > > It is straightforward to build your own packages. > http://docs.openvswitch.org/en/latest/intro/install/debian/ For what it's worth, the WAND research group at University of Waikato typically package up the latest OVS versions pretty quickly after release for a variety of Debian/Ubuntu platforms: http://packages.wand.net.nz/ ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Kernel 4.10.* supported in 2.7?
On 28 February 2017 at 10:44, Marko Weber wrote: > What about the idea of supported Kernels at top of Release notes? > Interesting maybe for a lot ppl. > > Can anyone tell me if 2.7 Supports 4.10.* ? One thing to note is that the ovs userspace should work with any kernel version; it's only the DKMS kernel module (out-of-tree) that comes with the OVS source which has limited support. Those that are concerned with this will find out soon enough when they try to build their own custom versions of OVS. I would expect that most users install OVS from their distribution, which typically do not use the DKMS module. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] ovs-vswitchd cpu always 100%, slave's change_seq value can't be updated.
On 17 February 2017 at 02:27, 张胜 wrote: > I use openvswitch-2.3.1 ,when my server run serveral months, ovs-vswitchd > run at 100%. I see some bugfixes in OVS 2.3.3 that look related, I suggest upgrading. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] BFD not working with RSTP, suggesting fix
On 15 February 2017 at 05:18, Mika Väisänen wrote: > Hello, > > I have discovered that RSTP and BFD do not work together. When BFD is > enabled on a link, it first assumes that the link is down and informs this > to RSTP. RSTP then puts that link to DISABLED state (similar as if carrier > was lost). > > BFD tries to send its messages over the link, but as RSTP considers port is > DISABLED and therefore not forwarding, no messages are allowed through. This > means BFD will never get its forwarding state to true even the link itself > was working. Therefore RSTP port will remain in DISABLED state forever. > > Seems that the problem is in ofproto-dpif-xlate.c. On openvswitch-2.5.1 I > have overcome the problem with following patch: Hi Mika, thanks for taking a look at this! Would you mind resubmitting in standard git format-patch(1) format, to the ovs-dev list, including a sign-off line? Patches on ovs-discuss aren't tracked through the usual systems so it's easier for developers to miss them. If you haven't done this before, there's documentation here about what the patch should look like: http://docs.openvswitch.org/en/latest/internals/contributing/submitting-patches/ ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] high cpu with revalidator threads
On 3 February 2017 at 14:31, Vijay Sampath wrote: > Hi Joe, > > Thanks for the reply; I will play with limiting the number of flows. > > So what would be the way to wildcard src/dst MACs? Is there another type of > action I can specify. If you know a priori where you want packets to go based on port, vlan, etc then you can configure flows such as "ovs-ofctl add-flow in_port=1,vlan_vid=1,actions=2" to send packets from port 1 with vlan vid 1 to port 2. See also http://openvswitch.org/support/dist-docs/ovs-ofctl.8.html http://openvswitch.org/support/dist-docs/ovs-fields.7.html ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] high cpu with revalidator threads
On 3 February 2017 at 14:26, Joe Stringer wrote: > On 3 February 2017 at 11:25, Vijay Sampath via discuss > wrote: >> We have a default rule in ovs which I assume makes it behave like a regular >> L2 switch >> >> cookie=0x0, duration=71407.425s, table=0, n_packets=33577078, >> n_bytes=38722336595, idle_age=0, hard_age=65534, priority=0 actions=NORMAL >> >> Through a traffic generator we are sending unknown unicast traffic/broadcast >> traffic to/from about 1 hosts at say 500 pkts/sec. We see that this >> causes really high CPU utilization with the revalidator threads as shown: >> >> PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ >> COMMAND >> 1522 root 20 0 413360 55972 3916 S 85.4 0.7 603:29.96 >> revalidator8 >> 1521 root 20 0 413360 55972 3916 R 79.7 0.7 616:24.68 >> revalidator9 >> >> >> And the following logs are seen in ovs-vswitchd.log >> >> 2017-02-02T21:27:15.474Z|9|poll_loop(revalidator23)|INFO|wakeup due to >> [POLLIN] on fd 52 (FIFO pipe:[23153437]) at lib/ovs-thread.c:306 (54% CPU >> usage) >> 2017-02-02T21:27:15.530Z|00014|poll_loop(revalidator22)|INFO|wakeup due to >> [POLLIN] on fd 50 (FIFO pipe:[23153436]) at lib/ovs-thread.c:306 (58% CPU >> usage) >> 2017-02-02T21:27:15.532Z|00015|poll_loop(revalidator22)|INFO|wakeup due to >> [POLLIN] on fd 50 (FIFO pipe:[23153436]) at lib/ovs-thread.c:306 (58% CPU >> usage) >> 2017-02-02T21:27:21.444Z|00016|poll_loop(revalidator22)|INFO|Dropped 242 log >> messages in last 5 seconds (most recently, 0 seconds ago) due to excessive >> rate >> 2017-02-02T21:27:21.445Z|00017|poll_loop(revalidator22)|INFO|wakeup due to >> [POLLIN] on fd 50 (FIFO pipe:[23153436]) at lib/ovs-thread.c:306 (73% CPU >> usage) >> 2017-02-02T21:27:27.471Z|00010|poll_loop(revalidator23)|INFO|Dropped 190 log >> messages in last 6 seconds (most recently, 0 seconds ago) due to excessive >> rate >> 2017-02-02T21:27:27.471Z|00011|poll_loop(revalidator23)|INFO|wakeup due to >> [POLLIN] on fd 52 (FIFO pipe:[23153437]) at lib/ovs-thread.c:306 (82% CPU >> usage) >> 2017-02-02T21:27:33.439Z|00012|poll_loop(revalidator23)|INFO|Dropped 195 log >> messages in last 6 seconds (most recently, 0 seconds ago) due to excessive >> rate >> 2017-02-02T21:27:33.439Z|00013|poll_loop(revalidator23)|INFO|wakeup due to >> [POLLIN] on fd 52 (FIFO pipe:[23153437]) at lib/ovs-thread.c:306 (88% CPU >> usage) >> 2017-02-02T21:27:39.479Z|00014|poll_loop(revalidator23)|INFO|Dropped 203 log >> messages in last 6 seconds (most recently, 0 seconds ago) due to excessive >> rate >> 2017-02-02T21:27:39.479Z|00015|poll_loop(revalidator23)|INFO|wakeup due to >> [POLLIN] on fd 52 (FIFO pipe:[23153437]) at lib/ovs-thread.c:306 (78% CPU >> usage) >> 2017-02-02T21:27:45.469Z|00016|poll_loop(revalidator23)|INFO|Dropped 239 log >> messages in last 6 seconds (most recently, 0 seconds ago) due to excessive >> rate >> 2017-02-02T21:27:45.469Z|00017|poll_loop(revalidator23)|INFO|wakeup due to >> [POLLIN] on fd 52 (FIFO pipe:[23153437]) at lib/ovs-thread.c:306 (80% CPU >> usage) >> 2017-02-02T21:27:51.733Z|00018|poll_loop(revalidator22)|INFO|Dropped 213 log >> messages in last 7 seconds (most recently, 1 seconds ago) due to excessive >> rate >> 2017-02-02T21:27:51.733Z|00019|poll_loop(revalidator22)|INFO|wakeup due to >> 422-ms timeout at ofproto/ofproto-dpif-upcall.c:917 (71% CPU usage) >> >> Are there any tips to improve OVS performance under such traffic, where the >> kernel cache may be constantly thrashed? > > Revalidator threads are pretty much designed to keep as many flows in > the datapath as it can, consuming additional CPU if necessary to do > so, with a maximum number of datapath flows around 200,000. I see that > you've limited this to 1 core using the n-revalidator-threads, another > way would to be also set the flow-limit option in the same > other_config column. This limits the number of flows that will exist > in the datapath; if this is low enough, then revalidators won't need > to spend so much CPU maintaining the flows, their statistics, > correctness, etc. YMMV. > >> Is there a way to wildcard Layer 2 information in the packets and purely >> forward packets based on vlan, port, so that the kernel cache undergoes less >> thrashing? > > Yes, you should be able to wildcard the src/dst MACs. Oh, I should clarify, I don't think this is compatible with the NORMAL action; that needs to specify MACs because it performs MAC learning. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] high cpu with revalidator threads
On 3 February 2017 at 11:25, Vijay Sampath via discuss wrote: > We have a default rule in ovs which I assume makes it behave like a regular > L2 switch > > cookie=0x0, duration=71407.425s, table=0, n_packets=33577078, > n_bytes=38722336595, idle_age=0, hard_age=65534, priority=0 actions=NORMAL > > Through a traffic generator we are sending unknown unicast traffic/broadcast > traffic to/from about 1 hosts at say 500 pkts/sec. We see that this > causes really high CPU utilization with the revalidator threads as shown: > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ > COMMAND > 1522 root 20 0 413360 55972 3916 S 85.4 0.7 603:29.96 > revalidator8 > 1521 root 20 0 413360 55972 3916 R 79.7 0.7 616:24.68 > revalidator9 > > > And the following logs are seen in ovs-vswitchd.log > > 2017-02-02T21:27:15.474Z|9|poll_loop(revalidator23)|INFO|wakeup due to > [POLLIN] on fd 52 (FIFO pipe:[23153437]) at lib/ovs-thread.c:306 (54% CPU > usage) > 2017-02-02T21:27:15.530Z|00014|poll_loop(revalidator22)|INFO|wakeup due to > [POLLIN] on fd 50 (FIFO pipe:[23153436]) at lib/ovs-thread.c:306 (58% CPU > usage) > 2017-02-02T21:27:15.532Z|00015|poll_loop(revalidator22)|INFO|wakeup due to > [POLLIN] on fd 50 (FIFO pipe:[23153436]) at lib/ovs-thread.c:306 (58% CPU > usage) > 2017-02-02T21:27:21.444Z|00016|poll_loop(revalidator22)|INFO|Dropped 242 log > messages in last 5 seconds (most recently, 0 seconds ago) due to excessive > rate > 2017-02-02T21:27:21.445Z|00017|poll_loop(revalidator22)|INFO|wakeup due to > [POLLIN] on fd 50 (FIFO pipe:[23153436]) at lib/ovs-thread.c:306 (73% CPU > usage) > 2017-02-02T21:27:27.471Z|00010|poll_loop(revalidator23)|INFO|Dropped 190 log > messages in last 6 seconds (most recently, 0 seconds ago) due to excessive > rate > 2017-02-02T21:27:27.471Z|00011|poll_loop(revalidator23)|INFO|wakeup due to > [POLLIN] on fd 52 (FIFO pipe:[23153437]) at lib/ovs-thread.c:306 (82% CPU > usage) > 2017-02-02T21:27:33.439Z|00012|poll_loop(revalidator23)|INFO|Dropped 195 log > messages in last 6 seconds (most recently, 0 seconds ago) due to excessive > rate > 2017-02-02T21:27:33.439Z|00013|poll_loop(revalidator23)|INFO|wakeup due to > [POLLIN] on fd 52 (FIFO pipe:[23153437]) at lib/ovs-thread.c:306 (88% CPU > usage) > 2017-02-02T21:27:39.479Z|00014|poll_loop(revalidator23)|INFO|Dropped 203 log > messages in last 6 seconds (most recently, 0 seconds ago) due to excessive > rate > 2017-02-02T21:27:39.479Z|00015|poll_loop(revalidator23)|INFO|wakeup due to > [POLLIN] on fd 52 (FIFO pipe:[23153437]) at lib/ovs-thread.c:306 (78% CPU > usage) > 2017-02-02T21:27:45.469Z|00016|poll_loop(revalidator23)|INFO|Dropped 239 log > messages in last 6 seconds (most recently, 0 seconds ago) due to excessive > rate > 2017-02-02T21:27:45.469Z|00017|poll_loop(revalidator23)|INFO|wakeup due to > [POLLIN] on fd 52 (FIFO pipe:[23153437]) at lib/ovs-thread.c:306 (80% CPU > usage) > 2017-02-02T21:27:51.733Z|00018|poll_loop(revalidator22)|INFO|Dropped 213 log > messages in last 7 seconds (most recently, 1 seconds ago) due to excessive > rate > 2017-02-02T21:27:51.733Z|00019|poll_loop(revalidator22)|INFO|wakeup due to > 422-ms timeout at ofproto/ofproto-dpif-upcall.c:917 (71% CPU usage) > > Are there any tips to improve OVS performance under such traffic, where the > kernel cache may be constantly thrashed? Revalidator threads are pretty much designed to keep as many flows in the datapath as it can, consuming additional CPU if necessary to do so, with a maximum number of datapath flows around 200,000. I see that you've limited this to 1 core using the n-revalidator-threads, another way would to be also set the flow-limit option in the same other_config column. This limits the number of flows that will exist in the datapath; if this is low enough, then revalidators won't need to spend so much CPU maintaining the flows, their statistics, correctness, etc. YMMV. > Is there a way to wildcard Layer 2 information in the packets and purely > forward packets based on vlan, port, so that the kernel cache undergoes less > thrashing? Yes, you should be able to wildcard the src/dst MACs. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow eviction based on LRU
On 25 January 2017 at 23:32, Avi Cohen (A) wrote: > > >> -Original Message- >> From: ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss- >> boun...@openvswitch.org] On Behalf Of Joe Stringer >> Sent: Wednesday, 25 January, 2017 8:47 PM >> To: Avi Cohen (A) >> Cc: ovs-discuss@openvswitch.org >> Subject: Re: [ovs-discuss] Flow eviction based on LRU >> >> On 24 January 2017 at 23:55, Avi Cohen (A) wrote: >> > Thanks Joe, >> > 1. so the only flows-eviction process (from datapath cache) is >> implemented in udpif_revalidator thread ? deleting flows that exceed 10s >> idle time ? >> >> Yes. Alternatively if flow dump duration is long (takes ~1s to dump all >> flows), >> then additional heuristics will kick in to delete low-throughput flows, see >> should_revalidate(). Furthermore, if any configuration or OpenFlow changes >> then that thread will delete related datapath flows. >> >> > 2. Where is the implementation of http://openvswitch.org/ovs- >> vswitchd.conf.db.5.pdf ? >> > This intends to be a LRU approximation >> >> Can you be more specific where in the 58-page document you're referring >> to? It's possible the documentation is a little out of sync with the current >> implementation. > [Avi Cohen (A)] > Joe - look at page 36 - pasted below: - specially look at the pseudo LRU > eviction algorithm 3 steps > > overflow_policy: optional string, either refuse or evict > Controls the switch’s behavior when an OpenFlow flow table modification > request would add > flows in excess of flow_limit. The supported values are: > refuse Refuse to add the flow or flows. This is also the default policy when > overflow_policy is > unset. > evict Delete the flow that will expire soonest. See groups for details. > groups: set of strings > When overflow_policy is evict, this controls how flows are chosen for > eviction when the flow table > would otherwise exceed flow_limit flows. Its value is a set of NXM fields or > sub-fields, each > of which takes one of the forms field[] or field[start..end], e.g. > NXM_OF_IN_PORT[]. Please > see nicira−ext.h for a complete list of NXM field names. > When a flow must be evicted due to overflow, the flow to evict is chosen > through an approximation > of the following algorithm: > 1. Divide the flows in the table into groups based on the values of the > specified fields or sub- > fields, so that all of the flows in a given group have the same values for > those fields. If a flow > does not specify a given field, that field’s value is treated as 0. > 2. Consider the flows in the largest group, that is, the group that contains > the greatest number of > flows. If two or more groups all have the same largest number of flows, > consider the flows in > all of those groups. > 3. Among the flows under consideration, choose the flow that expires soonest > for eviction. > The eviction process only considers flows that have an idle timeout or a hard > timeout. That is, > eviction never deletes permanent flows. (Permanent flows do count against > flow_limit.) > Open vSwitch ignores any inv alid or unknown field specifications. > When overflow_policy is not evict, this column has no effect. OK, this is talking about something different from what I was referring to. This is about OpenFlow flow table rule eviction, which ofproto_configure_table() will provide more details. This has nothing to do with the datapath flow cache and revalidator threads. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow eviction based on LRU
On 24 January 2017 at 23:55, Avi Cohen (A) wrote: > Thanks Joe, > 1. so the only flows-eviction process (from datapath cache) is implemented > in udpif_revalidator thread ? deleting flows that exceed 10s idle time ? Yes. Alternatively if flow dump duration is long (takes ~1s to dump all flows), then additional heuristics will kick in to delete low-throughput flows, see should_revalidate(). Furthermore, if any configuration or OpenFlow changes then that thread will delete related datapath flows. > 2. Where is the implementation of > http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf ? > This intends to be a LRU approximation Can you be more specific where in the 58-page document you're referring to? It's possible the documentation is a little out of sync with the current implementation. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow eviction based on LRU
On 24 January 2017 at 06:15, Avi Cohen (A) wrote: > Hi, > Can someone refer to the flow eviction based on LRU process? > I see that udpif_revalidator thread only handles: > - inactive flows - flow inactivity > 10s (default) > - an event that triggers the need_revalidate > > But I don't see where the main function (LRU) is performed There is no LRU. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Tuple Space Search implementation in the MegaFlow Cache
On 19 January 2017 at 15:26, Ben Pfaff wrote: > I don't understand the definitions of nesting level and ID. I had figured that it differs from the approach OVS implements (top layer is a linear list of masks), to instead have a trie structure with key+mask so you can work your way through the trie to determine which hashtable the packet resides in. Rather than worst case N masks to iterate to determine that the packet doesn't match anything, it's M layers of the trie + 1. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VXLAN support in OVS 2.5.0
On 13 January 2017 at 08:20, Michael Ben-Ami via discuss wrote: > I'm in a very similar boat as Shravan. The utility for me is to be able to > test flow sets on arbitrary mininet topologies that simulate real world > topologies that may or may not use VXLAN. The root cause as I see it is that > mininet must put all OVS bridges in the same namespace. This is probably an > OVS limitation not mininet. Has been discussed a little here: > https://mail.openvswitch.org/pipermail/ovs-discuss/2015-September/038543.html For what it's worth, I believe that this is a limitation for each OVS instance - each instance can only run bridges in the namespace it is running. If you ran multiple copies of OVS in different network namespaces / containers, it should work. (So would running the copies in different VMs) ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] kernel panic when setting QoS parameters more than once
On 12 January 2017 at 02:00, Riccardo R. wrote: > Hi Joe, > > In my first message I forgot to say that the interface on which to run the > command must be an existing interface, not a dummy one as in my example. > > Anyways, I recently tried on a 4.8 kernel and the problem disappeared. For > easiness I used the version of openvswitch that I already had in the system, > that is 2.4. I strongly suspect that it's a problem with kernel 4.6, > independently of the version of openvswitch. Yes, the backtrace confirms it's a bug in the Linux TC code; you probably don't even need OVS to reproduce this issue. If this has been fixed on newer kernels, I would suggest upgrading hosts with that kernel to something newer. Linux 4.6 is now end of life. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel 3.10.0-514.2.2.el7.x86_64)
Does your master include this commit? https://github.com/openvswitch/ovs/commit/6ccf21ca77ec092aa63b3daff66dc9 f0d0e1be93 On 11/01/2017 18:14, "liu yulong" wrote: Thanks Joe and Ben, actually the master branch we also got such error. The doc we followed is "Fedora, RHEL 7.x Packaging for Open vSwitch" [1]. The conflicting shown in [2] was basically same. [1] https://github.com/openvswitch/ovs/blob/master/ Documentation/intro/install/fedora.rst [2] http://paste.openstack.org/show/594350/ On Thu, Jan 12, 2017 at 7:51 AM, Joe Stringer wrote: > On 11 January 2017 at 15:38, Ben Pfaff wrote: > > On Wed, Jan 11, 2017 at 03:03:45PM -0800, Joe Stringer wrote: > >> On 9 January 2017 at 19:01, liu yulong wrote: > >> > Hi experts, > >> > > >> > We have failed to build Open vSwitch Kernel Modules on CentOS 7 > (kernel > >> > 3.10.0-514.2.2.el7.x86_64). > >> > > >> > Here are some traces we got: > >> > http://paste.openstack.org/show/594350/ > >> > > >> > Steps: > >> > 1. download the current openvswitch release: > >> > http://openvswitch.org/releases/openvswitch-2.6.1.tar.gz > >> > > >> > 2. rpmbuild > >> > (1) prepare the SOURCE > >> > cp openvswitch-2.6.1.tar.gz ~/rpmbuild/SOURCES/ > >> > tar -zxvf openvswitch-2.6.1.tar.gz > >> > cp ./openvswitch-2.6.1/rhel/* ~/rpmbuild/SOURCES/ > >> > cp ./openvswitch-2.6.1/rhel/*.spec ~/rpmbuild/SPECS/ > >> > > >> > > >> > (2) edit ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec > >> > change the #%define kernel to: > >> > #%define kernel 3.10.0-514.2.2.el7.x86_64 > >> > > >> > (3) start build > >> > rpmbuild -bb --without check ~/rpmbuild/SPECS/openvswitch-k > mod-fedora.spec > >> > > >> > Then we get that error. So can anyone help to solve such issue? > >> > Thank you. > >> > >> If you want to use the kernel module from the OVS tree, you need to > >> use master or wait for the next version of OVS. Alternatively you can > >> skip using the kernel module from OVS tree and only compile the > >> userspace programs, then use the kernel module that is provided with > >> Centos 7. > > > > Maybe liu is confused because the FAQ that comes with OVS 2.6.1 says > > that the kernel module should work with Linux 3.10. Maybe it does not > > work because Centos kernels diverge from upstream. > > True, it's a bit confusing. The FAQ distributed with 2.6 specifically > states the supported versions, with this caveat: > > "The Linux kernel versions are upstream kernel versions, so Linux > kernels modified from the upstream sources may not build in some cases > even if they are based on a supported version. This is most notably > true of Red Hat Enterprise Linux (RHEL) kernels, which are extensively > modified from upstream." > > https://github.com/openvswitch/ovs/blob/branch-2.6/FAQ.md#q- > what-linux-kernel-versions-does-each-open-vswitch-release-work-with > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel 3.10.0-514.2.2.el7.x86_64)
On 11 January 2017 at 15:38, Ben Pfaff wrote: > On Wed, Jan 11, 2017 at 03:03:45PM -0800, Joe Stringer wrote: >> On 9 January 2017 at 19:01, liu yulong wrote: >> > Hi experts, >> > >> > We have failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel >> > 3.10.0-514.2.2.el7.x86_64). >> > >> > Here are some traces we got: >> > http://paste.openstack.org/show/594350/ >> > >> > Steps: >> > 1. download the current openvswitch release: >> > http://openvswitch.org/releases/openvswitch-2.6.1.tar.gz >> > >> > 2. rpmbuild >> > (1) prepare the SOURCE >> > cp openvswitch-2.6.1.tar.gz ~/rpmbuild/SOURCES/ >> > tar -zxvf openvswitch-2.6.1.tar.gz >> > cp ./openvswitch-2.6.1/rhel/* ~/rpmbuild/SOURCES/ >> > cp ./openvswitch-2.6.1/rhel/*.spec ~/rpmbuild/SPECS/ >> > >> > >> > (2) edit ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec >> > change the #%define kernel to: >> > #%define kernel 3.10.0-514.2.2.el7.x86_64 >> > >> > (3) start build >> > rpmbuild -bb --without check ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec >> > >> > Then we get that error. So can anyone help to solve such issue? >> > Thank you. >> >> If you want to use the kernel module from the OVS tree, you need to >> use master or wait for the next version of OVS. Alternatively you can >> skip using the kernel module from OVS tree and only compile the >> userspace programs, then use the kernel module that is provided with >> Centos 7. > > Maybe liu is confused because the FAQ that comes with OVS 2.6.1 says > that the kernel module should work with Linux 3.10. Maybe it does not > work because Centos kernels diverge from upstream. True, it's a bit confusing. The FAQ distributed with 2.6 specifically states the supported versions, with this caveat: "The Linux kernel versions are upstream kernel versions, so Linux kernels modified from the upstream sources may not build in some cases even if they are based on a supported version. This is most notably true of Red Hat Enterprise Linux (RHEL) kernels, which are extensively modified from upstream." https://github.com/openvswitch/ovs/blob/branch-2.6/FAQ.md#q-what-linux-kernel-versions-does-each-open-vswitch-release-work-with ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel 3.10.0-514.2.2.el7.x86_64)
On 9 January 2017 at 19:01, liu yulong wrote: > Hi experts, > > We have failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel > 3.10.0-514.2.2.el7.x86_64). > > Here are some traces we got: > http://paste.openstack.org/show/594350/ > > Steps: > 1. download the current openvswitch release: > http://openvswitch.org/releases/openvswitch-2.6.1.tar.gz > > 2. rpmbuild > (1) prepare the SOURCE > cp openvswitch-2.6.1.tar.gz ~/rpmbuild/SOURCES/ > tar -zxvf openvswitch-2.6.1.tar.gz > cp ./openvswitch-2.6.1/rhel/* ~/rpmbuild/SOURCES/ > cp ./openvswitch-2.6.1/rhel/*.spec ~/rpmbuild/SPECS/ > > > (2) edit ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec > change the #%define kernel to: > #%define kernel 3.10.0-514.2.2.el7.x86_64 > > (3) start build > rpmbuild -bb --without check ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec > > Then we get that error. So can anyone help to solve such issue? > Thank you. If you want to use the kernel module from the OVS tree, you need to use master or wait for the next version of OVS. Alternatively you can skip using the kernel module from OVS tree and only compile the userspace programs, then use the kernel module that is provided with Centos 7. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] kernel panic when setting QoS parameters more than once
On 10 January 2017 at 05:46, Riccardo R. wrote: > Hi, > > By setting QoS parameters more than once on an OpenvSwitch bridge, we caused > kernel panic on our machine. This is > reproducible with the following commands: > > $ ovs-vsctl add-br mybridge > $ ovs-vsctl add-port mybridge myiface > $ ovs-vsctl set interface myiface ingress_policing_rate=100 > # with the command below the kernel will crash, regardless of the value > given as input: > $ ovs-vsctl set interface myiface ingress_policing_rate=1000 > > We tried this with openvswitch 2.4 and 2.6.1 on a 4.6 Linux kernel. > Interestingly, it works correctly on openvswitch 2.3.0 installed on a 3.16 > kernel. Are you able to get the kernel backtrace from the console when it crashes? Most likely this is a regression in upstream Linux for the kernel that you are seeing the problem. Can you provide more details? Eg, where did you get your 4.6 kernel from? What is the full "uname -r" version for it? What .config was used when compiling it? Are you able to also try other versions, eg 4.4 or 4.9? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] intermittent ovs-vswitchd segfault
On 10 January 2017 at 00:25, Numan Siddique wrote: > Hi, > > I am seeing intermittent segfault's in ovs-vswitchd. We have like 20 > compute nodes and noticed the crash in 4 or 5 nodes. Seems to me the crash > is seen when the system is idle for a long time (as I noticed over the > weekend) > > We are using master of ovs (with the latest commit id 92043ab8ffd4) > > Below is the dmesg and the backtrace of the core file > > > [297752.801094] revalidator239[2308]: segfault at 0 ip 7f2a8d966da3 sp > 7f2a28ff6c58 error 4 in ovs-vswitchd[7f2a8d8ef000+1ea000] > > > > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Core was generated by `ovs-vswitchd unix:/var/run/openvswitch/db.sock > -vconsole:emer -vsyslog:err -vfi'. > Program terminated with signal 11, Segmentation fault. > #0 0x7fe969b13da3 in cmap_replace__ () > Missing separate debuginfos, use: debuginfo-install > glibc-2.17-157.el7_3.1.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 > krb5-libs-1.14.1-27.el7_3.x86_64 libcap-ng-0.7.5-4.el7.x86_64 > libcom_err-1.42.9-9.el7.x86_64 libselinux-2.5-6.el7.x86_64 > openssl-libs-1.0.1e-60.el7.x86_64 pcre-8.32-15.el7_2.1.x86_64 > zlib-1.2.7-17.el7.x86_64 > (gdb) br > Breakpoint 1 at 0x7fe969b13da3 > (gdb) bt > #0 0x7fe969b13da3 in cmap_replace__ () > #1 0x7fe969b14491 in cmap_replace () > #2 0x7fe969aee9ff in ukey_delete () > #3 0x7fe969aefd42 in revalidator_sweep__ () > #4 0x7fe969af1bad in udpif_revalidator () > #5 0x7fe969b8b2a6 in ovsthread_wrapper () > #6 0x7fe968e07dc5 in start_thread () from /lib64/libpthread.so.0 > #7 0x7fe96862c73d in clone () from /lib64/libc.so.6 > > Thanks > Numan > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev Hi Numan, Thanks for the report. First, a couple of questions: * Was there anything relevant in the ovs-vswitchd log? * Can you provide backtraces for the other threads? Jarno and I discussed this, and there's some possibility that this patch will fix the issue. If you're able to test, please let us know whether this makes a difference: https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327513.html ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Packet sent to netfilter after modification in the pipeline
On 9 December 2016 at 00:57, Aswin S wrote: > Hi , > > > I was trying to use the ct action ( actions=ct(table=252,zone=5001)) for a > packet which got modified in the pipeline, like I have swapped the layer 3 > and layer 4 parameters. But in the netfilter event log I couldn't see a > modified packet being received. > > If a packet is modified in the pipeline and when it is send to netfilter, > do we send the original one or the modified one when using ct action ? It depends on where in the pipeline you modify the packet and where you send it to conntrack. Actions are executed in order, so I'd expect that if you modify l3/l4 fields before executing ct() action then conntrack should see the modified packet. Note that there was a netfilter events bug fixed a few months ago which may also explain why you don't see the modified packet. Consider upgrading to the latest version of your kernel, or using OVS 2.6 and its backport module. For reference, here's the commit: https://github.com/torvalds/linux/commit/d913d3a763a6f66a862a6eafcf6da89a7905832a ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] What's the purpose of alg=ftp in the ct action?
On 6 December 2016 at 11:19, Ben Pfaff wrote: > On Tue, Dec 06, 2016 at 10:22:18AM -0800, Joe Stringer wrote: >> Until recently, Linux has turned on automatic helper assignment by >> default. What this means is that even if you do not specify ALGs, the >> traffic will be put through that ALG. In such cases, it is possible to >> construct OpenFlow tables using conntrack actions that are missing the >> FTP option, and the conntrack action will track that FTP connection >> and correlate its sessions. >> >> However, Linux 4.7 turned this off by default: >> https://github.com/torvalds/linux/commit/3bb398d925ec73e42b778cf823c8f4aecae359ea >> >> So, to ensure that this works in a future-proof way you should always >> specify the alg option for FTP control connections. > > Is this something we should document? I sent a patch: https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326101.html ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Crash on netns teardown
On 9 December 2016 at 07:13, Florian Larysch wrote: > Hi, > > I'm running OVS 2.5.1 on a Linux 4.4.35 kernel (the latter is patched > significantly with regard to netfilter, but I don't think this > intersects with the present problem). When I reboot the box (which has > two net namespaces), I get an oops: > > [ 83.650231] Unable to handle kernel paging request for data at address > 0x2ea84000 > [ 83.657705] Faulting instruction address: 0xc022a20c > [ 83.662663] Oops: Kernel access of bad area, sig: 11 [#1] > [ 83.668050] SMP NR_CPUS=2 P2020 RDB > [ 83.671532] Modules linked in: [...] > [ 83.925212] CPU: 1 PID: 831 Comm: kworker/u4:2 Not tainted 4.4.35 #0 > [ 83.931559] Workqueue: netns cleanup_net > [ 83.935474] task: ea9b1f40 ti: eea94000 task.ti: eea94000 > [ 83.940862] NIP: c022a20c LR: c022a230 CTR: c0264154 > [ 83.945817] REGS: eea95d60 TRAP: 0300 Not tainted (4.4.35) > [ 83.951551] MSR: 00021000 CR: 4408 XER: 2000 > [ 83.957387] DEAR: 2ea84000 ESR: > GPR00: c022a230 eea95e10 ea9b1f40 0002 > GPR08: c05636ec 2ea84000 0004 c038669c c004d49c ee4af100 > GPR16: > GPR24: ea820800 00029000 eeb209c0 > [ 83.989626] NIP [c022a20c] __percpu_counter_sum+0x60/0xbc > [ 83.995016] LR [c022a230] __percpu_counter_sum+0x84/0xbc > [ 84.000316] Call Trace: > [ 84.002756] [eea95e10] [c022a230] __percpu_counter_sum+0x84/0xbc > (unreliable) > [ 84.009893] [eea95e30] [c0386774] inet_frags_exit_net+0xd8/0xfc > [ 84.015809] [eea95e50] [f16ca2f8] nf_ct_net_exit+0x2c/0x40 [nf_defrag_ipv6] > [ 84.022772] [eea95e60] [c02ee05c] ops_exit_list+0x40/0x80 > [ 84.028162] [eea95e80] [c02ef7a4] cleanup_net+0x190/0x250 > [ 84.033556] [eea95eb0] [c004703c] process_one_work+0x20c/0x330 > [ 84.039383] [eea95ed0] [c0047688] worker_thread+0x1b4/0x2ec > [ 84.044954] [eea95ef0] [c004d56c] kthread+0xd0/0xdc > [ 84.049830] [eea95f40] [c000fa5c] ret_from_kernel_thread+0x5c/0x64 > [ 84.056000] Instruction dump: > [ 84.058959] 7fa3eb78 481e75a5 7c7c1b78 83dd0008 83fd000c 3860 4828 > 813d0010 > [ 84.066712] 546a103a 3d00c056 390836ec 7d48502e <7d29502e> 7d2afe70 > 7fe9f814 7fcaf114 > [ 84.074643] ---[ end trace 31803f815add721e ]--- > > (FWIW: I've applied https://github.com/openvswitch/ovs/commit/e92669ba > to the OVS build I use already) > > I've added some debugging and it seems that nf_ct_net_exit is called > twice: Once as the kernel version and once as the backported OVS > version: > > [ 83.468964] inet_frags_exit_net called on nf eeb209c0 frags f1715d58 > (counters d0d668d4) > [ 83.477080] CPU: 1 PID: 831 Comm: kworker/u4:2 Not tainted 4.4.35 #0 > [ 83.483432] Workqueue: netns cleanup_net > [ 83.487346] Call Trace: > [ 83.489796] [eea95e10] [c01fded8] __dump_stack+0x24/0x34 (unreliable) > [ 83.496233] [eea95e20] [c01fdf5c] dump_stack+0x74/0xa0 > [ 83.501374] [eea95e30] [c03866e0] inet_frags_exit_net+0x44/0xfc > [ 83.507338] [eea95e50] [f170eec8] nf_ct_net_exit+0x1c/0x2c [openvswitch] > [ 83.514042] [eea95e60] [c02ee05c] ops_exit_list+0x40/0x80 > [ 83.519433] [eea95e80] [c02ef7a4] cleanup_net+0x190/0x250 > [ 83.524826] [eea95eb0] [c004703c] process_one_work+0x20c/0x330 > [ 83.530651] [eea95ed0] [c0047688] worker_thread+0x1b4/0x2ec > [ 83.536224] [eea95ef0] [c004d56c] kthread+0xd0/0xdc > [ 83.541102] [eea95f40] [c000fa5c] ret_from_kernel_thread+0x5c/0x64 > [ 83.547308] inet_frags_exit_net: evict_again > [ 83.551782] __percpu_counter_sum: eeb209c0 | d0d668d4 > [ 83.556870] percpu_counter_destroy: eeb209c0 | d0d668d4 > [ 83.562132] inet_frags_exit_net called on nf eeb209c0 frags f16ca794 > (counters (null)) > [ 83.570247] CPU: 1 PID: 831 Comm: kworker/u4:2 Not tainted 4.4.35 #0 > [ 83.576600] Workqueue: netns cleanup_net > [ 83.580515] Call Trace: > [ 83.582964] [eea95e10] [c01fded8] __dump_stack+0x24/0x34 (unreliable) > [ 83.589400] [eea95e20] [c01fdf5c] dump_stack+0x74/0xa0 > [ 83.594539] [eea95e30] [c03866e0] inet_frags_exit_net+0x44/0xfc > [ 83.600460] [eea95e50] [f16ca2f8] nf_ct_net_exit+0x2c/0x40 [nf_defrag_ipv6] > [ 83.607424] [eea95e60] [c02ee05c] ops_exit_list+0x40/0x80 > [ 83.612815] [eea95e80] [c02ef7a4] cleanup_net+0x190/0x250 > [ 83.618208] [eea95eb0] [c004703c] process_one_work+0x20c/0x330 > [ 83.624033] [eea95ed0] [c0047688] worker_thread+0x1b4/0x2ec > [ 83.629604] [eea95ef0] [c004d56c] kthread+0xd0/0xdc > [ 83.634481] [eea95f40] [c000fa5c] ret_from_kernel_thread+0x5c/0x64 > [ 83.640696] inet_frags_exit_net: evict_again > [ 83.645080] __percpu_counter_sum: eeb209c0 | (null) > [ 83.650231] Unable to handle kernel paging request for data at address > 0x2ea84000 > [...] > > (the "counters" value is nf->mem.counters in inet_frags_exit_net, which > gets set to NULL by percpu_counter_destroy the fir
Re: [ovs-discuss] tracing flows with ct state
On 9 December 2016 at 10:28, Michael Kashin wrote: > Apologies. > What is the right syntax to specify table id in ofproto/trace? ovs-vswitchd(8) describes the syntax for how to use ofproto/trace. TL;DR is you can provide ovs-ofctl syntax; for more information please consult the man pages. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] tracing flows with ct state
Please don't drop the list. On 9 December 2016 at 08:12, Michael Kashin wrote: > Thanks Joe, > Whenever I omit recirc_id and add only a ct_state I go back to my original > problem when trace just stops after the packet is submitted to ct. > > Rule: table=21 cookie=0 priority=100,ip,reg0=0x1/0x1,metadata=0x2 > OpenFlow actions=ct(table=22,zone=NXM_NX_REG13[0..15]) > > Final flow: > ct_state=new|trk,icmp,reg0=0x1,reg13=0x2,reg14=0x2,metadata=0x2,in_port=13,vlan_tci=0x,dl_src=fa:16:3e:4f:2f:b8,dl_dst=fa:16:3e:0d:df:ea,nw_src=10.0.0.2,nw_dst=8.8.8.8,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0 > Megaflow: > recirc_id=0,ip,in_port=13,vlan_tci=0x/0x1000,dl_src=fa:16:3e:4f:2f:b8,nw_src=10.0.0.2,nw_dst=8.0.0.0/7,nw_frag=no > Datapath actions: ct(zone=2),recirc(0xb6) Perhaps you need to specify table=22 along with the expected ct_zone and all of your registers/metadata when running the later flow through? > > Cheers, > Michael > > > > On 9 December 2016 at 05:03, Joe Stringer wrote: >> >> On 8 December 2016 at 13:43, Michael Kashin wrote: >> > Hi, >> > I'm trying to use ofproto/trace to trace flows installed by OVN >> > controller. >> > I start with a simple flow spec that I used in OVS before, I get to >> > table 21 >> > when packet gets submitted to connection tracker and that's where trace >> > stops: >> > Datapath actions: ct(zone=2),recirc(0x9f) >> > >> > I've tried adding recirc_id along with the ct_state to the same flow but >> > it >> > fails: >> > >> > # ovs-appctl ofproto/trace br-int >> > >> > in_port=13,ip,dl_src=fa:16:3e:4f:2f:b8,nw_src=10.0.0.2,nw_dst=8.8.8.8,dl_dst=fa:16:3e:0d:df:ea,recirc_id=0x9f,ct_state="new|trk" >> > Bridge: br-int >> > Flow: >> > >> > recirc_id=0x9f,ct_state=new|trk,ip,in_port=13,vlan_tci=0x,dl_src=fa:16:3e:4f:2f:b8,dl_dst=fa:16:3e:0d:df:ea,nw_src=10.0.0.2,nw_dst=8.8.8.8,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0 >> > >> > Final flow: unchanged >> > Megaflow: recirc_id=0x9f,ip,in_port=13,nw_frag=no >> > Datapath actions: drop >> > Translation failed (No recirculation context), packet is dropped. >> > >> > >> > Am I on the right track? Is this something achievable? >> >> I would suggest dropping the recirc_id; it is transient context that >> is kept around as long as a flow is flowing through OVS. >> >> You should be able to determine how your packets will flow through the >> tables by omitting recirc_id, and providing all of the flow fields >> that you know were available prior to the recirc() action. Depending >> on the flow table, often simply specifying the ct_state is enough. > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] tracing flows with ct state
On 8 December 2016 at 13:43, Michael Kashin wrote: > Hi, > I'm trying to use ofproto/trace to trace flows installed by OVN controller. > I start with a simple flow spec that I used in OVS before, I get to table 21 > when packet gets submitted to connection tracker and that's where trace > stops: > Datapath actions: ct(zone=2),recirc(0x9f) > > I've tried adding recirc_id along with the ct_state to the same flow but it > fails: > > # ovs-appctl ofproto/trace br-int > in_port=13,ip,dl_src=fa:16:3e:4f:2f:b8,nw_src=10.0.0.2,nw_dst=8.8.8.8,dl_dst=fa:16:3e:0d:df:ea,recirc_id=0x9f,ct_state="new|trk" > Bridge: br-int > Flow: > recirc_id=0x9f,ct_state=new|trk,ip,in_port=13,vlan_tci=0x,dl_src=fa:16:3e:4f:2f:b8,dl_dst=fa:16:3e:0d:df:ea,nw_src=10.0.0.2,nw_dst=8.8.8.8,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0 > > Final flow: unchanged > Megaflow: recirc_id=0x9f,ip,in_port=13,nw_frag=no > Datapath actions: drop > Translation failed (No recirculation context), packet is dropped. > > > Am I on the right track? Is this something achievable? I would suggest dropping the recirc_id; it is transient context that is kept around as long as a flow is flowing through OVS. You should be able to determine how your packets will flow through the tables by omitting recirc_id, and providing all of the flow fields that you know were available prior to the recirc() action. Depending on the flow table, often simply specifying the ct_state is enough. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] How to solve Unknown symbol issue while insmod ?
On 8 December 2016 at 20:49, Naveen M <77navee...@gmail.com> wrote: > Hi, > > Currently I'm working on openvswitch_2.5.1 in ubuntu16.04(kernel version > 4.3.3-040303-generic). Whenever i give insmod openvswitch.ko i,m getting > error like below : > > insmod: ERROR: could not insert module datapath/linux/openvswitch.ko: > Unknown symbol in module > > dmesg log : > === > [ 3881.697332] openvswitch: Unknown symbol udp_sock_create4 (err 0) > [ 3881.697362] openvswitch: Unknown symbol __nf_ct_try_assign_helper (err > 0) > [ 3881.697385] openvswitch: Unknown symbol nf_ct_helper_ext_add (err 0) > [ 3881.697413] openvswitch: Unknown symbol nf_connlabels_put (err 0) > [ 3881.697493] openvswitch: Unknown symbol nf_connlabels_replace (err 0) > [ 3881.697524] openvswitch: Unknown symbol nf_connlabels_get (err 0) > [ 3881.697565] openvswitch: Unknown symbol __nf_ct_expect_find (err 0) > [ 3881.697654] openvswitch: Unknown symbol __nf_conntrack_confirm (err 0) > [ 3881.697673] openvswitch: Unknown symbol __nf_ct_ext_destroy (err 0) > [ 3881.697695] openvswitch: Unknown symbol __nf_ct_ext_add_length (err 0) > [ 3881.697717] openvswitch: Unknown symbol udp_tunnel_sock_release (err 0) > [ 3881.697749] openvswitch: Unknown symbol setup_udp_tunnel_sock (err 0) > [ 3881.697780] openvswitch: Unknown symbol nf_ct_deliver_cached_events (err > 0) > [ 3881.697801] openvswitch: Unknown symbol crc32c (err 0) > [ 3881.697829] openvswitch: Unknown symbol udp_tun_rx_dst (err 0) > [ 3881.697853] openvswitch: Unknown symbol > nf_conntrack_helper_try_module_get (err 0) > [ 3881.697872] openvswitch: Unknown symbol udp_tunnel_xmit_skb (err 0) > [ 3881.697898] openvswitch: Unknown symbol nf_defrag_ipv6_enable (err 0) > [ 3881.697920] openvswitch: Unknown symbol nf_ct_get_tuplepr (err 0) > [ 3881.697960] openvswitch: Unknown symbol nf_conntrack_in (err 0) > > > How to fix this issue and why its happend? Can you please guide me on this? insmod is not aware of module dependencies and so it won't load all of the modules that openvswitch needs to load. The simplest way to address this is to install the modules first using 'make modules_install' and use 'modprobe' to load openvswitch. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] What's the purpose of alg=ftp in the ct action?
On 6 December 2016 at 10:41, Samuel Jean wrote: > Awesome, exactly the kind of context background I needed. Thanks Joe! > > On a side note, is that ok to assume the argument to the alg flag is one of > the exact helper name as found with all the nf_conntrack_* modules? Or is > FTP the only supported alg at the moment? Let's say I set alg=irc, is that > expected to turn on helper assignment for IRC conntrack? At the moment, only FTP is supported. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] What's the purpose of alg=ftp in the ct action?
On 6 December 2016 at 08:03, Samuel Jean via discuss wrote: > Howdy folks, > > Yesterday, I was playing with the conntrack stuff available since 2.5 and I > my assumption was that OVS relies on nf_conntrack for tracking tuples and > states. So for FTP to work, I assumed all I need is to make sure the > nf_conntrack_ftp module is loaded to perform its duty. It proved to work > just fine. However, the ovs-ofctl man page suggests to use the alg=ftp > argument to the ct() action. That puzzles me a bit since it seems all it > does is to load the nf_conntrack_ftp module on my behalf. > > One of the few thoughts I had to justify that sugar syntax is to allow FTP > session tracking regardless of the port on which the server is listening. > > Can anyone clarify the purpose of this argument and wether it is reliable to > not use alg= at all but rather load the conntrack helpers and allow the > ports on which the services are listening to? Until recently, Linux has turned on automatic helper assignment by default. What this means is that even if you do not specify ALGs, the traffic will be put through that ALG. In such cases, it is possible to construct OpenFlow tables using conntrack actions that are missing the FTP option, and the conntrack action will track that FTP connection and correlate its sessions. However, Linux 4.7 turned this off by default: https://github.com/torvalds/linux/commit/3bb398d925ec73e42b778cf823c8f4aecae359ea So, to ensure that this works in a future-proof way you should always specify the alg option for FTP control connections. For more context, see the blog post from the netfilter team: http://www.netfilter.org/news.html#2012-04-03 ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] What is the minimum Linux kernel version ovs 2.6.1 build requires?
On 1 December 2016 at 17:04, Yang, Yi Y wrote: > Joe, it is my bad. Our nsh patches added two pointer variables to " struct > ovs_skb_cb", that increased its size by 16 bytes, but sk_buff.cb only has 48 > bytes, when I build ovs with "--with-linux=..." option, sizeof(struct > ovs_gso_cb) will be over 48 bytes, that is the root cause of this build > issue. After I manage to remove those two pointer variables, it can be built > successfully. But sizeof(struct ovs_gso_cb) is still 48 bytes, obviously it > can't be extended any more in the future unless Linux kernel changes > sk_buff.cb to bigger size. OK, glad to hear it doesn't affect released versions of OVS. I wouldn't count on Linux expanding the sk_buff. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] What is the minimum Linux kernel version ovs 2.6.1 build requires?
On 30 November 2016 at 04:58, Yang, Yi Y wrote: > Hi, folks > > I tried to build ovs 2.6.1 in Ubuntu trusty 64 with the below configuration > options, but it failed, it is ok when I use the same way to build in Ubuntu > 16.04 which has Linux kernel 4.4. What is the minimum Linux kernel version > ovs 2.6.1 build requires? I'm surprised to see this; I regularly build master and branch-2.6 on Ubuntu 14.04 with linux 3.13 and 16.04 with linux 4.4. Which kernel version are you seeing this with? Can you also pastebin the $BUILD/datapath/linux/kcompat.h ? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS 2.3.2 hung - no arp with lacp bond
On 17 November 2016 at 23:25, Varun wrote: > Hello > > I observed an issue with OVS 2.3.2 on CentOS 6.6 KVM , kernel > 2.6.32-504.el6, with 25 tenant VMs where it stopped responding to ARPs all > of a sudden. There are 2 OVS bonds in balance-tcp mode in this > configuration. OVS service was restarted to resolve this state . > > Below logs were repeated many times over > > 2016-10-01T12:37:32.480Z|1786606|poll_loop|INFO|wakeup due to 0-ms timeout > at lib/seq.c:179 (97% CPU usage) > > 2016-10-01T23:59:02.480Z|1810465|poll_loop|INFO|wakeup due to 0-ms timeout > at ofproto/ofproto-dpif.c:1503 (99% CPU usage) > > 2016-10-02T00:33:32.481Z|1811683|poll_loop|INFO|wakeup due to [POLLIN] on fd > 10 (<->/var/run/openvswitch/db.sock) at lib/stream-fd-unix.c:124 (97% CPU > usage) > > > Is this related to revalidator thread or probably due to high traffic > volume ? Having said that , there has no increase in traffic volume to the > tenant VMs in the days leading up to the OVS hung state or after. > Hypervisor cpu and memory usage has been at normal levels as well. > > Has anyone else observed similar issues ? Any insight or comments would be > really appreciated. For what it's worth, I believe that OVS 2.3.3 fixed some issues related to bonding - for example: https://github.com/openvswitch/ovs/commit/c2e761f5b15291b56eb0c2f2311ef218ae0653c6 ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS DPDK with Conntrack
On 17 November 2016 at 19:44, Purnendu wrote: > How is the future support planned for OVS+DPDK+Conntrack? > Is it like this: > UserMode: OVS+DPDK > Kernel Mode: Conntrack OVS v2.6 already introduced initial support for connection tracking in userspace for DPDK: https://github.com/openvswitch/ovs/blob/v2.6.0/NEWS#L93 ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Flow synchronizing between user space to kernel space
On 14 November 2016 at 23:35, Naveen M <77navee...@gmail.com> wrote: > Hi all, > > I'm newbie to openvswitch. Currently i'm walk-throwing the > openvswitch(2.5.0) code about flow synchronization between userspace to > kernelspace. > > I have few doubts on synchronization mechanism. In user space revalidator > thread is maintaining the synchronization. > > 1.Is this must for UFID in every flow? UFID stands for Unique Flow IDentifier. Each datapath flow has one. > 2.While inserting the flow i didn't found anywhere where the UFID is > created. May i know where its created? It's generated using dpif_flow_hash(). ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
