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)
Here's some debugging I added myself (not the same flow as above):
adding flow, hash=-212754412, dmac=01-00-5e-00-00-16, dp_hash=0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000002 01005e00 00163860 778bd90a
08000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000000 0a211618 e0000016 00c00102
00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
*00220000*
*00000001* 00000000
deleting flow, lookup failed, hash=801760725, dmac=01-00-5e-00-00-16, dp_hash=0
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000002 01005e00 00163860 778bd90a
08000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000 00000000 0a211618 e0000016 00c00102
00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000
*00000000*
*00000000* 00000000
This is showing a hex dump of the relevant flow structures. the highlighted
fields are obviously different, and happen to be these:
ovs_be16 tp_src; /* TCP/UDP/SCTP source port. */
ovs_be16 tp_dst; /* TCP/UDP/SCTP destination port. */
ovs_be32 igmp_group_ip4; /* IGMP group IPv4 address */
I have tracked this down (I believe) to the lack of support for these fields
(for IGMP packets at least) in odp_flow_key_to_flow__ and
odp_flow_key_from_flow__. Looking at some of the conversation around the
original commits that added support for IGMP to the flow, I can see that some
work may have been deferred, but there is some question as to whether we want
this supported anyway. I would like to fix this issue if possible, but have
some questions:
1 - is my analysis correct?
2 - is there more to fix than just the routines I mentioned? (I know, I should
make the change and try it out, but it appears a bit more extensive than I
first thought, including adding to enum ovs_key_attr, which I wouldn't do
lightly.)
3 - is there something different I should be doing to fix my issue? (I have the
option of not adding the flows in my dpif (a variant of dpif-netdev) which will
solve the problem, but would possibly just be papering over this issue).
Note that I updated our OVS from GitHub in Sep/2014. I have checked and there
don't appear to be any subsequent commits that would address this.
Thanks
Tony
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
