[PATCH] VLAN trunking support in VirtualBox vboxnetflt

[Landon Fuller]

Hello,

This patch has been in the vbox kmod port for some time now, and I've been running it without incident; however, I recently ran into a configuration that the patch does not correctly handle:
	- A single host interface (eg, em0) bridged to a VM
	- VLANs also configured on the host interface (em0.vlan0, em0.vlan1)

The packet flow in this situation should be:
	- The ng filter is handed a packet from em0
	- The filter re-adds the VLAN header to the top of the packet and strips the M_VLANTAG flag
	- After passing to the virtual switch, the packet is re-injected into the host via ether_demux().
	- ether_demux() extracts the embedded VLAN tag and hands the packet off to vlan_input_p().

As it turns out, ether_demux() does not handle frames with embedded VLAN tags, and at this point, the packet is dropped, rather than being routed to the host's VLAN handling:
	http://lists.freebsd.org/pipermail/freebsd-net/2011-October/030201.html

The result is as follows:
	- Packets received via the host interface are handled correctly.
	- Packets (including VLAN tagged packets) are passed to sub-VMs correctly.
	- Packets that *should* be handled by vlan* sub-interfaces on the host are never received by those interfaces as they're dropped in ether_demux().

This worked in my existing configuration because the host and the VMs actually use two different VLAN trunks (em0 and em1), and so em0 packets being dropped after injection into the virtual switch does not affect the host's handling of packets on em1.

I've attached an updated patch that should resolve this issue; I'm currently testing it locally on my home deployment and so far it is working fine. The patch simply restores the VLAN flags and stripped ethernet header after injecting the packet into the virtual ethernet switch. With this change in place, ether_demux() correctly hands the packet off to vlan_input_p().

Cheers,
Landon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c
Type: application/octet-stream
Size: 2389 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20130526/cdd2eefa/attachment.obj>
-------------- next part --------------


On Apr 13, 2012, at 2:51 PM, Landon J Fuller <landonf at plausible.coop> wrote:

> Howdy,
> 
> I was looking into trunking VLANs into a virtual machine via bridging, and noted that transmit of 802.1q tagged packets worked from the guest VM, but upon reception, the VLAN tag seemed to be stripped before the packets hit the guest's interface.
> 
> Taking a look at the netgraph-based bridging implementation, it looks like the VLAN tag is not being re-inserted at the head of the ethernet frame prior to handing off the to VirtualBox, and VBox doesn't seem to have an equivalent 'ether_vtag' field in its INTNETSG struct to handle this.
> 
> Thus, to preserve the VLAN tag, I modified vboxNetFltFreeBSDMBufToSG() to ether_vlanencap() to insert the VLAN tag before handing off to VBox. With this in place, I was able to successfully trunk VLANs to a virtual machine. 
> 
> Some caveats:
> 	- If using virtio-kmod's if_vtnet, you must set vlanhwfilter (or promisc) flags on the guest interface before virtualbox will pass the VLAN tagged packets through. Otherwise, the VBox virtio-net device implementation will filter out the incoming packets before handing them to the VM hardware.
> 	- VBox's em(4) host implementation does not appear to support 'hardware' VLAN tagging, but it does declare it. If using a em(4) virtualized NIC, you must set -vlanhwtag on the guest interface.
> 
> I welcome someone(s) with more experience than I eyeballing the (tiny) attached patch. I'm also especially concerned as to whether this should be considered supported functionality in VBox, or I'm just getting lucky with the virtio-net code path.
> 
> Thanks,
> Landon
> 
> <patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c>_______________________________________________
> freebsd-emulation at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation
> To unsubscribe, send any mail to "freebsd-emulation-unsubscribe at freebsd.org"