who determines whether should ping send a ARP request?

Question

In my Fedora linux, My eno1's ip is 192.168.1.105 and my gateway's ip is 192.168.1.1, and netmask netmask 255.255.255.0

For monitoring ARP request, in one terminal, I used sudo tcpdump -i eno1 -v "icmp or arp", in another terminal, I run the ping 192.168.1.5(not exist) or ping 192.168.91.1:

When I ping 192.168.1.5, which is not existed in my LAN, in the tcpdump terminal, I got the ARP request:

 [abelard@localhost iputils]$ sudo tcpdump -i eno1 -v "icmp or arp"
 [sudo] password for abelard: 
 tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
 06:39:13.111379 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has     192.168.1.5 tell localhost.localdomain, length 28

When I ping 192.168.91.5, which is still not existed in my LAN, in the tcpdump terminal, I did not get the ARP request:

 [abelard@localhost iputils]$ sudo tcpdump -i eno1 -v "icmp or arp"
 tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
 06:50:02.417926 IP (tos 0x0, ttl 64, id 32986, offset 0, flags [DF], proto ICMP (1), length 84)
localhost.localdomain > 192.168.91.1: ICMP echo request, id 6682, seq 1, length 64
 06:50:03.417060 IP (tos 0x0, ttl 64, id 33783, offset 0, flags [DF], proto ICMP (1), length 84)
localhost.localdomain > 192.168.91.1: ICMP echo request, id 6682, seq 2, length 64

I want to know who determines to send ARP request or not to send ARP request? The some googled results said this is done by linux kernel, if yes, I want to know where in linux kernel?

Answer 1

A host that needs to send something to another host on the LAN needs to resolve the layer-3 (e.g. IP) address to the layer-2 (e.g. ethernet) address. That is what ARP (Address Resolution Protocol) does.

A host will maintain an ARP table in which it can look up a layer-3 address to resolve to the corresponding layer-2 address. If the layer-3 address is not in the ARP table, then the host broadcasts an ARP request to get the necessary information.

Answer 2

What happens is

1. Ping builds a ping packet and passes it to the kernel.
2. The kernel looks up the destination in the routing table. Based on the routing table it determines an interface and a "next hop IP address".
3. If the interface is "Ethernet like" the kernel looks up the next hop IP address in the ARP table for the interface.
4. If there is an entry in the ARP table the kernel attaches the MAC addresses to the packet and sends it. Otherwise it puts it in a queue and sends out an ARP request.

You do not say what your subnet mask is but I will assume it is 255.255.255.0

ping 192.168.1.5

1. Ping generates a packet destined for 192.168.1.5
2. The kernel looks up the destination in the routing table. The packet matches the implicit route created by setting the subnet mask. This tells it that the destination is "on link" on eth0. Since the destination is on-link the next hop IP address is the same as the destination address.
3. The kernel looks up the next hop in the arp table for eth0. It finds no entry.
4. The kernel sends out an arp request.

ping 192.168.91.5

1. Ping generates a packet destined for 192.168.91.5
2. The kernel looks up the destination in the routing table. The packet matches the default route (aka the default gateway). The next hop IP address is 192.168.1.1
3. The kernel looks up 192.168.1.1 in the arp table and most likely finds a match (you tend to talk to your default gateway quite a lot).
4. The ping gets sent.

Sorry I don't know the exact layout of the code in the linux kernel to tell you where the code implementing this is.

Answer 3

Peter Green's answer is correct and comprehensive.

I want to point out why there is no ARP request when you ping 192.168.91.1.

High-Level

Because the subnet mask is 255.255.255.0 and your IP is 192.168.1.105, the protocol stack recognizes that 192.168.91.1 is not in the same subnet as yourself. Thus it determines that the next-hop IP is the first-hop router IP 192.168.1.1. Then it resolves the MAC address of 192.168.1.1, which most likely has been in the ARP table, since you frequently send packets to the first-hop router.

Concretely

The kernel looks up the destination 192.168.91.1 in the routing table(netstat -r or route). Which should look like:

Destination	Gateway	Genmask	Iface
default	192.168.1.1	0.0.0.0	eno1
192.168.1.0	*	255.255.255.0	eno1

Note:

• * might be 0.0.0.0 for some versions of netstat.
• default and * will be 0.0.0.0 for netstat -rn or route -n.
• Windows netstat -r or route PRINT will show On-link instead of *.

netstat and route is deprecated, ip route will show routing table in another format looks like:

default via 192.168.1.1 dev eno1

192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.105

The kernel finds that 192.168.91.1 doesn't match 192.168.1.0/24 or 192.168.1.0 Genmask 255.255.255.0, so it uses default entry and resolves the next-hop IP to 192.168.1.1.