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

Thu Jun 27 15:53:10 UTC 2013

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 <horms at verge.net.au> 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 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
>>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
X-CudaMail-Whitelist-To: dev at openvswitch.org