Dlaczego NTP synchronizuje się z LOKALNYM, a nie ze zdalnym serwerem?

Tak więc próbuję debugować moją obecną konfigurację NTP i odkryłem, że przesunięcie względem mojego pojedynczego skonfigurowanego serwera trwa ponad 3 sekundy i nie dostosowuję się. Gwiazdka na LOCAL (0) w wyjściu ntpq wydaje się wskazywać, że system szczęśliwie synchronizuje się z samym sobą, a nie z serwerem 10.130.33.201 (który jest kolejnym systemem linux w naszym systemie, z którym chcemy synchronizować wszystko).

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.130.33.201   LOCAL(0)         9 u   49   64  377    0.242  -3742.2   1.049
*LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.001

A to jest mój plik ntp.conf. Napisane przez kogoś innego, więc nie jestem w 100% pewien, że wszystko jest w porządku.

server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift

restrict -4 default  nomodify nopeer notrap
restrict -6 default  ignore

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

Czytałem o serii i iburst oraz minpoll / maxpoll, więc zdaję sobie sprawę, że mogą one nie być potrzebne, ale nie sądzę, aby miało to związek z moim bieżącym problemem.

Ponadto, ze względu na sposób jego wdrożenia, ten plik konfiguracji zajmie dużo pracy, aby zmienić, więc mam nadzieję, że nic, co naprawdę musi zostać zmienione. Mam nadzieję, że to przypadek, w którym nie rozumiem, jak działa NTP.

EDYTOWAĆ -

Wygląda na to, że jest to duplikat tego pytania , ale nie sądzę, aby plakat otrzymał wystarczającą odpowiedź, więc nadal chciałbym wiedzieć, dlaczego czas lokalny jest lepszy niż serwer. Ponadto, zgodnie z jedną z poniższych odpowiedzi, próbowałem użyć prefersłowa kluczowego w linii serwera konfiguracji i zrestartować, ale nie wydaje się, aby miało to wpływ.

Jeśli usunę wszystkie „lokalne” wiersze w konfiguracji jako odpowiedź na inne pytanie, co się stanie, jeśli serwer będzie nieosiągalny? Czy NTP umiera, czy tylko próbuje?

WAŻNA EDYCJA -

Ok, zwykle 10.130.33.201 („serwer”) nie ma dostępu do Internetu i nie ma źródła czasu GPS. Ważną częścią jest to, że wszystkie urządzenia w systemie mają taki sam czas jak serwer, niezależnie od tego, jak poprawny jest ten czas.

Tak więc, aby zobaczyć, co się stanie, dodałem jeden z serwerów puli NTP do pliku konfiguracyjnego serwera, aby uzyskać czas stamtąd zamiast uzyskiwać czas lokalny. Teraz poprawnie pobiera czas z serwera czasu NTP.

Po wykonaniu tej czynności klienci synchronizują się teraz z serwerem zamiast preferować LOCAL (0)

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.130.33.201   38.229.71.1      3 u   58   64  377    0.216  715621.   1.001
 LOCAL(0)        .LOCL.          10 l   18   64  377    0.000    0.000   0.001

NOWE PYTANIE - Gdy mój serwer używa lokalnego (podany oryginalny przykład), wydaje się, że klienci mówią: „Och, 10.130.33.201 używa LOKALNEGO (0). Hmm, mam również serwer LOKALNY (0) - - Wykorzystam to bezpośrednio, zamiast uzyskiwać te same informacje za pośrednictwem 10.130.33.201 ”.

Czy tak jest w przypadku? Czy próbują przejść „bezpośrednio do źródła”, które jest niepoprawnie LOKALNE (0)? Potrzebuję mojego serwera, aby uzyskać czas z LOCAL (0) i potrzebuję klientów, aby uzyskać czas z serwera. W tej chwili usunięcie „lokalnego” serwera z plików konfiguracyjnych klienta jest jedyną opcją, ale chciałbym zrozumieć, dlaczego tak się dzieje, i jeśli to w ogóle możliwe, unikaj zmiany ich konfiguracji (zmiana konfiguracji będzie dużo pracy z powodu Nasze środowisko...).

Także, to wygląda jak kolejny duplikat bez dobrej odpowiedzi.

Po skonfigurowaniu tylko jednego serwera NTP algorytm nie jest całkowicie pewien, komu zaufać. Mimo że warstwa jest niższa w przypadku zdalnego hosta, założę się, że algorytm uważa, że ​​czas lokalny jest bardziej godny zaufania.

Spróbuj użyć prefersłowa kluczowego w serverzestawieniu, aby ustawić je jako preferencyjne źródło czasu.

EDYTOWAĆ -

Wygląda na to, że jest to duplikat tego pytania, ale nie wydaje mi się, aby plakat otrzymał wystarczającą odpowiedź, więc nadal chciałbym wiedzieć, dlaczego czas lokalny jest lepszy niż serwer.

Aby uzyskać naprawdę wystarczającą odpowiedź, będziesz kopać w trzewiach bardzo złożonego algorytmu. Dokumentacja nawet nie jest zbyt szczegółowa, ale jestem pewien, że jest tam biała księga lub specyfikacja.

Jeśli usunę wszystkie „lokalne” wiersze w konfiguracji jako odpowiedź na inne pytanie, co się stanie, jeśli serwer będzie nieosiągalny? Czy NTP umiera, czy tylko próbuje?

Demon NTP nie umiera ani się nie zatrzymuje, ale przestaje synchronizować czas po nieudanym dotarciu do zdalnego serwera. Dlatego najlepsze praktyki zalecają co najmniej trzy zdalne serwery i nieużywanie LCL, chyba że zostaniesz odłączony od sieci. Sugerowane są trzy serwery, ponieważ gdy są tylko dwa i nie zgadzają się, co wybierze? Trzeci serwer powinien pomóc algorytmowi wyeliminować fałszywy serwer.

Wreszcie zauważyłem, że nie definiujesz driftfile. To może pomóc?

Wydaje mi się, że odstęp przesunięcia (różnica między czasem systemowym a czasem hosta NTP) jest zbyt różny, aby NTP mógł go poprawnie ustawić.

Moja sugestia,

 1. Stop the NTP service
 2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
 3. Start the NTP service

Po tym nie powinieneś mieć żadnych problemów.

Warstwa 10.130.33.201 jako serwer LOCAL ma 9, co sprawia, że ​​lokalna warstwa obliczona na tej podstawie (9 + 1 = 10) konkuruje z lokalnym serwerem LOCAL w warstwie 10. Ponieważ lokalna warstwa LOCAL nie ma opóźnień ani zakłóceń w sieci, może wyglądać nieco lepiej na ntpd niż na zdalny.

Jeśli chcesz, aby ta konfiguracja działała, ustaw LOKALNY serwer „master” na warstwę niższą niż 9. Nie za niską, jeśli chcesz, aby preferowany był czas do śledzenia na serwerze warstwy 1.

Wiem, że to stare, ale myślę, że masz rację. Nikt nie pokazuje żadnego sposobu debugowania problemów z NTTP. Okazuje się, że jest to wykonalne.

Myślę, że byłeś na dobrej drodze, gdy podejrzewałeś, że używanie LOCAL (0) lokalnie i na serwerze nadrzędnym może być problemem.

Z pewnością znajdował się na wyspie składającej się z 4 serwerów, z którymi miałem podobny problem. Wszystkie były ustawione na siebie nawzajem, więc być może jest to inny problem niż twój.

Po pierwsze jednak istnieje lepszy sposób obsługi wysp czasowych zwany trybem osieroconym, który jest obsługiwany w wersjach NTTP z ostatnich kilku lat:

Tryb Sierot na doc.ntp.org

Początkowo wszystkie 4 serwery miały tę samą warstwę 10 i wolały swój lokalny zegar. Naprawiłem to i nadal woleli swój lokalny zegar (warstwa wydaje się być ważna).

Użyłem polecenia ntpq pe (peer), as, rv, aby zrozumieć, co się dzieje. Musisz użyć rv (readvar) na numerze powiązania, aby serwer zrzucił informacje. pe i as wydają się być posortowane według tego samego indeksu, dzięki czemu można uzyskać w ten sposób liczbę as. podobnie jak pole o nazwie warunek, który może pokazywać wartość odrzucenia, jeśli serwer nie lubi.

W wyjściu rv znajduje się pole o nazwie flash. Jeśli wszystko będzie dobrze, będzie to zero. Jeśli nie, jest to maska ​​bitowa (wyświetlana szesnastkowo) problemów. Można je tutaj zobaczyć:

dekodowania wewnętrzne ntpd

Problem, który miałem, to 0800 peer_loop. Okazało się, że refid zegara jest ważny. Widząc LOCAL (0) zarówno na zegarze lokalnym, jak i ze zdalnego serwera, ntpd myślało, że istnieje pętla. David Mills potwierdza to w postach na comp.protocols.time „Jak uniknąć pętli w NTP” (Niestety, osiągnąłem limit 2 linków, przepraszam!)

Użycie argumentu refid do kruszenia w celu ustawienia unikalnego refid nie zadziałało - nadal pojawia się jako LOCAL (0) u odbiorcy.

Wydawało się, że zadziałało użycie unikalnych numerów instancji dla lokalnego sterownika. 127.127.1. [0–3]. Użyj tego samego identyfikatora na serwerze i linii krówki. Kiedy to zrobiłem, serwery generalnie synchronizowały się z serwerem najniższej warstwy, który zwykle używał lokalnego zegara. Jednak czasami próbował użyć jednego z innych serwerów, który używał go jako źródła. Czasy się jednak zsynchronizowały i wydaje się, że tak jest.

Prawdopodobnie o wiele za późno, aby pomóc, ale oferuję to, aby pokazać, że NTP jest podatny na logikę i rozwiązywanie problemów. Spędziłem godziny, próbując znaleźć odpowiedź metodą prób i błędów, a potem znalazłem dokumenty później.

Użyj iburst, aby wymusić na serwerze wysłanie żądania NTP do żądanego NTS, nawet jeśli jedno żądanie nie powiedzie się