Puncte:0

Traficul NTP provoacă solicitări ARP frecvente

drapel in

Rulez Ubuntu LTS 22.04 folosind Chrony ca server NTP. Am descoperit că, chiar și cu trafic NTP frecvent între un client NTP și serverul NTP, solicitările ARP sunt încă trimise înainte și înapoi foarte frecvent. În mod implicit, memoria cache ARP expiră 60 de secunde.

Este un bug?

09:32:28.116858 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:32:28.117032 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:32:30.117770 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:32:30.117936 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:32:33.116704 ARP, Solicitați cine-are 10.68.1.1 spuneți 10.68.1.2, lungime 46
09:32:33.116750 ARP, Răspuns 10.68.1.1 este la 20:7c:14:a0:b9:a1, lungime 28
09:32:33.190181 ARP, Solicitați cine-are 10.68.1.2 spuneți 10.68.1.1, lungime 28
09:32:33.190327 ARP, Răspuns 10.68.1.2 este la 00:90:e8:9d:aa:dc, lungime 46
09:32:46.117215 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:32:46.117470 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:32:48.117032 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:32:48.117277 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:33:04.116931 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:33:04.117104 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:33:06.116888 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:33:06.117144 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:33:09.286195 ARP, Solicitați cine-are 10.68.1.2 spuneți 10.68.1.1, lungime 28
09:33:09.286332 ARP, Răspuns 10.68.1.2 este la 00:90:e8:9d:aa:dc, lungime 46
09:33:22.116699 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:33:22.116833 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:33:24.116869 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:33:24.117034 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:33:27.116688 ARP, Solicitați cine-are 10.68.1.1 spuneți 10.68.1.2, lungime 46
09:33:27.116751 ARP, Răspuns 10.68.1.1 este la 20:7c:14:a0:b9:a1, lungime 28
09:33:40.116842 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:33:40.117011 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:33:42.116923 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:33:42.117089 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:33:45.126169 ARP, Solicitați cine-are 10.68.1.2 spuneți 10.68.1.1, lungime 28
09:33:45.126332 ARP, Răspuns 10.68.1.2 este la 00:90:e8:9d:aa:dc, lungime 46
09:33:58.116928 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:33:58.117095 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:34:00.116873 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:34:00.117039 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:34:16.116895 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:34:16.117154 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:34:18.116863 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:34:18.117029 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:34:21.116733 ARP, Solicitați cine-are 10.68.1.1 spuneți 10.68.1.2, lungime 46
09:34:21.116768 ARP, Răspuns 10.68.1.1 este la 20:7c:14:a0:b9:a1, lungime 28
09:34:21.222128 ARP, Solicitați cine-are 10.68.1.2 spuneți 10.68.1.1, lungime 28
09:34:21.222294 ARP, Răspuns 10.68.1.2 este la 00:90:e8:9d:aa:dc, lungime 46
09:34:34.116899 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:34:34.117069 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:34:36.127025 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:34:36.127269 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:34:52.116889 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:34:52.117145 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:34:54.116943 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:34:54.117187 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:34:57.318148 ARP, Solicitați cine-are 10.68.1.2 spuneți 10.68.1.1, lungime 28
09:34:57.318299 ARP, Răspuns 10.68.1.2 este la 00:90:e8:9d:aa:dc, lungime 46
09:35:10.116983 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:35:10.117159 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:35:12.116865 IP 10.68.1.2.123 > 10.68.1.1.123: NTPv4, Client, lungime 48
09:35:12.117031 IP 10.68.1.1.123 > 10.68.1.2.123: NTPv4, Server, lungime 48
09:35:15.116750 ARP, Solicitați cine-are 10.68.1.1 spuneți 10.68.1.2, lungime 46
09:35:15.116810 ARP, Răspuns 10.68.1.1 este la 20:7c:14:a0:b9:a1, lungime 28
drapel cn
Cred că este acoperit aici: https://serverfault.com/a/924165/20701. Acest lucru este similar cu comportamentul din Windows, timeout-ul este nedeterminist.
R SONG avatar
drapel in
Multumesc Greg. Am observat si postarea aia. Să fim de acord că, implicit, memoria cache ARP expiră între 15 și 45 de secunde. Intrarea în cache ARP expiră dacă nu este utilizată. Dacă există trafic mai frecvent de 15 secunde folosind acea adresă IP/MAC, acea intrare ARP nu ar trebui să expire, nu-i așa?
drapel cn
Ar trebui să fie destul de ușor de testat. Fara NTP.
Puncte:0
drapel ru

Este perfect normal și nu este un bug.

Intrările din tabelul ARP sunt reîmprospătate sau actualizate numai de pachetele ARP (răspunsurile ARP sau solicitările ARP create ca ARP gratuit mesaje), nu prin pachete IP. În consecință, intrările expiră chiar și atunci când sunt utilizate frecvent și trebuie actualizate prin solicitări/răspunsuri ARP.

R SONG avatar
drapel in
Mulțumesc Zac67. Am fost sub o impresie greșită. Am crezut că intrarea ARP nu va expira atâta timp cât este accesată frecvent. Dar, ar trebui răspunsul ARP să-și actualizeze și propriul cache ARP la primirea cererii ARP? De exemplu, gazda A trimite o cerere ARP către gazda B, va actualiza gazda B și intrarea ARP pentru gazda A? În tcpdump de mai sus, 10.68.1.2 a trimis cererea ARP la 10.68.1.1, 10.68.1.1 a răspuns, imediat după, 10.68.1.1 a trimis cererea ARP la 10.68.1.2 și 10.68.1.2 a răspuns. De ce este necesar?
Zac67 avatar
drapel ru
O solicitare ARP actualizează tabelul ARP numai atunci când este creat ca un mesaj *ARP gratuit* (TPA=SPA, THA=zero), solicitările ARP normale nu actualizează ARP.
R SONG avatar
drapel in
Mulțumesc Zac67. [link](http://manpages.ubuntu.com/manpages/bionic/man7/arp.7.html) ... Feedback-ul pozitiv poate fi obținut de la un strat superior... **base_reachable_time (de la Linux 2.2) O dată a fost găsit un vecin, intrarea este considerată a fi valabilă pentru cel puțin o valoare aleatorie între base_reachable_time/2 și 3*base_reachable_time/2. _Valabilitatea unei intrări va fi extinsă dacă primește feedback pozitiv de la protocoalele de nivel superior._** Se pare că alt protocol ar putea extinde valabilitatea intrărilor ARP. Problema este de ce Chrony's NTP sau NTP ca general nu face asta?
Zac67 avatar
drapel ru
Feedback pozitiv = cadrele primite de la o adresă MAC nu prelungește durata de viață a unei intrări, ci doar previne scurtarea acesteia. „Odată ce a fost găsit un vecin” se referă la rezoluția ARP de succes. Cu toate acestea, gazda și implementările lor sunt în mod explicit în afara subiectului aici, consultați [ajutor/la subiect].

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.