Bug 2133902
| Summary: | OVN Cannot Support Triple VLAN Tagged Networking Traffic | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux Fast Datapath | Reporter: | David Hill <dhill> |
| Component: | ovn-2021 | Assignee: | OVN Team <ovnteam> |
| Status: | CLOSED WONTFIX | QA Contact: | Ehsan Elahi <eelahi> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | FDP 20.F | CC: | ctrautma, ihrachys, jiji, jishi, mmichels, vanhoof |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-02-23 00:57:53 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: | |||
Hi. Currently neither OVS nor OVN support more than two vlan tags on a packet. OVS is not capable of stripping more than two VLAN tags off. OVN is also unable to operate on more than two VLAN tags in the same packet. You may find that triple-vlan tagged packets may happen to work in the case where simple L2 switching is required. As soon as anything L3 or beyond is required, things will fall apart. Triple-vlan tagged packets have never been explicitly supported in OVS/OVN. Supporting this would require adding the feature to both OVS and OVN. What are the customer expectations on this? Can they work around this or is it a requirement for them that triple-vlan tags should work in OVS/OVN? Should we support arbitrary numbers of VLAN tags? Only 3? FYI OVN supports 0x88a8 eth type since 21.06: https://github.com/ovn-org/ovn/commit/50f4ea011622a63c5ac0eec200c4176b1afe6fb6 This issue is being closed as an automatic process due to the issue's age. If you wish to re-open this issue, please do so in Jira (https://issues.redhat.com) in the 'FDP' project. Please be sure to set the component to the latest OVN version where this issue is known to occur. If this is a feature request or improvement, please set the component to 'OVN'. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |
What problem/issue/behavior are you having trouble with? What do you expect to see? When triple VLAN tagged traffic (0x8100,0x88a8,x8100 ethertype) is presented to OVN Transparent VLAN, the OVN properly pushes and pops the outer tag, however it also destroys the inner 0x8100. The expectation would be that the inner tags remain untouched and delivered to other VMs and the network with the tags un-modified. Setup: Two IPERF Servers OpenStack OVN Transparent Network on VLAN 295 Each server has two network interfaces Outer Tag which is pushed and popped is 295 S-Tag (0x88a8 ethertype): 500 C-Tag (0x8100 ethertype): 20 ----- Configuration IPERF2: ip link add link eth1 eth1.500 type vlan proto 802.1ad id 500 ip address add 172.15.0.2/24 dev eth1.500 ip link set eth1.500 up ip link add link eth1.500 eth1.500.20 type vlan proto 802.1Q id 20 ip address add 172.15.1.2/24 dev eth1.500.20 ip link set eth1.500.20 up Configuration IPERF3: ip link add link eth1 eth1.500 type vlan proto 802.1ad id 500 ip address add 172.15.0.3/24 dev eth1.500 ip link set eth1.500 up ip link add link eth1.500 eth1.500.20 type vlan proto 802.1Q id 20 ip address add 172.15.1.3/24 dev eth1.500.20 ip link set eth1.500.20 up -------- Layout: IPERF2 ---------> iPERF3 eth1.500.20 --> eth1.500 --> eth1 --> tap interface --> OVN br-int---> (T tag, S Tag, CTag) (T Tag, STag) <--- C Tag gone when looking at the OVN bridge and other tap for ----------- Expectations: IPERF2 sends ping to IPERF3, the VM should append vlan 500 and 20 to the packet, OVN should push on the transparent tag 295 as the outermost tag and deliver to the other VM with vlan 500 and 20 intact ---------- TCPdumps: ARP Double Encapsulated - Confirmed [root@iperf-rs-2 ~]# tcpdump -i eth1 -nne | grep -e vlan tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 16:53:52.933683 fa:16:3e:d8:0a:06 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q-QinQ (0x88a8), length 50: vlan 500, p 0, ethertype 802.1Q, vlan 20, p 0, ethertype ARP, Request who-has 172.15.1.3 tell 172.15.1.2, length 28 Seen on tap RS3 OVN Interface? - Confirmed inner vlan missing [root@overcloud-computehci-2 ~]# ip a | grep 0ab9 250: tap0ab9fde4-90: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8800 qdisc noqueue master ovs-system state UNKNOWN group default qlen 1000 [root@overcloud-computehci-2 ~]# tcpdump -i tap0ab9fde4-90 -nne vlan dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap0ab9fde4-90, link-type EN10MB (Ethernet), capture size 262144 bytes 17:08:02.131597 fa:16:3e:d8:0a:06 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q-QinQ (0x88a8), length 46: vlan 500, p 0, ethertype ARP, Request who-has 172.15.1.3 tell 172.15.1.2, length 28 What is the business impact? Please also provide timeframe information. Preventing the use of OVN for the traffic and preventing a customer from proper deployment Where are you experiencing the behavior? What environment? OpenStack 16.2 When does the behavior occur? Frequency? Repeatedly? At certain times? Repeatedly Hide Section - TagsTags