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
  • 3,938
  • 15
  • 36
RXS
  • 11
  • 1
  • 1
    I believe it is covered here: https://serverfault.com/a/924165/20701 . This is similar to the behavior in Windows, the timeout is non-deterministic. – Greg Askew May 27 '22 at 17:01
  • Thanks Greg. I noticed that post as well. Let’s agree that by default ARP cache expires between 15 and 45 seconds. ARP cache entry expires if it is not being used. If there are traffic more frequent than 15 seconds using that ip/MAC address, that ARP entry should not expire, shouldn’t it? – RXS May 28 '22 at 18:56
  • Should be easy enough to test. Without NTP. – Greg Askew May 29 '22 at 11:02

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
  • 8,639
  • 2
  • 10
  • 28
  • 1
    Thanks Zac67. I was under wrong impression. I thought ARP entry won’t expire as long as it is frequently accessed. But, should ARP responder also update its own ARP cache on receiving ARP request? For example, host A send ARP request to Host B, will host B also update its the ARP entry for Host A? In the tcpdump above, the 10.68.1.2 sent ARP request to 10.68.1.1, 10.68.1.1 responded, right after, 10.68.1.1 sent ARP request to 10.68.1.2 and 10.68.1.2 responded. Why that is necessary? – RXS May 29 '22 at 01:00
  • An ARP request only updates the ARP table when it is crafted as a *gratuitous ARP* message (TPA=SPA, THA=zero), normal ARP requests don't update ARP. – Zac67 May 29 '22 at 06:03
  • Thanks Zac67. [link](http://manpages.ubuntu.com/manpages/bionic/man7/arp.7.html) ... Positive feedback can be gotten from a higher layer ... **base_reachable_time (since Linux 2.2) Once a neighbor has been found, the entry is considered to be valid for at least a random value between base_reachable_time/2 and 3*base_reachable_time/2. _An entry's validity will be extended if it receives positive feedback from higher level protocols._** It looks like other protocol could extend validity ARP entries. The problem is why Chrony's NTP or NTP as general not doing that? – RXS May 29 '22 at 13:23
  • Positive feedback=received frames from a MAC address doesn't extend an entry's lifetime, it just prevents shortening it. "Once a neighbor has been found" refers to successful ARP resolution. However, host and their implementations are explicitly off-topic here, see the [help/on-topic]. – Zac67 May 29 '22 at 13:53