Indirizzo MAC identico su due VM diverse, ma ho la connettività Internet

Ho impostato una rete come tale: imposta la rete solo host su VirtualBox. Il primo adattatore è configurato con NAT, il secondo con rete solo host

HOST: Windows
OSPITE: CentOS VM1, CentOS VM2 (clone di VM1)

Durante l'esecuzione di ifconfig -a su entrambe le macchine virtuali, ho notato che gli indirizzi MAC sono esattamente gli stessi. La mia domanda è: come posso eseguire il ping da VM1 a VM2 considerando che gli indirizzi MAC sono gli stessi?

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

— utente
fonte

Sei sicuro di eseguire il ping di VM1 da VM2 e di non eseguire il ping di VM1? Puoi avere due macchine con lo stesso indirizzo MAC, ma solo se si trovano su collegamenti Ethernet diversi, il che non è il caso di due macchine virtuali che utilizzano lo stesso software di virtualizzazione sullo stesso host.

— Gilles 'SO- smetti di essere malvagio' il

Perché questo è chiuso come duplicato? Le domande non sono le stesse.

— Patrick,

Hai copiato una VM sull'altra? In tal caso è necessario modificarlo tramite "VirtualBox Manager" -> Impostazioni -> Scheda 1 -> Avanzate -> Indirizzo MAC

— Anthon,

@Gilles. Tui hai torto. Due macchine virtuali che utilizzano lo stesso software di virtualizzazione sullo stesso host possono avere collegamenti Ethernet diversi. Guarda l'editor di rete virtuale di VMware Workstation per un esempio.

— fpmurphy

@khadija, nota che vedi dadfailednella tua ip -6 addruscita. Ciò significa che il tuo indirizzo non è riuscito a rilevare duplicati dell'indirizzo, quindi IPv6 non sarà utilizzabile su tale interfaccia.

— mpontillo,

Risposte:

Questa è una di quelle cose che sorprende le persone perché va contro ciò che è stato loro insegnato.
2 macchine con lo stesso indirizzo mac hardware sullo stesso dominio di trasmissione possono comunicare tra loro bene purché abbiano indirizzi IP diversi (e il dispositivo di commutazione suona bene).

Iniziamo con una configurazione di prova:

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

Quindi nota come entrambe le macchine hanno lo stesso indirizzo MAC, ma IP diversi.

Proviamo a eseguire il 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

Quindi, l'host remoto ha risposto. Bene, è strano. Diamo un'occhiata al tavolo vicino:

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

Questo è il nostro MAC!

Facciamo un test tcpdumpsull'altro host per vedere che sta effettivamente ricevendo il traffico:

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

Quindi, come puoi vedere, anche se il traffico ha lo stesso indirizzo mac hardware di origine e destinazione, tutto funziona ancora perfettamente.

La ragione di ciò è che la ricerca dell'indirizzo MAC arriva molto tardi nel processo di comunicazione. La casella ha già utilizzato l'indirizzo IP di destinazione e le tabelle di routing per determinare su quale interfaccia verrà inviato il traffico. L'indirizzo mac che aggiunge al pacchetto viene dopo quella decisione.

Dovrei anche notare che questo dipende dall'infrastruttura di livello 2. Come sono collegate queste macchine e cosa si frappone tra loro. Se hai un interruttore più intelligente, questo potrebbe non funzionare. Potrebbe vedere arrivare questo pacchetto e rifiutarlo.

Ora, proseguendo con la credenza tradizionale, di ciò non funziona. Bene, è vero, da un certo punto di vista :-)
Il problema sorge quando un altro host sulla rete deve parlare con una di queste macchine. Quando il traffico si interrompe, lo switch instraderà il traffico in base all'indirizzo mac di destinazione e lo invierà solo a un singolo host.

Esistono alcuni motivi possibili per cui questa configurazione di test funziona:

Il traffico viene trasmesso a tutte le porte o a tutte le porte corrispondenti al MAC.
Lo switch ignora la porta di origine come opzione per determinare la porta di destinazione.
Lo switch è in realtà uno switch di livello 3 e esegue il routing in base all'indirizzo IP e non all'indirizzo mac.

— Patrick
fonte

Spiegazione interessante! Grazie per aver fornito alcuni chiarimenti.

— utente

Gli effetti di un indirizzo MAC duplicato possono essere sottili in alcuni casi.

Gli switch distribuiscono il traffico agli host in base agli indirizzi "MAC visti". Quando accendi il computer e invia il suo primo pacchetto sulla rete, il tuo switch accederà alla sua tabella MAC che "l'indirizzo MAC X proviene dalla porta Y". Al contrario, in futuro, quando vede un pacchetto unicast indirizzato all'indirizzo MAC X, sa di inviarlo alla porta Y.

Poiché la VM si trova solo su una singola porta dello switch fisico, spetta all'hypervisor (VirtualBox) ordinare dove inviare i pacchetti diretti a quel MAC virtuale. Nel caso di un duplicato, probabilmente lo invia a entrambe le macchine virtuali e consente alla rete di impilarsi su ciascuna macchina virtuale per risolverlo. (lo stack di rete probabilmente vedrebbe che il traffico è stato inviato al suo indirizzo MAC che non apparteneva a uno dei suoi indirizzi IP e rilasciava silenziosamente il pacchetto.) Quindi puoi immaginare che ciò causerebbe una discreta quantità di lavoro extra, per il sistema operativo per riattivare ed elaborare ciascun pacchetto, mentre se si disponessero di indirizzi MAC univoci, l'hardware o il driver [virtuale] potrebbe rilasciare il pacchetto destinato all'altro host, prima di inviarlo nello stack.

Su una rete commutata (diversamente dall'esempio della VM), un indirizzo MAC duplicato causerebbe la confusione di uno switch su dove inviare il traffico. Ogni pacchetto che un host con un MAC duplicato invia in genere indurrebbe lo switch a supporre che l'host "si spostasse" da una porta sullo switch a un'altra. Se entrambi gli host inviassero e ricevessero traffico alla stessa velocità, ti aspetteresti che ogni host perda il 50% del suo traffico di ritorno.

ARP e IPv4 potrebbero non essere troppo preoccupati per gli indirizzi MAC duplicati, quindi la rete IPv4 potrebbe funzionare correttamente. (anche se uno stack robusto o un host con strumenti di sicurezza / rete aggiuntivi, può considerare un indirizzo MAC duplicato come una bandiera rossa). Inoltre, se si utilizza DHCP, un server DHCP (in assenza di un ID client sufficientemente univoco) potrebbe assegnare un indirizzo IPv4 duplicato, che potrebbe essere problematico.

D'altra parte, IPv6 basa automaticamente gli indirizzi configurati sull'indirizzo MAC . IPv6 include anche il concetto di rilevamento di indirizzi duplicati , il che significa che un indirizzo MAC duplicato potrebbe causare i seguenti effetti (secondo RFC 4862 sezione 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

Esistono switch di livello 3, che instradano in base a IP, non a MAC.

— Patrick,

@Patrick Gli switch di livello 3 su cui ho lavorato usano ancora gli indirizzi MAC al livello 2. Quando dicono "Switch di livello 3" in genere significano che l'hardware di commutazione sa anche come instradare il traffico al livello 3. (fungere da router IP ) Il traffico instradato al livello 3 viene trattato in modo diverso rispetto al traffico commutato al livello 2. (quindi i pacchetti indirizzati in arrivo potrebbero non essere influenzati dalla perdita di pacchetti, ma lo farebbero i pacchetti commutati di livello 2 sulla stessa rete.) Ma di quale specifico switch stai parlando ?

— mpontillo,