Join Log in
Score:0
R SONG avatar Server

NTP traffic causes frequent ARP requests

in flag
R SONG

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
44
0 + 0
ntp
arp
cn flag
Greg Askew
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.
1
Reply
R SONG avatar
in flag
R SONG
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?
0
Reply
cn flag
Greg Askew
Should be easy enough to test. Without NTP.
0
Reply
Score:0
Zac67 avatar Server
ru flag
Zac67

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.

0 + 0
R SONG avatar
in flag
R SONG
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?
1
Reply
Zac67 avatar
ru flag
Zac67
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.
0
Reply
R SONG avatar
in flag
R SONG
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?
0
Reply
Zac67 avatar
ru flag
Zac67
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].
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.