Почему один из моих выключателей отключен на две минуты, несмотря на ntp?

Я просто случайно заметил, что один из моих коммутаторов 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

cisco ntp time-synchronization

— Хаген фон Айцен
источник

Я не могу определить ни одну систему, в которой IP-адреса вы настроили как ntp-серверы, используемые каждым устройством. И я замечаю петлю, а также пару, использующую друг друга в качестве серверов ntp. Я полагаю, что в этих случаях вы должны указывать их как пиров ntp, а не как серверы. Хотя я должен признать, что я не знаю, в чем именно разница, определяете ли вы его как одноранговый или серверный. Кроме того, я не уверен, что это хорошая идея, чтобы все синхронизировалось через один хост ( 10.0.0.1). Но я не думаю, что какие-либо из моих наблюдений могут напрямую объяснить причину вашей текущей проблемы.

— Касперд

Одна вопиющая проблема с вашей конфигурацией ntp состоит в том, что каждый хост настроен с наихудшим из возможных источников времени. «Человек с одними часами знает, который час, человек с двумя часами никогда не уверен ...» Любое другое число лучше двух, наверное, четыре - лучший выбор, оно дает подушку, если один недоступен и все еще уходит три источника.

— декабря

Вся ваша конфигурация NTP должна быть пересмотрена. Вам нужно работать с уровнями пласта. Как отметил @kasperd, у вас могут быть проблемы с циклом. Вы должны синхронизироваться только с серверами с более низким уровнем страты, и серверы с тем же уровнем страты могут быть одноранговыми, но не использовать друг друга в качестве серверов. Одноранговым устройствам по-прежнему требуется один или несколько серверов на более низком уровне страты в качестве авторитетного источника (источников), но они будут пытаться настроить себя на других одноранговых узлах Не используйте занятые устройства (например, коммутаторы ядра) в качестве серверов NTP.

— Рон Мопин

Происходит что-то очень странное. Весь вывод ntp достаточно нормальный и показывает хорошую синхронизацию. Тем не менее, ваша команда получить время от устройства дала время, которое еще далеко. Это говорит о том, что по какой-то причине устройство с выключенным временем не устанавливает системные часы из своей подсистемы ntp.

— Дэвид Шварц

Это действительно звучит так, как будто вы нашли ошибку, и, вероятно, единственный путь вперед - это перезагрузить ее и надеяться, что она исчезнет или связаться с Cisco.

— Дероберт

Ответы:

Я немного неохотно публикую это как ответ, потому что первоначальная причина до сих пор неясна. Тем не менее, проблема, кажется, решена - по крайней мере, на данный момент.

После комментариев, сделанных 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 на коммутаторе?

Надеюсь это поможет!

— Дэн
источник