Co to jest dyspersja NTP i jak ją kontrolować?

Wdrażamy serwery Ubuntu 14.04 w izolowanych sieciach, działające w ntpd 4.2.6p5, skonfigurowane do korzystania z wielu serwerów NTP podanych przez klientów (brak dostępu do pool.ntp.org). Nasze głupie urządzenia klienckie obsługują starszą wersję BusyBox (1.00-rc2) i ntpclient 2010 od Larry'ego Doolittle.

Ta konfiguracja działała świetnie od lat, ale ostatnio natrafiliśmy na przeszkodę dla nowego klienta. Dostarczyli nam 5 wewnętrznych adresów serwerów NTP, które wydają się działać same z siebie, jeśli chodzi ntpdate-debiano serwer Linux. Po stronie BusyBox ntpclientnarzeka jednak na „Zbyt duże rozrzuty”. Z wyniku debugowania ntpclientpobiera „1217163.1” z serwera NTP, ale maksymalna obsługiwana przez niego wartość to bezwzględna wartość (65536).

$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
  -c probe_count 1
  -d (debug)     1
  -g goodness    0
  -h hostname    10.17.162.250
  -i interval    15
  -l live        0
  -p local_port  0
  -q min_delay   800.000000
  -s set_clock   1
  -x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0  VN=3  Mode=4  Stratum=4  Poll=4  Precision=-20
Delay=60745.2  Dispersion=1346801.8  Refid=10.31.10.21
Reference 3668859928.942079
(sent)    3668859928.708371
Originate 3668859928.708371
Receive   3668859928.963271
Transmit  3668859928.963369
Our recv  3668859928.708371
Total elapsed:      0.00
Server stall:      93.09
Slop:             -93.09
Skew:          255443.94
Frequency:             0
 day   second     elapsed    stall     skew  dispersion  freq
42463 56728.708  rejected packet: abs(DISP)>65536

To są wszystkie urządzenia w tej samej sieci LAN, więc szczerze mówiąc, jestem oszołomiony. Nawet okropnie.

Oto dane ntpq -pnwyjściowe z serwera Ubuntu 14.04:

user@host:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l 1025   64    0    0.000    0.000   0.000
 10.17.162.249   10.17.6.10       5 u   23 1024   37    0.865  1381.07 697.260
 10.31.10.22     .LOCL.           1 u 1044 1024   17   29.586  -838.06 397.342
 10.17.6.10      10.31.10.21      4 u 1065 1024   17    0.366  105.245 402.999
*10.31.10.21     132.246.11.238   3 u    5 1024   37   29.418  794.292 616.796
 10.17.6.11      10.31.10.21      4 u 1038 1024   17    0.408  120.030 381.058

Moje pytania to:

1. Co to jest dyspersja i co może zmienić jej wartość?
2. Jakie polecenia mogę uruchomić, aby uzyskać więcej informacji z serwerów NTP?
3. Czy błąd może leżeć po stronie serwera Ubuntu z niewłaściwym ntp.conf? Naprawdę nie ma tam nic specjalnego.
4. Czy przejście na chrony zmieniłoby cokolwiek w tym przypadku?

Widzę pewne zamieszanie w odpowiedziach tutaj. Na początek, ntpclientprzynajmniej w -strybie, nie działa jako pełny klient NTP, tylko wysyła i odbiera jeden pakiet , więc nie ma „ostatnich 8 odebranych pakietów”. W rzeczywistości wcale nie szacuje własnej dyspersji.

Zamiast tego wartość, którą wypisuje, to wartość zwana „dyspersją root” (rootdisp) w pakiecie zwróconym przez serwer, która jest oszacowaniem całkowitej ilości błędu / wariancji między tym serwerem a właściwym czasem. Sposób obliczania tego jest dość prosty: każdy serwer NTP albo pobiera swój czas z zewnętrznego zegara (na przykład odbiornika radiowego lub GPS), albo z innego serwera NTP. Jeśli serwer pobiera swój czas z zewnętrznego zegara, jego dyspersja root jest szacowanym maksymalnym błędem tego zegara. Jeśli pobiera czas z innego serwera NTP, jego dyspersja root jest dyspersją root tego serwera plus dyspersją dodaną przez połączenie sieciowe między nimi.

Jednym z nieporozumień jest to, że podczas gdy ntpq i chrony wyświetlają dyspersję i dyspersję roota w kilka sekund, do czego ludzie są przyzwyczajeni, to ntpclient wyświetla je w mikrosekundach . Niezależnie od tego wartość 1217163 jest wciąż dość wysoka. Dobry serwer NTP zna czas w ciągu kilku milisekund; zły w ciągu kilkudziesięciu lub setek milisekund. Pozdrawiam, że można zaufać jego czasowi w ciągu +/- 1,2 sekundy.

Tak naprawdę możesz poprosić ntpclient o synchronizację z tym serwerem, przekazując opcję -x 0lub -t(w zależności od wersji ntpclient), co wyłącza sprawdzanie poprawności NTP. Jeśli potrzebujesz tylko z grubsza dokładnego czasu (w ciągu kilku sekund), może to być wystarczające. Jednak ntpclient jest dość rozsądny, odmawiając synchronizacji z tak złym serwerem. Twój ntpqwynik na maszynie ubuntu pokazuje jitter setek milisekund dla wszystkich swoich serwerów, mimo że mają one małe opóźnienie, co wskazuje albo na bardzo zawodną sieć, spisek wszystkich serwerów, aby zapewnić nieregularny czas, lub podstawową problem z mierzeniem czasu na samym serwerze.

Niepokoi mnie również to, że serwer 10.31.10.22 reklamuje refid LOCL(niezdyscyplinowany zegar lokalny), ale ma warstwę 1. Zwykle zegar lokalny jest sfałszowany do warstwy 10, więc jest on używany tylko jako źródło synchronizacji w ostateczności aby stado się nie rozpadło. Albo 10.31.10.22 jest źle skonfigurowany i zapewnia zły czas pozostałej części sieci, albo jest dyscyplinowany przez dobry program przez program poza kontrolą NTP, w którym to przypadku LOCLbłędna konfiguracja polega na tym, że reklamuje refid; powinno być nadpisane na przykład GPSlub cokolwiek, co zapewnia swój czas.

Tylko częściowa odpowiedź na pytanie „Co to jest dyspersja?”:

Typowa podróż w obie strony NTP:

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

Daje to dwie wartości, przesunięcie (różnica czasu między klientem a serwerem) oraz opóźnienie (niezbędne dla czasu podróży w sieci) z następującymi wzorami:

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

Klient wybiera bieżące przesunięcie z ostatnich 8 odebranych pakietów, wybierając ten z najmniejszym opóźnieniem.

Tych samych 8 pakietów używa się do obliczenia dyspersji , wykonując średnią ważoną różnicy tych 8 przesunięć w stosunku do wybranej w ostatnim etapie, gdzie opóźnienie stosuje się jako czynnik ważący, co daje większą wagę mniejszym opóźnieniom. Jest to miara „rozproszenia” wartości i używana do obliczania jakości serwera czasu, szczególnie jeśli masz wiele do wyboru.

Twoje rozproszenie i pochylenie są ogromne, istnieje bardzo duże przesunięcie od lokalnego zegara do tego elementu. Powinieneś porównać przesunięcia z lokalnym datei ustawić zegar ręcznie.

Uruchom ntpd i pokaż ntpq -pz hosta za pomocą wszystkich peerów. Wybierze lepsze.

Według tej dokumentacji firmy Cisco „ rozproszenie , zgłaszane w sekundach, to maksymalna różnica czasu, jaką kiedykolwiek zaobserwowano między zegarem lokalnym a zegarem serwera”. W przypadku serwerów NTTP, które nie są całkowicie zepsute, nigdy nie powinno wystąpić duże rozproszenie. Jedynym możliwym scenariuszem jest sytuacja, w której klient rozpoczyna ntp i do tej pory ma tylko swój lokalny zegar. I nawet wtedy dyspersja tak wysoka, jak podajesz, odpowiada zegarom, które są wyłączone o ponad dwa tygodnie .

Powinno wystarczyć upewnienie się, że lokalny zegar na początku nie jest zbyt daleko (nawet kilka godzin byłoby nadal do zaakceptowania), albo poprzez dostosowanie zegara (i nawet daty!) W BIOS-ie, albo przez wydanie ntpdatejednego przed uruchomieniem ntpdna kliencie.