Why ARP request failed when the router is configured to be another subnet?

router
f0/0
192.168.1.1
255.255.255.0

host
192.168.11.10
255.255.255.0

I understood this is incorrect, but thought ARP should work. I ran a test in PT. When ping from the host, ARP packet is addressed to FFFFFFFFFFF, requesting the MAC for target IP 192.168.1.1. The ARP request reached the router. The router did not respond. But why? ARP is layer 2. Is it also in charge of verifying the validity of IP address?

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

networker050184

What you are thinking of is proxy arp. If the router has a route to the remote subnet it will respond with it's own MAC. If there is no route the router will not respond with a proxy arp response.

johnifanx98

networker050184 wrote: »

What you are thinking of is proxy arp. If the router has a route to the remote subnet it will respond with it's own MAC. If there is no route the router will not respond with a proxy arp response.

No. I don't think this is anything to do with Proxy ARP. I've just gone through the RFC for ARP.

RFC 826 - Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware

Below is the algorithm how a arp receiver handles the arp req.

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is already in my translation table, update the sender hardware address field of the entry with the new information in the packet and set Merge_flag to true.
?Am I the target protocol address?
Yes:
If Merge_flag is false, add the triplet <protocol type,sender protocol address, sender hardware address> to the translation table.
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on the same hardware on which the request was received.

Somehow the receiver detects the requestor's IP addr is not in the same subnet, then disrupt the whole process.

networker050184

I think you are misinterpreting the RFC. A router does not respond to ARP requests for objects other than itself except in the case of proxy arp. You have already seen this in your testing.

johnifanx98

networker050184 wrote: »

I think you are misinterpreting the RFC. A router does not respond to ARP requests for objects other than itself except in the case of proxy arp. You have already seen this in your testing.

In my test, the router does not even respond to ping to itself. I understood it could be out of misconfiguration of IP address. Just curious how ARP interpret it since ARP is layer 2 protocol and should ignore such layer 3 address mistake.

lantech

Is that host directly connected to the router?

m3zilla

Taken from Cisco:

For each ARP datagram, an ARP reply is discarded if the destination IP address does not match the local host address. An ARP request is discarded if the source IP address is not in the same subnet. It is desirable that this test be overridden by a configuration parameter in order to support the infrequent cases where more than one subnet can co-exist on the same cable.

An ARP reply is generated only if the destination protocol IP address is reachable from the local host, as determined by the routing algorithm, and the next hop is not through the same interface.

If you want the router to reply, put in a static route for the source IP (192.168.11.10/32), with fa0/0 as the exit interface. You can verify this by turning on ARP debugging via debug arp.

Here is the debug before the static route was added

*Mar 1 00:18:25.955: IP ARP req filtered src 192.168.1.1 cc00.18b4.0000, dst 19 2.168.11.1 0000.0000.0000 wrong cable, interface FastEthernet0/0

After the static route was added

*Mar 1 00:24:16.367: IP ARP: rcvd req src 192.168.1.1 cc00.18b4.0000, dst 192.168.11.1 FastEthernet0/0
*Mar 1 00:24:16.371: IP ARP: creating entry for IP address: 192.168.1.1, hw: cc00.18b4.0000
*Mar 1 00:24:16.371: IP ARP: sent rep src 192.168.11.1 cc01.18b4.0000, dst 192.168.1.1 cc00.18b4.0000 FastEthernet0/0

johnifanx98

An ARP request is discarded if the source IP address is not in the same subnet.

Brilliant! I guess this rule is part of the applicance, not part of ARP protocol?!

22karthikreddy

ARP gets the response only when the IP address is found. When you consider a network with only the end-systems and do a resolution you get the reply only if the system with the protocol address is present. Otherwise the ARP is just discarded.

Same works with the router. when router doesn't find a path to the destination address it just discards.

johnifanx98

22karthikreddy wrote: »

ARP gets the response only when the IP address is found. When you consider a network with only the end-systems and do a resolution you get the reply only if the system with the protocol address is present. Otherwise the ARP is just discarded.

Same works with the router. when router doesn't find a path to the destination address it just discards.

In my case the protocol address requested exists, but just the requestor and the responder are misconfigured to be different subnet. Thus, I want to explore how ARP module responds to such a case.