Introduction
In this lab, you will explore the fundamental interaction between the network layer (Layer 3) and the data link layer (Layer 2) in a Linux environment. You will use the common ping and arp command-line utilities to observe the Address Resolution Protocol (ARP) in action. The primary goal is to understand how your system resolves IP addresses to physical MAC addresses for devices on the local network and how it handles communication with remote hosts.
You will begin by inspecting the state of the ARP cache. Then, you will use ping to communicate with a local device (your default gateway) and a remote device (google.com). By observing the ARP cache before and after these actions, you will see how your system uses MAC addresses for local communication and relies on the default gateway for remote traffic.
View the Initial ARP Cache with arp -a
In this step, you will inspect the initial state of your system's Address Resolution Protocol (ARP) cache. The ARP cache is a crucial networking component that stores the mappings between Layer 3 (IP) addresses and their corresponding Layer 2 (MAC) addresses for devices on the same local network.
First, let's check the current state of the ARP cache using the arp command. The -a flag tells the command to display all current entries.
In your terminal, which is already at the ~/project path, execute the following command:
arp -a
You will likely see one or more entries. It is common for the default gateway to already be present in the cache. Your output may look similar to this:
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
It is important to note that due to the virtualized nature of the LabEx environment, it's not always possible to completely clear the ARP cache. Therefore, you will likely see a pre-populated cache from the start. In a typical non-virtualized setup, you would more likely see an empty or
<incomplete>entry for the gateway before the first communication.
This output shows the initial state of our ARP cache. It serves as a baseline for our next steps, where we will trigger network activity and observe how this table is used.
Ping a Local Device to Trigger an ARP Request
In this step, you will use the ping command to initiate communication with another device on your local network. This action will use the Address Resolution Protocol (ARP) mapping if one is required. When your system tries to send a packet to a local IP address, it first checks its ARP cache. If it doesn't find a corresponding MAC address, it sends out a broadcast ARP request. If the entry already exists, it will use the cached MAC address.
To perform this, we first need to identify the IP address of a device on the local network. The most reliable target in this environment is your default gateway (the virtual router). You can find its IP address by inspecting the routing table.
In your terminal, run the following command to display the routing table:
ip route show
The output will show you the default route. Look for the line that starts with default via. The IP address listed there is your gateway.
default via 172.16.50.253 dev eth0 ...
...
From the example output above, the gateway's IP address is 172.16.50.253. Now, use this IP address to send a few ping packets. The -c 4 option tells ping to send exactly 4 packets and then stop. Replace 172.16.50.253 with the actual gateway IP you found.
ping -c 4 172.16.50.253
You should see a successful reply for each packet, confirming that your system was able to communicate with the gateway.
PING 172.16.50.253 (172.16.50.253) 56(84) bytes of data.
64 bytes from 172.16.50.253: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 172.16.50.253: icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from 172.16.50.253: icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from 172.16.50.253: icmp_seq=4 ttl=64 time=0.045 ms
--- 172.16.50.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3060ms
rtt min/avg/max/mdev = 0.045/0.056/0.066/0.007 ms
This simple action has forced your system to perform an ARP lookup. In the next step, we will inspect the ARP cache again to see the result.
Verify Local IP-to-MAC Resolution in the ARP Cache
In this step, you will re-examine the ARP cache to see the direct result of the ping command you executed previously. Since your system successfully communicated with the local gateway, it must have had a valid IP-to-MAC address mapping. Let's see if the table has changed.
Let's inspect the ARP cache again. In your terminal, run the same command as in the first step:
arp -a
This time, the output will be different only if the entry wasn't already complete. In our case, since the entry was already resolved in Step 1, the output will be identical.
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Compare this output to the one from Step 1. It's identical. This is because the ARP entry for the gateway was already complete before we sent the ping. Your system didn't need to perform a new ARP request; it simply relied on the information already in the cache.
This demonstrates a key principle: the ARP cache prevents redundant ARP requests. If the entry had been <incomplete> or missing, this ping command would have populated it, and you would have seen a change in the output.
Ping an External Host to Involve the Default Gateway
In this step, you will shift from communicating with a local device to communicating with a host on the internet. This demonstrates a fundamental networking concept: how your computer uses its default gateway to reach destinations outside of its own local network.
When the destination IP address is not on the same subnet as your computer, your system knows it cannot send the packet directly. Instead, it must send the packet to its designated default gateway. The gateway (a router) is responsible for forwarding the packet toward its final destination across the internet.
To see this in action, you will ping a well-known external host, google.com.
In your terminal, execute the following command:
ping -c 4 google.com
You will see the domain google.com get resolved to an IP address, and then you will receive replies from that address.
PING google.com (142.250.189.174) 56(84) bytes of data.
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=1 ttl=118 time=4.38 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=2 ttl=118 time=4.40 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=3 ttl=118 time=4.35 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=4 ttl=118 time=4.39 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.353/4.380/4.401/0.017 ms
Even though you successfully communicated with google.com, your computer did not perform an ARP request for Google's IP address. It only needed the MAC address of its local gateway, which it already found in the previous steps. In the next step, you will analyze the ARP cache to confirm this behavior.
Analyze the ARP Cache for Remote Communication
In this final step, you will analyze the ARP cache one last time to confirm how your system handles communication with remote hosts. This will solidify the distinction between local and remote network communication and highlight the role of the default gateway.
Now that you've successfully pinged google.com, let's check the ARP cache again. In your terminal, run the arp -a command:
arp -a
Carefully examine the output. It should look identical to the cache state from the previous steps.
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
You will notice that there is no entry for google.com or its IP address (e.g., 142.250.189.174). The only significant entry present is still the one for your default gateway.
This is the key takeaway of this lab. ARP operates at Layer 2 and is only used to find MAC addresses on the local network segment. When your computer sends a packet to a remote destination, it knows the destination is not local, so it sends the packet to the MAC address of the next hop—your default gateway. The router then takes responsibility for forwarding the IP packet toward its final destination. Your computer doesn't need to know the MAC address of google.com; it only needs to know the MAC address of the device that can forward the packet for it.
Summary
In this lab, you explored the fundamental interaction between Layer 3 (IP) and Layer 2 (MAC) networking by using the ping and arp commands in Linux. You began by inspecting the state of the Address Resolution Protocol (ARP) cache with arp -a, observing that it may already contain entries for critical devices like the default gateway. By pinging the local gateway, you confirmed that the system uses this cached information for local communication, avoiding redundant address lookups.
Furthermore, you investigated how communication with a remote host differs. When you pinged an external IP address, you observed that the system does not perform an ARP request for the final destination. Instead, it sends the packet to the default gateway to be routed outside the local network. The final analysis of the ARP cache reinforced this concept, showing that no entry was added for the remote host. The only relevant entry remained that of the default gateway, highlighting its crucial role as the intermediary for all traffic destined for external networks.
