ARP (Address Resolution Protocol) explained

[molnarattila1221 (Attila Molnár)]

PT.zip (49.6 KB)
Hi Laz,

Apologies for the long post.

Thank you very much for the detailed response.

One thing I don’t understand is that if H1 sees that a packet with the source IP of H2 arrives with the source MAC address of R1, why is it that H1 doesn’t map R1’s MAC address with H2’s IP address? For all H1 knows, what happened was it received a ping from a device that is in its own subnet, so H1 populates its ARP cache with this information.

Please allow me to introduce another related topic:

I’ve experimented with this scenario in Packet Tracer and found something interesting. Not sure if it’s a PT bug or something that works like this in real life (I have no access to real gear yet to experiment with). The interesting thing I found was if the ARP table of at least one host contains the MAC-to-IP mapping of the other host (it doesn’t matter which host this is), then the ping succeeds. It doesn’t matter which host thinks it’s in the same subnet as the other one, and who plays which role (sender or receiver).

Please note that I’ve changed the IP addresses from our earlier example, just for convenience (it was easier for me to change the subnet masks this way as I was experimenting).

Topology, default gateway, and host settings:

Both host’s ARP caches are empty. First ping attempt fails: PC0 thinks it’s in the same subnet as PC1; PC1 thinks it’s in a different subnet than PC0.

Second ping attempt succeeds: both hosts think they’re on the same subnet. The ARP caches of both hosts are now populated.

Third ping attempt succeeds: PC0 thinks it’s in the same subnet as PC1; PC1 thinks it’s in a different subnet than PC0.

Here are all possible scenarios. All pings succeed:

Sender thinks it’s in the same subnet as the receiver; sender’s ARP cache populated, receiver’s not:

Sender thinks it’s in the same subnet as the receiver; sender’s ARP table not populated, receiver’s is populated:

Sender thinks it’s in a different subnet; sender’s ARP cache not populated, receiver’s is populated:

Sender thinks it’s in a different subnet; sender’s ARP cache populated, receiver’s not

I’ve also played around with the tracert command.

To get the behavior where the traffic from PC1 goes through the router, you first

1. start with an empty ARP cache,
2. change the subnet mask of PC1 so that it’s in the /8 subnet (this will clear its arp cache),
3. ping PC1 from PC0,
4. change the subnet mask of PC1 so that it’s in the /24 subnet (other masks probably work as well),
5. ping PC1 from PC0,
6. do a tracert from PC0 to PC1,
7. do a tracert from PC1 to PC0.

How the tracert command doesn’t work:

1. start with an empty ARP cache,
2. change PC1’s subnet to /8,
3. issue a tracert from PC0 to PC1,
4. change PC1’s subnet to /24,
5. issue a tracert from PC1 to PC0.

Sometimes the above steps don’t work, but when I’ve restarted Packet Tracer, they did. So this all might be a PT bug.

I’ve uploaded the Packet Tracer lab for your convenience.

Can you please help me out what’s going on here?
Have a nice week.
Attila

[lagapidis (Lazarus Agapidis)]

Hello Attila

@molnarattila1221

One thing I don’t understand is that if H1 sees that a packet with the source IP of H2 arrives with the source MAC address of R1, why is it that H1 doesn’t map R1’s MAC address with H2’s IP address?

When H1 receives a packet with the source IP of H2 and the source MAC address of R1, it doesn’t map R1’s MAC address with H2’s IP address because it knows that the packet is coming from a different subnet. H1 expects the source MAC address to be the MAC address of the default gateway since the source IP address is in another subnet. That’s the definition of what routers do. So ARP will only populate its ARP table with MACs that correspond to IP addresses within their own subnet.

Now as for your scenario with Packet Tracer, thanks for being so thorough. From your experiments, it seems that the ping succeeds when at least one of the hosts has the correct MAC-to-IP mapping in its ARP cache. This behavior is not expected in real-life situations, and it’s likely a limitation or a bug in Packet Tracer.

In a real-life scenario, if a host has an incorrect subnet mask configured, it would not be able to communicate with hosts in other subnets as it would not send the packet to the default gateway (router) for forwarding. My hunch would be that this is indeed a limitation of Packet Tracer.

I hope this has been helpful!

Laz

[davidilles]

Hello, everyone!

A quick question. If we have 3 hosts on the same segment - PC1, PC2 and PC3 and PC1 sends an ARP request to PC2, it will include its own sender information in the ARP packet (its MAC and its IP).

My question is, why won’t PC3 (who will receive this request as well, since it’s sent as broadcast) use it to create an ARP entry for PC1? I’ve tried this in a lab and was quite suprised that PC3 didn’t do so, despite having the sender’s MAC and IP right in the ARP packet.

Kind regards,
David

[lagapidis (Lazarus Agapidis)]

Hello David

The behavior is a matter of the particular host’s NIC operating mode: Normal or Promiscuous mode.

In normal mode, which is typically the default operating mode, a NIC only processes packets addressed to its own MAC address, as well as broadcast packets and multicast packets for which the NIC is specifically configured to listen. In this mode, when a NIC receives an ARP request that is broadcast, it will open it and take a look at the target IP address (the IP address for which the request wants to learn the corresponding MAC address). If that address is not its own, it will not process the request any further, and it will discard it. Even though the sender MAC and IP are available to it, it will not populate its ARP.

In promiscuous mode, the NIC processes all packets it sees on the network, regardless of the destination MAC address. It effectively “listens” to all the traffic in its network segment. If it receives an ARP request, it will look at the sender’s IP and MAC addresses and use that information to populate its ARP table.

Now what mode is the default, and what mode you are able to configure depends upon the host in question. On a Windows device, promiscuous mode is typically controlled by software applications that may require it. For example, Wireshark can be configured to use promiscuous mode to listen to and process packets arriving on a NIC.

I hope this has been helpful!

Laz

[davidilles]

Hello, everyone.

Please, why does a Cisco device create a static ARP entry for its own IP address? Why is this necessary?

Thank you.

David

[lagapidis (Lazarus Agapidis)]

Hello David

@davidilles

Please, why does a Cisco device create a static ARP entry for its own IP address? Why is this necessary?

First of all, this is not standard ARP behavior. In other words, it’s not something that is defined as part of the protocol. This is a device/vendor-specific behavior.

There are several reasons why Cisco has chosen to implement ARP in this way, and all of them have to do with the role and functionality of the Cisco device, as an intermediary device and not an end host. The reasons include:

• Avoid ARP Broadcasts for Local Communication: Network devices need to communicate with themselves in certain situations (i.e. when implementing dynamic routing protocols, validating routing table updates, and performing self-checks with control traffic). Having a static ARP entry for its own IP address means it doesn’t need to broadcast an ARP request to resolve its own IP address to a MAC address. This reduces unnecessary ARP traffic on the network and ensures quicker local communication.
• Prevent ARP Spoofing and Security Attacks: Static ARP entries can protect against certain types of security attacks, such as ARP spoofing or ARP poisoning. By having a static ARP entry for its own IP address, the Cisco device can avoid being tricked into sending traffic to an attacker’s device.
• Maintain Stability in Critical Network Functions: Some network protocols and features, such as high availability configurations (HSRP, VRRP, GLBP) and certain routing protocols, rely on the device consistently knowing its own MAC and IP address without relying on dynamic ARP resolutions. Static ARP entries ensure that these critical functions operate without interruption.

You wouldn’t see this behavior on end devices such as a Windows PC, because they don’t have mechanisms that use their own IP address, so no ARP requests would be necessary. It is the specific role of network devices that has made Cisco decide to implement their ARP mechanism in this way, for the benefits that I described above.

I hope this has been helpful!

Laz