8

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
Improve this question
11
  • Are 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. Commented Oct 4, 2014 at 14:05
  • Why is this closed as a duplicate? The questions are not the same. Commented Oct 4, 2014 at 14:58
  • Did 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 Commented Oct 4, 2014 at 15:52
  • @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. Commented Oct 4, 2014 at 16:03
  • 1
    @khadija, notice that you see dadfailed in your ip -6 addr output. That means that your address failed duplicate address detection, so IPv6 will not be usable on that interface. Commented Oct 5, 2014 at 2:17

2 Answers 2

Reset to default
16

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:

  1. The traffic is broadcast to all ports, or to all ports which the MAC matches.
  2. The switch discards the source port as an option when determining the destination port.
  3. The switch is actually a layer 3 switch and is routing based on the IP address, and not the mac address.
Improve this answer
1
  • Interesting explanation! Thanks for providing some clarification. Commented Oct 4, 2014 at 23:20
6

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).
Improve this answer
2
  • Layer 3 switches exist, which route based on IP, not MAC. Commented Oct 4, 2014 at 18:02
  • 2
    @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? Commented Oct 4, 2014 at 18:04

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.