Endereço MAC idêntico em duas VM diferentes, mas eu tenho conectividade com a Internet

Eu configurei uma rede como tal: Configure a rede somente host no VirtualBox. O primeiro adaptador é configurado com NAT, o segundo com rede somente host

HOST: Windows
CONVIDADO: CentOS VM1, CentOS VM2 (clone da VM1)

Ao executar o ifconfig -a nas duas VMs, notei que os endereços MAC são exatamente os mesmos. Minha pergunta é como posso executar o ping da VM1 para a VM2, considerando que os endereços MAC são os mesmos?

VM1:
eth0      Link encap:Ethernet  HWaddr 08:00:27:AF:A3:28  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feaf:a328/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27 errors:0 dropped:0 overruns:0 frame:0
          TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10671 (10.4 KiB)  TX bytes:5682 (5.5 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:C4:A8:B6  
          inet addr:192.168.56.102  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fec4:a8b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:859 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:114853 (112.1 KiB)  TX bytes:4823 (4.7 KiB)

 ip -6 addr
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:feaf:a328/64 scope link 
           valid_lft forever preferred_lft forever
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:fec4:a8b6/64 scope link 
           valid_lft forever preferred_lft forever

VM2:

eth0      Link encap:Ethernet  HWaddr 08:00:27:AF:A3:28  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feaf:a328/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:114 errors:0 dropped:0 overruns:0 frame:0
          TX packets:151 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:41594 (40.6 KiB)  TX bytes:13479 (13.1 KiB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:C4:A8:B6  
          inet addr:192.168.56.101  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fec4:a8b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1900 errors:0 dropped:0 overruns:0 frame:0
          TX packets:78 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:259710 (253.6 KiB)  TX bytes:9736 (9.5 KiB)



ip -6 addr
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:feaf:a328/64 scope link 
           valid_lft forever preferred_lft forever
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
        inet6 fe80::a00:27ff:fec4:a8b6/64 scope link tentative dadfailed 
           valid_lft forever preferred_lft forever

networking ip ethernet mac-address

— do utilizador
fonte

Você tem certeza de que está realmente executando o ping da VM1 da VM2 e, na verdade, não está executando o ping da VM1? Você pode ter duas máquinas com o mesmo endereço MAC, mas apenas se estiverem em links Ethernet diferentes, o que não é o caso de duas VMs usando o mesmo software de virtualização no mesmo host.

— Gilles 'SO- stop be evil'

Por que isso é fechado como duplicado? As perguntas não são as mesmas.

— Patrick

Você copiou uma VM para a outra? Nesse caso, você precisa alterar isso por meio do "VirtualBox Manager" -> Configurações -> Adaptador 1 -> Avançado -> Endereço MAC

— Anthon

@Gilles. Você está errado. Duas VMs que usam o mesmo software de virtualização no mesmo host podem ter links Ethernet diferentes. Veja o VMware Workstation Virtual Network Editor para um exemplo.

— precisa saber é o seguinte

@khadija, observe que você vê dadfailedna sua ip -6 addrsaída. Isso significa que seu endereço falhou na detecção de endereço duplicado, portanto, o IPv6 não será utilizável nessa interface.

— mpontillo

Respostas:

Essa é uma daquelas coisas que surpreende as pessoas porque vai contra o que elas aprenderam.
2 máquinas com o mesmo endereço MAC de hardware no mesmo domínio de broadcast podem conversar entre si muito bem, desde que tenham endereços IP diferentes (e o equipamento de comutação seja bom).

Vamos começar com uma configuração de teste:

VM1 $ ip addr show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:3c:f9:ad brd ff:ff:ff:ff:ff:ff
    inet 169.254.0.2/24 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe3c:f9ad/64 scope link 
       valid_lft forever preferred_lft forever

VM2 $ ip addr show dev enp0s8
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:3c:f9:ad brd ff:ff:ff:ff:ff:ff
    inet 169.254.0.3/24 scope global enp0s8
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe3c:f9ad/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever

Portanto, observe como ambas as máquinas têm o mesmo endereço MAC, mas IPs diferentes.

Vamos tentar fazer ping:

VM1 $ ping -c 3 169.254.0.3
PING 169.254.0.3 (169.254.0.3) 56(84) bytes of data.
64 bytes from 169.254.0.3: icmp_seq=1 ttl=64 time=0.505 ms
64 bytes from 169.254.0.3: icmp_seq=2 ttl=64 time=0.646 ms
64 bytes from 169.254.0.3: icmp_seq=3 ttl=64 time=0.636 ms

--- 169.254.0.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.505/0.595/0.646/0.070 ms

Então, o host remoto respondeu. Bem, isso é estranho. Vamos olhar para a tabela vizinha:

VM1 $ ip neigh
169.254.0.3 dev enp0s8 lladdr 08:00:27:3c:f9:ad REACHABLE
10.0.2.2 dev enp0s3 lladdr 52:54:00:12:35:02 STALE

Esse é o nosso MAC!

Vamos fazer um tcpdumpno outro host para ver que ele realmente está recebendo o tráfego:

VM2 $ tcpdump -nn -e -i enp0s8 'host 169.254.0.2'
16:46:21.407188 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.2 > 169.254.0.3: ICMP echo request, id 2681, seq 1, length 64
16:46:21.407243 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.3 > 169.254.0.2: ICMP echo reply, id 2681, seq 1, length 64
16:46:22.406469 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.2 > 169.254.0.3: ICMP echo request, id 2681, seq 2, length 64
16:46:22.406520 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.3 > 169.254.0.2: ICMP echo reply, id 2681, seq 2, length 64
16:46:23.407467 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.2 > 169.254.0.3: ICMP echo request, id 2681, seq 3, length 64
16:46:23.407517 08:00:27:3c:f9:ad > 08:00:27:3c:f9:ad, ethertype IPv4 (0x0800), length 98: 169.254.0.3 > 169.254.0.2: ICMP echo reply, id 2681, seq 3, length 64

Portanto, como você pode ver, mesmo que o tráfego tenha o mesmo endereço mac do hardware de origem e destino, tudo ainda funciona perfeitamente.

A razão para isso é que a pesquisa de endereço MAC chega muito tarde no processo de comunicação. A caixa já usou o endereço IP de destino e as tabelas de roteamento para determinar em qual interface ele enviará o tráfego. O endereço mac que ele adiciona ao pacote vem após essa decisão.

Devo também observar que isso depende da infraestrutura da camada 2. Como essas máquinas estão conectadas e o que há entre elas. Se você tiver um switch mais inteligente, isso pode não funcionar. Pode ver esse pacote chegando e rejeitá-lo.

Agora, seguindo a crença tradicional, de que isso não funciona. Bem, é verdade, de um certo ponto de vista :-)
O problema surge quando outro host da rede precisa conversar com qualquer uma dessas máquinas. Quando o tráfego acaba, o switch direciona o tráfego pelo endereço mac de destino e envia apenas para um único host.

Existem algumas razões possíveis pelas quais essa configuração de teste funciona:

O tráfego é transmitido para todas as portas ou para todas as portas com as quais o MAC corresponde.
O switch descarta a porta de origem como uma opção ao determinar a porta de destino.
O switch é realmente um switch de camada 3 e é roteado com base no endereço IP e não no endereço mac.

— Patrick
fonte

Explicação interessante! Obrigado por fornecer alguns esclarecimentos.

— usuário

Os efeitos de um endereço MAC duplicado podem ser sutis em alguns casos.

Os switches distribuem o tráfego para os hosts com base nos endereços "vistos MAC". Quando você liga o computador e ele envia seu primeiro pacote na rede, o switch registra na tabela MAC que "o endereço MAC X veio da porta Y". Por outro lado, no futuro, quando vir um pacote unicast endereçado ao endereço MAC X, ele saberá enviá-lo para a porta Y.

Como a sua VM está apenas em uma única porta de switch físico, cabe ao seu hipervisor (VirtualBox) descobrir para onde enviar os pacotes direcionados para esse MAC virtual. No caso de uma duplicata, provavelmente a envia apenas para as duas VMs e permite que a rede empilhe em cada VM. (a pilha de rede provavelmente verá que o tráfego foi enviado para seu endereço MAC que não pertence a um de seus próprios endereços IP e silenciosamente descarta o pacote.) Portanto, você pode imaginar que isso causaria uma quantidade considerável de trabalho extra, por o sistema operacional para ativar e processar cada pacote, enquanto que se você tivesse endereços MAC exclusivos, o hardware ou o driver [virtual] poderia descartar o pacote destinado ao outro host, antes de enviá-lo para a pilha.

Em uma rede comutada (diferente do exemplo da sua VM), um endereço MAC duplicado causaria uma confusão no comutador sobre para onde enviar tráfego. Cada pacote que um host com um MAC duplicado envia normalmente faz com que o comutador suponha que o host "se moveu" de uma porta no comutador para outra. Se os dois hosts estiverem enviando e recebendo tráfego na mesma taxa, você espera que cada host perca 50% do tráfego de retorno.

O ARP e o IPv4 podem não estar muito preocupados com endereços MAC duplicados; portanto, a rede IPv4 pode funcionar corretamente. (embora uma pilha robusta, ou um host com ferramentas adicionais de segurança / rede, considere um endereço MAC duplicado como uma bandeira vermelha.) Além disso, se você estiver usando DHCP, um servidor DHCP (sem um ID de cliente suficientemente exclusivo) poderá atribuir um endereço IPv4 duplicado, o que pode ser problemático.

Por outro lado, o IPv6 baseia os endereços configurados automaticamente no endereço MAC . O IPv6 também inclui o conceito de detecção de endereço duplicado , o que significa que um endereço MAC duplicado pode causar os seguintes efeitos (de acordo com a RFC 4862, seção 5.4.5):

-  not send any IP packets from the interface,

-  silently drop any IP packets received on the interface, and

-  not forward any IP packets to the interface (when acting as a
   router or processing a packet with a Routing header).

— mpontillo
fonte

Os switches da camada 3 existem, que são roteados com base no IP, não no MAC.

— Patrick

@Patrick Os switches da camada 3 em que trabalhei ainda usam endereços MAC na camada 2. Quando eles dizem "switch da camada 3", normalmente significam que o hardware de comutação também sabe como rotear o tráfego na camada 3. (agir como um roteador IP ) O tráfego roteado na camada 3 é tratado de maneira diferente do tráfego comutado na camada 2. (portanto, os pacotes roteados que chegam não podem ser afetados pela perda de pacotes, mas os pacotes comutados da camada 2 na mesma rede.) Mas de qual switch específico você está falando? ?

— mpontillo