Właśnie przypadkiem zauważyłem, że jeden z moich przełączników Cisco 4500 ma nieprawidłowy zegar: jest ponad 2 minuty opóźnienia, pomimo pozornie funkcjonalnego NTTP. Moim zdaniem nawet jedna sekunda nie powinna być uważana za akceptowalną dla zaangażowanych systemów. Ponadto nie zauważyłbym różnicy w porównaniu z diagnostyką, gdybym nie porównał jej do zwykłego zegara ściennego.
Trochę szczegółów
Oto informacje ntp dla niektórych moich hostów (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241), które częściowo odwołują się do siebie na wypadek awarii, ale przede wszystkim powinny to wszystko ostatecznie zsynchronizować z 10.0.0.1, co ponownie pociąga za sobą czas z zewnątrz. Tak więc rozbieżność czasu nie może wynikać z różnych oryginalnych źródeł czasu. Ponieważ obserwacje sprawiły, że stałem się nieco paranoikiem, „ma właściwy czas” w następujący sposób: show clock(lub date) wytworzył wyjście, które pasuje do mojego zegara ściennego i mojego lokalnego zegara systemowego (co jest zgodne z http://time.is ) z błąd z pewnością poniżej 1 sekundy (dokładność mojego wciśnięcia ENTER podczas oglądania mojego lokalnego zegara)
10.0.1.119 (Ubuntu) ma poprawny czas
$ ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
+10.0.99.1 10.0.0.1 3 u 855 1024 377 0.904 -2.658 0.113
*10.0.0.1 130.149.17.8 2 u 266 1024 377 0.253 0.909 0.127
10.0.99.241 (Cisco 2960) ma poprawny czas
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.99.1 10.0.0.1 3 28 64 377 1.462 85.288 19.758
+~10.0.99.2 10.0.1.119 4 29 64 377 1.297 83.515 5.369
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.2 (Cico 4500) ma poprawny czas
#sho ntp associations
address ref clock st when poll reach delay offset disp
+~10.0.99.1 10.0.0.1 3 6 1024 111 1.148 -1.618 42.875
*~10.0.1.119 10.0.0.1 3 31 1024 377 0.043 1.687 1.064
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.1 (Cisco 4500) pozostaje w tyle o około 2 minuty 6 sekund
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.0.1 130.149.17.8 2 274 1024 377 15.625 3.681 30.403
+~10.0.99.2 10.0.1.119 4 415 1024 376 15.625 0.855 33.276
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
#sho ntp status
Clock is synchronized, stratum 3, reference is 10.0.0.1
nominal freq is 250.0000 Hz, actual freq is 249.9988 Hz, precision is 2**6
reference time is DAD8B428.54C6BAEA (20:36:24.331 MESZ Sat May 7 2016)
clock offset is 3.6818 msec, root delay is 32.80 msec
root dispersion is 71.74 msec, peer dispersion is 30.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000004720 s/s
system poll interval is 1024, last update was 683 sec ago.
pytania
- Dlaczego 10.0.99.1 jest tak daleko?
- Dlaczego systemy zsynchronizowane z 10.0.99.1 są poprawne?
- Jak mam się dowiedzieć z danych wyjściowych
sho ntp status10.0.99.1, że zegar jest całkowicie niezsynchronizowany (w porównaniu do wszystkich hostów i zegarów odniesienia wymienionych wsho ntp asso)? Dla mnie wyjście wygląda jak bardzo dopracowane „Jestem całkowicie szczęśliwy”.
EDYCJA: Według popularnego popytu, produkcjasho clock detail
10.0.99.1
#sho clock detail
13:06:38.605 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
10.0.99.2
#sho clock detail
13:10:54.083 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
źródło
10.0.0.1). Ale nie sądzę, że moje obserwacje mogą bezpośrednio wyjaśnić przyczynę twojego obecnego problemu.Odpowiedzi:
Nie chcę publikować tego jako odpowiedzi, ponieważ pierwotna przyczyna jest nadal niejasna. Niemniej jednak wydaje się, że problem został rozwiązany - przynajmniej na razie.
Po komentarzach htm11h postanowiłem zaktualizować oprogramowanie. I rzeczywiście, teraz, gdy korzystam z nowszego oprogramowania, zegar wydaje się pasować do właściwej godziny.
Ale czy to oznacza, że nowe oprogramowanie było rozwiązaniem? Niestety nie. Podczas mojej pierwszej próby załadowania nowego oprogramowania zapomniałem zmienić rejestr konfiguracji, który wciąż był ustawiony na domyślne ustawienia fabryczne. Dlatego moje pierwsze ponowne uruchomienie zakończyło się na tym samym oryginalnym obrazie ROM, który router działał przez prawie cztery lata (tj. Od momentu pierwszego włączenia). A jednak wystarczyło, aby zegar dokonał jednej wielkiej regulacji, a następnie pozostał zsynchronizowany. Sugeruje to, że zwykłe ponowne uruchomienie mogło pomóc - tymczasowo. To z kolei oznacza, że teraz poprawny czas pokazany w nowszym oprogramowaniu może nadal odchodzić od czasu NTTP w nadchodzących latach. Minie kilka dni, zanim będę mógł spokojnie stwierdzić, czy zegar stracił około 5 sekund dziennie ...
Na razie sprawa jest zamknięta.
źródło
Od połowy lat 90. wykonałem sporo pracy z projektem NTP Pool i uruchomiłem tutaj kilka serwerów synchronizacji GPS NTP Stratum-1. Jak inni stwierdzili, potrzebujesz więcej niż 2 serwerów, aby uzyskać czas. Zwykle używam tutaj 4 z powodów podanych powyżej przez Rona Maupina. Również zgodnie z listą musisz uważać na pętle i ustawiać rzeczy jako serwery kontra równorzędne.
Przesunięcie czasu może być spowodowane znanym błędem w systemie IOS, który został naprawiony w tej aktualizacji IOS, polegający na tym, że ntp.drift nie został poprawnie usunięty lub zaktualizowany, a tym samym problem z dryfowaniem. Również 4 LATA bez konieczności ponownego uruchamiania lub aktualizacji musiały pozostawić cię w bardzo złym miejscu pod względem bezpieczeństwa, ponieważ aktualizacje IOS Security pojawiają się dość często.
Oto doskonały post na temat konfigurowania NTP na Cisco IOS http://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/
Mam nadzieję, że to jest pomocne. Zapytaj, czy masz więcej pytań lub problemów.
źródło
Pełne ujawnienie: Od czasu do czasu majstrowałem przy konfiguracjach przełączników i w żadnym wypadku nie jestem ekspertem od NTP.
To powiedziawszy, widziałem demona NTP w systemach RHEL 5.x (tak, wracam, ale powiedziałeś, że twój przełącznik ma około 4-letni obraz ...) utknął w „szczęśliwym” stanie , gdzie wydawało się, że jest idealnie zsynchronizowany, ale najwyraźniej nie. Skorzystalibyśmy z sesji ClusterSSH, aby uruchomić „datę” na wszystkich systemach jednocześnie, co czasami pokazywałoby nawet 5 minut dryfu między systemami. Jeśli dobrze pamiętam, wydaje się, że możemy rozwiązać problem tylko poprzez zrestartowanie demona i ostatecznie po prostu kazałem cronowi restartować usługę co noc ...
W żadnym wypadku nie jest to idealne rozwiązanie, ale możesz być w stanie zastosować podobne podejście z zadaniem cron, aby połączyć się z przełącznikiem i zainicjować ponowne uruchomienie, lub jakoś „wykopać” demona NTP na przełączniku?
Mam nadzieję że to pomoże!
źródło