ARP Reply Behavior When Subnet Mismatch Exists Between Devices

[ragulkarthick]

Hi all,

I'm trying to understand how a device (or router) decides whether or not to respond to an ARP request, especially when there's a mismatch in subnet configurations between the sender and receiver.

Consider the following setup:

R1 – Gig 0/0/0 IP: 192.168.1.1/24

R2 – Gig 0/0/0 IP: 192.168.1.130/25

From R1's perspective, 192.168.1.130 is part of its subnet (192.168.1.0/24), so it sends an ARP request to resolve R2's MAC address.

However, from R2's perspective, its subnet is 192.168.1.128/25, and R1's IP 192.168.1.1 does not fall within that range.

My question is:
When R2 receives the ARP request from R1:

Does R2 respond to the ARP request, even though R1 is not in the same subnet as per R2's configuration?

Or does R2 drop the ARP request due to the subnet mismatch?

In general, what checks are performed by the receiving device before it decides to send an ARP reply?

Thanks in advance for the clarification.

[Harold Ritter]

Hi @ragulkarthick ,

R2 considers that the ARP request was received on the wrong interface and drops it.

[ragulkarthick]

Hi @Harold Ritter 

Thank you for pitching in. I have a doubt:

From R1's perspective, it believes that R2 is in the same subnet, so it sends an ARP request.
Are you saying that R2 receives the ARP request on the wrong interface and therefore does not respond?
Could you please clarify?

Also, could you specify what parameters or conditions a device typically checks when deciding whether to respond to an ARP request?
For example, does it validate the interface, subnet, or something else?

Thanks in advance!

[Harold Ritter · Accepted solution]

Hi @ragulkarthick ,

> Could you please clarify?

The sender IP address (R1) and target IP address (R2) are included in the ARP request sent by R1. The receiver (R2) checks the sender IP address and considers that it does not belong to the subnet configured on the interface on which the ARP request was received. The ARP request is simply dropped.

For more information, you can read the ARP RFC:

https://datatracker.ietf.org/doc/html/rfc826

[Jonatan Jonasson · Accepted solution]

From R2 points of view, it doesn't matter if R1 believes R2 to be a part of the subnet.

And since the source IP of the ARP request (192.168.1.1) falls outside of the subnet of R2 interface that received the packet (g0/0/0), R2 deems the arp request to be on the "wrong interface" and drops the packet.

This is an ideal scenario for something like Cisco Modeling Labs (CML) to test out yourself:
R1 does not get an ARP response, and with "debug arp" on R2 you'll see the following message:

*May 23 13:49:40.359: IP ARP req filtered src 192.168.1.1 5254.0067.3fa7, dst 192.168.1.130 0000.0000.0000 wrong cable, interface GigabitEthernet1 tableid 0