Bug 1951112
| Summary: | VLAN Transparency: IPv6 packets dropped when port security enabled | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux Fast Datapath | Reporter: | Eduardo Olivares <eolivare> |
| Component: | ovn2.13 | Assignee: | Ihar Hrachyshka <ihrachys> |
| Status: | CLOSED ERRATA | QA Contact: | Ehsan Elahi <eelahi> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | FDP 20.H | CC: | apevec, ctrautma, egarciar, ffernand, ihrachys, jiji, kfida, lhh, majopela, mmichels, ralongi, scohen |
| Target Milestone: | --- | Keywords: | Triaged |
| 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: | Environment: | ||
| Last Closed: | 2022-12-15 00:21:16 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 |
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