[ovs-discuss] IGMP fields added to the flow structure causes problem?

[Tony van der Peet]

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 <blp at nicira.com>
>>> Sent: Friday, 24 April 2015 11:08 a.m.
>>> To: Tony van der Peet
>>> Cc: discuss at 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 at 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)?
>>>