Just to finalise this thread: + my earlier test must have been incorrectly specifying the packet, and I decided to specify the packet as a hex string instead, using a packet captured from our LAN + running my test on the Sep/2014 snapshot revealed the issue + running my test on the Apr/2015 snapshot showed the flow deletion worked, ie no issue
Seems as if I should do an upgrade! Tony On 30/04/15 02:26, Ben Pfaff wrote: > I'm glad to hear that you're tracking down the problem. Good luck. > > On Wed, Apr 29, 2015 at 06:05:48AM +0000, Tony van der Peet wrote: >> OK, downloaded OVS from top of master, and wrote a unit test that >> hopefully would have reproduced the problem (I guess I should run that >> test on the version we are actually using). Anyway, the test passed. >> Looking more closely at the code, I can see that in flow_put and >> flow_del in dpif-netdev.c, the way the hashes are calculated seems to >> have changed. I suspect that this is why the code no longer exhibits >> this behaviour. >> >> So, for now I don't think I want any help on this issue. I'll keep >> working on this as a background activity, but will probably do an update >> from the upstream repo sometime soon and see if the problem goes away >> after that. >> >> Thanks for the earlier response. >> >> Tony >> >> On 25/04/15 07:14, Tony van der Peet wrote: >>> Just to get dates in order: >>> >>> Jun/2014 - deliveries to master branch that introduce IGMP fields to flow >>> structure >>> Sep/2014 - we update from tip of master >>> Apr/2014 - I notice this potential issue >>> >>> I am running a simple ryu application (using code from >>> https://github.com/samrussell/nss) and connecting my desktop PC to our main >>> LAN. Flows with multicast addresses appear to come and go, but I suspect >>> it's IGMPv3 Membership Reports (type 0x22) that are causing flows to be >>> created that then persist. >>> >>> In this application at least, matching is done purely on source and >>> destination MAC, so the existence of these flows is probably not that much >>> of a problem since the flows will cover many other packets that aren't >>> Membership reports. It's not really that surprising that this might not be >>> noticed since the switch is behaving perfectly normally and acceptably. >>> >>> To your point of reproducing on unmodified OpenVSwitch, yes, I will do >>> that, and report further. Time zones and public holidays mean that it won't >>> be until next week. >>> >>> Tony >>> ________________________________________ >>> From: Ben Pfaff <[email protected]> >>> Sent: Friday, 24 April 2015 11:08 a.m. >>> To: Tony van der Peet >>> Cc: [email protected] >>> Subject: Re: [ovs-discuss] IGMP fields added to the flow structure causes >>> problem? >>> >>> On Thu, Apr 23, 2015 at 12:03:08AM +0000, Tony van der Peet wrote: >>>> I have been investigating some anomalous behaviour in a switch >>>> (developed by us, based on OpenVSwitch code). It appears that flows >>>> added as a result of receiving IGMP packets are never deleted. Here's >>>> one of the flows (this is a switch running a simple MAC learning >>>> application, so you don't see the upper level fields). >>>> >>>> recirc_id(0),in_port(2),eth(src=38:60:77:8b:d9:0a,dst=01:00:5e:00:00:16),eth_type(0x0800),ipv4(frag=no), >>>> packets:26, bytes:2236, used:9.600s, actions:1,6,5,4,3 >>>> >>>> Here's a log message I'm seeing: >>>> >>>> 2015 Apr 23 12:33:23 awplus ovs-vswitchd: >>>> 02570|dpif(revalidator4)|WARN|system@ovs-system: failed to flow_del (No >>>> such file or directory) >>>> >>>> skb_priority(0),skb_mark(0),recirc_id(0),dp_hash(0),in_port(2),eth(src=38:60:77:8b:d9:0a,dst=01:00:5e:00:00:16),eth_type(0x0800),ipv4(src=10.33.22.24,dst=224.0.0.22,proto=2,tos=0xc0,ttl=1,frag=no) >>> Thanks for the report. I'm a little surprised to hear about this, since >>> that code is somewhat old (I think you said September 2014) and I don't >>> remember getting similar reports before. Can you explain how to >>> reproduce the problem (with unmodified OVS)? >>> _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
