Bug 1914816

Summary:	VLAN Transparency: packets dropped with flat provider network
Product:	Red Hat Enterprise Linux Fast Datapath	Reporter:	Slawek Kaplonski <skaplons>
Component:	ovn-2021	Assignee:	OVN Team <ovnteam>
Status:	CLOSED ERRATA	QA Contact:	Ehsan Elahi <eelahi>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	FDP 21.A	CC:	apevec, ctrautma, dalvarez, ekuris, eolivare, ihrachys, jiji, jishi, jlibosva, kfida, lhh, majopela, mmichels, nusiddiq, ralongi, scohen, sputhenp
Target Milestone:	---	Flags:	eelahi: needinfo- eelahi: needinfo-
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ovn-2021-21.06.0-12.el8fdp	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1907779	Environment:
Last Closed:	2022-12-15 00:21:16 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:	1907779
Bug Blocks:	1846019

Description Slawek Kaplonski 2021-01-11 09:39:29 UTC

+++ 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.

Comment 3 Ihar Hrachyshka 2021-03-17 17:49:55 UTC

Upstream patch: https://patchwork.ozlabs.org/project/ovn/patch/20210317174716.1786663-1-ihrachys@redhat.com/

Comment 4 Ihar Hrachyshka 2021-04-15 13:35:07 UTC

u/s patch merged, to be released in next release

Comment 8 Ehsan Elahi 2021-09-01 11:37:04 UTC

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

Comment 9 Ehsan Elahi 2021-09-02 16:41:32 UTC

(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.

Comment 11 errata-xmlrpc 2022-12-15 00:21:16 UTC

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