[EDITAR]
O sistema de produção é atualmente um sistema físico misto e baseado em ESXi. Obviamente, nunca usaríamos o virtualbox, mesmo em um ambiente de pré-produção! Ele foi usado aqui apenas para diminuir rapidamente o problema diretamente na minha área de trabalho.
Obrigado pela explicação para o "em espera" na meta!
[/EDITAR]
Minha configuração:
- Rede privada
vboxnet1
10.0.7.0/24 - 1 host, desktop ubuntu
- 1 VM, servidor ubuntu (VirtualBox)
Layout de endereço:
- HOST: 10.0.7.1
- VM: 10.0.7.101
- VM MAC NAMESPACE : 10.0.7.102
No VM
, executei os seguintes comandos:
ip netns add mac # create a new nmespace
ip link add link eth0 mac0 type macvlan # create a new macvlan interface
ip link set mac0 netns mac
No mac
espaço para nome, dentro da VM:
ip link set lo up
ip link set mac up
ip addr add 10.0.7.102/24 dev mac0
Para que basicamente terminemos com: (como o início?)
+------------------------+
| Host: 10.0.7.1 |
| |
| +--------------------+ |
| | VM: 10.0.7.101 | |
| | | |
| | +----------------+ | |
| | | NS: 10.0.7.102 | | |
| | | | | |
| | +----------------+ | |
| +--------------------+ |
+------------------------+
O que funciona:
- Ping entre
Host
eVM
- Ping entre
NS
eNS
- dhclient de
NS
O que não funciona:
- ping entre
NS
eVM
- ping entre
NS
eHost
Onde eu comecei a enlouquecer:
- tcpdump on
host
(a máquina real) realmente mostra a solicitação e respostas ARP - tcpdump on
NS
mostra solicitações de ARP enviadas ao host - O tcpdump on
VM
faz toda a bagunça funcionar (!) -> ping começa a obter respostas quando o tcpdump é iniciado na VM?!?
Então, aposto que você estava ansioso por isso, minha pergunta é: como fazê-lo funcionar? Eu suspeito que algo está errado com o ARP no macvlan dentro do NS, mas não consigo descobrir exatamente o que ...
Btw, eu fiz as mesmas experiências com a mac0
interface diretamente na VM (sem espaço para nome) e funcionou perfeitamente.
fonte
Respostas:
OK, então, para a posteridade, o fato de o tcpdump fazer com que tudo de repente funcione deveria ter me colocado no caminho certo. O que ele faz internamente é alternar
eth0
para o modo promíscuo. Ou seja,eth0
produzirá todo o tráfego da rede, não apenas aquele com o servidor principalMAC
No entanto, é exatamente assim que
macvlan
funciona: ele adiciona um novo endereço MAC virtual secundário que o adaptador de rede "físico" (que é uma VM) não conhece.Portanto, a solução fácil é manualmente:
ifconfig eth0 promisc
Espero que ajude !
fonte