Problema de red de nodo múltiple vagabundo (Virtualbox) solo de host

Estoy tratando de usar un entorno vagabundo de varias máquinas virtuales como banco de pruebas para implementar OpenStack, y me he encontrado con un problema de red al intentar comunicarme desde una máquina virtual a una máquina virtual dentro de una máquina virtual.

Tengo dos nodos Vagrant, un nodo controlador de nube y un nodo de cómputo. Estoy usando redes solo de host. Mi Vagrantfile se ve así:

Vagrant::Config.run do |config|

  config.vm.box = "precise64"

  config.vm.define :controller do |controller_config|
    controller_config.vm.network :hostonly, "192.168.206.130" # eth1
    controller_config.vm.network :hostonly, "192.168.100.130" # eth2
    controller_config.vm.host_name = "controller"
  end

  config.vm.define :compute1 do |compute1_config|
    compute1_config.vm.network :hostonly, "192.168.206.131" # eth1
    compute1_config.vm.network :hostonly, "192.168.100.131" # eth2
    compute1_config.vm.host_name = "compute1"
    compute1_config.vm.customize ["modifyvm", :id, "--memory", 1024]
  end
end

Cuando intento iniciar una máquina virtual (basada en QEMU), se inicia con éxito en compute1, y su nic virtual (vnet0) se conecta a través de un puente, br100:

root@compute1:~# brctl show 100
bridge name bridge id       STP enabled interfaces
br100       8000.08002798c6ef   no      eth2

                        vnet0

Cuando la VM QEMU realiza una solicitud al servidor DHCP (dnsmasq) que se ejecuta en el controlador, puedo ver que la solicitud llega al controlador debido a la salida en el syslog en el controlador:

Aug  6 02:34:56 precise64 dnsmasq-dhcp[12042]: DHCPDISCOVER(br100) fa:16:3e:07:98:11 
Aug  6 02:34:56 precise64 dnsmasq-dhcp[12042]: DHCPOFFER(br100) 192.168.100.2 fa:16:3e:07:98:11 

Sin embargo, el DHCPOFFER nunca regresa a la VM que se ejecuta en compute1. Si veo las solicitudes usando tcpdump en la interfaz vboxnet3 en mi máquina host que ejecuta Vagrant (Mac OS X), puedo ver tanto las solicitudes como las respuestas

$ sudo tcpdump -i vboxnet3  -n port 67 or port 68
tcpdump: WARNING: vboxnet3: That device doesn't support promiscuous mode
(BIOCPROMISC: Operation not supported on socket)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vboxnet3, link-type EN10MB (Ethernet), capture size 65535 bytes
22:51:20.694040 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:20.694057 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:20.696047 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311
22:51:23.700845 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:23.700876 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:23.701591 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311
22:51:26.705978 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:26.705995 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
22:51:26.706527 IP 192.168.100.1.67 > 192.168.100.2.68: BOOTP/DHCP, Reply, length 311

Pero, si tcpdump en eth2 en cómputo, solo veo las solicitudes, no las respuestas:

root@compute1:~# tcpdump -i eth2 -n port 67 or port 68
tcpdump: WARNING: eth2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
02:51:20.240672 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
02:51:23.249758 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280
02:51:26.258281 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fa:16:3e:07:98:11, length 280

En este punto, estoy atascado. No estoy seguro de por qué las respuestas de DHCP no llegan al nodo de cómputo. ¿Quizás tenga algo que ver con la configuración del conmutador / enrutador virtual VirtualBox?

Tenga en cuenta que las interfaces eth2 en ambos nodos se han configurado en modo promiscuo.

El problema es que la interfaz debe configurarse en modo promiscuo a través de Vagrant, hacerlo dentro de los sistemas operativos invitados no es suficiente.

Por ejemplo, si agrega dos NIC, y la última NIC que defina es la que se conectará a las VM, su Vagrantfile debería contener algo como:

compute1_config.vm.customize ["modifyvm", :id, "--nicpromisc3", "allow-all"]