Bug 2018365
Summary: | check_pkt_larger translation is incomplete | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux Fast Datapath | Reporter: | Numan Siddique <nusiddiq> |
Component: | openvswitch2.15 | Assignee: | Numan Siddique <nusiddiq> |
Status: | CLOSED ERRATA | QA Contact: | Zhiqiang Fang <zfang> |
Severity: | medium | Docs Contact: | |
Priority: | urgent | ||
Version: | FDP 21.I | CC: | ctrautma, ekuris, eolivare, ihrachys, i.maximets, jhsiao, jiji, jishi, kfida, nusiddiq, ralongi, zfang |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | openvswitch2.16-2.16.0-32.el8fdp openvswitch2.15-2.15.0-53.el8fdp openvswitch2.13-2.13.0-139.el8fdp openvswitch2.13-2.13.0-112.el7fdp | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | 2017424 | Environment: | |
Last Closed: | 2022-01-10 16:50:29 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 2017424, 2018459, 2018980 | ||
Bug Blocks: |
Description
Numan Siddique
2021-10-29 03:00:56 UTC
The patch is up for review - https://patchwork.ozlabs.org/project/openvswitch/patch/20211029172648.3859172-1-numans@ovn.org/ Reproduced the issue on openvswitch2.16-2.16.0-31.el8fdp.x86_64 / ovn-2021-21.09.1-23.el8fdp.x86_64 and verified the fix on openvswitch2.16-2.16.0-32.el8fdp.x86_64 / ovn-2021-21.09.1-23.el8fdp.x86_64 Using below reproducer. The IPs are netns ls1p1 192.168.1.1 netns ls1p1 192.168.1.2 netns lp 192.168.1.11 systemctl start openvswitch systemctl start ovn-northd ovn-nbctl set-connection ptcp:6641 ovn-sbctl set-connection ptcp:6642 ovs-vsctl set open . external_ids:system-id=hv1 external_ids:ovn-remote=tcp:20.0.183.25:6642 external_ids:ovn-encap-type=geneve external_ids:ovn-encap-ip=20.0.183.25 systemctl restart ovn-controller ovs-vsctl add-br br-ext ovs-vsctl set Open_vSwitch . external-ids:ovn-bridge-mappings=provider:br-ext ovn-nbctl ls-add ls1 ovn-nbctl lsp-add ls1 ls1p1 ovn-nbctl lsp-set-addresses ls1p1 "00:00:00:01:01:01 192.168.1.1 2001::1" ovn-nbctl lsp-add ls1 ls1p2 ovn-nbctl lsp-set-addresses ls1p2 "00:00:00:01:01:02 192.168.1.2 2001::2" ovn-nbctl lsp-add ls1 lp ovn-nbctl lsp-set-type lp localport ovn-nbctl lsp-set-addresses lp "00:00:00:01:01:11 192.168.1.11 2001::11" ovn-nbctl lsp-add ls1 public ovn-nbctl lsp-set-type public localnet ovn-nbctl lsp-set-addresses public unknown ovn-nbctl lsp-set-options public network_name=provider ovn-nbctl lr-add lr1 ovn-nbctl lrp-add lr1 lr1-ls1 00:00:00:00:00:01 192.168.1.254/24 2001::a/64 ovn-nbctl lsp-add ls1 ls1-lr1 ovn-nbctl lsp-set-addresses ls1-lr1 router ovn-nbctl lsp-set-type ls1-lr1 router ovn-nbctl lsp-set-options ls1-lr1 router-port=lr1-ls1 ovn-nbctl set logical_switch ls1 other_config:vlan-passthru=true ovn-nbctl set logical_router_port lr1-ls1 options:gateway_mtu=1300 ovs-vsctl add-port br-int ls1p1 -- set interface ls1p1 type=internal external_ids:iface-id=ls1p1 ip netns add ls1p1 ip link set ls1p1 netns ls1p1 ip netns exec ls1p1 ip link set ls1p1 address 00:00:00:01:01:01 ip netns exec ls1p1 ip link set ls1p1 up ip netns exec ls1p1 ip addr add 192.168.1.1/24 dev ls1p1 ip netns exec ls1p1 ip addr add 2001::1/64 dev ls1p1 ovs-vsctl add-port br-int ls1p2 -- set interface ls1p2 type=internal external_ids:iface-id=ls1p2 ip netns add ls1p2 ip link set ls1p2 netns ls1p2 ip netns exec ls1p2 ip link set ls1p2 address 00:00:00:01:01:02 ip netns exec ls1p2 ip link set ls1p2 up ip netns exec ls1p2 ip addr add 192.168.1.2/24 dev ls1p2 ip netns exec ls1p2 ip addr add 2001::2/64 dev ls1p2 ovs-vsctl add-port br-int lp -- set interface lp type=internal external_ids:iface-id=lp ip netns ad lp ip link set lp netns lp ip netns exec lp ip link set lp address 00:00:00:01:01:11 ip netns exec lp ip link set lp up ip netns exec lp ip addr add 192.168.1.11/24 dev lp ip netns exec lp ip addr add 2001::11/64 dev lp ip netns exec ls1p1 ping 192.168.1.2 -c 1 ip netns exec ls1p1 ping 192.168.1.11 -c 1 Based on github test "AT_SETUP([ofproto-dpif - check_pkt_larger action])" I verified the fix for ovs2.15 without ovn. Issue was reproduced on openvswitch2.15-2.15.0-51.el8fdp and fix was verified on openvswitch2.15-2.15.0-55.el8fdp The steps are: systemctl start openvswitch ovs-vsctl add-br br0 ovs-vsctl add-port br0 p1 -- set Interface p1 type=internal ofport_request=1 ovs-vsctl add-port br0 p2 -- set Interface p2 type=internal ofport_request=2 ovs-vsctl add-port br0 p3 -- set Interface p3 type=internal ofport_request=3 ovs-vsctl add-port br0 p4 -- set Interface p4 type=internal ofport_request=4 ip netns add p1 ip link set p1 netns p1 ip netns exec p1 ip link set p1 address 50:54:00:00:00:09 ip netns exec p1 ip link set p1 up ip netns exec p1 ip address add 10.10.10.1/24 dev p1 ip netns add p2 ip link set p2 netns p2 ip netns exec p2 ip link set p2 address 50:54:00:00:00:a1 ip netns exec p2 ip link set p2 up ip netns exec p2 ip address add 10.10.10.2/24 dev p2 ip netns add p3 ip link set p3 netns p3 ip netns exec p3 ip link set p3 address 50:54:00:00:00:0a ip netns exec p3 ip link set p3 up ip netns exec p3 ip address add 10.10.10.3/24 dev p3 ip netns add p4 ip link set p4 netns p4 ip netns exec p4 ip link set p4 address 50:54:00:00:00:a2 ip netns exec p4 ip link set p4 up ip netns exec p4 ip address add 10.10.10.4/24 dev p4 #ovs-vsctl -- --columns=name,ofport list Interface ovs-ofctl dump-flows br0 ovs-ofctl del-flows br0 ovs-ofctl dump-flows br0 ovs-ofctl --protocols=OpenFlow10 add-flows br0 flows.txt ovs-ofctl dump-flows br0 ovs-appctl ofproto/trace br0 in_port=p1,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,dl_type=0x0800,nw_src=10.10.10.2,nw_dst=10.10.10.1,nw_proto=1,nw_tos=1,icmp_type=8,icmp_code=0 #Through 2nd ssh session monitor ip netns exec p2 tcpdump -i p2 -n #Through 3rd ssh session monitor ip netns exec p3 tcpdump -i p3 -n #Through 4th ssh session monitor ip netns exec p4 tcpdump -i p4 -n # send ping packets from p1 ip netns exec p1 ping 10.10.10.2 ip netns exec p1 ping 10.10.10.3 ip netns exec p1 ping 10.10.10.4 #cat flows.txt table=0,in_port=1 actions=load:0x1->NXM_NX_REG1[],resubmit(,1),load:0x2->NXM_NX_REG1[],resubmit(,1),load:0x3->NXM_NX_REG1[],resubmit(,1) table=1,in_port=1,reg1=0x1 actions=check_pkt_larger(200)->NXM_NX_REG0[0],resubmit(,4) table=1,in_port=1,reg1=0x2 actions=output:2 table=1,in_port=1,reg1=0x3 actions=output:4 table=4,in_port=1 actions=output:3 ~~~~~~ On openvswitch2.15-2.15.0-51.el8fdp.x86_64, the output of ovs-appctl ofproto/trace is below, [root@netqe6 ~]# ovs-appctl ofproto/trace br0 in_port=p1,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,dl_type=0x0800,nw_src=10.10.10.2,nw_dst=10.10.10.1,nw_proto=1,nw_tos=1,icmp_type=8,icmp_code=0 Flow: icmp,in_port=1,vlan_tci=0x0000,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,nw_src=10.10.10.2,nw_dst=10.10.10.1,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=8,icmp_code=0 bridge("br0") ------------- 0. in_port=1, priority 32768 load:0x1->NXM_NX_REG1[] resubmit(,1) 1. reg1=0x1,in_port=1, priority 32768 check_pkt_larger(200)->NXM_NX_REG0[0] resubmit(,4) 4. in_port=1, priority 32768 output:3 resubmit(,4) 4. in_port=1, priority 32768 output:3 Final flow: icmp,reg1=0x1,in_port=1,vlan_tci=0x0000,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,nw_src=10.10.10.2,nw_dst=10.10.10.1,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=8,icmp_code=0 Megaflow: recirc_id=0,eth,ip,in_port=1,nw_frag=no Datapath actions: check_pkt_len(size=200,gt(4),le(4)) <<------ Ping test result (from namespace p1) is that only namespace p3 (on 3rd ovs port) can receive icmp packets, namespace p2 and p4 didn't receive any packets. ~~~~~~~ On openvswitch2.15-2.15.0-55.el8fdp.x86_64, the output is below, [root@netqe6 ~]# ovs-appctl ofproto/trace br0 in_port=p1,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,dl_type=0x0800,nw_src=10.10.10.2,nw_dst=10.10.10.1,nw_proto=1,nw_tos=1,icmp_type=8,icmp_code=0 Flow: icmp,in_port=1,vlan_tci=0x0000,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,nw_src=10.10.10.2,nw_dst=10.10.10.1,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=8,icmp_code=0 bridge("br0") ------------- 0. in_port=1, priority 32768 load:0x1->NXM_NX_REG1[] resubmit(,1) 1. reg1=0x1,in_port=1, priority 32768 check_pkt_larger(200)->NXM_NX_REG0[0] resubmit(,4) 4. in_port=1, priority 32768 output:3 resubmit(,4) 4. in_port=1, priority 32768 output:3 load:0x2->NXM_NX_REG1[] resubmit(,1) 1. reg1=0x2,in_port=1, priority 32768 output:2 load:0x3->NXM_NX_REG1[] resubmit(,1) 1. reg1=0x3,in_port=1, priority 32768 output:4 Final flow: icmp,reg1=0x3,in_port=1,vlan_tci=0x0000,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,nw_src=10.10.10.2,nw_dst=10.10.10.1,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=8,icmp_code=0 Megaflow: recirc_id=0,eth,ip,in_port=1,nw_frag=no Datapath actions: check_pkt_len(size=200,gt(4),le(4)),3,5 <<--------------- other two ports have been added Ping test result (from namespace p1) is that all three namespace p2, p3, p4 can receive icmp packets. On p2: 23:38:51.006804 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 25888, seq 1, length 64 23:39:08.228559 IP 10.10.10.1 > 10.10.10.3: ICMP echo request, id 25895, seq 1, length 64 23:39:28.152465 IP 10.10.10.1 > 10.10.10.4: ICMP echo request, id 25904, seq 1, length 64 On p3: 23:38:51.006803 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 25888, seq 1, length 64 23:39:08.228558 IP 10.10.10.1 > 10.10.10.3: ICMP echo request, id 25895, seq 1, length 64 23:39:28.152465 IP 10.10.10.1 > 10.10.10.4: ICMP echo request, id 25904, seq 1, length 64 On p4: 23:38:51.006804 IP 10.10.10.1 > 10.10.10.2: ICMP echo request, id 25888, seq 1, length 64 23:39:08.228559 IP 10.10.10.1 > 10.10.10.3: ICMP echo request, id 25895, seq 1, length 64 23:39:28.152466 IP 10.10.10.1 > 10.10.10.4: ICMP echo request, id 25904, seq 1, length 64 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.15 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-2022:0052 |