Description of problem: Two ipv6 vlan transparency tests have been created at [1]. With port security disabled, it works fine. With port security enabled, there is no connectivity from the vlan interfaces (the untagged traffic works fine, therefore security group rules should be correctly configured). With port security enabled (See 'Steps to Reproduce' below), when a ping is sent from vm0 to vm1 thorugh vlan100, vm0 sends a neighbor solicitation that is not answered: [root@compute-0 ~]# tcpdump -i tapcc5e57d9-d1 -vne vlan 100 tcpdump: listening on tapcc5e57d9-d1, link-type EN10MB (Ethernet), capture size 262144 bytes 16:20:10.105577 fa:16:3e:55:ae:51 > 33:33:ff:00:02:ff, ethertype 802.1Q (0x8100), length 90: vlan 100, p 0, ethertype IPv6, (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db9::223 > ff02::1:ff00:2ff: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db9::2ff source link-address option (1), length 8 (1): fa:16:3e:55:ae:51 16:20:11.129311 fa:16:3e:55:ae:51 > 33:33:ff:00:02:ff, ethertype 802.1Q (0x8100), length 90: vlan 100, p 0, ethertype IPv6, (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db9::223 > ff02::1:ff00:2ff: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db9::2ff When this happens, the following rule matches each packet: cookie=0x992b8960, duration=887.269s, table=25, n_packets=167, n_bytes=15026, idle_age=0, priority=50,icmp6,metadata=0x4,ipv6_dst=ff02::1:ff00:2ff,nw_ttl=255,icmp_type=135,icmp_code=0,nd_target=2001:db9::2ff actions=controller(userdata=0 0.00.00.03.00.00.00.00.00.19.00.10.80.00.08.06.fa.16.3e.4a.11.58.00.00.00.19.00.18.80.00.34.10.20.01.0d.b9.00.00.00.00.00.00.00.00.00.00.02.ff.00.19.00.18.80.00.3e.10.20.01.0d.b9.00.00.00.00.00.00.00.00.00.00.02.ff.00.19.00.10.80.00.42.06 .fa.16.3e.4a.11.58.00.00.00.1c.00.18.00.20.00.00.00.00.00.00.00.01.1c.04.00.01.1e.04.00.00.00.00.00.19.00.10.00.01.15.08.00.00.00.01.00.00.00.01.ff.ff.00.10.00.00.23.20.00.0e.ff.f8.25.00.00.00) [1] https://code.engineering.redhat.com/gerrit/#/c/225041/ Version-Release number of selected component (if applicable): RHOS-16.1-RHEL-8-20210415.n.0 How reproducible: 100% Steps to Reproduce: 1. create network with vlan transparency enabled and an ipv6 subnet with dhcp disabled 2. create servers (vm0 and vm1) connected to that network 3. add the neutron IPv6 address allocated for each server to the eth0 interface and try to ping vm1 from vm0 -> there is connectivity 4. remove the previous IPs from eth0 interfaces in vm0 and vm1 5. create a vlan interface on those servers (e.g.: eth0.100) and add the neutron IPv6 addresses allocated for each server to the vlan interface 6. try to ping vm1 from vm0 using the IPv6 address -> it fails
Status: 1. we can update ND/NA flow to reuse vlan tag sent by a port. 2. but it may not reflect expected behavior when ports use different vlan tags, so they are not really "neighbors". 3. it may be better to disable local responder when vlan-passthru=true and allow the other port to reply if needed. Same consideration for other flows, f.e. router solicitation. Curiously, ARP responder already reuses the tag, regardless of ports' "neighborliness". We may want to adjust all controller() local responder flows to behave the same way. We'll have to discuss the expected behavior before moving forward.
I believe the correct behavior for vlan transparent networks is to disable local responder for ND (and ARP) and pass requests to port owners that will then reply if needed. The patch to achieve this: https://patchwork.ozlabs.org/project/ovn/patch/20210616004004.3040291-1-ihrachys@redhat.com/
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 ovn-northd ovn-nbctl set-connection ptcp:6641 ovn-sbctl set-connection ptcp:6642 systemctl start openvswitch ovs-vsctl set open . external_ids:system-id=hv1 ovs-vsctl set open . external_ids:ovn-remote=tcp:192.168.1.1:6642 ovs-vsctl set open . external_ids:ovn-encap-type=geneve ovs-vsctl set open . external_ids:ovn-encap-ip=192.168.1.1 systemctl start ovn-controller 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 2001::1" ovn-nbctl lsp-set-port-security lsp1 "00:00:00:01:01:01 192.168.1.1 2001::1" ovn-nbctl lsp-add ls lsp2 ovn-nbctl lsp-set-addresses lsp2 "00:00:00:01:01:02 192.168.1.2 2001::2" ovn-nbctl lsp-set-port-security lsp2 "00:00:00:01:01:02 192.168.1.2 2001::2" 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 ip netns exec lsp1 ip addr add 2001::1/64 dev lsp1.100 ovs-vsctl add-port br-int lsp2 -- set interface lsp2 type=internal external_ids:iface-id=lsp2 ip netns add lsp2 ip link set lsp2 netns lsp2 ip netns exec lsp2 ip link set lsp2 address 00:00:00:01:01:02 ip netns exec lsp2 ip link set lsp2 up ip netns exec lsp2 ip link add link lsp2 name lsp2.100 type vlan id 100 ip netns exec lsp2 ip link set lsp2.100 up ip netns exec lsp2 ip addr add 192.168.1.2/24 dev lsp2.100 ip netns exec lsp2 ip addr add 2001::2/64 dev lsp2.100 <======= ipv4 packets traversed between lsp1 and lsp2 but ipv6 packets dropped so pingv6 failed. 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 <========== All ipv4 and ipv6 packets traversed through with no loss.
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