Dirección MAC idéntica en dos máquinas virtuales diferentes, pero tengo conectividad a Internet

He configurado una red como tal: configurar redes de solo host en VirtualBox. El primer adaptador está configurado con NAT, el segundo con redes solo de host

Anfitrión: Windows
INVITADO: CentOS VM1, CentOS VM2 (clon de VM1)

Al ejecutar ifconfig -a en ambas máquinas virtuales, noté que las direcciones MAC son exactamente las mismas. Mi pregunta es ¿cómo puedo hacer ping de VM1 a VM2 teniendo en cuenta que las direcciones MAC son las mismas?

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

— usuario
fuente

¿Estás seguro de que realmente estás haciendo ping a VM1 desde VM2 y no estás haciendo ping a VM1? Puede tener dos máquinas con la misma dirección MAC, pero solo si están en diferentes enlaces Ethernet, que no es el caso para dos máquinas virtuales que usan el mismo software de virtualización en el mismo host.

— Gilles 'SO- deja de ser malvado'

¿Por qué se cierra esto como un duplicado? Las preguntas no son lo mismo.

— Patrick

¿Copiaste una VM a la otra? En ese caso, debe cambiar eso a través de "VirtualBox Manager" -> Configuración -> Adaptador 1 -> Avanzado -> Dirección MAC

— Anthon

@Gilles. Está usted equivocado. Dos máquinas virtuales que usan el mismo software de virtualización en el mismo host pueden tener diferentes enlaces Ethernet. Mire el Editor de red virtual de VMware Workstation para ver un ejemplo.

— fpmurphy

@ Khadija, observe que ve dadfaileden su ip -6 addrsalida. Eso significa que su dirección falló en la detección de direcciones duplicadas, por lo que IPv6 no será utilizable en esa interfaz.

— mpontillo

Respuestas:

Esta es una de esas cosas que sorprende a la gente porque va en contra de lo que se les ha enseñado.
2 máquinas con la misma dirección mac de hardware en el mismo dominio de transmisión pueden comunicarse entre sí bien siempre que tengan diferentes direcciones IP (y el equipo de conmutación funciona bien).

Comencemos con una configuración de prueba:

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

Observe cómo ambas máquinas tienen el mismo MAC addr, pero diferentes IP.

Vamos a intentar hacer 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

Entonces, el host remoto respondió. Bueno, eso es raro. Veamos la mesa vecina:

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

Ese es nuestro MAC!

Hagamos un tcpdumpen el otro host para ver que realmente está recibiendo el tráfico:

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

Entonces, como puede ver, a pesar de que el tráfico tiene la misma dirección mac de hardware de origen y destino, todo funciona perfectamente bien.

La razón de esto es que la búsqueda de la dirección MAC llega muy tarde en el proceso de comunicación. El cuadro ya ha utilizado la dirección IP de destino y las tablas de enrutamiento para determinar en qué interfaz enviará el tráfico. La dirección mac que agrega al paquete viene después de esa decisión.

También debo señalar que esto depende de la infraestructura de la capa 2. Cómo se conectan estas máquinas y qué se ubica entre ellas. Si tiene un interruptor más inteligente, esto puede no funcionar. Puede ver este paquete llegando y rechazarlo.

Ahora, pasando a la creencia tradicional, de que esto no funciona. Bueno, es cierto, desde cierto punto de vista :-)
El problema surge cuando otro host en la red necesita hablar con cualquiera de estas máquinas. Cuando se corta el tráfico, el conmutador lo enrutará por la dirección MAC de destino, y solo lo enviará a un solo host.

Hay algunas razones posibles por las que funciona esta configuración de prueba:

El tráfico se transmite a todos los puertos o a todos los puertos con los que coincide el MAC.
El conmutador descarta el puerto de origen como una opción al determinar el puerto de destino.
El conmutador es en realidad un conmutador de capa 3 y se enruta en función de la dirección IP y no de la dirección mac.

— Patricio
fuente

Interesante explicación! Gracias por proporcionar alguna aclaración.

— usuario

Los efectos de una dirección MAC duplicada pueden ser sutiles en algunos casos.

Los conmutadores distribuyen el tráfico a los hosts en función de las direcciones "MAC vistas". Cuando enciende su computadora y envía su primer paquete a la red, su conmutador registrará en su tabla MAC que "la dirección MAC X vino del puerto Y". Por el contrario, en el futuro, cuando vea un paquete de unidifusión dirigido a la dirección MAC X, sabe enviarlo al puerto Y.

Dado que su VM solo está en un solo puerto de conmutador físico, depende de su hipervisor (VirtualBox) decidir dónde enviar los paquetes dirigidos a ese MAC virtual. En el caso de un duplicado, probablemente solo lo envíe a ambas máquinas virtuales y permita que la red se apile en cada máquina virtual. (la pila de red probablemente vería que el tráfico se envió a su dirección MAC que no pertenecía a una de sus propias direcciones IP, y descartará el paquete en silencio). Así que puede imaginar que esto causaría una buena cantidad de trabajo adicional, por el sistema operativo para activar y procesar cada paquete, mientras que si tuviera direcciones MAC únicas, el hardware [virtual] o el controlador podrían descartar el paquete destinado al otro host, antes de enviarlo a la pila.

En una red conmutada (a diferencia de su ejemplo de VM), una dirección MAC duplicada podría confundir a un conmutador sobre dónde enviar tráfico. Cada paquete que envía un host con un duplicado de MAC causaría que el conmutador suponga que el host se "movió" de un puerto en el conmutador a otro. Si ambos hosts enviaran y recibieran tráfico a la misma velocidad, esperaría que cada host pierda el 50% de su tráfico de retorno.

ARP e IPv4 pueden no estar demasiado preocupados por las direcciones MAC duplicadas, por lo que las redes IPv4 pueden funcionar correctamente. (aunque una pila robusta, o un host con herramientas de seguridad / redes adicionales, puede considerar una dirección MAC duplicada como una bandera roja). Además, si está utilizando DHCP, un servidor DHCP (a falta de una ID de cliente suficientemente única) podría asignar un Dirección IPv4 duplicada, lo que podría ser problemático.

Por otro lado, IPv6 basa las direcciones configuradas automáticamente en la dirección MAC . IPv6 también incluye el concepto de detección de direcciones duplicadas , lo que significa que una dirección MAC duplicada podría causar los siguientes efectos (de acuerdo con RFC 4862 sección 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
fuente

Existen conmutadores de capa 3, que se basan en IP, no en MAC.

— Patrick

@Patrick Los conmutadores de capa 3 en los que he trabajado todavía usan direcciones MAC en la capa 2. Cuando dicen "Conmutador de capa 3" generalmente significan que el hardware de conmutación también sabe cómo enrutar el tráfico en la capa 3. (actuar como un enrutador IP ) El tráfico enrutado en la capa 3 se trata de manera diferente al tráfico conmutado en la capa 2. (por lo que los paquetes enrutados que ingresan pueden no verse afectados por la pérdida de paquetes, pero los paquetes conmutados en la capa 2 en la misma red sí lo harían). Pero, ¿de qué conmutador específico está hablando? ?

— mpontillo