[ovs-discuss] Kernel cache flow match error with linux bond port as physical NIC GRO on

[Jesse Gross]

On Thu, Feb 25, 2016 at 11:06 PM, 康敬亭 <jingting at unitedstack.com> wrote:
> Hi guys:
>
> I hava test environment as below:
> ENV: Neutron + ovs(2.1.2) with linux bond(eth2,eth3), vm in compute node
> couldn't get ip from dhcp server.
>
> I had flow [1] added  in br-int, and with eth2 and eth3 GRO on, the kernel
> cache flow was [3],and packets droped. But with eth2 and eth3 GRO off, the
> kernel cache flow was[2], and the packets will be forward with pop_vlan, and
> works OK.
>
> In the failed situation, I found error msg in log as below:
>  openvswitch: netlink: Flow modification message rejected, unmasked key does
> not match.
>
> Anyone have idea about what wrong about ovs does not works with the linux
> bond?
> OVS can't get field of vlan to match for packets from linux bond port with
> gro on?
>
> BR
> Jingting
>
> [1]  cookie=0x0, duration=1383.630s, table=0, n_packets=237, n_bytes=68899,
> idle_age=3, priority=3,in_port=37,dl_vlan=2001 actions=mod_vlan_vid:1,NORMAL
>
> [2]skb_priority(0),in_port(6),eth(src=fa:16:3e:09:58:b6,dst=fa:16:3e:32:b3:d5),eth_type(0x8100),vlan(vid=2001,pcp=0),encap(eth_type(0x0800),ipv4(src=172.30.248.4/0.0.0.0,dst=172.30.248.210/0.0.0.0,proto=17/0,tos=0xc0/0,ttl=64/0,frag=no/0xff)),
> packets:0, bytes:0, used:never, actions:pop_vlan,7
>
> [3]skb_priority(0),in_port(6),eth(src=fa:16:3e:09:58:b6,dst=fa:16:3e:32:b3:d5),eth_type(0x8100),vlan(vid=2001/0xfff,pcp=0/0x0,cfi=1/1),encap(eth_type(0x0800),ipv4(src=172.30.248.4/0.0.0.0,dst=172.30.248.210/0.0.0.0,proto=17/0,tos=0xc0/0,ttl=64/0,frag=no/0xff)),
> packets:0, bytes:0, used:never, actions:drop

These flows are very odd - for one thing, the basic incoming flow
without any mask applied is the same, meaning that it doesn't appear
that GRO is really having an effect (as it shouldn't) and another is
that they are overlapping, which is not allowed. Finally, the
wildcards in the second datapath flow doesn't make any sense given the
input OpenFlow flow.

I think the best thing to at this point is try a newer OVS version.
The specific warning that you mentioned has been fixed but more
generally, a lot of the flow generation code was in flux around 2.1
and things have calmed down since then.