Dlaczego jeden z moich przełączników jest wyłączony o dwie minuty pomimo NTTP?

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 w sho 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

cisco ntp time-synchronization

— Hagen von Eitzen
źródło

Nie mogę wykryć żadnego systemu, w którym adresy IP skonfigurowane jako serwery NTTP są używane przez każde urządzenie. I dostrzegam pętlę, a także parę, która używa się nawzajem jako serwerów NTTP. Wierzę, że w takich przypadkach powinieneś określić je jako równorzędne ntp, a nie jako serwery. Chociaż muszę przyznać, że nie wiem, jaką dokładnie to robi różnicę, czy określasz ją jako równorzędną, czy serwerową. Nie jestem też przekonany, że dobrym pomysłem jest zezwolenie na synchronizację wszystkiego za pośrednictwem jednego hosta ( 10.0.0.1). Ale nie sądzę, że moje obserwacje mogą bezpośrednio wyjaśnić przyczynę twojego obecnego problemu.

— kasperd

Jednym z rażących problemów z konfiguracją NTTP jest to, że każdy host jest skonfigurowany z możliwie najgorszą liczbą źródeł czasu. „Mężczyzna z jednym zegarkiem wie, która jest godzina, mężczyzna z dwoma zegarkami nigdy nie jest pewien ...” Każda inna liczba jest lepsza niż dwa, cztery są prawdopodobnie najlepszym wyborem, daje poduszkę, jeśli jeden jest niedostępny i nadal wychodzi trzy źródła.

— dfc,

Należy ponownie rozważyć całą konfigurację NTP. Musisz pracować z poziomami warstwy. Jak zauważył @kasperd, możesz mieć problem z pętlą. Należy synchronizować tylko z serwerami o niższym poziomie warstwy, a te na tym samym poziomie warstwy można obserwować, ale nie można używać ich jako serwerów. Urządzenia monitorowane nadal potrzebują jednego lub więcej serwerów na niższym poziomie warstwy jako wiarygodnych źródeł, ale będą próbowały dostosować się do innych urządzeń równorzędnych. Nie używaj zajętych urządzeń (np. Przełączników podstawowych) jako serwerów NTP.

— Ron Maupin,

Dzieje się coś bardzo dziwnego. Wszystkie dane wyjściowe NTTP są w miarę normalne i wykazują dobrą synchronizację. Jednak twoje polecenie, aby uzyskać czas z urządzenia, dało czas, który jest daleko. To sugeruje, że z jakiegoś powodu urządzenie z czasem, który jest wyłączony, nie ustawia zegara systemowego z podsystemu NTTP.

— David Schwartz,

To naprawdę brzmi, jakbyś znalazł błąd, i prawdopodobnie jedynym sposobem jest zrestartowanie go i nadzieję, że zniknie lub skontaktowanie się z Cisco.

— derobert

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.

— Hagen von Eitzen
ź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.

— George Kasica
ź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!

— Dan
źródło