Я просто случайно заметил, что один из моих коммутаторов 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 при просмотре местных часов)
10.0.1.119 (Ubuntu) имеет правильное время
$ 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) имеет правильное время
#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) имеет правильное время
#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) отстает примерно на 2 минуты 6 секунд
#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.
Вопросов
- Почему 10.0.99.1 так далеко?
- Почему системы, которые синхронизируются с 10.0.99.1, верны?
- Как я должен узнать из выходных данных
sho ntp status10.0.99.1, что часы на самом деле полностью не синхронизированы (по сравнению со всеми хостами и опорными часами, упомянутыми вsho ntp asso)? Для меня результат выглядит полностью как очень тщательно продуманное «Я полностью счастлив».
РЕДАКТИРОВАТЬ: По многочисленным просьбам, выходsho 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
источник
10.0.0.1). Но я не думаю, что какие-либо из моих наблюдений могут напрямую объяснить причину вашей текущей проблемы.Ответы:
Я немного неохотно публикую это как ответ, потому что первоначальная причина до сих пор неясна. Тем не менее, проблема, кажется, решена - по крайней мере, на данный момент.
После комментариев, сделанных htm11h , я решил обновить прошивку. И действительно, теперь, когда я работаю с более новой прошивкой, часы, кажется, соответствуют правильному времени.
Но значит ли это, что новая прошивка была решением? К сожалению нет. В моей первой попытке загрузить новую прошивку я забыл изменить регистр конфигурации, который по-прежнему был по умолчанию. Поэтому моя первая перезагрузка оказалась в том же исходном образе ПЗУ, на котором маршрутизатор работал почти четыре года (т.е. с момента его первоначального включения). И все же этого было достаточно для того, чтобы часы сделали одну огромную настройку и затем остались в синхронизации. Это говорит о том, что простая перезагрузка могла бы помочь - временно. В свою очередь, это означает, что теперь правильное время, показанное с более новой прошивкой, может все еще отклоняться от времени ntp в последующие годы. Это займет несколько дней, пока я не смогу с уверенностью сказать, теряют ли часы около 5 секунд в день ...
На данный момент дело закрыто.
источник
С середины 90-х годов я проделал немалую работу с проектом NTP Pool и запускаю здесь несколько серверов NTP Stratum-1 GPS Synced. Как уже говорили другие, вам нужно более 2 серверов, чтобы получить время. Я обычно использую 4 здесь по причинам, изложенным Роном Мопином выше. Кроме того, как указано в списке, вам нужно следить за циклами и настройкой серверов и пиров.
Дрейф времени мог быть связан с известной ошибкой в IOS, которая была исправлена в этом обновлении IOS, связанной с тем, что ntp.drift не удалялся или обновлялся правильно, и, следовательно, с проблемой дрейфа. Кроме того, 4 ЛЕТ без перезагрузки или обновления, должно быть, поставили вас в довольно плохое положение с точки зрения безопасности, поскольку обновления IOS Security выходят довольно часто.
Вот отличный пост по настройке 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 на коммутаторе?
Надеюсь это поможет!
источник