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

20

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?
Jeff
źródło
Zakładając - czy zegary pięciu dostarczonych serwerów NTP są dobre? Czy możesz usunąć najgorsze z konfiguracji?
Criggie,
1
Twoje przesunięcia i drgania są zbyt wysokie. Uzyskaj co najmniej jedno właściwe źródło.
Przywróć Monikę - M. Schröder

Odpowiedzi:

21

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.

Hobbs
źródło
Fantastyczna odpowiedź. Spróbuję -x 0lub zdam -traport. Jeśli chodzi o to 10.31.10.22, mogę usunąć go z listy serwerów. Świetne przyjęcie. Naprawdę nie mam żadnych informacji na temat tych serwerów, czy są jakieś inne polecenia debugowania, aby uzyskać szczegółowe informacje z serwera NTP, czy to w zasadzie ntpq -p?
Jeff
Jak powiedziałeś, -tprzełącznik ufa wewnętrznemu serwerowi NTP pomimo dużej dyspersji. Nadal nie możemy wyjaśnić, dlaczego tak losowo osiąga szczyt, ale może to dotyczy innego postu. Dziękuję Ci.
Jeff
@Jeff chętnie pomoże :)
hobbs
12

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.

Sven
źródło
Pewnie o formułach? W końcu tylko t4-t2 i t3-t1 są znane zainteresowanym stronom
Hagen von Eitzen
@HagenvonEitzen Godzinę można uwzględnić w pakiecie
Thomas
@ Sven Uważam również, że istnieje problem z formułami; patrz strona 28 tutaj, a także niniejsza biała księga , oba autorstwa Millsa. Nawiasem mówiąc, twoje t jest ułożone, powinno być offset = 1/2 * [(T2-T1) + (T4-T3)]i „opóźnienie = (T3-T1) - (T4-T2)”
Ian Riley
Sven, czy jesteś t3/t4we właściwym miejscu podczas typowej podróży w obie strony? Obliczenia przepływu ruchu i opóźnień wydają się wskazywać, że powinny być odwrotnie: t4 -t1powinny być całkowitym RTT, t3-t2powinny być czasem spędzonym wewnątrz serwera.
7

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.

John Mahowald
źródło
Dodano ntpq -pnwyjście do mojego pytania. Dziękujemy za przyjrzenie się temu.
Jeff
4
Przesunięcie i drgania w setkach? To niezbyt dobrze. Wspomniałeś o braku dostępu do źródeł internetowych, takich jak pool.ntp.org, ale te działają znacznie lepiej. Rozważ dodanie zegara odniesienia, takiego jak GPS, źródło radiowe, wejście PPS lub podobne. Lub wybierz hosta z lokalnym zegarem, który nie jest wszędzie.
John Mahowald,
5

Według tej dokumentacji firmy Ciscorozproszenie , 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.

Hagen von Eitzen
źródło
1
ntpclient zgłasza wartości w mikrosekundach, więc rozproszenie na liście wynosi w rzeczywistości ~ 1,2 sekundy, a nie tygodni :) Również interpretacja w tym dokumencie Cisco nie ma zastosowania do tej wartości.
hobbs