Я просто случайно заметил, что у одного из моих коммутаторов Cisco 4500 часы идут неправильно: это более чем на 2 минуты позади несмотря на кажущуюся работоспособность ntp. На мой взгляд, даже одна секунда не должна считаться приемлемой для задействованных систем. Также я бы не заметил отличия от диагностики, если бы не сравнил ее с простыми настенными часами.
Вот информация ntp для некоторых из моих хостов (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241), которые частично ссылаются друг на друга для отката, но в основном все должны в конечном итоге синхронизироваться с 10.0.0.1, что снова вызывает время извне. Таким образом, расхождение во времени не может быть результатом разных исходных источников времени. Поскольку наблюдения сделали меня несколько параноиком, "правильно время" означает следующее: show clock (или date) выдал результат, который соответствует моим настенным часам и моим локальным системным часам (что нормально в соответствии с http://time.is) с ошибкой, конечно, менее 1 секунды (точность нажатия ENTER при просмотре моих локальных часов)
$ 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
#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
#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
#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.
sho ntp status на 10.0.99.1, что часы на самом деле полностью не синхронизированы (по сравнению с все хосты и эталонные часы, упомянутые в sho ntp asso)? Для меня результат выглядит как очень тщательно продуманное «Я полностью счастлив».РЕДАКТИРОВАТЬ: По многочисленным просьбам выпуск sho clock detail
#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
#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
Я немного не хочу публиковать это в качестве ответа, потому что первоначальная причина все еще неясна. Тем не менее проблема вроде бы решена - по крайней мере, на данный момент.
После комментариев, сделанных htm11h, Решил обновить прошивку. И действительно, теперь, когда я использую более новую прошивку, часы, кажется, показывают правильное время.
Но означает ли это, что новая прошивка была решением? К сожалению нет. При первой попытке загрузить новую прошивку я забыл изменить регистр конфигурации, который по-прежнему оставался заводским по умолчанию. Таким образом, моя первая перезагрузка закончилась тем же исходным образом ПЗУ, на котором маршрутизатор работал почти четыре года (т.е. с момента его первоначального включения). И все же этого было достаточно для того, чтобы часы сделали одну огромную корректировку и затем синхронизировались. Это говорит о том, что простая перезагрузка могла помочь - временно. В свою очередь, это означает, что текущее правильное время, показываемое в новой прошивке, может все еще отклоняться от времени ntp в ближайшие годы. Пройдет несколько дней, прежде чем я смогу с уверенностью сказать, теряли ли часы около 5 секунд в день ...
На данный момент дело закрыто.
Я довольно много поработал с проектом NTP Pool с середины 90-х и запустил здесь несколько серверов NTP Stratum-1 GPS Synced. Как утверждали другие, вам нужно более 2 серверов, чтобы получить время. Я обычно использую здесь 4 по причинам, указанным выше Роном Мопином. Также, как указано в списке, вам нужно следить за циклами и настраивать параметры как серверы против одноранговых.
Дрейф времени мог быть из-за известной ошибки в IOS, которая была исправлена в этом обновлении IOS, касающегося того, что ntp.drift не удаляется или не обновляется правильно, и, следовательно, проблема дрейфа. Кроме того, 4 ГОДА без перезагрузки или обновления должны были оставить вас в довольно плохом месте с точки зрения безопасности, поскольку обновления безопасности IOS выходят довольно часто.
Вот отличный пост о настройке NTP на Cisco IOS http://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/
Надеюсь, это будет полезно. Пожалуйста, спросите, есть ли у вас еще вопросы или проблемы.
Полное раскрытие: я лишь изредка возился с конфигурациями коммутаторов, и я ни в коем случае не эксперт по NTP.
Тем не менее, я раньше видел, как демон NTP в системах RHEL 5.x (да, я возвращаюсь назад, но вы сказали, что у вашего коммутатора изображение возрастом ~ 4 года ...) застревает в "счастливом" состоянии , где казалось, что это было идеально синхронизировано, но явно не было. Мы использовали бы сеанс ClusterSSH для одновременного запуска «даты» на всех системах, и это иногда показывало бы до 5 минут дрейфа между системами. Если я правильно помню, мы могли решить проблему только путем перезапуска демона и в конечном итоге просто заставили cron перезапускать службу каждую ночь ...
Ни в коем случае не идеальное решение, но вы могли бы применить аналогичный подход с заданием cron для подключения к коммутатору и инициировать перезагрузку, или каким-то образом «пнуть» демона NTP на коммутаторе?
Надеюсь это поможет!