Understanding ARP Requests and Link failure

By Farhan Ahmed – Jun 19, 2023

An ARP request is a message sent by a device on a network to find the Media Access Control (MAC) address associated with a specific IP address. It is used in IPv4 networks to map an IP address to its corresponding MAC address. The device broadcasts the request, asking “Who has this IP address?” All devices on the network receive the request, but only the one with the requested IP address responds with an ARP reply, providing its MAC address. This MAC address allows the requester to send data directly to the intended device on the local network, facilitating communication within the network segment.
1.1. ARP REQUESTS AND LINK FAILURE
Delete all ARP tables of H2 and H1. Start pinging H2 from H1. After about 90s, simulate a link failure by disconnecting the cable from the switch. Observe the ARP messages exchanged between H2 and H1 using Wireshark.
pcs
Figure 1.1-1 Computers in the network 172.16.1.0/25
1.1.1. What happens during the first 90s when everything is working?
During the first 90s everything is working normal. There is an ARP request (broadcast) in the start to get the MAC Address of H2. Then echo requests and echo replies are exchanged. After some time there is another ARP request from H2 to H1 (unicast) as a keepalive.
firtst90
Figure 1.1-2 Wireshark – first 90 seconds
1.1.2. What happens if the failure lasts less than 5s? Check the ARP tables of H1 and H2.
A failure is simulated by disconnecting H2. In this case the ping reply stops. The ARP table of H1 remains the same and H2 deletes the ARP entry of H1. (In the end when we connect H2 again in the network, it sends a broadcast ARP to know who H1 is in order to continue the ping reply)
linkfailure5sec
Figure 1.1.3. Link failure less than 5 seconds
1.1.3. What happens if failure lasts more than 30s? Check ARP tables of H1 and H2.
Once again a failure is simulated by disconnecting H2 from the switch; but in this case, H1 detects that there is no H2 and sends unicast ARP requests to H2 three times. After this, the MAC Address of H2 is deleted from H1’s ARP table and H1 sends broadcast ARP request to get the MAC address against H2’s IP. At last after connecting H2 back it sends reply to H1, but H2’s ARP table doesn’t change.
90s
Figure.1.1.4. H1 Wireshark and ARP table for Link failure more than 30 seconds
1.1.4. What happens as soon as the link is re-established at the physical layer?
Check the RTT measurements of ICMP messages after the link goes up again. When the link is re-established the H2 starts to reply to H1’s ARP request (broadcast) and resumes normal communication.
1.1.5
Figure 1.1.5. RTT measurement of ICMP packets after link re-establishment
One thing can be noticed here that after re-establishing the link the starting two ICMP packets have large RTT (>1ms). The reason is that there are packets at H1 layer 3 (buffer), waiting for the ARP reply. As soon as the ARP request is fulfilled, they are sent to lower layers and the RTT goes to normal for the other packets.
1.2. CONNECTIVITY CHECK – ADVANCED PING
1.2.1. What happens when host pings the broadcast address?
The broadcast address is 172.16.1.127 in this case. When this address is pinged, a notification is given by the Linux terminal to use the –b option in case of broadcast. After using this option, it starts pinging. As it is a broadcast so it will be received by all the hosts and all will reply including the source.
Figure 1.2-1 Pinging Broadcast Address
Figure 1.2-1 Pinging Broadcast Address
In the Wireshark capture it can be seen that there are only two replies (these are the replies from H2 and H3), from which it can be inferred that the host reply is not captured by the wireshark. The DUP!s (duplicate) are the replies which are received later from H2 and H3; these are considered duplicates because the ICMP sequence number in those packets is already received from the echo reply that H1 sent back to itself. The RTT of the first reply is small because the echo is replied by the loopback interface of the source host itself and the NIC/physical media is not used.
1.2.2. What happens when the host pings the network address?
To ping network address again –b option is required like in broadcast case. The behaviour is also the same as in the previous case. At the end there are ARP requests from H2 and H3 to H1, which are unicast just for some confirmation.
Figure 1.2-2 Pinging Network Address
Figure 1.2-2 Pinging Network Address
1.2.3. Duplicate Address: Configure the LAN so that there are two hosts with the same IP Address i.e. H1, H1’ and H2.
H1 and H1’ have the same IP address.
Figure 1.2-3 Duplicating Address
Figure 1.2-3 Duplicating Address
1.2.3.1. What happens when H2 pings H1? Check ARP tables.

It can be seen in the wireshark capture that when H2 pings H1, it sends an ARP request (broadcast) to get H1’s MAC address. Instead of H1, H1’ replies to the request and H2 communicates with H1’ instead of H1. After a very short time, H1 also reply to the request, but H2 keeps on communicating with H1’. After a few seconds H1’ sends a unicast ARP request to H2 to verify the MAC address.

Figure 1.2-4 Wireshark capture of H2 (H2 pings H1)
Figure 1.2-4 Wireshark capture of H2 (H2 pings H1)

H2 is only communicating with H1’ so it only has the MAC Address of H1’. The ARP table of H1 and H1’ both have the MAC Address and IP of H2.

Figure 1.2-5 ARP Table of H1 (H2 pings H1)
Figure 1.2-5 ARP Table of H1 (H2 pings H1)
Figure 1.2-6 ARP Table of H1’ (H2 pings H1)
Figure 1.2-6 ARP Table of H1’ (H2 pings H1)
Figure 1.2-7 ARP Table of H2 (H2 pings H1)
Figure 1.2-7 ARP Table of H2 (H2 pings H1)
1.2.3.2. What happens when H1 and H1’ start pinging H2 at the same time? Check the ARP tables.
What happens when H1 and H1’ start pinging H2 at the same time? Check the ARP tables. When we ping H2 from H1 and H1’ at the same time, H2 will reply to request which it receives first due to a small time delay between the pings originated from H1 and H1’. In our case it first starts replying to H1’ because it receives first the ARP request of H1’. But after some time H2 receives the broadcast ARP request from H1 as well and starts communicating with H1 and stops with H1’. After a few seconds H1’ sends unicast ARP request to H2, and H2 saves the MAC address of H1’ against the IP 172.16.1.1 and starts replying to the requests of H1’. Thus the ping reply keeps bouncing between H1 and H1’ as soon as H2 gets a new unicast ARP request from either H1 or H1’.
Figure 1.2-8 Wireshark Capture of H2 – H1 and H1’ pinging simultaneously
Figure 1.2-8 Wireshark Capture of H2 – H1 and H1’ pinging simultaneously
The ARP tables of both H1 and H1’ has the MAC address of H2; but in H2’s table, the MAC address changes from H1’ to H1; and after some time back to H1’ since it receives successive unicast ARP requests from both H1 and H1’.
Figure 1.2-9 Changing in ARP Table of H2 – H1 and H1’ pinging simultaneously
Figure 1.2-9 Changing in ARP Table of H2 – H1 and H1’ pinging simultaneously

Comparison between 1.2.3.1 and 1.2.3.2

In the former question, when H2 pings H1, H1’ replies to the ARP request first. Although H1 also sends back an ARP reply, yet H2 does not update its ARP table. While in the latter question, H2 updates its ARP table since it receives an ARP request and not an ARP reply, thus proving that ARP table is updated if there is an ARP request. This is the difference that shows why H2 only communicates with H1’ in the former question and not with both, while in the latter case, it communicates with both.

1.2.4. Wrong Netmask: Configure the LAN so that H1 sees H2 as belonging to his subnet, but H2 sees H1 as not belonging to his subnet. (Use different netmask for H1 and H2).
We are using different Netmask for H1 and H2. H1: 172.16.1.1/24 H2: 172.16.1.200/25
1.2.4.1. What happens when H1 pings H2? Which packets is H1 sending? Which packets is H2 sending? How do ARP tables of H1 and H2 change?

How do ARP tables of H1 and H2 change?
H1 keeps sending broadcast ARP and H2 doesn’t reply. ARP table of H2 is empty and H1 is incomplete. This means, H2 knows that H1 is not a part of the subnet and this is a sort of an unexpected ARP.

Figure 1.2-10 Wrong Netmask – H1 ARP Table, H1 pings H2
Figure 1.2-11 Wrong Netmask – H1 pings H2
Figure 1.2-12 Wrong Netmask – Wirehsark Capture
1.2.4.2. What happens when H2 pings H1? Which packets is H1 sending? Which packets is H2 sending? How do ARP tables of H1 and H2 change?

How do ARP tables of H1 and H2 change?
Nothing happens as route is unreachable, H1 is not part of H2’s subnet and the route 172.16.1.0/24 is not in the routing table of H2. No packet is generated. ARP table is not updated.

Figure 1.2-13 Wrong Netmask – H2 pings H1
Figure 1.2-13 Wrong Netmask – H2 pings H1
1.2.5. Wrong netmask and conflict with broadcast address: Configure the LAN so that:
– H1 has address 172.16.0.127 and netmask 255.255.255.0 – H2 has address 172.16.0.1 and netmask 255.255.255.128
1.2.5.1. What happens when H1 pings H2? Which packets is H1 sending? Which packets is H2 sending? How do ARP tables of H1 and H2 change?
H1 keeps on sending ARP requests on broadcast, H2 does not respond to H1 ARP request. No ARP tables updated. That means, H2 knows that ARP is coming from a broadcast IP. Maybe H2 considers this request as bogus.
Figure 1.2-14 Broadcast Address Conflict – H1 pings H2
Figure 1.2-15 Wireshark Capture - Broadcast Address Conflict – H1 pings H2
1.2.5.2. What happens when H2 pings H1? Which packets is H1 sending? Which packets is H2 sending? How do ARP tables of H1 and H2 change?
H2 keeps on sending ICMP echo requests to the IP 172.16.0.127 on broadcast MAC address. H1 receives this packet, but cannot reply. Why? Because H1 needs to know the MAC address of H2, so H1 sends an ARP request (broadcast) to get H2’s IP, but H2 still does not reply like in the previous part, it considers this IP as a bogus. But H2 also receives ping replies from his own loopback adapter. H2 ARP table is empty and H1 ARP table is incomplete.
Figure 1.2-16 Broadcast Address Conflict - H1 ARP table – H2 pings H1
Figure 1.2-16 Broadcast Address Conflict - H1 ARP table – H2 pings H1
Figure 1.2-17 Broadcast Address Conflict - H2 Arp table – H2 pings H1
Figure 1.2-17 Broadcast Address Conflict - H2 Arp table – H2 pings H1
Figure 1.2-18 Wireshark Capture on H2 - Broadcast Address Conflict
Figure 1.2-18 Wireshark Capture on H2 - Broadcast Address Conflict