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
patch-src-VBox-HostDrivers-VBoxNetFlt-freebsd-VBoxNetFlt-freebsd.c
Description: Binary data
On Apr 13, 2012, at 2:51 PM, Landon J Fuller <land...@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
_______________________________________________ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
