How a router handles an ARP request.

[speculor_cisco]

If I am right, a router responds to an ARP request when 2 conditions are met:

1. The IP source address must belong to the major network of the incoming interface.

2. The IP target address must be present in the routing information database and then:

2a. If the IP target address is the IP address of the incoming interface we have ARP.

2b. If the IP target address is different from the IP address of the incoming interface but it is reachable through an interface different fron the incoming interface we have PROXY ARP.

2c. If the IP target address is different from the IP address of the incoming interface but is reachable through the incoming interface itself we have not an ARP response.

With the GNS simulator I have noted that the first condition can be less strong: if the router has a route to the IP source address out the incoming interface we can have a response. Infact, this route appears as connected in the routing information databese. I wondered if the condition can be extended to a IP source address reachable through the incoming interface but that the router does not see as connected. But I can not imagine a scenario where a router receives an ARP request where the IP source address is, for example, 1 hop away. To do this test, I should build a particular ARP request with a packet generator and send it to a router interface. Have you got any trick? Does someone already know the result of this test.

Thanks.

[lgijssel]

Please consider that ARP is a layer2 protocol used to enable the mappings between mac addresses and ip addresses.

ARP requests are not supposed to cross a layer3 boundary. They only have significance within a vlan.

The scenario you describe is never supposed to occur in a normal network.

When taking this in account, your scenario is pretty much rendered invalid. 

regards,

Leo

[speculor_cisco]

Hello Leo and thanks for your answer.

As I had always seen that the rule was that the IP source address should belong to the major network of the incoming interface, as this rule is not so true because it is also possible that the IP source address can belong to a different major network if the router sees it as "connected" because it has a static route that points to it out the incoming interface, now I wondered if it was possible to go even ahead.

I understand the logic you are talking about, but are you sure that if we sent an ARP request with a general IP source address that the router could reach through the incoming interface, this request would be discarded? After all the router expects to receive packets from that IP address and through that incoming interface, why not respond to an ARP request even if the IP source address in not seen as "connected". The router could say: ok, that IP source address in not "connected" but I expects to receive communications from him and through this incoming interface, this is not strange, and as it wants my "help" to resolve an ARP request, I decide to offer it my help.

Clearly it depends from the software that implements ARP inside the router, but in order to be sure, or I do a lab test or someone can explain me that, as this type of software could give problems, it is not possible that CIsco has implemented it.

I know that it is a type of may be useless discussion, but I am not so sure in a scenario with security envolved.

What do you think about?

[lgijssel]

Your example is what would occur when the client is 1 hop away from the router.

Let's suppose the router has no ARP entry for the client-ip but it has a static route pointing to the next hop.

This scenario would be possible when the ARP on the router has aged out or has been cleared.

However, in this case it is not the client which sends an ARP directly but rather this would be done by the intermediate router.

In fact the ARP process is repeated twice. First for the client to resolve the upstream router.

Then, this router again uses ARP to resolve the mac address of the next-hop router.

So it will never occur that the clients ARP's a router outside of the local vlan. This stays the same when using either 'normal' arp or proxy arp.

regards,

Leo

[speculor_cisco]

Hello Leo and thanks for your answer.

I understand what you are saying but I am not concerned about a normal behavior of a network.

I would like to attach to a router interface a packet generator that sends an ARP request whose IP source address is an IP address that the

router can reach through the incoming interface, that is not seen as connected but that is seen, it does not matter, 1 or 2 or n hops away.

This would be clearly possible. May be this is an odd test. May be I am crazy too. May be that the ARP debug would simply say "WRONG CABLE".

But if I do not the test, how can I see this?

I have already done a test where the ARP debug says "WRONG CABLE", but the router did not have a route that pointed to the IP source address through the incoming interface.

If "WRONG CABLE" means that the IP source address does not belong to the major network, then the router should not have respond only because it has a route to the IP source address through the incoming interface, IP source address that does not belong to the major network but that the router sees as "connected" because the only way to put the route in the route table is with the interface itself.

It is likely that the rule is: if the router sees the IP source address as "connected", and why it sees it as "connected" does not matter, then it will respond.

Otherwise it will not responds. But how can I be sure?

[lgijssel]

I think I have found a document describing your test setup:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800ef7b2.shtml#topic1

The text says:

If you point a static route to a broadcast interface, the route is inserted into the routing table only when the broadcast interface is up. This configuration is not recommended because when the next hop of a static route points to an interface, the router considers each of the hosts within the range of the route to be directly connected through that interface. For example, ip route 0.0.0.0 0.0.0.0 Ethernet0.

With this type of configuration, a router performs Address Resolution Protocol (ARP) on the Ethernet for every destination the router finds through the (default) route because the router considers all of these destinations as directly connected to Ethernet 0.

This kind of default route, especially if it is used by a lot of packets to many different destination subnets, can cause high processor utilization and a very large ARP cache (along with attendant memory allocation failures).

regards,

Leo

[speculor_cisco]

Hello Leo and thanks for your answer. While you was writing your last response, that I have just read but I have to analyze yet, I have succeeded with a scenario and make a test with the GNS simulator.

I have been able to send an ARP request to interface Fa0/0 of a router with these parameters:

IP source address: 172.16.0.1

IP target address : 172.16.1.1

Whit this first router's configuration:

interface FastEthernet0/0
ip address 192.168.0.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
!

ip route 172.16.1.1 255.255.255.255 192.168.1.2

the ARP debug showed WRONG CABLE.

But with this second router's configuration:

interface FastEthernet0/0
ip address 192.168.0.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
!
ip route 172.16.0.1 255.255.255.255 192.168.0.2
ip route 172.16.1.1 255.255.255.255 192.168.1.2

the ARP debug did not show WRONG CABLE and did show PROXY ARP. And in this case the IP source address was not seen as "connected".

So, unless future surprises and at least in this simple and clean example, but may be the best as initial starting point, we could state this rule:

Not true that the ARP request must have an IP source address that belongs to the major network of the incoming interface (strong condition).

Not true that the ARP request must have an IP source address that the router consider "connected" to the incoming interface, and the way the router consider it "connected" does not matter (strong-weak condition).

True that the ARP request must have an IP source address that the router can reach through the incoming interface (weak condition).

I do not think that it is all, by the way thanks for your precious information, but happy to not be crazy .

[lgijssel]

It's never crazy to want to completely understand a problem.

My example was pointing to the possibility to use an interface as the next hop instead of an ip.

This alters the behavior and perhaps you should try it in your lab:

ip route 172.16.1.1 255.255.255.255 fa0/1

This will enable ARP for 172.16.1.1.

regards,

Leo