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 <b...@nicira.com> > > Sent: Friday, 24 April 2015 11:08 a.m. > > To: Tony van der Peet > > Cc: discuss@openvswitch.org > > 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 discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
