Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VxLAN packets are encapsulated with an outer VLAN tag with VID 1 on Trident3 #414

Open
KanjiMonster opened this issue Sep 4, 2023 · 0 comments

Comments

@KanjiMonster
Copy link
Contributor

Expected Behavior

There is no outer VLAN tag on VxLAN packets unless explicitly configured.

Actual Behavior

On Trident3, there is an outer VLAN tag on VxLAN packets.

Steps to Reproduce the Problem

Create a VxLAN tunnel, try to send packets over it. When looking at them form the other side, there will be a VLAN tag added to them, while non-VxLAN packets are correctly untagged:

08:07:48.026027 f8:8e:a1:e0:bb:14 > 90:e2:ba:61:16:50, ethertype 802.1Q (0x8100), length 114: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 45, id 50, offset 0, flags [none], proto UDP (17), length 96)
    192.168.0.2.54443 > 192.168.0.1.4789: VXLAN, flags [I] (0x08), vni 50000
f8:8e:a1:e0:83:49 > 90:e2:ba:61:13:a0, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.2, length 46
08:07:49.060756 f8:8e:a1:e0:bb:14 > 90:e2:ba:61:16:50, ethertype 802.1Q (0x8100), length 114: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 45, id 51, offset 0, flags [none], proto UDP (17), length 96)
    192.168.0.2.54443 > 192.168.0.1.4789: VXLAN, flags [I] (0x08), vni 50000
f8:8e:a1:e0:83:49 > 90:e2:ba:61:13:a0, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.2, length 46
08:07:50.094093 f8:8e:a1:e0:bb:14 > 90:e2:ba:61:16:50, ethertype 802.1Q (0x8100), length 114: vlan 1, p 0, ethertype IPv4, (tos 0x0, ttl 45, id 52, offset 0, flags [none], proto UDP (17), length 96)
    192.168.0.2.54443 > 192.168.0.1.4789: VXLAN, flags [I] (0x08), vni 50000
f8:8e:a1:e0:83:49 > 90:e2:ba:61:13:a0, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.2, length 46
...
08:08:20.585970 90:e2:ba:61:16:50 > f8:8e:a1:e0:bb:14, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.2 tell 192.168.0.1, length 28
08:08:20.586112 f8:8e:a1:e0:bb:14 > 90:e2:ba:61:16:50, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.0.2 is-at f8:8e:a1:e0:bb:14, length 46

Specifications

  • Version: 5.0.0
  • Platform: cel-questone-2a, as5835-54x tested, as7726-32x and as4630-54pe likely affected as well
  • Subsystem: ofdpa
KanjiMonster added a commit that referenced this issue May 3, 2024
Using unbridged, untagged ports at the same time as VID 1 as default
PVID on a bridge may cause unexpected leakage and forwarding of traffic.

Moving to the reserved VID 4095 would avoid this, but we cannot
unconditionally use it until we solved #414, as otherwise we would leak
packets with VID 4095.

So for now allow changing the VID used internally for ports, but keep
the default at 1.

Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
KanjiMonster added a commit that referenced this issue May 3, 2024
Using unbridged, untagged ports at the same time as VID 1 as default
PVID on a bridge may cause unexpected leakage and forwarding of traffic.

Moving to the reserved VID 4095 would avoid this, but we cannot
unconditionally use it until we solved #414, as otherwise we would leak
packets with VID 4095.

So for now allow changing the VID used internally for ports, but keep
the default at 1.

Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
KanjiMonster added a commit that referenced this issue May 8, 2024
Using unbridged, untagged ports at the same time as VID 1 as default
PVID on a bridge may cause unexpected leakage and forwarding of traffic.

Moving to the reserved VID 4095 would avoid this, but we cannot
unconditionally use it until we solved #414, as otherwise we would leak
packets with VID 4095.

So for now allow changing the VID used internally for ports, but keep
the default at 1.

Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
(cherry picked from commit a2d1e6b)
KanjiMonster added a commit that referenced this issue May 8, 2024
Using unbridged, untagged ports at the same time as VID 1 as default
PVID on a bridge may cause unexpected leakage and forwarding of traffic.

Moving to the reserved VID 4095 would avoid this, but we cannot
unconditionally use it until we solved #414, as otherwise we would leak
packets with VID 4095.

So for now allow changing the VID used internally for ports, but keep
the default at 1.

Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
(cherry picked from commit a2d1e6b)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant