Description of problem: While working on ml2/ovn offload with geneve tunnel, observed following flow. ufid:82f3fade-f87d-4815-a635-6d8584e13c8c, skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(ens1f1_1),packet_type(ns=0/0,id=0/0),eth(src=00:00:00:00:00:00/01:00:00:00:00:00,dst=f8:f2:1e:03:bf:f4),eth_type(0x0800),ipv4(src=0.0.0.0/0.0.0.0,dst=0.0.0.0/0.0.0.0,proto=0/0,tos=0/0x3,ttl=0/0,frag=no), packets:662, bytes:105920, used:0.610s, offloaded:yes, dp:tc, actions:set(tunnel(tun_id=0x2,dst=152.20.0.11,ttl=64,tp_dst=6081,key6(bad key length 1, expected 0)(01)geneve({class=0x102,type=0x80,len=4,0x20003}),flags(key))),genev_sys_6081 While discussing over IRC, imaximets informed this. "looks like a bug in netdev-offload-tc in OVS. While dumping flows from TC it constructs OVS_TUNNEL_KEY_ATTR_CSUM (key #6) with 'nl_msg_put_u8' passing a boolean value instead of 'nl_msg_put_flag' without a value. The flow itself in TC should be OK, but this should definitely be fixed." Version-Release number of selected component (if applicable): openvswitch2.13-2.13.0-71.el8fdp.x86_64 How reproducible: Always Steps to Reproduce: 1. Deploy ovs hw offload 2. Have genve provider network and VM belongs to it 3. Ping to outside destination. Actual results: bad key length. Expected results: No bad key length Additional info:
Posted upstream on April 7, 2021 https://patchwork.ozlabs.org/project/openvswitch/patch/161779578418.6597.11950001999120876543.stgit@fed.void/
*** Bug 1976014 has been marked as a duplicate of this bug. ***
Patch got accepted upstream and backported all the way to 2.12. https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/384753.html The next FDP release will pick up the fix.
[root@netqe1 ~]# ovs-vsctl add-port ovsbr0 geneve1 -- set interface geneve1 type=geneve options:remote_ip=1.1.1.2 options:local_ip=1.1.1.1 options:key=100 options:csum=true [root@netqe1 ~]# ovs-vsctl get Open_vSwitch . other_config {hw-offload="true", tc-policy=none} [root@netqe1 ~]# systemctl restart openvswitch.service [root@netqe1 ~]# ovs-vsctl show c5486238-1fe9-4eb2-80d5-9cf9dec17c9b Bridge ovsbr0 Port geneve1 Interface geneve1 type: geneve options: {csum="true", key="100", local_ip="1.1.1.1", remote_ip="1.1.1.2"} Port ens1f0_pf0vf0 Interface ens1f0_pf0vf0 Port ovsbr0 Interface ovsbr0 type: internal ovs_version: "2.13.5" [root@netqe1 ~]# [root@netqe1 ~]# ovs-appctl dpctl/dump-flows type=offloaded --names -m recirc_id(0),in_port(2),eth(src=e4:11:22:33:44:60,dst=06:8a:a7:48:06:e6),eth_type(0x0800),ipv4(tos=0/0x3,frag=no), packets:188, bytes:18424, used:0.010s, actions:set(tunnel(tun_id=0x64,src=1.1.1.1,dst=1.1.1.2,ttl=64,tp_dst=6081,flags(df|csum|key))),3 recirc_id(0),tunnel(tun_id=0x64,src=1.1.1.2,dst=1.1.1.1,flags(-df-csum+key)),in_port(3),eth(src=06:8a:a7:48:06:e6,dst=e4:11:22:33:44:60),eth_type(0x0800),ipv4(frag=no), packets:189, bytes:18522, used:0.010s, actions:2 [root@netqe1 ~]# [root@netqe1 ~]# rpm -qa | grep openvswitch2.13 openvswitch2.13-2.13.0-120.el8fdp.x86_64 [root@netqe1 ~]# [root@netqe1 ~]# uname -r 4.18.0-305.12.1.el8_4.x86_64 [root@netqe1 ~]# cat /etc/redhat-release Red Hat Enterprise Linux release 8.4 (Ootpa) [root@netqe1 ~]#
no more bad key length seen in the flows 21.G ovs2.13 8.4 Set this to VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (openvswitch2.13 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:3448