1

I am running Ubuntu LTS 22.04 using Chrony as NTP server. I discovered that even with frequent NTP traffic between a NTP client and the NTP Server, the ARP requests are still being sent back and forth very frequently. By default, ARP cache expires 60 seconds.

Is it a bug?

09:32:28.116858 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:32:28.117032 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:32:30.117770 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:32:30.117936 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:32:33.116704 ARP, Request who-has 10.68.1.1 tell 10.68.1.2, length 46
09:32:33.116750 ARP, Reply 10.68.1.1 is-at 20:7c:14:a0:b9:a1, length 28
09:32:33.190181 ARP, Request who-has 10.68.1.2 tell 10.68.1.1, length 28
09:32:33.190327 ARP, Reply 10.68.1.2 is-at 00:90:e8:9d:aa:dc, length 46
09:32:46.117215 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:32:46.117470 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:32:48.117032 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:32:48.117277 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:33:04.116931 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:33:04.117104 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:33:06.116888 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:33:06.117144 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:33:09.286195 ARP, Request who-has 10.68.1.2 tell 10.68.1.1, length 28
09:33:09.286332 ARP, Reply 10.68.1.2 is-at 00:90:e8:9d:aa:dc, length 46
09:33:22.116699 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:33:22.116833 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:33:24.116869 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:33:24.117034 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:33:27.116688 ARP, Request who-has 10.68.1.1 tell 10.68.1.2, length 46
09:33:27.116751 ARP, Reply 10.68.1.1 is-at 20:7c:14:a0:b9:a1, length 28
09:33:40.116842 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:33:40.117011 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:33:42.116923 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:33:42.117089 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:33:45.126169 ARP, Request who-has 10.68.1.2 tell 10.68.1.1, length 28
09:33:45.126332 ARP, Reply 10.68.1.2 is-at 00:90:e8:9d:aa:dc, length 46
09:33:58.116928 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:33:58.117095 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:34:00.116873 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:34:00.117039 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:34:16.116895 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:34:16.117154 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:34:18.116863 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:34:18.117029 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:34:21.116733 ARP, Request who-has 10.68.1.1 tell 10.68.1.2, length 46
09:34:21.116768 ARP, Reply 10.68.1.1 is-at 20:7c:14:a0:b9:a1, length 28
09:34:21.222128 ARP, Request who-has 10.68.1.2 tell 10.68.1.1, length 28
09:34:21.222294 ARP, Reply 10.68.1.2 is-at 00:90:e8:9d:aa:dc, length 46
09:34:34.116899 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:34:34.117069 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:34:36.127025 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:34:36.127269 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:34:52.116889 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:34:52.117145 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:34:54.116943 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:34:54.117187 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:34:57.318148 ARP, Request who-has 10.68.1.2 tell 10.68.1.1, length 28
09:34:57.318299 ARP, Reply 10.68.1.2 is-at 00:90:e8:9d:aa:dc, length 46
09:35:10.116983 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:35:10.117159 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:35:12.116865 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, length 48
09:35:12.117031 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, length 48
09:35:15.116750 ARP, Request who-has 10.68.1.1 tell 10.68.1.2, length 46
09:35:15.116810 ARP, Reply 10.68.1.1 is-at 20:7c:14:a0:b9:a1, length 28
Paul Gear
  • 4,686
RXS
  • 11

1 Answers1

1

That is perfectly normal and not a bug.

ARP table entries are only ever refreshed or updated by ARP packets (ARP replies or ARP requests crafted as gratuitous ARP messages), not by IP packets. Consequently, entries time out even when they are in frequent use and need to be updated by ARP requests/replies.

Zac67
  • 13,684