Problema de rede com múltiplos nós somente no host Vagrant (Virtualbox)

Estou tentando usar um ambiente vagante de várias VMs como plataforma de teste para implantar o OpenStack, e encontrei um problema de rede ao tentar me comunicar de uma VM para uma VM dentro de uma VM.

Eu tenho dois nós do Vagrant, um nó do controlador de nuvem e um nó de computação. Estou usando rede somente host. Meu Vagrantfile fica assim:

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

Quando tento iniciar uma VM (baseada em QEMU), ela inicializa com êxito no compute1 e seu nic virtual (vnet0) é conectado por meio de uma ponte, br100:

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

                        vnet0

Quando a VM QEMU faz uma solicitação ao servidor DHCP (dnsmasq) em execução no controlador, posso ver que a solicitação chega ao controlador devido à saída no syslog no 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 

No entanto, o DHCPOFFER nunca retorna à VM em execução no compute1. Se eu assistir as solicitações usando tcpdump na interface vboxnet3 na minha máquina host que executa o Vagrant (Mac OS X), posso ver as solicitações e as respostas

$ 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

Mas, se eu tcpdump no eth2 na computação, só vejo os pedidos, não as respostas:

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

Neste ponto, eu estou preso. Não sei por que as respostas do DHCP não estão chegando ao nó de computação. Talvez tenha algo a ver com a configuração do switch / roteador virtual do VirtualBox?

Observe que as interfaces eth2 nos dois nós foram configuradas para o modo promíscuo.

O problema é que a interface deve ser configurada no modo promíscuo através do Vagrant, não é suficiente fazê-lo dentro dos sistemas operacionais convidados.

Por exemplo, se você adicionar duas NICs, e a última NIC que você definir for a que será conectada às VMs, seu arquivo Vagrant deverá conter algo como:

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