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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
H1 and H1’ have the same IP address.
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’.
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’.
We are using different Netmask for H1 and H2. H1: 172.16.1.1/24
– 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
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.
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.