[ovs-dev] Possible regression in "datapath: Mega flow implementation"

Simon Horman horms at verge.net.au
Thu Jun 27 09:05:45 UTC 2013


Hi Justin,

Thanks.

I have enabled some extra debugging as you suggest and I now agree that the
zero UDP source and destination ports are suspicious.  And that the packet
in question is an IPv6/UDP mDNS packet with source and destination port of
5353 rather than a router solicitation request as I previously suggested.

I have included a log where a facet for an mDNS packet is added and then
not so long after a dump of a facet with the same match, other than the
source and destination ports being zero occurs.

There are also some unrelated facets in the dump but I have left them in
the log below for completeness.

2013-06-27T08:51:54Z|00071|dpif|DBG|system at ovs-system: miss upcall:
in_port(2),eth(src=0e:7c:5c:93:7f:04,dst=33:33:00:00:00:fb),eth_type(0x86dd),ipv6(src=fe80::c7c:5cff:fe93:7f04,dst=ff02::fb,label=0,proto=17,tclass=0,hlimit=255,frag=no),udp(src=5353,dst=5353)
udp6,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=0e:7c:5c:93:7f:04,dl_dst=33:33:00:00:00:fb,ipv6_src=fe80::c7c:5cff:fe93:7f04,ipv6_dst=ff02::fb,ipv6_label=0x00000,nw_tos=0,nw_ecn=0,nw_ttl=255,tp_src=5353,tp_dst=5353 udp_csum:4cfd
2013-06-27T08:51:54Z|00072|dpif|DBG|system at ovs-system: execute 3,1 on packet udp6,metadata=0,in_port=0,vlan_tci=0x0000,dl_src=0e:7c:5c:93:7f:04,dl_dst=33:33:00:00:00:fb,ipv6_src=fe80::c7c:5cff:fe93:7f04,ipv6_dst=ff02::fb,ipv6_label=0x00000,nw_tos=0,nw_ecn=0,nw_ttl=255,tp_src=5353,tp_dst=5353 udp_csum:4cfd
2013-06-27T08:51:54Z|00073|dpif|DBG|system at ovs-system: put[create][modify] in_port(2),eth(src=0e:7c:5c:93:7f:04,dst=33:33:00:00:00:fb),eth_type(0x86dd),ipv6(src=fe80::c7c:5cff:fe93:7f04/::,dst=ff02::fb/::,label=0/0,proto=17/0,tclass=0/0,hlimit=255/0,frag=no/0),udp(src=5353/0,dst=5353/0), actions:3,1
2013-06-27T08:51:55Z|00074|dpif|DBG|system at ovs-system: flow_dump_start success
2013-06-27T08:51:55Z|00075|dpif|DBG|system at ovs-system: flow_dump in_port(1),eth(src=ba:66:f2:f2:e3:44,dst=33:33:00:00:00:16),eth_type(0x86dd),ipv6(src=::/::,dst=ff02::16/::,label=0/0,proto=58/0,tclass=0/0,hlimit=1/0,frag=no/0),icmpv6(type=143,code=0), packets:0, bytes:0, used:never
2013-06-27T08:51:55Z|00076|dpif|DBG|system at ovs-system: flow_dump in_port(1),eth(src=ba:66:f2:f2:e3:44,dst=33:33:ff:8b:9f:6f),eth_type(0x86dd),ipv6(src=::/::,dst=ff02::1:ff8b:9f6f/::,label=0/0,proto=58/0,tclass=0/0,hlimit=255/0,frag=no/0),icmpv6(type=135,code=0),nd(target=fe80::d4ed:acff:fe8b:9f6f), packets:0, bytes:0, used:never
2013-06-27T08:51:55Z|00077|dpif|DBG|system at ovs-system: flow_dump in_port(1),eth(src=ba:66:f2:f2:e3:44,dst=33:33:00:00:00:02),eth_type(0x86dd),ipv6(src=fe80::d4ed:acff:fe8b:9f6f/::,dst=ff02::2/::,label=0/0,proto=58/0,tclass=0/0,hlimit=255/0,frag=no/0),icmpv6(type=133,code=0), packets:0, bytes:0, used:never
2013-06-27T08:51:55Z|00078|dpif|DBG|system at ovs-system: flow_dump in_port(2),eth(src=0e:7c:5c:93:7f:04,dst=33:33:00:00:00:fb),eth_type(0x86dd),ipv6(src=fe80::14e9:14e9:fe93:7f04/::,dst=ff02::fb/::,label=0/0,proto=17/0,tclass=0/0,hlimit=255/0,frag=no/0),udp(src=0,dst=0), packets:0, bytes:0, used:never
2013-06-27T08:51:55Z|00079|ofproto_dpif|WARN|unexpected flow: in_port(2),eth(src=0e:7c:5c:93:7f:04,dst=33:33:00:00:00:fb),eth_type(0x86dd),ipv6(src=fe80::14e9:14e9:fe93:7f04,dst=ff02::fb,label=0,proto=17,tclass=0,hlimit=255,frag=no),udp(src=0,dst=0)
2013-06-27T08:51:55Z|00080|dpif|WARN|system at ovs-system: failed to flow_del (No such file or directory) in_port(2),eth(src=0e:7c:5c:93:7f:04,dst=33:33:00:00:00:fb),eth_type(0x86dd),ipv6(src=fe80::14e9:14e9:fe93:7f04,dst=ff02::fb,label=0,proto=17,tclass=0,hlimit=255,frag=no),udp(src=0,dst=0)

On Wed, Jun 26, 2013 at 11:17:50PM -0700, Justin Pettit wrote:
> I was noticing some similar IPv6 issues earlier this evening.  I'm planning to dig into it more in the morning, so I may have additional information then.  Simon, if you wanted to see the flow that triggered this, you could try starting OVS with the "dpif" logging set at "dbg".  This will show the flow put and dumps, and may provide some useful information, since the output below looks strange with the 0 UDP ports.  If you don't have a chance, I'll do it as part of my debugging tomorrow.
> 
> --Justin
> 
> 
> On Jun 26, 2013, at 11:06 PM, Simon Horman <horms at verge.net.au> wrote:
> 
> > Hi Jesse, Hi Andy,
> > 
> > I have observed what seems to be a regression added
> > by "datapath: Mega flow implementation" which is still present in
> > master as of 7431e17196fdb1c3189d67e3aeed4adeab4cf479
> > ("ofproto-dpif: Always un-wildcard 'dl_type'.").
> > 
> > The problem that I am observing is that in some cases
> > ovs-vswitchd asks the (kernel) datapath to remove facets
> > which the latter claims do not exist.
> > 
> > The case where I see this is the facet set up as a result
> > of IPv6 router solicitation requests sent when the link
> > to the bridge is brought up as part of system initialisation -
> > my test runs in a (usually short-lived) KVM instance.
> > 
> > A sample log message is as follows:
> > 
> > 2013-06-27T05:13:13Z|00039|dpif|WARN|system at ovs-system: failed to flow_del (No such file or directory) in_port(3),skb_mark(0),eth(src=4a:08:11:f1:13:f0,dst=33:33:00:00:00:fb),eth_type(0x86dd),ipv6(src=fe80::14e9:14e9:fef1:13f0,dst=ff02::fb,label=0,proto=17,tclass=0,hlimit=255,frag=no),udp(src=0,dst=0)
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
> 



More information about the dev mailing list