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-debian
o serwer Linux. Po stronie BusyBox ntpclient
narzeka jednak na „Zbyt duże rozrzuty”. Z wyniku debugowania ntpclient
pobiera „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 -pn
wyjś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:
- Co to jest dyspersja i co może zmienić jej wartość?
- Jakie polecenia mogę uruchomić, aby uzyskać więcej informacji z serwerów NTP?
- Czy błąd może leżeć po stronie serwera Ubuntu z niewłaściwym
ntp.conf
? Naprawdę nie ma tam nic specjalnego. - Czy przejście na chrony zmieniłoby cokolwiek w tym przypadku?
Odpowiedzi:
Widzę pewne zamieszanie w odpowiedziach tutaj. Na początek,
ntpclient
przynajmniej w-s
trybie, 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 0
lub-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ójntpq
wynik 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 przypadkuLOCL
błędna konfiguracja polega na tym, że reklamuje refid; powinno być nadpisane na przykładGPS
lub cokolwiek, co zapewnia swój czas.źródło
-x 0
lub zdam-t
raport. Jeśli chodzi o to10.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 zasadzientpq -p
?-t
przełą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.Tylko częściowa odpowiedź na pytanie „Co to jest dyspersja?”:
Typowa podróż w obie strony NTP:
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:
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.
źródło
offset = 1/2 * [(T2-T1) + (T4-T3)]
i „opóźnienie = (T3-T1) - (T4-T2)”t3/t4
we 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 -t1
powinny być całkowitym RTT,t3-t2
powinny być czasem spędzonym wewnątrz serwera.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
date
i ustawić zegar ręcznie.Uruchom ntpd i pokaż
ntpq -p
z hosta za pomocą wszystkich peerów. Wybierze lepsze.źródło
ntpq -pn
wyjście do mojego pytania. Dziękujemy za przyjrzenie się temu.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
ntpdate
jednego przed uruchomieniemntpd
na kliencie.źródło