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@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@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@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@ovs-system: flow_dump_start success 2013-06-27T08:51:55Z|00075|dpif|DBG|system@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@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@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@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@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 <[email protected]> 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@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 > > [email protected] > > http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
