Today I had an interesting e-mail from a supplier with regard to an issue they were experiencing. Firstly let me outline the issue –
- Devices are tracked using a combination of radio frequency technologies to ensure we can local objects (people, equipment etc) within a building
- Each device has an identifier, this supplier would like to associate incoming packets with an object based on the MAC address
- Example – object A has the MAC 00:11:22:33:44:55 therefore when we see a packet with this MAC we know it came from that object
- The device reports back to a central system located across two datacenters geographically separate from the device
The issue reported was that the MAC address received on the server does not match that of the device in the field. My immediate thoughts were that MAC addresses being layer 2 and that these packets are traversing broadcast domains and sites, obviously the MAC on the receiving end will not be the same. This however appeared to be news to the engineer who then asked if there was a way we could ‘get around this’. At this point I decided it was best to walk away from the computer! I know that it isn’t fair to assume everyone has the same exposure or understanding of technologies, one of my favorite sayings is ‘every day is a school day’ – we always have opportunities to learn and develop.
So with all that being said let’s have a quick recap of how a packet traverses networks and what happens (without getting too deep) along the way. Please note that I refer to all datagrams as packets for simplicity, it is correct to say that a layer 2 Ethernet datagram should be referred to as a frame but not all people are familiar with the various terminology for datagrams through the layers.
- PC 1 – 192.168.50.11
- PC 2 – 172.16.50.11
As you can see the above lab is very simple, we have two endpoints connected to a local switch with a router to traverse the broadcast domains. While the production environment discussed above is much more complex this is all we need to demonstrate packet flow and the changing of layer 2 addresses.
Let us create an ICMP packet on PC 1 and send it to PC2, we can observe the way this packet changes as it flows through the network.
Step 1 – Packet Creation
Here we have our initial packet on PC1 – we can see the layer 2 address for this device is 00E0.8F73.1D85 and it has applied a destination layer 2 address of 0001.962E.9A01 which belongs to our gateway.
Step 2 – Packet Received by Switch A
The packet is received by switch A which checks to see if the destination MAC is known, it is therefore we forward the packet out of the relevant port – no address changes are made.
Step 3 – Packet Received by Gateway
In this first screenshot we see the inbound packet received by our gateway from switch A. The destination MAC is 0001.962E.9A01 which belongs to our gateway and the source is PC 1.
The second screenshot shows the outbound packet sent by our gateway to switch B. The source MAC addresses has been modified and is now that of the gateway. The destination MAC address has also been modified to 0001.C756.C73C
Step 4 – Packet Received by Switch B
Here we see the packet received by switch B – the switch looks up the destination MAC, finds a match and forwards the packet.
Step 5 – Packet Received by PC 2
Finally the packet is received by PC 2.
The above steps have been simplified but suffice to say when a layer 2 frame transitions broadcast domains forwarding devices amend the source MAC address to reflect their own unique MAC. Therefore when the PC 2 receives the frame the layer 2 source address is that of the gateway and not PC 1.
There is definitely more going on than I cover in the above but again, this is just meant to be a simple explanation that I can point people to.