Date: Sat, 29 Mar 2025 19:01:33 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 285755] [netgraph] VLAN tag loss/corruption down the ng_socket(4) vmlink hook (bhyve) Message-ID: <bug-285755-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
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.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-285755-227>