Interface baseada em Macvlan pings do host, mas não do namespace

[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 vboxnet110.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 macespaç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 HosteVM
Ping entre NSeNS
dhclient de NS

O que não funciona:

ping entre NSeVM
ping entre NSeHost

Onde eu comecei a enlouquecer:

tcpdump on host(a máquina real) realmente mostra a solicitação e respostas ARP
tcpdump on NSmostra solicitações de ARP enviadas ao host
O tcpdump on VMfaz 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 mac0interface diretamente na VM (sem espaço para nome) e funcionou perfeitamente.

— yadutaf
fonte

Não entendo por que essa pergunta foi sinalizada como fora de tópico. Definitivamente, é uma pergunta sysadmin / netadmin, relevante para vários ambientes de virtualização, e não é trivial (ou, se for, 90% das perguntas no StackOverflow também são fora de tópico). Eu adoraria se as pessoas que o sinalizaram como "fora de tópico" se preocupassem em explicar o porquê, em vez de copiar e colar uma regra que obviamente não se aplica aqui. Obrigado!

— jpetazzo

@jpetazzo Isso não é fora de tópico, e posso apenas assumir que as pessoas que o fecharam o fizeram com base na organização / apresentação inadequada da pergunta (provavelmente devido ao OP não ser um administrador de sistema / rede). Além disso, o escopo do Server Fault (não apenas o tópico) é diferente do Stack Overflow - seu argumento me faz pensar que você não visitou nossa Central de Ajuda, pois não faz sentido.

— Chris S

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 eth0para o modo promíscuo. Ou seja, eth0produzirá todo o tráfego da rede, não apenas aquele com o servidor principalMAC

No entanto, é exatamente assim que macvlanfunciona: 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 !

— yadutaf
fonte

Então você teve que desmarcar "no modo promisc" nessa VM também, suponho?

— Nils

Na verdade, é desmarcado.

— yadutaf