Skip to main content
Unix & Linux

Return to Answer

added 677 characters in body
Source Link
phemmer
phemmer
  • 73.9k
  • 21
  • 199
  • 231

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. The issue will arise if someone else on (and the network tries to talk to themswitching gear plays nice).

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.

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. The issue will arise if someone else on the network tries to talk to them.

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).

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.
added 253 characters in body
Source Link
phemmer
phemmer
  • 73.9k
  • 21
  • 199
  • 231

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.

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.

Source Link
phemmer
phemmer
  • 73.9k
  • 21
  • 199
  • 231

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. The issue will arise if someone else on the network tries to talk to them.

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.