Странно: почему linux отвечает на ping с помощью запроса ARP после последнего ответа ping?

Я (и коллега) только что заметил и протестировал, что когда машина Linux пингуется, после последнего пинга она инициирует одноадресный ARP-запрос к машине, которая инициировала пинг ICMP. При пинге с машиной Windows машина Windows не выдает запрос ARP в конце.

Кто-нибудь знает, какова цель этого одноадресного ARP-запроса и почему он происходит в Linux, а не в Windows?

Трассировка Wireshark (с 10.20.30.45 - это окно Linux):

No.Time        Source           Destination      Prot  Info
19 10.905277   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
20 10.905339   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
21 11.904141   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
22 11.904173   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
23 12.904104   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
24 12.904137   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
25 13.904078   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
26 13.904111   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
27 15.901799   D-Link_c5:e7:ea  D-Link_33:cb:92  ARP   Who has 10.20.30.14?  Tell 10.20.30.45
28 15.901855   D-Link_33:cb:92  D-Link_c5:e7:ea  ARP   10.20.30.14 is at 00:05:5d:33:cb:92

Обновление: я только что прибегнул к поиску однонаправленных ARP-запросов , и единственная полезная ссылка, которую я нашел, - это RFC 4436, посвященный «Обнаружению сетевого подключения» (с 2006 года). Этот метод использует одноадресные ARP, чтобы хост мог определить, подключен ли он к ранее известной сети. Но я не вижу, как это относится к запросу ARP в результате выполнения пинга. Так что загадка остается ...

Linux отправляет различные одноадресные ARP-запросы для обновления своего ARP-кэша. Это сделано для предотвращения устаревших (и потенциально вредоносных) записей кэша ARP.

Есть несколько ситуаций, когда используется одноадресный ARP, в основном для проверки ARP-кэша. Если запись устарела, то резервным вариантом является трансляция ARP.

Это обсуждается в RFC1122 2.3.2.1

Я думаю, что это то, что он делает, поэтому, по-моему, мое первое предположение было бы своего рода антиспуфинговой мерой. Пакеты ARP всегда никогда не маршрутизируются, поэтому я предполагаю, что вы делаете это в локальной сети? Происходит ли эта ситуация постоянно каждый раз, когда вы пингуете хост, или вы только что проследили один раз? В этом случае кэш ARP для этого хоста мог быть по тайм-ауту по совпадению.

Какая ОС работает на хосте, с которого вы пингуете компьютер?

Я думаю, что это ошибка. Следующая трассировка от пинга до адреса, который находится в кэше ARP, но устарел. Я не могу придумать вескую причину для одноадресной передачи ARP дважды за такое короткое время. Это с 4.14.15, но я видел поведение во многих версиях ядра.

root@observer:~# tcpdump -nevi eth0 arp
device eth0 entered promiscuous mode
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

13:11:57.362910 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.1 tell 10.1.2.2, length 28
13:11:57.363018 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.1 is-at 42:5f:03:40:00:22, length 28
13:11:57.392890 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.2 tell 10.1.2.1, length 28
13:11:57.393049 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.2 is-at 42:5f:03:40:00:43, length 28

Просто предположение ... но это может быть "функция" для регистрации MAC-адреса клиента всякий раз, когда машина отвечает на последовательность пингов или на определенное количество пингов. Это может быть полезной информацией для отслеживания пинг спама.