Руководство по отладке, а также поиску и устранению неполадок протокола NTP
Содержание
Введение
В этом документе описывается использование отладки для поиска и устранения неполадок в работе протокола NTP, а также выходные данные основных команд show ntp.
Команды show протокола NTP
Прежде чем начинать поиск причин неполадок в работе протокола NTP, необходимо понять, как использовать следующие команды и их выходные данные:
- show ntp association
- show ntp association detail
- show ntp status
show ntp association
NTP-ассоциация может быть одноранговой (одна система готова к синхронизации с другой системой или готова разрешить другой системе синхронизацию с собой) или серверной (только одна система синхронизируется с другой системой, но не наоборот).
Вот пример выходных данных команды show ntp association:
CLA_PASA#sh ntp association
address ref clock st when poll reach delay offset disp
~127.127.7.1 127.127.7.1 9 50 64 377 0.0 0.00 0.0
~10.50.44.69 10.50.36.106 5 21231 1024 0 3.8 -4.26 16000.
+~10.50.44.101 10.50.38.114 5 57 64 1 3.6 -4.30 15875.
+~10.50.44.37 10.50.36.50 5 1 256 377 0.8 1.24 0.2
~10.50.44.133 10.50.38.170 5 12142 1024 0 3.2 1.24 16000.
+~10.50.44.165 10.50.38.178 5 35 256 357 2.5 -4.09 0.2
+~10.50.38.42 86.79.127.250 4 7 256 377 0.8 -0.29 0.2
*~10.50.36.42 86.79.127.250 4 188 256 377 0.7 -0.17 0.3
+~10.50.38.50 86.79.127.250 4 42 256 377 0.9 1.02 0.4
+~10.50.36.50 86.79.127.250 4 20 256 377 0.7 0.87 0.5
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
| Термин | Пояснение |
|---|---|
Символы, указанные перед адресом, имеют следующие определения:
|
|
адрес |
Это IP-адрес узла. В первой записи в этом примере указан адрес 127.127.7.1. Это указывает, что локальный компьютер синхронизирован сам с собой. Обычно только тактовый генератор NTP синхронизируется сам с собой. |
ref clock |
Это адрес тактовых сигналов для однорангового узла. В данном примере первые шесть одноранговых узлов/серверов имеют частный IP-адрес для тактовых импульсов, поэтому их тактовыми генераторами, вероятно, являются маршрутизаторы, коммутаторы или серверы в локальной сети. Для последних четырех записей тактовый сигнал имеет общедоступный IP-адрес, поэтому их тактовым генератором, вероятно, является общедоступный источник синхросигналов. |
st |
В NTP используется понятие уровня для описания расстояния (в переходах NTP) от машины до доверенного источника синхросигналов. Например, сервер синхронизации времени с уровнем 1 имеет непосредственно подключенные к нему радиочасы или атомные часы. Он передает по протоколу NTP свое время на сервер синхронизации времени с уровнем 2 и так далее до уровня 16. Компьютер, на котором выполняется протокол NTP, автоматически выбирает компьютер с самым низким номером уровня, с которым может связаться, и использует NTP как свой источник синхросигналов. |
when |
Время, начиная с получения последнего пакета NTP от однорангового узла (указывается в секундах). Это значение должно быть меньше, чем интервал опроса. |
poll |
Об Об Интервал опроса указывается в секундах. Интервал обычно начинается минимум с 64-секундных интервалов опроса. RFC указывает, что для синхронизации двух компьютеров необходимо не более одной транзакции NTP в минуту. Как только NTP начнет устойчиво работать между клиентом и сервером, интервал опроса может с небольшим шагом увеличиваться от 64 до 1024 секунд и обычно устанавливается на каком-то промежуточном значении. Однако это значение динамически изменяется в зависимости от сетевых условий между клиентом и сервером и потери пакетов NTP. Если сервер недостижим в течение некоторого времени, интервал опроса постепенно увеличивается до 1024 секунд, чтобы сократить дополнительную нагрузку на сеть. Невозможно отрегулировать интервал опроса NTP на маршрутизаторе, поскольку он определяется эвристическими алгоритмами. |
reach |
Достижимость однорангового узла является строкой битов, передаваемой в виде восьмеричного значения. Это поле показывает, были ли последние 8 пакетов получены процессом NTP в ПО Cisco IOS®. Пакеты должны быть получены, обработаны и приняты как допустимые процессом NTP, а не только маршрутизатором или коммутатором, который получает IP-пакеты NTP. Процесс reach использует интервал опроса в качестве тайм-аута для принятия решения о том, был ли пакет получен или нет. Интервал опроса — это время ожидания до того, как протокол NTP придет к заключению, что пакет был потерян. Время опроса может быть различным для разных одноранговых узлов, поэтому время до того, как процесс reach решит, что пакет был потерян, может также быть различным для них. В данном примере есть четыре различных значения достижимости:
Достижимость является хорошим индикатором того, отбрасываются ли пакеты NTP из-за плохого канала, проблем с ЦП или других периодических неполадок. |
delay |
О О Задержка прохождения сигнала в прямом и обратном направлении к одноранговому узлу (указывается в миллисекундах). Эта задержка принимается во внимание для более точной настройки синхронизации. |
offset |
Смещение представляет собой различие во времени между одноранговыми узлами или между тактовым генератором и клиентом. Это значение представляет собой поправку, которая применяется к клиентским часам для их синхронизации. Положительное значение указывает, что показания часов сервера больше. Отрицательное значение указывает, что показания клиентских часов больше. |
disp |
Дисперсия (в секундах) — это максимальная разница во времени, которая когда-либо наблюдалась между локальными часами и часами сервера. В данном примере дисперсия равна 0.3 для сервера 10.50.36.42, поэтому максимальная разница во времени, когда-либо наблюдавшаяся локально между локальными часами и часами сервера, составляет 0,3 секунды. При первоначальной синхронизации часов можно ожидать большое значение. Однако, если дисперсия оказывается слишком большой в других случаях, значит, процесс NTP на клиенте не принимает сообщения NTP от сервера. Максимальная дисперсия составляет 16000; в данном примере такова дисперсия для серверов 10.50.44.69 и 10.50.44.133, поэтому локальный клиент не принимает время от этих серверов. Если достижимость равна нулю и дисперсия очень высока, клиент, вероятно, не принимает сообщения от этого сервера. См. вторую строку примера: address ref clock st when poll reach delay offset disp Несмотря на то что смещение составляет всего -4.26, дисперсия очень высока (возможно, из-за события в прошлом) и достижимость равна нулю, поэтому этот клиент не принимает время от этого сервера. |
show ntp association detail
Вот пример выходных данных команды show ntp association detail:
Router#sho ntp assoc detail
10.4.2.254 configured, our_master, sane, valid, stratum 1
ref ID .GPS., time D36968AA.CC528FE7 (02:10:50.798 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.44, reach 377, sync dist 207.565
delay 2.99 msec, offset 268.3044 msec, dispersion 205.54
precision 2**19, version 3
org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012)
rcv time D36968B7.A2F44E2C (02:11:03.636 UTC Fri May 25 2012)
xmt time D36968B7.A21D3780 (02:11:03.633 UTC Fri May 25 2012)
filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72
filtoffset = 268.30 172.15 -452.49 -253.59 -462.03 -81.98 -58.04 22.38
filterror = 0.02 0.99 1.95 1.97 2.00 2.01 2.03 2.04
10.3.2.254 configured, selected, sane, valid, stratum 1
ref ID .GPS., time D36968BB.B16C4A21 (02:11:07.693 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 3.34, reach 377, sync dist 192.169
delay 0.84 msec, offset 280.3251 msec, dispersion 188.42
precision 2**19, version 3
org time D36968BD.E69085E4 (02:11:09.900 UTC Fri May 25 2012)
rcv time D36968BD.9EE9048B (02:11:09.620 UTC Fri May 25 2012)
xmt time D36968BD.9EA943EF (02:11:09.619 UTC Fri May 25 2012)
filtdelay = 0.84 0.75 663.68 0.67 0.72 968.05 714.07 1.14
filtoffset = 280.33 178.13 -286.52 42.88 41.41 -444.37 -320.25 35.15
filterror = 0.02 0.99 1.97 1.98 1.98 2.00 2.03 2.03
10.1.2.254 configured, insane, invalid, stratum 1
ref ID .GPS., time D3696D3D.BBB4FF24 (02:30:21.733 UTC Fri May 25 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 4.15, reach 1, sync dist 15879.654
delay 0.98 msec, offset 11.9876 msec, dispersion 15875.02
precision 2**19, version 3
org time D3696D3D.E4C253FE (02:30:21.893 UTC Fri May 25 2012)
rcv time D3696D3D.E1D0C1B9 (02:30:21.882 UTC Fri May 25 2012)
xmt time D3696D3D.E18A748D (02:30:21.881 UTC Fri May 25 2012)
filtdelay = 0.98 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filtoffset = 11.99 0.00 0.00 0.00 0.00 0.00 0.00 0.00
filterror = 0.02 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
Термины, уже определенные в разделе, посвященном команде show ntp association, не повторяются.
Термин |
Пояснение | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
configured |
Этот источник синхронизации NTP настроен как сервер. Это значение также может быть динамическим, когда одноранговый узел или сервер обнаруживается динамически. |
|||||||||||||||||||||||||||
our_master |
Локальный клиент синхронизируется с этим одноранговым узлом. |
|||||||||||||||||||||||||||
selected |
Одноранговый узел или сервер выбран для возможной синхронизации в случае сбоя our_master или потери синхронизации клиентом. |
|||||||||||||||||||||||||||
sane |
Проверки правильности используются для проверки пакета NTP, полученного от сервера. Эти тесты описаны в документе RFC 1305, спецификация, реализация и анализ протокола сетевого времени (версия 3). Вот эти проверки:
Данные пакета допустимы, если пройдены проверки 1–4. Эти данные затем используются для вычисления смещения, задержки и дисперсии. Заголовок пакета допустим, если пройдены проверки 5–8. Только пакеты с допустимым заголовком могут использоваться для определения того, может ли одноранговый узел быть выбран для синхронизации. |
|||||||||||||||||||||||||||
insane |
Проверки правильности не пройдены, поэтому время от данного сервера не принимается. Сервер не синхронизирован. |
|||||||||||||||||||||||||||
valid |
Время однорангового узла или сервера допустимо. Локальный клиент принимает это время, если данный одноранговый узел становится тактовым генератором. |
|||||||||||||||||||||||||||
invalid |
Время на одноранговом узле или сервере недопустимо, и это время не будет принято. |
|||||||||||||||||||||||||||
ref ID |
Каждому одноранговому узлу или серверу назначается ссылочный идентификатор (метка). |
|||||||||||||||||||||||||||
time |
Это последняя метка времени, полученная от данного однорангового узла или сервера. |
|||||||||||||||||||||||||||
our mode/ peer mode |
Это состояние локального клиента или однорангового узла. |
|||||||||||||||||||||||||||
our poll intvl/ peer poll intvl |
Это интервал опроса от нашей системы к данному одноранговому узлу или от этого однорангового узла к локальной системе. |
|||||||||||||||||||||||||||
root delay |
Корневая задержка — это задержка в миллисекундах к корневому устройству настройки NTP. Часы с уровнем 1 считаются корневыми в настройке или схеме NTP. В данном примере все три сервера могут быть корневыми, поскольку находятся в уровне 1. |
|||||||||||||||||||||||||||
root dispersion |
Корневая дисперсия — это максимальная разница во времени, которая когда-либо наблюдалась между локальными и корневыми часами. Дополнительную информацию см. в разъяснении значения disp, приведенном в разделе show ntp association. |
|||||||||||||||||||||||||||
sync dist. |
Это оценка максимального различия между временем в источнике с уровнем 0 и временем, измеренным клиентом; формируется из значений времени прохождения сигнала в прямом и обратном направлении, точности системы и дрейфа показаний часов, начиная с последнего фактического значения на источнике уровня. В крупномасштабной среде NTP (серверы NTP в страте 1 в Интернете с серверами, являющимися источниками времени в других стратах) с серверами/клиентами в нескольких стратах топология синхронизации NTP должна быть организована таким образом, чтобы достичь высочайшей точности, однако нельзя допустить формирование петли синхронизации времени. Дополнительным фактором является то, что в каждом добавленном уровне имеется потенциально ненадежный сервер синхронизации времени, который вносит дополнительные ошибки измерения. Алгоритм выбора, используемый в NTP, включает вариант алгоритма распределенной маршрутизации Беллмана — Форда для вычисления связующих деревьев минимального веса с привязкой к основным серверам. Критерий расстояния, используемый этим алгоритмом, состоит из уровня и расстояния синхронизации, которое в свою очередь состоит из дисперсии и половины абсолютной задержки. Таким образом, путь синхронизации всегда проходит через минимальное количество серверов до корневого сервера; связи определяются на основе максимальной ошибки. |
|||||||||||||||||||||||||||
delay |
Это задержка прохождения сигнала в прямом и обратном направлении до однорангового узла. |
|||||||||||||||||||||||||||
precision |
Это точность часов однорангового узла в Гц. |
|||||||||||||||||||||||||||
version |
Это номер версии NTP, используемой одноранговым узлом. |
|||||||||||||||||||||||||||
org time |
Это метка времени источника пакета NTP; другими словами, это метка времени данного однорангового узла в момент создания пакета NTP, но до отправки пакета локальному клиенту. |
|||||||||||||||||||||||||||
rcv time |
Это метка времени в момент получения сообщения локальным клиентом. Различие между значениями org time и rcv time представляет собой смещение для данного однорангового узла. В этом примере у сервера времени 10.4.2.254 есть следующие значения времени: org time D36968B7.E74172BF (02:11:03.903 UTC Fri May 25 2012) Разница между ними — это смещение в 268,3044 мс. |
|||||||||||||||||||||||||||
xmt time |
Это метка времени передачи для пакета NTP, который локальный клиент отправляет данному одноранговому узлу или серверу. |
|||||||||||||||||||||||||||
filtdelay |
Это задержка при прохождении пакета в прямом и обратном направлении в миллисекундах для каждой выборки. Выборка является последним полученным пакетом NTP. В данном примере у сервера времени 10.4.2.254 есть следующие значения: filtdelay = 2.99 2.88 976.61 574.65 984.71 220.26 168.12 2.72 Эти восемь выборок соответствуют значению поля достижимости, которое показывает, получил ли локальный клиент последние восемь пакетов NTP. |
show ntp status
Вот пример выходных данных команды show ntp status:
USSP-B33S-SW01#sho ntp status
Clock is synchronized, stratum 2, reference is 10.4.2.254
nominal freq is 250.0000 Hz, actual freq is 250.5630 Hz, precision is 2**18
reference time is D36968F7.7E3019A9 (02:12:07.492 UTC Fri May 25 2012)
clock offset is 417.2868 msec, root delay is 2.85 msec
root dispersion is 673.42 msec, peer dispersion is 261.80 msec
Термины, уже определенные в разделах show ntp association и show ntp association details, не повторяются.
| Термин | Пояснение |
|---|---|
precision |
Точность определяется автоматически и измеряется в виде степени числа 2. В данном примере 2**18 означает 2^(-18), или 3,8 микросекунды. Потеря синхронизации между одноранговыми узлами NTP или между сервером времени и клиентом может произойти по многим причинам. В NTP синхронизация с компьютером, время которого могло бы быть неоднозначным, предотвращается следующими способами:
|
Поиск и устранение неполадок NTP с помощью отладки
Вот некоторые наиболее распространенные причины неполадок в работе NTP:
- Пакеты NTP не получены.
- Пакеты NTP получены, но не обработаны процессом NTP в IOS.
- Пакеты NTP обработаны, но ошибочные показатели или данные пакета приводят к потере синхронизации.
- Период тактовых импульсов NTP установлен вручную.
Вот важные команды отладки, которые позволяют выявить причину этих неполадок:
- debug ip packets <acl>
- debug ntp packets
- debug ntp validity
- debug ntp sync
- debug ntp events
В следующих разделах иллюстрируется использование отладок для устранения этих распространенных неполадок.
Пакеты NTP не получены
Используйте команду debug ip packet, чтобы проверить, происходит ли получение и передача пакетов NTP. Так как выходные данные команды отладки могут быть обширными, можно ограничить их с помощью списков контроля доступа (ACL). NTP использует порт 123 протокола пользовательских датаграмм (UDP).
- Создайте ACL 101:
access-list 101 permit udp any any eq 123
Пакеты NTP обычно имеют порт источника и порт назначения 123; это будет полезно:
access-list 101 permit udp any eq 123 any
permit udp any eq 123 any eq 123
- Используйте этот ACL-список для ограничения выходных данных команды debug ip packet:
debug ip packet 101
- Если неполадка связана с конкретными одноранговыми узлами, сузьте ACL 101 до этих узлов. Если адрес однорангового узла — 172.16.1.1, измените ACL 101 следующим образом:
access-list 101 permit udp host 172.16.1.1 any eq 123
access-list 101 permit udp any eq 123 host 172.16.1.1
Выходные данные в этом примере указывают, что пакеты не отправляются:
241925: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76,
input feature
241926: Apr 23 2012 15:46:26.101 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0,
forus FALSE, sendself FALSE, mtu 0
241927: Apr 23 2012 15:46:26.101 ETE: IP: s=10.50.38.70 (Tunnel99), d=10.50.44.101, len 76,
input feature
241928: Apr 23 2012 15:46:26.101 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0,
forus FALSE, sendself FALSE, mtu 0
Как только вы подтвердите, что пакеты NTP не получены, необходимо сделать следующее:
- Проверьте, правильно ли настроен NTP.
- Проверьте, не блокирует ли ACL-список пакеты NTP.
- Проверьте наличие проблем маршрутизации к IP-адресу источника или назначения.
Пакеты NTP не обрабатываются
Если включены команды debug ip packet и debug ntp packets, можно увидеть получаемые и передаваемые пакеты, а также действия NTP с этими пакетами. Для каждого полученного пакета NTP (как показано командой debug ip packet) существует соответствующая запись, создаваемая командой debug ntp packets.
Вот выходные данные отладки, когда процесс NTP обрабатывает полученные пакеты:
Apr 20 00:16:34.143 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), routed
via FIB
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:34.143 UTC: IP: s=10.3.2.31 (local), d=10.1.2.254 (Vlan2), len 76, sending
full packet
.Apr 20 00:16:34.143 UTC: NTP: xmit packet to 10.1.2.254:
.Apr 20 00:16:34.143 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0021 (0.504), rtdsp 1105E7 (17023.056), refid 0A0102FE
(10.1.2.254)
.Apr 20 00:16:34.143 UTC: ref D33B2922.24FEBDC7 (00:15:30.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: IP: s=10.1.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:34.143 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:34.143 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:34.143 UTC: rtdel 0000 (0.000), rtdsp 009D (2.396), refid 47505300 (71.80.83.0)
.Apr 20 00:16:34.143 UTC: ref D33B2952.4CC11CCF (00:16:18.299 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: org D33B2962.24CAFAD1 (00:16:34.143 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: rec D33B2962.49D3724D (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: xmt D33B2962.49D997D0 (00:16:34.288 UTC Fri Apr 20 2012)
.Apr 20 00:16:34.143 UTC: inp D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: tableid=0, s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), routed
via FIB
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
.Apr 20 00:16:36.283 UTC: IP: s=10.3.2.31 (local), d=10.8.2.254 (Vlan2), len 76, sending
full packet
.Apr 20 00:16:36.283 UTC: NTP: xmit packet to 10.8.2.254:
.Apr 20 00:16:36.283 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 002F (0.717), rtdsp 11058F (17021.713), refid 0A0102FE
(10.1.2.254)
.Apr 20 00:16:36.283 UTC: ref D33B2962.25010310 (00:16:34.144 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: IP: s=10.8.2.254 (Vlan2), d=10.3.2.31, len 76, rcvd 2
.Apr 20 00:16:36.283 UTC: NTP: rcv packet from 10.8.2.254 to 10.3.2.31 on Vlan2:
.Apr 20 00:16:36.283 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.Apr 20 00:16:36.283 UTC: rtdel 0000 (0.000), rtdsp 0017 (0.351), refid 47505300 (71.80.83.0)
.Apr 20 00:16:36.283 UTC: ref D33B295B.8AF7FE33 (00:16:27.542 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: org D33B2964.48947E87 (00:16:36.283 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: rec D33B2964.4A6AD269 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: xmt D33B2964.4A7C00D0 (00:16:36.290 UTC Fri Apr 20 2012)
.Apr 20 00:16:36.283 UTC: inp D33B2964.498A755D (00:16:36.287 UTC Fri Apr 20 2012)
Вот пример, когда NTP не обрабатывает полученные пакеты. Несмотря на то что пакеты NTP получены (как показывает команда debug ip packet), процесс NTP не обрабатывает их. Для отправленных пакетов NTP представлены соответствующие выходные данные команды debug ntp packets, поскольку процесс NTP должен сгенерировать пакет. Эта неполадка характерна для полученных пакетов NTP, которые не обрабатываются.
071564: Apr 23 2012 15:46:26.100 ETE: NTP: xmit packet to 10.50.44.101:
071565: Apr 23 2012 15:46:26.100 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071566: Apr 23 2012 15:46:26.100 ETE: rtdel 07B5 (30.106), rtdsp 0855 (32.547), refid 0A32266A
(10.50.38.106)
071567: Apr 23 2012 15:46:26.100 ETE: ref D33FDB05.1A084831 (15:43:33.101 ETE Mon Apr 23 2012)
071568: Apr 23 2012 15:46:26.100 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071569: Apr 23 2012 15:46:26.100 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071570: Apr 23 2012 15:46:26.100 ETE: xmt D33FDBB2.19D3457C (15:46:26.100 ETE Mon Apr 23 2012)
PCY_PAS1#
071571: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071572: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0,
forus FALSE, sendself FALSE, mtu 0
071573: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071574: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0,
forus FALSE, sendself FALSE, mtu 0
071575: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src
10.50.38.78 dst 10.50.44.69
071576: Apr 23 2012 15:47:31.497 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071577: Apr 23 2012 15:47:31.497 ETE: FIBipv4-packet-proc: packet routing failed
071578: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071579: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123
071580: Apr 23 2012 15:47:31.497 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop
process pak for forus packet
071581: Apr 23 2012 15:47:31.497 ETE: UDP src=123, dst=123
PCY_PAS1#
071582: Apr 23 2012 16:03:30.105 ETE: NTP: xmit packet to 10.50.44.101:
071583: Apr 23 2012 16:03:30.105 ETE: leap 0, mode 1, version 3, stratum 5, ppoll 1024
071584: Apr 23 2012 16:03:30.105 ETE: rtdel 0759 (28.702), rtdsp 087D (33.157), refid 0A32266A
(10.50.38.106)
071585: Apr 23 2012 16:03:30.105 ETE: ref D33FDF05.1B2CC3D4 (16:00:37.106 ETE Mon Apr 23 2012)
071586: Apr 23 2012 16:03:30.105 ETE: org 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071587: Apr 23 2012 16:03:30.105 ETE: rec 00000000.00000000 (01:00:00.000 HIVER Mon Jan 1 1900)
071588: Apr 23 2012 16:03:30.105 ETE: xmt D33FDFB2.1B1D5E7E (16:03:30.105 ETE Mon Apr 23 2012)
PCY_PAS1#
071589: Apr 23 2012 16:04:35.502 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071590: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123, Ingress-NetFlow(13), rtype 0,
forus FALSE, sendself FALSE, mtu 0
071591: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76,
input feature
071592: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123, MCI Check(55), rtype 0, forus
FALSE, sendself FALSE, mtu 0
071593: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: route packet from Tunnel99 src
10.50.38.78 dst 10.50.44.69
071594: Apr 23 2012 16:04:35.506 ETE: FIBfwd-proc: base:10.50.44.69/32 receive entry
PCY_PAS1#
071595: Apr 23 2012 16:04:35.506 ETE: FIBipv4-packet-proc: packet routing failed
071596: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, rcvd 2
071597: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123
071598: Apr 23 2012 16:04:35.506 ETE: IP: s=10.50.38.78 (Tunnel99), d=10.50.44.69, len 76, stop
process pak for forus packet
071599: Apr 23 2012 16:04:35.506 ETE: UDP src=123, dst=123
PCY_PAS1#
Потеря синхронизации
Потеря синхронизации может произойти, если значение дисперсии и/или задержки для сервера оказывается очень большим. Большие значения указывают, что пакеты слишком долго перемещаются от сервера или однорангового узла до клиента по отношению к источнику синхросигналов. Итак, локальный компьютер не может доверять точности времени, представленного в пакете, поскольку не знает, как долго передавался пакет.
Протокол NTP скрупулезен в отношении времени и не будет выполнять синхронизацию с другим устройством, которому не может доверять или не может скорректировать так, чтобы ему можно было доверять.
Если канал загружен и по пути выполняется буферизация, возникает задержка пакетов при доставке клиенту NTP. Поэтому метка времени в последующем пакете NTP может иногда очень сильно отличаться, и локальный клиент не может скорректировать это различие.
Отключить проверку таких пакетов в NTP можно только при использовании SNTP (простой сетевой протокол синхронизации времени). SNTP не может по большей части считаться альтернативным вариантом, поскольку не имеет широкой поддержки в программном обеспечении.
Столкнувшись с потерей синхронизации, необходимо проверить каналы связи:
- Они перегружены?
- Есть ли отбрасывание пакетов в ваших каналах глобальной сети (WAN)
- Выполняется ли шифрование?
Контролируйте значение достижимости с помощью команды show ntp associations detail. Самое большое значение — 377. Если значение равно 0 или мало, пакеты NTP поступают с перебоями, а локальный клиент теряет синхронизацию с сервером.
debug ntp validity
Команда debug ntp validity указывает, если пакет NTP не прошел проверку правильности или достоверности, а также причину сбоя. Сравните эти выходные данные с проверками правильности, указанными в RFC1305, которые используются для проверки пакета NTP, полученного от сервера. Определены восемь проверок:
| Проверка | Маска | Пояснение |
|---|---|---|
| 1 | 0x01 | Получен дубликат пакета |
| 2 | 0x02 | Получен поддельный пакет |
| 3 | 0x04 | Протокол не синхронизирован |
| 4 | 0x08 | Задержка или дисперсия однорангового узла не прошла проверку граничных условий |
| 5 | 0x10 | Сбой аутентификации однорангового узла |
| 6 | 0x20 | Часы однорангового узла не синхронизированы (характерно для несинхронизированного сервера) |
| 7 | 0x40 | Уровень однорангового узла вне пределов |
| 8 | 0x80 | Задержка или дисперсия корневого узла не прошла проверку граничных условий |
Вот пример выходных данных команды debug ntp validity:
PCY_PAS1#debug ntp validity
NTP peer validity debugging is on
009585: Mar 1 2012 09:14:32.670 HIVER: NTP: packet from 192.196.113.57 failed validity tests 52
009586: Mar 1 2012 09:14:32.670 HIVER: Authentication failed
009587: Mar 1 2012 09:14:32.670 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009588: Mar 1 2012 09:14:38.210 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009589: Mar 1 2012 09:14:38.210 HIVER: Authentication failed
PCY_PAS1#
009590: Mar 1 2012 09:14:43.606 HIVER: NTP: packet from 163.110.103.27 failed validity tests 14
009591: Mar 1 2012 09:14:43.606 HIVER: Authentication failed
PCY_PAS1#
009592: Mar 1 2012 09:14:48.686 HIVER: NTP: packet from 192.196.113.57 failed validity tests 52
009593: Mar 1 2012 09:14:48.686 HIVER: Authentication failed
009594: Mar 1 2012 09:14:48.686 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009596: Mar 1 2012 09:14:54.222 HIVER: NTP: packet from 163.110.103.35 failed validity tests 14
009597: Mar 1 2012 09:14:54.222 HIVER: Authentication failed
PCY_PAS1#
009598: Mar 1 2012 09:14:54.886 HIVER: NTP: synced to new peer 10.50.38.106
009599: Mar 1 2012 09:14:54.886 HIVER: NTP: 10.50.38.106 synced to new peer
PCY_PAS1#
009600: Mar 1 2012 09:14:59.606 HIVER: NTP: packet from 163.110.103.27 failed validity tests 14
009601: Mar 1 2012 09:14:59.606 HIVER: Authentication failed
PCY_PAS1#
009602: Mar 1 2012 09:15:04.622 HIVER: NTP: packet from 192.196.113.137 failed validity tests 52
009603: Mar 1 2012 09:15:04.622 HIVER: Authentication failed
009604: Mar 1 2012 09:15:04.622 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009605: Mar 1 2012 09:15:10.238 HIVER: NTP: packet from 192.168.56.1 failed validity tests 14
009606: Mar 1 2012 09:15:10.238 HIVER: Authentication failed
PCY_PAS1#
009607: Mar 1 2012 09:15:15.338 HIVER: NTP: packet from 163.83.23.140 failed validity tests 52
009608: Mar 1 2012 09:15:15.338 HIVER: Authentication failed
009609: Mar 1 2012 09:15:15.338 HIVER: Peer/Server Stratum out of bound
PCY_PAS1#
009610: Mar 1 2012 09:15:20.402 HIVER: NTP: packet from 192.196.113.92 failed validity tests 74
009611: Mar 1 2012 09:15:20.402 HIVER: Authentication failed
009612: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Clock unsynchronized
009613: Mar 1 2012 09:15:20.402 HIVER: Peer/Server Stratum out of bound
debug ntp packets
Можно использовать команду debug ntp packets, чтобы просмотреть время, предоставленное одноранговым узлом или сервером в полученном пакете. Локальный компьютер синхронизации времени также сообщает известное ему время одноранговому узлу или серверу в передаваемом пакете.
| Поле | пакет rcv | пакет xmit |
|---|---|---|
| org | Метка времени отправителя пакета, которая представляет собой время сервера. | Метка времени отправителя (клиента) при отправке пакета. (Клиент отправляет пакет на сервер. |
| rec | Метка времени на клиенте при получении пакета. | Текущее время клиента. |
В этом примере выходных данных метки времени в пакете, полученном от сервера, и пакете, отправленном на другой сервер, одинаковы; это указывает, что NTP клиент синхронизирован.
USSP-B33S-SW01#debug ntp packets
NTP packets debugging is on
USSP-B33S-SW01#
May 25 02:21:48.182 UTC: NTP: rcv packet from 10.1.2.254 to 10.3.2.31 on Vlan2:
May 25 02:21:48.182 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:21:48.182 UTC: rtdel 0000 (0.000), rtdsp 00F2 (3.693), refid 47505300 (71.80.83.0)
May 25 02:21:48.182 UTC: ref D3696B38.B722C417 (02:21:44.715 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: org D3696B3C.2EA179BA (02:21:48.182 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: rec D3696B3D.E58DE1BE (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: xmt D3696B3D.E594E7AF (02:21:49.896 UTC Fri May 25 2012)
May 25 02:21:48.182 UTC: inp D3696B3C.2EDFC333 (02:21:48.183 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:22:46.051 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:22:46.051 UTC: rtdel 00C0 (2.930), rtdsp 1C6FA (1777.252), refid 0A0402FE (10.4.2.254)
May 25 02:22:46.051 UTC: ref D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: org D3696B37.E72C75AE (02:21:43.903 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: rec D3696B36.33D43F44 (02:21:42.202 UTC Fri May 25 2012)
May 25 02:22:46.051 UTC: xmt D3696B76.0D43AE7D (02:22:46.051 UTC Fri May 25 2012)
Вот пример выходных данных, когда часы не синхронизированы. Обратите внимание на разницу во времени между пакетами xmit и rcv. Дисперсия однорангового узла будет иметь максимальное значение в 16000. Кроме того, для узла будет указана достижимость 0.
USSP-B33S-SW01#
.May 25 02:05:59.011 UTC: NTP: xmit packet to 10.4.2.254:
.May 25 02:05:59.011 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 00A3 (2.487), rtdsp 1104D0 (17018.799), refid 0A0402FE
(10.4.2.254)
.May 25 02:05:59.011 UTC: ref D3696747.03D8661A (02:04:55.015 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
.May 25 02:05:59.011 UTC: xmt D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
.May 25 02:05:59.011 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
.May 25 02:05:59.011 UTC: rtdel 0000 (0.000), rtdsp 0014 (0.305), refid 47505300 (71.80.83.0)
.May 25 02:05:59.011 UTC: ref D3696782.C96FD778 (02:05:54.786 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: org D3696787.03105783 (02:05:59.011 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: rec D3696787.281A963F (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: xmt D3696787.282832C4 (02:05:59.156 UTC Fri May 25 2012)
.May 25 02:05:59.011 UTC: inp D3696787.03C63542 (02:05:59.014 UTC Fri May 25 2012)
debug ntp sync and debug ntp events
Команда debug ntp sync формирует выходные данные, состоящие из одной строки, которые показывают, синхронизированы ли часы, или синхронизация изменилась. Эта команда обычно выполняется вместе с командой debug ntp events.
Команда debug ntp events показывает все происходящие события NTP, что помогает определить, не привело ли изменение в NTP к неполадке, такой как нарушение синхронизации часов. (Другими словами, если ваши синхронизированные часы внезапно сходят с ума, вы знаете, что нужно искать изменение или триггер!
Вот пример обеих команд отладки. Первоначально клиентские часы были синхронизированы. Команда debug ntp events показывает, что произошло изменение на уровне однорангового узла NTP и синхронизация часов нарушилась.
USSP-B33S-SW01#debug ntp sync
NTP clock synchronization debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
USSP-B33S-SW01#debug ntp events
NTP events debugging is on
USSP-B33S-SW01#
USSP-B33S-SW01#
May 25 02:25:57.620 UTC: NTP: xmit packet to 10.4.2.254:
May 25 02:25:57.620 UTC: leap 0, mode 3, version 3, stratum 2, ppoll 64
May 25 02:25:57.620 UTC: rtdel 00D4 (3.235), rtdsp 26B26 (2418.549), refid 0A0402FE (10.4.2.254)
May 25 02:25:57.620 UTC: ref D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696BF7.E5F91077 (02:24:55.898 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696BF5.C47EB880 (02:24:53.767 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: NTP: rcv packet from 10.4.2.254 to 10.3.2.31 on Vlan2:
May 25 02:25:57.620 UTC: leap 0, mode 4, version 3, stratum 1, ppoll 64
May 25 02:25:57.620 UTC: rtdel 0000 (0.000), rtdsp 000E (0.214), refid 47505300 (71.80.83.0)
May 25 02:25:57.620 UTC: ref D3696C37.D528800E (02:25:59.832 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: org D3696C35.9ED1CE97 (02:25:57.620 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: rec D3696C37.E5C7AB3D (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: xmt D3696C37.E5D1F273 (02:25:59.897 UTC Fri May 25 2012)
May 25 02:25:57.620 UTC: inp D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:25:59.830 UTC: NTP: clock reset
May 25 02:25:59.830 UTC: NTP: sync change
May 25 02:25:59.830 UTC: NTP: peer stratum change
May 25 02:26:05.817 UTC: NTP: xmit packet to 10.1.2.254:
May 25 02:26:05.817 UTC: leap 3, mode 3, version 3, stratum 0, ppoll 64
May 25 02:26:05.817 UTC: rtdel 00C2 (2.960), rtdsp 38E9C (3557.068), refid 0A0402FE (10.4.2.254)
May 25 02:26:05.817 UTC: ref D3696C35.9F9EA2C4 (02:25:57.623 UTC Fri May 25 2012)
May 25 02:26:05.817 UTC: org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
May 25 02:26:05.817 UTC: xmt D3696C3D.D12D0565 (02:26:05.817 UTC Fri May 25 2012)
Настройка периода тактовых импульсов NTP вручную
Веб-сайт Cisco.com предупреждает о следующем:
«Команда ntp clock-period формируется автоматически для отражения постоянно изменяющегося поправочного коэффициента, когда вводится команда copy running-configuration startup-configuration для сохранения конфигурации в NVRAM. Не пытайтесь использовать команду ntp clock-period вручную. Обязательно удалите строку с этой командой при копировании файлов конфигурации на другие устройства»
Значение периода тактовых импульсов зависит от аппаратного обеспечения и поэтому отличается для каждого устройства.
Команда ntp clock-period автоматически появляется в конфигурации при включении NTP. Эта команда используется для корректировки программных часов. Значение adjustment value компенсирует тактовый интервал до 4 мс, поэтому с такой незначительной коррекцией в конце интервала вы получите 1 секунду.
Если устройство вычислило, что его системные часы отстают (возможно, требуется компенсация частоты по сравнению с базовым уровнем маршрутизатора), это значение автоматически добавляется к показаниям системных часов для поддержания их синхронности.
Период тактовых импульсов NTP по умолчанию для маршрутизатора составляет 17179869 и главным образом используется для запуска процесса NTP.
Формула преобразования: 17179869 * 2^(-32) = 0.00399999995715916156768798828125, или приблизительно 4 миллисекунды.
Например, было обнаружено, что системные часы для маршрутизаторов Cisco 2611 (один из маршрутизаторов Cisco серии 2600) немного рассинхронизированы и их синхронизация могла быть восстановлена с помощью следующей команды:
ntp clock-period 17208078
Это соответствует 17208078 * 2^(-32) = 0.0040065678767859935760498046875, или немногим больше 4 миллисекунд.
Cisco рекомендует обеспечить работу маршрутизатора в течение приблизительно одной недели в нормальных сетевых условиях, а затем использовать команду wr mem, чтобы сохранить это значение. Это обеспечит точное значение для следующей перезагрузки и позволит ускорить синхронизацию NTP.
Не Не Не используйте команду ntp clock-period при сохранении конфигурации для использования на другом устройстве, поскольку эта команда восстановит значение по умолчанию для периода тактовых импульсов этого устройства. Настоящее значение будет вычислено повторно (но точность системных часов в течение периода повторного расчета уменьшится).
Помните, что это значение зависит от аппаратного обеспечения, поэтому использование скопированной конфигурации на других устройствах может приводить к неполадкам. Для устранения этой проблемы Cisco планирует заменить версию 3 протокола NTP версией 4.
Будучи неосведомленным об этих проблемах, вы можете решить исправить это значение вручную. Для перехода от одного устройства к другому вы можете решить скопировать старую конфигурацию и вставить ее на новое устройство. К сожалению, поскольку команда ntp clock-period приведена в конфигурациях running-config и startup-config, на новое устройство вставляется и период тактовых импульсов NTP. Когда это происходит, NTP на новом клиенте всегда теряет синхронизацию с сервером с высоким значением дисперсии однорангового узла.
Вместо этого очистите период тактовых импульсов NTP с помощью команды no ntp clock-period, а затем сохраните конфигурацию. Маршрутизатор в конечном счете вычислит подходящий для него период тактовых импульсов.
Команда ntp clock-period больше недоступна в ПО Cisco IOS версии 15.0 и более поздних версий; синтаксический анализатор теперь отклоняет эту команду со следующей ошибкой:
"%NTP: This configuration command is deprecated."
Поэтому нельзя настраивать период тактовых импульсов вручную. Кроме того, период тактовых импульсов не разрешен в running-config. Синтаксический анализатор отклоняет команду, если она присутствовала в конфигурации запуска (в более ранних версиях Cisco IOS, например в версии 12.4), при копировании конфигурации запуска в рабочую конфигурацию (running-config) в ходе загрузки.
Новая, заменяющая команда — ntp clear drift.
Дополнительные сведения
Обратная связь