[Bug 285755] [netgraph] VLAN tag loss/corruption down the ng_socket(4) vmlink hook (bhyve)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285755

            Bug ID: 285755
           Summary: [netgraph] VLAN tag loss/corruption down the
                    ng_socket(4) vmlink hook (bhyve)
           Product: Base System
           Version: 14.2-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: bugzilla.freebsd@omnilan.de

Hello,

My issue:
I'm observing VLAN tagged frames reading VID=0 when received inside a bhyve(8)
VM, while they (correctly) read VID=77 at ng_eiface(4) connected to the same
ng_bridge as the vmlink hook (created by bhyve with netgraph backend).
[On the wire and on the host NIC they are tagged VID=77 - no ng_vlan(4) is
involved and the NIC was configured -vlanhwfilter and -vlamnhwtag]

Narrowed down to be a netgraph(4) problem:
Using if_tap(4) as bhyve(8) backend instead of netgraph preserves VLAN tagging
(tcpdump frames captured inside the VM read VID=77).

The VLAN tag corruption also happens with ng_ether(4).
(ng_eiface(4) doesn't rewrite VLAN tag, but down the path through ng_socket(4)
and ng_either(4) they unintentionally become VID=0).

Due to my weak C skills I couldn't find the part where the data received via
ng_socket gets injected into the virtual network interface (no matter if it's
virtio-net or e1000).
But since I can see originally tagged VLAN=77 frames reading VLAN=0 when
captured on bridged ng_ether(4) interfaces, loss/corruption might happen
earlier.
I guess it's not an issue with ng_bridge(4) itself, because when I connect the
ng_eiface(4) ether hook, tcpdump frames captured on the ng_eiface(4) read
VID=77 (preserves VLAN tagging).

The use case is to have a 'trunk' port on the host, passing all (tagged and
untagged) frames into a VM.
I intentionally try to avoid using multiple virtual network interfaces, i.e.
one for each vlan.
Since this involves high packets/sec traffic (one VLAN ships PPPoE), ppt(4) is
not a alternative.

Any help appreciated, thanks in advance!

-- 
You are receiving this mail because:
You are the assignee for the bug.