QinQ SDN zone not forwarding VLAN traffic to VM bridge (vnet/vmbr chain issue)

[Vishaal Golam]

Hi, I’m stuck with a QinQ+Proxmox SDN forwarding issue — short version: the outer/inner tags arrive on the host bridge, but the VM bridge never learns the remote MAC and never receives inbound frames.

Topology (relevant parts):

VM (tap101i1) <=> vnetQnQ (pr_HexaDonQ) <=> ln_HexaDonQ
^
z_HexaDonQ
^
vmbrQnQ.300 (on vmbrQnQ -> bond1)
^
swD <-> swVDBI <-> end-device (remote MAC 00:50:56:a6:2d:f2)


Proxmox SDN:
zones.cfg (QinQ):

qinq: HexaDonQ
bridge vmbrQnQ
tag 300
vlan-protocol 802.1ad

vnets.cfg:
vnet: vnetQnQ
zone HexaDonQ
vlanaware 1


Linux bridges: vmbrQnQ, vmbrQnQ.300, z_HexaDonQ (bridge), ln/pr veth pair, vnetQnQ (bridge), tap101i1.

What I see (evidence)

vmbrQnQ tcpdump:
00:50:56:a6:2d:f2 > ff:ff:ff, ethertype 802.1Q, vlan 802, ARP request (remote → host)

So the host receives inner VLAN 802 frames (after QinQ decap some place on the path).

tap101i1 tcpdump:
only shows ARPs sent by the VM (outbound). No inbound ARP/frames from 00:50:56:a6:2d:f2.


Linux bridge FDB:

bridge fdb show | grep 00:50:56:a6:2d:f2
# at one point showed: 00:50:56:a6:2d:f2 dev bond1 vlan 1 master vmbrQnQ
# currently no entry shown for that MAC on vlan 802


Switch configs (actual state)

swD → link to pveD / to swVDBI:

interface Ten-GigabitEthernet2/0/46 (swD)
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 300
port trunk pvid vlan 300
qinq enable


swVDBI → port toward end-device (physical port / BAGG)

interface Ten-GigabitEthernet2/0/51 (swVDBI)
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 802
port trunk pvid vlan 99


Observations on switches:

swVDBI shows MAC 00:50:56:a6:2d:f2 learned on VLAN 802 (BAGG2).

swD shows the same MAC learned on VLAN 300 on XGE2/0/46 (the QinQ SVLAN).

What I tried / changed

Ensured vmbrQnQ.300 and z_HexaDonQ exist and are UP.

Added bridge vlan add for vid 802 on vmbrQnQ.300, ln_HexaDonQ, pr_HexaDonQ, tap101i1, vnetQnQ so VLAN 802 is allowed across the veth chain. bridge vlan show now lists 802 on those interfaces.

Observed tcpdump on ln_HexaDonQ/pr_HexaDonQ — sometimes the 802 frames are visible on vmbrQnQ but not on the veth/tap; FDB shows no entry for the remote MAC on vlan 802.

Question:
Given the above, why does the Linux bridging stack / Proxmox SDN not deliver the inbound VLAN-802 frames to the VM/tap even though vmbrQnQ sees the tagged frames and the chain allows VLAN 802? Is there a Proxmox SDN behavior or Linux-bridge/FDB nuance (vlan filtering, learned FDB on wrong interface, qinq interaction) that prevents learning/flooding to the vnet bridge? Any pointers on the exact debug steps or settings I should inspect?

Thanks for any hints — I feel the QinQ path and switch side is ok, but the VM side bridging/learning is what’s failing.