[vbox-dev] Control IP multicast reception via API?

Klaus Espenlaub klaus.espenlaub at oracle.com
Wed Jul 16 09:36:11 GMT 2014


On 15.07.2014 09:00, Karoline Haus wrote:
> Hi Klaus, thanks for your reply.
> So are you saying that the best way to support multicast in a VBOX
> environment is to use the bridging configuration for my VM's network
> cards, and if I do that, then all multicast is passed into VMs? Or does
> it actually do something smarter like IGMP filtering?

The "virtual switch" code in VirtualBox is currently not particularly 
smart regarding multicast, it treats them like broadcasts. Of course 
this can be improved, but so far multicast is a feature with extremely 
low demand, so the polishing doesn't have enough priority.

> If I want to receive multicast in my VM, then it (or better: my
> application inside the VM) would normally register on IP multicast
> addresses via IGMP. On a non-virtualized system, the network card of the
> machine would be switched into multicast listening mode and would only
> register on that particular address (at Ethernet level) to pass packets
> to that address up to the host OS. It would not go into promiscous mode.
> And multicast packets to other addresses I didn't register for, will be
> dropped.

Right, and that's what happens with the VM's NIC.

> If I now have a VM environment, then how do I get the host NIC to
> register for multicast addresses my VMs are interested in? Does that
> work with VBOX? Or will, with bridging, the host NIC be set into all
> promiscous mode by default? That seems to be a performance hit. Will it
> pass ANY multicast packets into my VM and not do any sort of filtering
> at all, I guess?

On the host promiscuous mode is unavoidable, because most NICs can only 
support one MAC address. The few expensive ones which support multiple 
MAC addresses (and the ones which do support very small numbers usually, 
which means with a few VMs it's easily possible to exhaust them, having 
to go to promisc again) often don't meet the necessary host OS support 
for such multiple MAC addresses, rendering the feature unusable.


> Thanks for your help.
> Karoline
> Klaus Espenlaub <klaus.espenlaub at oracle.com> schrieb am 13:35
> Donnerstag, 10.Juli 2014:
> Karoline
> On 10.07.2014 07:49, Karoline Haus wrote:
>  > Do the host-only network interfaces in any way behave differently to the
>  > typical tun/tap Ethernet devices Linux offers? I mean in terms of
>  > multicast reception. So if I bridge from the physical device to the
>  > host-only interface then it should be able to process multicast pakets
>  > as well right?
> It should - but why would one want to touch the linux bridging support?
> The reason why we dumped it years ago was that it was extremely
> unreliable. Caused random connectivity problems, and there were setups
> where for unexplainable reasons no data would ever pass through br0 to
> the tap device used by VirtualBox. Of course it might be all fixed by
> now, but using linux bridging to connect to a host only network sounds
> like a very complicated way to replace VirtualBox bridging straight to
> the desired interface.
> There is no intentional multicast blocking done anywhere in VirtualBox.
> Klaus
>  > Klaus Espenlaub <klaus.espenlaub at oracle.com
> <mailto:klaus.espenlaub at oracle.com>> schrieb am 18:20 Dienstag,
>  > 8.Juli 2014:
>  >
>  >
>  > Karoline,
>  >
>  > On 08.07.2014 17:42, Karoline Haus wrote:
>  >  > Hi there, I was just wondering, if it was possible to control
> multicast
>  >  > reception for VMs via host-only interfaces via the VBOX API? I
> could not
>  >  > find anything but not sure I searched in the right place. Thanks
> for any
>  >  > pointers!
>  >
>  >
>  > There's nothing in the API controlling this, and the reason is that the
>  > emulation itself deals with ethernet frames. It couldn't care less what
>  > they mean. Of course the actual behavior heavily depends on the
>  > networking mode (NAT definitely doesn't handle multicast in a sensible
>  > way), and bridged/host only/internal network should be able to handle
>  > them. Theoretically. Not aware of this getting tested :)
>  >
>  > Klaus

More information about the vbox-dev mailing list