Is this related to the issue that Andy started to work on here?: http://openvswitch.org/pipermail/dev/2013-June/028820.html
On Thu, Jun 27, 2013 at 2:05 AM, Simon Horman <[email protected]> wrote: > 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 X-CudaMail-Whitelist-To: [email protected] _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
