arp requesting to another subnet, how?

Question

I’m wondering if I have a computer in subnet A with IP address 192.168.123.1, and a computer with IP address 192.168.124.1 in a different subnet.

Both networks are connected with a router. If I want now to send a packet from computer A to computer B, I’ll have to use ARP to get their MAC address to send the frame (supposing ARP cache is empty).

My question is now: What would this ARP request look like, I have two possible methods I can think of:

1. Computer A, sees that the IP address of computer B is outside his own subnet. It decides to send the packet to his default gateway (router) and sends an ARP request with the IP address of the router. Next: the router replies with his mac Address and the frame is send to the router, which will take care of the frame.

2. Computer A, is "stupid" and sends an ARP request with the IP address of B. The router is smart enough and sees that the IP address is in it's routing table. And replies with his own MAC address. Next, computer A sends the frame to the router, thinking it is computer B. The router sends the package to computer B.

The downside I see with the second approach, is that when you surf to google, it will do an ARP request with the IP address of Google. The router will reply with it’s own, since it knows how to get to Google. The next time you surf to another website you will have to do the same thing again and send an ARP request with the IP of that website. This will result in many ARP requests (one for every website). And the ARP cache will get very big.

I really don’t know the answer. I found two YouTube videos—this one and this one—each telling me different things:

I hope somebody can help me.

Answer 1

It's "method A". ARP requests for addresses outside the subnet won't be sent at all. The only ARP request will be for the gateway's IP address.

If you just set up 192.168.123.1/24 for computer A and do not do anything else, it will have a routing table like this:

• 192.168.123.0/24 to device eth0
• 0.0.0.0/0 to gateway 192.168.123.254 device eth0

In such a routing table, the first entry declares that the 192.168.123.0/24 is local – accessible over eth0 without a gateway – so attempting to contact 192.168.123.42 would indeed send an ARP request for 192.168.123.42.

However, the second entry has a gateway defined, so it is assumed to be non-local, and the OS does not bother sending ARP requests for these other IP addresses, because it already knows it cannot reach them. It will therefore directly send an ARP request for the gateway's address and nothing else.

(You can verify this by just looking at the ARP cache; ip neigh or arp -a depending on operating system; or by using a packet capture tool like tcpdump or Wireshark.)

In most operating systems, you can, of course, add routes explicitly telling the OS that certain subnets are local (e.g. ip route add 192.168.124.0/24 dev eth0).

Answer 2

Those are two different methods for IPv4 network configuration, either can be made to work and have advantages and disadvantages.

1. (A) classical networking: client needs to know at least three things: IPv4 address, subnet size, default gateway address. When client A wants to talk to client B, it looks at B's address and based on its knowledge of the subnet size can determine if B is local or remote. If local then it will arp for B's MAC address and then talk; if remote then A will send the data to the gateway and let the gateway handle routing.

   Advantages: client limited size of ARP table, will know if client is local or remote and so can "tune" network time-outs accordingly.

   Disadvantages: client needs more configuration information, if gateway changes then all clients need to be updated, subnet size needs to be a power of two in size (EG 256, 512, 2048, etc).

2. (B) proxy-ARP based routing client only needs to know its own IPv4 address. The subnet size is set to whole world (subnet mask 0.0.0.0) and no gateway is needed. IE client thinks it is directly connected to all other computers in the whole world. When client A wants to talk to client B, it just arps for B's MAC address, it gets a reply and it starts talking.

   There needs to be a gateway on the subnet with a special configuration: proxy-ARP enabled and correct subnet size. When gateway "sees" an arp request it checks to see if the destination (B) client is on the local subnet. If it is the gateway will remain quiet and let B respond, if its remote then the gateway will respond to A with its own MAC address. Thus client A will get a usable MAC address and not worry/know if B is local or remote.

   Advantages: simpler client configuration, ability to have odd sized subnets (EG 768 hosts) thus with better address utilization.

   Disadvantages: potentially huge ARP tables in clients with more churn and a larger percentage of arp request traffic. potentially more difficulty diagnosing trouble. Also does not play well with IPv6 in a dual-stack situation.

At one time we used proxy-arp routing for some of our client subnets but found it to be more trouble than it was worth and now use classical routing for all our subnets.

Answer 3

Both Address Resolution Protocol and Neighbor Discovery Protocol (IPv6) are used only when no other route but an interface route matches. If there is a matching route, be it default or explicit, the specified gateway will be contacted. Resolving the gateway address still uses ARP/NDP, of course.