Networking Primer – Part 6.1: Data Link Layer, Ethernet and MAC

In previous posts we’ve covered logical addressing and moving IP packets of data across our network from source to destination. We’re now going to take a further shift towards the bits and bytes details of how that logical addressing and routing relates to the more tangible physical media that is used to transmit the data. This is where the Data Link Layer becomes applicable. “The Data Link Layer” is a bit of a mouthful, so this is often dropped and the OSI stack layer number is substituted, Layer 2. From this point forward I will use “Data Link Layer” and “Layer 2” as interchangeable terms which mean exactly the same thing.

The Data Link Layer breaks down into two sub-layers. Firstly, we have the upper sub-layer, called Logical Link Control (LLC) and beneath it we have the Media Access Control Layer. The LLC Layer is responsible for establishing links (connections) between devices in the same local area. It also includes some error checking and handling. The MAC Layer encapsulates a set of protocols and rules for how those devices will gain access to the physical media in order to transmit/receive data.

Historically, there have been a number of competing protocols and topologies used at this layer. In the 80’s and later Ethernet, FDDI and Token Ring approaches were all vying to become the standard for LAN (Local Area Network) traffic, but unquestionably due to its flexibility and reduced cost, Ethernet has won that battle. Most LANs are built on Ethernet today, although more recently with the rise of mobile devices, it has become a shoulder to shoulder partner with the WLAN (Wireless LAN) which provides WiFi access to networks.

Ethernet

Ethernet is predicated on the concept of giving network nodes access to a shared physical media, where all nodes in the network can either send or receive data. In its original incarnation, coax (coaxial cable) was used as Ethernet’s shared physical media combined with a Bus topology. As more and more devices were added to the network, the coax based approach did not scale well and became difficult retain reliable service. The coax approach was superseded by the use non-shared physical media interconnected via network devices which we have yet to introduce such as Hubs, Bridges and Switches. Before we get to the topologies we should look some of the other functions and terminology.

As with our upper layers, when the data is passed down to this layer we add another additional outer wrapper that includes all of the relevant metadata we need to work with Layer 2 functions. We are effectively adding some header information and may also break down our data further if that is required by the underlying devices. In the network layer, we have so far referred to our chunks of data as Packets (IP Packets), at this layer we refer to our chunks of data as Frames (Ethernet Frames). To re-iterate the clear distinction here: Network Layer = Packets, Data Link Layer = Frames. This is useful terminology to get clear.

We’re ready to send our frame out onto the physical media but how will the other nodes know whether or not they’re the intended recipient? Answer, MAC addressing.

MAC Addresses

IP Addresses are a logical constructs that can be allocated, de-allocated, moved and re-used. To physically tie our node to the network, IP addresses are not used. We have a different addressing mechanism at Layer 2, this is the MAC (Media Access Control) Address. The physical component that interacts with the network from our node is the NIC (Network Interface Card). Historically, at the time of manufacture each NIC was allocated a unique MAC Address from a world-wide pool, so it could be differentiated on any network. The MAC Address is a 48-bit address that is most commonly displayed in hexadecimal format (e.g. 28:CF:E9:1F:B4:79). While it is not as humanly readable as an IP address is, it’s still a better representation than the underlying 48 0’s and 1’s that we’d have to remember without it. Do the following to check your local MAC Address:

Go to your Start Menu and search for and run “Windows Powershell”. This may be in a slightly different location depending on your version of windows. At the Powershell prompt: Type “IPCONFIG /ALL” and see the results. You should see something like this:

The MAC address is listed here against, “Physical Address”.

Open up a terminal window and type IFCONFIG. On a Mac you will see a result that looks like this:

I’ve highlighted some of the same information that you could also see on the Windows tab.

When our frame leaves our node via our NIC onto the shared media, the layer 2 wrapper includes both a source and destination MAC Address. This is all good but there’s a problem we have missed here, we know the destination IP address, but where did we get the destination MAC address from? Well there isn’t a DNS style server that stores and provides this. As the nodes are all on the same physical media (sometimes referred to as “broadcast domain”) we can simply ask all the nodes, but we need some protocols to do that. This is where ARP (Address Resolution Protocol) joins the party.

ARP (Address Resolution Protocol)

ARP is simply a mechanism for finding and storing relationships between IP and MAC addresses.

Each node retains a local ARP table/cache which lists relationships between IP and MAC Addresses. When a frame is being sent, the sender cross references the IP address with its local ARP cache. If the IP/MAC combination isn’t listed, an ARP request is broadcast to all nodes on the network to find it. In plain English, the source node is asking “What’s the MAC for this IP address I have?”. All nodes pick this request up, and if they are the intended node, they’ll reply with a “That’s me and here’s my MAC address.” response. The response is cached for future reference.

Side note: There is also a protocol called RARP (Reverse Address Resolution Protocol) which does exactly the opposite. It was used so that nodes could find their own IP address, if they only knew their MAC. This protocol is now obsolete and has since been superseded BOOTP which was in turn superseded by DHCP functionality.

In the same way that we can use IPCONFIG/IFCONFIG to display, alter IP configurations, we can use the ARP command to view, manipulate the ARP cache. Examples here:

Open a Powershell prompt and type “ARP -A”. You should see output similar to this:

Very simple IP to MAC Mappings.

Open up a terminal window and type “ARP-A”. On a Mac you will see a result that looks like this:

The ARP cache is not always up to date, especially where IP address changes might be frequent, so it is worth familiarizing yourself with the ARP switch commands that are used to directly manipulate the cache during troubleshooting. For instance, “ARP -D” can be used to delete entries. There are also mechanisms for flushing the whole table.

Now we have all of our layer 2 addressing sorted, our frame is ready to go.