Identical MAC address on two different VM, yet I have internet connectivity
Solution 1
This is one of those things that surprises people because it goes against what they've been taught.
2 machines with the same hardware mac address on the same broadcast domain can talk to each other just fine as long as they have different IP addresses (and the switching gear plays nice).
Lets start with a test setup:
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
So notice how both machines have the same MAC addr, but different IPs.
Lets try pinging:
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
So, the remote host responded. Well, that's weird. Lets look at the neighbor table:
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
That's our MAC!
Lets do a tcpdump
on the other host to see that it's actually getting the traffic:
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
So, as you can see, even though the traffic has the same source and destination hardware mac address, everything still works perfectly fine.
The reason for this is that the MAC address lookup comes very late in the communication process. The box has already used the destination IP address, and the routing tables to determine which interface it is going to send the traffic out on. The mac address that it adds onto the packet comes after that decision.
I should also note that this is dependent upon the layer 2 infrastructure. How these machines are connected, and what sits between them. If you've got a more intelligent switch, this may not work. It may see this packet coming through and reject it.
Now, going on to the traditional belief, of that this doesn't work. Well it is true, from a certain point of view :-)
The problem arises when another host on the network needs to talk to either of these machines. When the traffic goes out, the switch is going to route the traffic by the destination mac address, and it's only going to send it to a single host.
There are a few possible reasons why this test setup works:
- The traffic is broadcast to all ports, or to all ports which the MAC matches.
- The switch discards the source port as an option when determining the destination port.
- The switch is actually a layer 3 switch and is routing based on the IP address, and not the mac address.
Solution 2
The effects of a duplicate MAC address can be subtle in some cases.
Switches distribute traffic to hosts based on "seen MAC" addresses. When you turn on your computer and it sends its first packet out on the network, your switch will log in its MAC table that "MAC address X came from port Y". Conversely then, in the future when it sees a unicast packet addressed to MAC address X, it knows to send it to port Y.
Since your VM is only on a single physical switch port, it's up to your hypervisor (VirtualBox) to sort out where to send the packets directed to that virtual MAC. In the case of a duplicate, it probably just sends it to both VMs and lets the network stack on each VM sort it out. (the networking stack would likely see that traffic was sent to its MAC address that did not belong to one of its own IP addresses, and silently drop the packet.) So you can imagine that this would cause a fair amount of extra work, for the OS to wake up and process each packet, whereas if you had unique MAC addresses the [virtual] hardware or driver could drop the packet intended for the other host, before sending it up the stack.
On a switched network (unlike your VM example), a duplicate MAC address would cause a switch to be confused about where to send traffic. Each packet a host with a duplicate MAC sends out would typically cause the switch to surmise that the host "moved" from one port on the switch to another. If both hosts were sending and receiving traffic at the same rate, you would expect each host to lose 50% of its return traffic.
ARP and IPv4 may not be too concerned about duplicate MAC addresses, so IPv4 networking may work properly. (though a robust stack, or a host with additional security/networking tools, may consider a duplicate MAC address as a red flag.) Also, if you are using DHCP, a DHCP server (absent a sufficiently unique client ID) could assign a duplicate IPv4 address, which could be problematic.
On the other hand, IPv6 bases automatically configured addresses on the MAC address. IPv6 also includes the concept of duplicate address detection, which means that a duplicate MAC address could cause the following effects (according to RFC 4862 section 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).
Related videos on Youtube
![user](https://i.stack.imgur.com/WH37e.jpg?s=256&g=1)
user
Updated on September 18, 2022Comments
-
user almost 2 years
I have set up a network as such: Set up host-only networking on VirtualBox. The first adapter is configured with NAT, the second with host-only networking
HOST: Windows
GUEST: CentOS VM1, CentOS VM2 (clone of VM1)When executing ifconfig -a on both VMs, I noticed that the MAC addresses are exactly the same. My question is how am I able to ping from VM1 to VM2 considering that the MAC addresses are the same?
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
-
Gilles 'SO- stop being evil' over 9 yearsAre you sure that you're really pinging VM1 from VM2, and not actually pinging VM1? You can have two machines with the same MAC address, but only if they're on different Ethernet links, which isn't the case for two VMs using the same virtualization software on the same host.
-
phemmer over 9 yearsWhy is this closed as a duplicate? The questions are not the same.
-
Anthon over 9 yearsDid you copy the one VM to the other? In that case you need to change that via "VirtualBox Manager" -> Settings -> Adapter 1 -> Advanced -> MAC Address
-
fpmurphy over 9 years@Gilles. You are wrong. Two VMs using the same virtualization software on the same host can have different Ethernet links. Look at VMware Workstation Virtual Network Editor for an example.
-
slm over 9 years@Patrick - when I looked at them earlier they appeared to be duplicates to me. If not I can reopen it.
-
dmarucco over 9 yearsOne interesting thing about this example: notice that the link-local IPv6 addresses here (which are based on the MAC addresses) are identical. IPv6 has a duplicate address detection feature, which should prevent this setup from working. Would you mind posting the output of
ip -6 addr
on both machines? I'm curious if one of the addresses was marked duplicate. (which, if I remember the RFC correctly, should cause the [IPv6] interface to be shut down) -
Mark Plotnick over 9 yearsWhen you say "The first adapter is configured with NAT, the second with host-only networking", do you mean that each VM has two adapters? If so, can you show us the output of ifconfig for both interfaces on both VMs?
-
user over 9 years@MarkPlotnick added the further details above. Yes two adapters.
-
user over 9 years@Gilles but I have created two adapters for VM1 and two adapters for VM2. I thought the virtual adapters function as physical ports exclusive from each other. Doesn't this mean they are automatically on different Ethernet links?
-
user over 9 years@MarkPlotnick found this in dmesg for VM1 but not VM2
code eth0: no IPv6 routers present eth1: no IPv6 routers present
-
dmarucco over 9 years@khadija, notice that you see
dadfailed
in yourip -6 addr
output. That means that your address failed duplicate address detection, so IPv6 will not be usable on that interface.
-
-
phemmer over 9 yearsLayer 3 switches exist, which route based on IP, not MAC.
-
dmarucco over 9 years@Patrick The layer 3 switches I've worked on still use MAC addresses at layer 2. When they say "Layer 3 switch" they typically mean that the switching hardware also knows how to route traffic at layer 3. (act as an IP router) Routed traffic at layer 3 is treated differently than switched traffic at layer 2. (so routed packets coming in may not be affected by packet loss, but layer 2 switched packets on the same network would.) But which specific switch are you talking about?
-
user over 9 yearsInteresting explanation! Thanks for providing some clarification.