Lạ: tại sao linux trả lời ping với yêu cầu ARP sau lần trả lời ping cuối cùng?

Tôi (và một đồng nghiệp) vừa nhận thấy và đã kiểm tra rằng khi máy Linux được ping, sau lần ping cuối cùng, nó sẽ thực hiện yêu cầu ARP unicast cho máy đã khởi tạo ping ICMP. Khi ping đến máy Windows, máy Windows không đưa ra yêu cầu ARP ở cuối.

Có ai biết mục đích của yêu cầu ARP unicast này là gì không và tại sao nó lại xảy ra trên Linux mà không phải trên Windows?

Dấu vết của Wireshark (với 10,20.30,45 là một hộp 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

Cập nhật: Tôi vừa mới tìm hiểu thêm về các yêu cầu ARP chưa phát hành và tài liệu tham khảo hữu ích duy nhất tôi tìm thấy là trong RFC 4436 nói về "Phát hiện tệp đính kèm mạng" (từ năm 2006). Kỹ thuật này sử dụng ARP unicast để cho phép máy chủ xác định liệu nó có được kết nối lại với mạng đã biết trước đó hay không. Nhưng tôi không thấy điều này áp dụng cho yêu cầu ARP như thế nào khi thực hiện ping. Vì vậy, bí ẩn vẫn còn ...

Linux gửi các yêu cầu ARP khác nhau để cập nhật bộ đệm ARP của nó. Điều này là để ngăn chặn các mục bộ đệm ARP cũ (và có khả năng độc hại).

Có một vài tình huống sử dụng ARP unicast, về cơ bản để xác nhận bộ đệm ARP. Nếu mục nhập cũ, thì dự phòng sẽ phát ARP.

Điều này được thảo luận trong RFC1122 2.3.2.1

Tôi nghĩ đó là những gì nó đang làm, như tại sao, suy đoán đầu tiên của tôi sẽ là một biện pháp chống giả mạo nào đó. Các gói ARP luôn không bao giờ được định tuyến, vì vậy tôi cho rằng bạn đang thực hiện việc này trên mạng LAN cục bộ của mình? Có phải tình huống này xảy ra liên tục mỗi khi bạn ping máy chủ hoặc bạn chỉ truy tìm một lần? Trong trường hợp đó, bộ đệm ARP cho máy chủ đó có thể đã hết thời gian.

Hệ điều hành nào đang chạy trên máy chủ mà bạn đang ping máy?

Tôi nghĩ đó là một lỗi. Dấu vết sau đây là từ một ping đến một địa chỉ trong bộ đệm ARP nhưng cũ. Tôi không thể nghĩ ra bất kỳ lý do chính đáng nào để unicast ARP hai lần trong một thời gian ngắn như vậy. Đây là với 4.14.15 nhưng tôi đã thấy hành vi trên nhiều phiên bản kernel.

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

Chỉ là một phỏng đoán .. nhưng đây có thể là một 'tính năng' để ghi lại địa chỉ MAC của máy khách bất cứ khi nào máy trả lời một loạt ping hoặc số lần ping nhất định. Nó có thể là thông tin hữu ích để theo dõi thư rác ping.