+++ This bug was initially created as a clone of Bug #1907779 +++ Description of problem: An external provider network is configured with VLAN Transparency. Port security is disabled. A subnet is created with default gateway 10.0.0.1, which is an IP located on the hypervisor server (I am using an OSP virt environment for this test), specifically on its interface 'external'. A RHEL VM is created with a port connected to that network. Once that VM starts, a VLAN interface (vlan100) is created on its interface eth0. The IP from eth0 (10.0.0.242/24) is moved to vlan100. The hypervisor's network configuration is modified: 1) add external.100 VLAN interface on external 2) add 10.0.0.250/24 on external.100 3) remove route to 10.0.0.0/24 from external (now traffic to 10.0.0.0/24 is routed through external.100) Run from the VM (no responses are received) # arping -I vlan100 10.0.0.250 On the compute node, ARP requests and replies are captured on ens5 interface (packets are tagged with vlan 100) [root@compute-0 ~]# tcpdump -vne -i ens5 tcpdump: listening on ens5, link-type EN10MB (Ethernet), capture size 262144 bytes 08:21:09.442069 fa:16:3e:44:ad:84 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.250 (Broadcast) tell 10.0.0.242, length 28 08:21:09.442235 52:54:00:9a:8d:95 > fa:16:3e:44:ad:84, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.0.0.250 is-at 52:54:00:9a:8d:95, length 28 On the compute node, only ARP requests are captured on br-ex interface (packets are tagged with vlan 100) [root@compute-0 ~]# tcpdump -vne -i br-ex tcpdump: listening on br-ex, link-type EN10MB (Ethernet), capture size 262144 bytes 08:22:56.473129 fa:16:3e:44:ad:84 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.250 (Broadcast) tell 10.0.0.242, length 28 08:22:57.473341 fa:16:3e:44:ad:84 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.250 (Broadcast) tell 10.0.0.242, length 28 It looks like the following rule is dropping packets: cookie=0x0, duration=54139.119s, table=34, n_packets=52568, n_bytes=2426347, idle_age=0, priority=100,reg10=0/0x1,reg14=0x4,reg15=0x4,metadata=0x4 actions=drop Version-Release number of selected component (if applicable): RHOS-16.1-RHEL-8-20201203.n.0 ovn2.13-20.09.0-17.el8fdp.x86_64 python3-networking-ovn-7.3.1-1.20201114024043.el8ost.noarch <- this packet was installed manually, it is part of the original OSP compose How reproducible: 100% --- Additional comment from on 2020-12-16 16:14:29 UTC --- a similar test doesn't fail with vlan provider networks --- Additional comment from Slawek Kaplonski on 2021-01-08 16:04:33 UTC --- After investigation it seems for me like it is ovn issue. In case of flat neutron network openflow rule created in table=0 by ovn is like: cookie=0x779c3409, duration=5186.275s, table=0, n_packets=316, n_bytes=37480, priority=100,in_port="patch-br-int-to",vlan_tci=0x0000/0x1000 actions=load:0x4->NXM_NX_REG13[],load:0x3->NXM_NX_REG11[],load:0x2->NXM_NX_REG12[],load:0x2->OXM_OF_METADATA[],load:0x1->NXM_NX_REG14[],resubmit(,8) So if we have there network with vlan configured, it don't match that rule (and any other rule in the table=0) and such packet isn't processed by other rules. When I added rule like: cookie=0x0, duration=450.544s, table=0, n_packets=70, n_bytes=7194, in_port="patch-br-int-to" actions=load:0x4->NXM_NX_REG13[],load:0x3->NXM_NX_REG11[],load:0x2->NXM_NX_REG12[],load:0x2->OXM_OF_METADATA[],load:0x1->NXM_NX_REG14[],resubmit(,8) Connectivity was working fine.
Upstream patch: https://patchwork.ozlabs.org/project/ovn/patch/20210317174716.1786663-1-ihrachys@redhat.com/
u/s patch merged, to be released in next release
Reproduced on: rpm -qa |grep -E 'ovn|openvswitch' ovn2.13-central-20.12.0-161.el8fdp.x86_64 openvswitch-selinux-extra-policy-1.0-28.el8fdp.noarch ovn2.13-host-20.12.0-161.el8fdp.x86_64 openvswitch2.13-2.13.0-120.el8fdp.x86_64 ovn2.13-20.12.0-161.el8fdp.x86_64 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.175.25:6642 external_ids:ovn-encap-type=geneve external_ids:ovn-encap-ip=20.0.175.25 systemctl restart ovn-controller ovs-vsctl add-br br-phys ovs-vsctl set open . external-ids:ovn-bridge-mappings=phys:br-phys ovn-nbctl ls-add ls ovn-nbctl --wait=sb add Logical-Switch ls other_config vlan-passthru=true ovn-nbctl lsp-add ls lsp1 ovn-nbctl lsp-set-addresses lsp1 "00:00:00:01:01:01 192.168.1.1" ovn-nbctl lsp-add ls lsp2 ovn-nbctl lsp-set-addresses lsp2 "00:00:00:01:01:02 192.168.1.2" ovn-nbctl lsp-add ls ln #ovn-nbctl lsp-add ls ln "" 100 # tested with and without tag, same results in the reproduced bug. When use tag option, packets dropped in the fixed version too ovn-nbctl lsp-set-type ln localnet ovn-nbctl lsp-set-addresses ln unknown ovn-nbctl lsp-set-options ln network_name=phys ovs-vsctl add-port br-int lsp1 -- set interface lsp1 type=internal external_ids:iface-id=lsp1 ip netns add lsp1 ip link set lsp1 netns lsp1 ip netns exec lsp1 ip link set lsp1 address 00:00:00:01:01:01 ip netns exec lsp1 ip link set lsp1 up ip netns exec lsp1 ip link add link lsp1 name lsp1.100 type vlan id 100 ip netns exec lsp1 ip link set lsp1.100 up ip netns exec lsp1 ip addr add 192.168.1.1/24 dev lsp1.100 ovs-vsctl add-port br-phys ext1 -- set interface ext1 type=internal ip netns add ext1 ip link set ext1 netns ext1 ip netns exec ext1 ip link set ext1 up ip netns exec ext1 ip link add link ext1 name ext1.100 type vlan id 100 ip netns exec ext1 ip link set ext1.100 up ip netns exec ext1 ip addr add 192.168.1.100/24 dev ext1.100 <======== ping failed between lsp1 and ext1 Verified on: rpm -qa |grep -E 'ovn|openvswitch' ovn2.13-central-20.12.0-173.el8fdp.x86_64 openvswitch-selinux-extra-policy-1.0-28.el8fdp.noarch ovn2.13-host-20.12.0-173.el8fdp.x86_64 openvswitch2.13-2.13.0-120.el8fdp.x86_64 ovn2.13-20.12.0-173.el8fdp.x86_64 Also verified on: rpm -qa |grep -E 'ovn|openvswitch' ovn-2021-central-21.06.0-24.el8fdp.x86_64 openvswitch-selinux-extra-policy-1.0-28.el8fdp.noarch ovn-2021-host-21.06.0-24.el8fdp.x86_64 openvswitch2.15-2.15.0-26.el8fdp.x86_64 ovn-2021-21.06.0-24.el8fdp.x86_64 If add switch port without tag option, ping successful between lsp1 and ext1 but if add switch port with tag (i.e. ovn-nbctl lsp-add ls ln "" 100), ping failed. Is this the expected behavior? Here is the tcpdump with tagged and untagged port options: ######## tcpdump without tag port option ########### 06:07:05.755696 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > 192.168.1.1: ICMP echo request, id 49832, seq 1, length 64 06:07:05.755736 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > 192.168.1.100: ICMP echo reply, id 49832, seq 1, length 64 06:07:06.761755 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > 192.168.1.1: ICMP echo request, id 49832, seq 2, length 64 06:07:06.761776 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > 192.168.1.100: ICMP echo reply, id 49832, seq 2, length 64 06:07:07.785756 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > 192.168.1.1: ICMP echo request, id 49832, seq 3, length 64 06:07:07.785776 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > 192.168.1.100: ICMP echo reply, id 49832, seq 3, length 64 06:07:10.857725 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.168.1.100 tell 192.168.1.1, length 28 06:07:10.857977 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.168.1.1 tell 192.168.1.100, length 28 06:07:10.857987 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Reply 192.168.1.1 is-at 00:00:00:01:01:01, length 28 06:07:10.857989 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Reply 192.168.1.100 is-at 22:67:1a:69:56:0e, length 28 06:07:16.157108 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > 192.168.1.100: ICMP echo request, id 49833, seq 1, length 64 06:07:16.157144 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > 192.168.1.1: ICMP echo reply, id 49833, seq 1, length 64 06:07:17.193762 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > 192.168.1.100: ICMP echo request, id 49833, seq 2, length 64 06:07:17.193790 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > 192.168.1.1: ICMP echo reply, id 49833, seq 2, length 64 06:07:18.217808 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > 192.168.1.100: ICMP echo request, id 49833, seq 3, length 64 06:07:18.217837 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > 192.168.1.1: ICMP echo reply, id 49833, seq 3, length 64 #### Tcpdump with tagged port option ######### 06:16:11.529702 00:00:00:01:01:01 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::200:ff:fe01:101 > ff02::2: ICMP6, router solicitation, length 16 06:16:21.227268 00:00:00:01:01:01 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.168.1.100 tell 192.168.1.1, length 28 06:16:22.281708 00:00:00:01:01:01 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.168.1.100 tell 192.168.1.1, length 28 06:16:23.305738 00:00:00:01:01:01 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.168.1.100 tell 192.168.1.1, length 28 06:16:27.913726 00:00:00:01:01:01 > 33:33:00:00:00:02, ethertype 802.1Q (0x8100), length 74: vlan 100, p 0, ethertype IPv6, fe80::200:ff:fe01:101 > ff02::2: ICMP6, router solicitation, length 16 06:16:38.835512 06:0c:5a:c2:f0:a7 > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.1 tell 192.168.1.100, length 28 06:16:39.881707 06:0c:5a:c2:f0:a7 > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.1 tell 192.168.1.100, length 28 06:16:40.905764 06:0c:5a:c2:f0:a7 > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.1 tell 192.168.1.100, length 28
(In reply to Ehsan Elahi from comment #8) > Reproduced on: > rpm -qa |grep -E 'ovn|openvswitch' > ovn2.13-central-20.12.0-161.el8fdp.x86_64 > openvswitch-selinux-extra-policy-1.0-28.el8fdp.noarch > ovn2.13-host-20.12.0-161.el8fdp.x86_64 > openvswitch2.13-2.13.0-120.el8fdp.x86_64 > ovn2.13-20.12.0-161.el8fdp.x86_64 > > > 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.175.25:6642 > external_ids:ovn-encap-type=geneve external_ids:ovn-encap-ip=20.0.175.25 > systemctl restart ovn-controller > > > > ovs-vsctl add-br br-phys > > ovs-vsctl set open . external-ids:ovn-bridge-mappings=phys:br-phys > > > > ovn-nbctl ls-add ls > > ovn-nbctl --wait=sb add Logical-Switch ls other_config vlan-passthru=true > > ovn-nbctl lsp-add ls lsp1 > > ovn-nbctl lsp-set-addresses lsp1 "00:00:00:01:01:01 192.168.1.1" > > > > ovn-nbctl lsp-add ls lsp2 > > ovn-nbctl lsp-set-addresses lsp2 "00:00:00:01:01:02 192.168.1.2" > > > > ovn-nbctl lsp-add ls ln > #ovn-nbctl lsp-add ls ln "" 100 # tested with and without tag, same results > in the reproduced bug. When use tag option, packets dropped in the fixed > version too > > ovn-nbctl lsp-set-type ln localnet > > ovn-nbctl lsp-set-addresses ln unknown > > ovn-nbctl lsp-set-options ln network_name=phys > > > > ovs-vsctl add-port br-int lsp1 -- set interface lsp1 type=internal > external_ids:iface-id=lsp1 > > > ip netns add lsp1 > > ip link set lsp1 netns lsp1 > > ip netns exec lsp1 ip link set lsp1 address 00:00:00:01:01:01 > > ip netns exec lsp1 ip link set lsp1 up > > ip netns exec lsp1 ip link add link lsp1 name lsp1.100 type vlan id 100 > > ip netns exec lsp1 ip link set lsp1.100 up > > ip netns exec lsp1 ip addr add 192.168.1.1/24 dev lsp1.100 > > > > ovs-vsctl add-port br-phys ext1 -- set interface ext1 type=internal > > ip netns add ext1 > > ip link set ext1 netns ext1 > > ip netns exec ext1 ip link set ext1 up > > ip netns exec ext1 ip link add link ext1 name ext1.100 type vlan id 100 > > ip netns exec ext1 ip link set ext1.100 up > > ip netns exec ext1 ip addr add 192.168.1.100/24 dev ext1.100 > > <======== ping failed between lsp1 and ext1 > > Verified on: > rpm -qa |grep -E 'ovn|openvswitch' > ovn2.13-central-20.12.0-173.el8fdp.x86_64 > openvswitch-selinux-extra-policy-1.0-28.el8fdp.noarch > ovn2.13-host-20.12.0-173.el8fdp.x86_64 > openvswitch2.13-2.13.0-120.el8fdp.x86_64 > ovn2.13-20.12.0-173.el8fdp.x86_64 > > Also verified on: > rpm -qa |grep -E 'ovn|openvswitch' > ovn-2021-central-21.06.0-24.el8fdp.x86_64 > openvswitch-selinux-extra-policy-1.0-28.el8fdp.noarch > ovn-2021-host-21.06.0-24.el8fdp.x86_64 > openvswitch2.15-2.15.0-26.el8fdp.x86_64 > ovn-2021-21.06.0-24.el8fdp.x86_64 > > If add switch port without tag option, ping successful between lsp1 and ext1 > but if add switch port with tag (i.e. ovn-nbctl lsp-add ls ln "" 100), ping > failed. Is this the expected behavior? Here is the tcpdump with tagged and > untagged port options: > > ######## tcpdump without tag port option ########### > 06:07:05.755696 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > > 192.168.1.1: ICMP echo request, id 49832, seq 1, length 64 > 06:07:05.755736 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > > 192.168.1.100: ICMP echo reply, id 49832, seq 1, length 64 > 06:07:06.761755 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > > 192.168.1.1: ICMP echo request, id 49832, seq 2, length 64 > 06:07:06.761776 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > > 192.168.1.100: ICMP echo reply, id 49832, seq 2, length 64 > 06:07:07.785756 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > > 192.168.1.1: ICMP echo request, id 49832, seq 3, length 64 > 06:07:07.785776 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > > 192.168.1.100: ICMP echo reply, id 49832, seq 3, length 64 > 06:07:10.857725 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q > (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has > 192.168.1.100 tell 192.168.1.1, length 28 > 06:07:10.857977 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q > (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has > 192.168.1.1 tell 192.168.1.100, length 28 > 06:07:10.857987 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q > (0x8100), length 46: vlan 100, p 0, ethertype ARP, Reply 192.168.1.1 is-at > 00:00:00:01:01:01, length 28 > 06:07:10.857989 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q > (0x8100), length 46: vlan 100, p 0, ethertype ARP, Reply 192.168.1.100 is-at > 22:67:1a:69:56:0e, length 28 > 06:07:16.157108 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > > 192.168.1.100: ICMP echo request, id 49833, seq 1, length 64 > 06:07:16.157144 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > > 192.168.1.1: ICMP echo reply, id 49833, seq 1, length 64 > 06:07:17.193762 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > > 192.168.1.100: ICMP echo request, id 49833, seq 2, length 64 > 06:07:17.193790 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > > 192.168.1.1: ICMP echo reply, id 49833, seq 2, length 64 > 06:07:18.217808 00:00:00:01:01:01 > 22:67:1a:69:56:0e, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.1 > > 192.168.1.100: ICMP echo request, id 49833, seq 3, length 64 > 06:07:18.217837 22:67:1a:69:56:0e > 00:00:00:01:01:01, ethertype 802.1Q > (0x8100), length 102: vlan 100, p 0, ethertype IPv4, 192.168.1.100 > > 192.168.1.1: ICMP echo reply, id 49833, seq 3, length 64 > > #### Tcpdump with tagged port option ######### > 06:16:11.529702 00:00:00:01:01:01 > 33:33:00:00:00:02, ethertype IPv6 > (0x86dd), length 70: fe80::200:ff:fe01:101 > ff02::2: ICMP6, router > solicitation, length 16 > 06:16:21.227268 00:00:00:01:01:01 > Broadcast, ethertype 802.1Q (0x8100), > length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.168.1.100 tell > 192.168.1.1, length 28 > 06:16:22.281708 00:00:00:01:01:01 > Broadcast, ethertype 802.1Q (0x8100), > length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.168.1.100 tell > 192.168.1.1, length 28 > 06:16:23.305738 00:00:00:01:01:01 > Broadcast, ethertype 802.1Q (0x8100), > length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.168.1.100 tell > 192.168.1.1, length 28 > 06:16:27.913726 00:00:00:01:01:01 > 33:33:00:00:00:02, ethertype 802.1Q > (0x8100), length 74: vlan 100, p 0, ethertype IPv6, fe80::200:ff:fe01:101 > > ff02::2: ICMP6, router solicitation, length 16 > 06:16:38.835512 06:0c:5a:c2:f0:a7 > Broadcast, ethertype ARP (0x0806), > length 42: Request who-has 192.168.1.1 tell 192.168.1.100, length 28 > 06:16:39.881707 06:0c:5a:c2:f0:a7 > Broadcast, ethertype ARP (0x0806), > length 42: Request who-has 192.168.1.1 tell 192.168.1.100, length 28 > 06:16:40.905764 06:0c:5a:c2:f0:a7 > Broadcast, ethertype ARP (0x0806), > length 42: Request who-has 192.168.1.1 tell 192.168.1.100, length 28 As the localnet is tagged, so there are 2 vlan headers when the packet goes into ext1. So a new vlan over ext1.100 is created as below: ip netns add ext1 ip link set ext1 netns ext1 ip netns exec ext1 ip link set ext1 up ip netns exec ext1 ip link add link ext1 name ext1.100 type vlan id 100 ip netns exec ext1 ip link set ext1.100 up ip netns exec ext1 ip link add link ext1.100 name ext1.100_2 type vlan id 100 ip netns exec ext1 ip link set ext1.100_2 up ip netns exec ext1 ip addr add 192.168.1.100/24 dev ext1.100_2 This time the ping successful between ext1 and lsp1. Hence the fix is 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 (ovn2.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-2022:9044