Guest

Устранение проблем проблем протокола NTP и отладка руководства

Параметры загрузки

  • PDF     (194.5 KB)
    Просмотр в Adobe Reader на различных устройствах
  • ePub     (92.6 KB)
    Просмотр в различных приложениях на устройствах iPhone, iPad, Android, Sony Reader или Windows Phone
  • Mobi (Kindle)     (106.9 KB)
    Просмотр на устройстве Kindle или в приложении Kindle на нескольких устройствах
Обновлено:17 августа 2013 года
Идентификатор документа:116161
О переводе

Об этом переводе

Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.

Введение

Этот документ описывает использование отладок для решения проблем Протокола NTP, а также выходных данных от ключевых команд show ntp.

Команды показа NTP

Перед рассмотрением причины проблем NTP необходимо понять использование и вывести от этих команд:

  • ассоциация show ntp
  • show ntp association detail
  • show ntp status

Примечание: Чтобы получить подробные сведения о командах в данном документе, используйте Средство поиска команд (только для зарегистрированных клиентов).

Примечание: Средство интерпретации выходных данных (только зарегистрированные клиенты) поддерживает некоторые команды show. Используйте Средство интерпретации выходных данных, чтобы просмотреть анализ выходных данных команды show.

ассоциация show ntp

Сопоставление NTP может быть одноранговым сопоставлением (одна система готова синхронизироваться с другой системой или позволить, что другая система для синхронизации с ним) или ассоциация сервера (только одна система синхронизируется с другой системой а не наоборот).

Это - пример вывода от команды ассоциации show ntp:

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 master синхронизирует с собой.

касательно часов

Это - адрес системных часов для узла. В примере первые шесть узлов/серверов имеют частное IP как системные часы, таким образом, их ведущие устройства являются, вероятно, маршрутизаторами, коммутаторами или серверами в локальной сети. Для последних четырех записей системные часы являются общим IP, таким образом, их ведущие устройства являются, вероятно, общим источником времени.

Св.

NTP использует понятие страты, чтобы описать, как далеко далеко (в переходах NTP) машина от надежного источника времени. Например, страта 1 временной сервер имеет радиочасы или атомные часы, непосредственно подключенные к нему. Это передает свое время к страте 2 временных сервера через NTP, и так далее до страты 16. Рабочий NTP машины автоматически выбирает машину с самым низким номером страты, с которым это может связаться и NTP использования как его источник времени.

когда

Время начиная с последнего пакета NTP было получено от узла, сообщается в секундах. Это значение должно быть ниже, чем интервал опроса.

опрос

Об интервале опроса сообщают в секундах. Интервал обычно запускается с минимума 64-секундных интервалов опроса. RFC указывает, что не больше, чем одна транзакция в минуту NTP необходима для синхронизации двух машин. Поскольку NTP становится стабильным между клиентом и сервером, интервал опроса может увеличить в маленьких шагах с 64 секунд до 1024 секунд и обычно стабилизировался где-нибудь промежуточный. Но, это значение динамично изменяется, на основе состояний сети между клиентом и сервером и потерей пакетов NTP. Если сервер недостижим в течение некоторого времени, интервал опроса увеличен в шагах в 1024 секунды для сокращения служебных данных сети.

Не возможно отрегулировать интервал опроса NTP на маршрутизаторе, потому что внутреннее определено эвристическими алгоритмами.

достигнуть

Доступность однорангового узла является небольшим количеством строки, сообщил как восьмеричное значение. Это поле показывает, были ли последние восемь пакетов получены процессом NTP на программном обеспечении Cisco IOS. Пакеты должны быть получены, обработаны, и приняты как допустимые процессом NTP и не только маршрутизатором или переключиться, который получает пакеты IP NTP.

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

В примере существует четыре других значения досягаемости:

  • 377 восьмеричных = 11111111 двоичных файлов, которые указывают на процесс NTP, получили последние восемь пакетов.
  • 0 восьмеричных = 00000000, который указывает на процесс NTP, не получили пакета.
  • 1 восьмеричное = 00000001, который указывает на процесс NTP, получило только последний пакет.
  • Были потеряны 357 восьмеричных = 11101111, который указывает на пакет перед последними четырьмя пакетами.

Досягаемость является хорошим индикатором того, отбрасываются ли пакеты NTP из-за плохой ссылки, проблем ЦП и других периодических проблем.

Преобразуйте восьмеричный <->, двоичные файлы являются онлайновым преобразователем модуля для этого и многих других преобразований.

задержка

О задержке приема-передачи для пиринга сообщают в миллисекундах. Когда время синхронизации установлено, для установки часов более точно, эта задержка принята во внимание.

смещение

Смещение является различием времени синхронизации между узлами или между ведущим устройством и клиентом. Это значение является исправлением, которое применено к клиентским часам для синхронизации его. Положительное значение указывает, что часы сервера выше. Отрицательное значение указывает, что клиентские часы выше.

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
~10.50.44.69 10.50.36.106  5 21231 1024  0   3.8  -4.26 16000.

Даже при том, что смещение всего-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, не повторены.

Условие

 Пояснение

настроенный

Этот источник синхронизации NTP был настроен, чтобы быть сервером. Это значение может также быть динамичным, где был динамично обнаружен узел/сервер.

our_master

Локальный клиент синхронизируется с этим узлом.

выбранный

Когда сбои 'our_master' или клиент теряют синхронизование, узел/сервер выбран для возможной синхронизации.

нормальный

Тесты здравомыслия используются для тестирования пакета NTP, полученного от сервера. Эти тесты заданы в RFC 1305, Протокол сетевого времени (Версия 3) Спецификация, Реализация и Анализ . Тесты:

Тест Маска Пояснение
1 0x01 Повторяющийся пакет получен
2 0x02 Поддельный пакет получен
3 0x04 Несинхронизованный протокол
4 0x08 Одноранговая задержка/дисперсия отказала граничную проверку
5 0x10 Аутентификация однорангового узла отказала
6 0x20 Одноранговые несинхронизованные часы (характерный для несинхронизованного сервера)
7 0x40 Одноранговая страта из связанного
8 0x80 Корневая задержка/дисперсия отказала граничную проверку

Если тесты 1 - 4 проходятся, данные пакета допустимы. Данные тогда используются для вычисления смещения, задержки и дисперсии.

Если тесты 5 - 8 проходятся, заголовок пакета допустим. Только пакеты с допустимым заголовком могут использоваться, чтобы определить, может ли узел быть выбран для синхронизации.

безумный

Проверки работоспособности отказали, таким образом, не принято время от сервера. Сервер не синхронизован.

допустимый

Узел/время на сервере допустим. Если этот узел становится ведущим устройством, локальный клиент принимает на этот раз.

недопустимый

Узел/время на сервере недопустим, и время не будет принято.

касательно ID

Каждому узлу/серверу назначают ссылочный ID (метка).

время

Время прошлый раз штамп, полученный от того узла/сервера.

наш режим / одноранговый режим

Это - состояние локального клиента / узел.

наш опрос intvl/узел опрашивает intvl

Это - интервал опроса от нашего опроса до этого узла или с узла на локальный компьютер.

корневая задержка

Корневая задержка является задержкой миллисекунд к root настройки NTP. Страта 1 часы, как полагают, в root настройки/дизайна NTP. В примере все три сервера могут быть root, потому что они в страте 1.

корневая дисперсия

Корневая дисперсия является разницей во времени максимальной ошибки датчика синхронизирующих импульсов, которая когда-либо наблюдалась между локальными часами и корневыми часами. См. пояснение 'disp' под show ntp ассоциация разделяют для получения дополнительной информации.

синхронизование dist.

Это - оценка максимального несовпадения между временем на страте 0 источников и время, измеренное клиентом; это состоит из компонентов в течение Round Trip Time, системной точности и ухода часов начиная с последнего фактического чтения источника страты.

В большой настройке NTP (Серверы NTP в страте 1 в Интернете, с серверами, что исходное время в других стратах) с серверами/клиентами во множественных стратах, должна быть организована топология синхронизации NTP, чтобы произвести самую высокую точность, но никогда не должна разрешаться сформировать петлю синхронизования времени. Дополнительный фактор - то, что каждый инкремент в страте включает потенциально ненадежный временной сервер, который представляет ошибки дополнительного измерения. Алгоритм выбора, используемый в NTP, использует вариант распределенного алгоритма маршрутизации Форда Белмана для вычислений связующих деревьев минимального веса, базированных на основных серверах. Метрика расстояния, используемая алгоритмом, состоит из страты плюс расстояние синхронизации, которое само состоит из дисперсии плюс половина абсолютной задержки. Таким образом путь синхронизации всегда берет минимальный номер серверов к root; связи решены на основе максимальной ошибки.

задержка

Это - задержка приема-передачи для пиринга.

precision

Это - точность одноранговых часов в Гц.

version

Это - номер версии NTP, используемый узлом.

время org

Это - штамп времени инициатора пакета NTP; другими словами, это - штамп времени этого узла, когда это создало пакет NTP, но прежде чем это передало пакет локальному клиенту.

время rcv

Когда локальный клиент получил сообщение, это - штамп времени. Различием между временем org и rcv временем является смещение для этого узла. В примере у ведущего устройства 10.4.2.254 есть эти времена:

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)

Различием является смещение 268.3044 мс.

время xmt

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

filtdelay
filtoffset
filterror

Это - задержка приема-передачи в миллисекундах каждой выборки.
Это - смещение часов в миллисекундах каждой выборки.
Это - приблизительная ошибка каждой выборки.

Выборка является последним полученным пакетом NTP. В примере у ведущего устройства 10.4.2.254 есть эти значения:

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

Эти восемь выборок соответствуют значению поля досягаемости, которое показывает, получил ли локальный клиент последние восемь пакетов 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 или подробном разделе ассоциации show ntp, не повторены.

Условие Пояснение

precision

Точность определена автоматически и измерена как питание два. В примере, 2 ** 18 средств 2^ (-18), или 3.8 микросекунды.

Потеря синхронизации между Ntp peer или между ведущим устройством и клиентом может произойти из-за множества причин. NTP избегает синхронизации с машиной, время которой могло бы быть неоднозначным этими способами:

  1. NTP никогда не синхронизируется с машиной, которая "not synchronized" самой.
  2. NTP сравнивает время, о котором сообщают несколько машин и не синхронизируется с машиной, время которой существенно отличается от других, даже если его страта ниже.

Устранение проблем NTP с отладками

Некоторые наиболее распространенные причины проблем NTP:

  • Пакеты NTP не получены.
  • Пакеты NTP получены, но не обработаны процессом NTP на IOS.
  • Пакеты NTP обработаны, но ошибочные факторы или данные пакета вызывают потерю синхронизации.
  • NTP clock-period вручную установлен.

Важные команды отладки, которые помогают изолировать причину этих проблем, включают:

  • <acl> debug ip packet
  • пакеты debug ntp
  • законность debug ntp
  • синхронизование debug ntp
  • события debug ntp

Следующие разделы иллюстрируют использование отладок для решения этих общих проблем.

Примечание: Чтобы получить подробные сведения о командах в данном документе, используйте Средство поиска команд (только для зарегистрированных клиентов).

Примечание: Обратитесь к документу Важная информация о командах отладки, прежде чем использовать команды debug.

Пакеты NTP, не полученные

Используйте команду debug ip packet, чтобы проверить, получены ли пакеты NTP и переданы. Так как выходные данные отладки могут быть болтливыми, можно ограничить выходные данные отладки с использованием Списков контроля доступа (ACL). NTP использует порт протокола пользовательских датаграмм (UDP) 123.

  1. Создайте ACL 101:

    access-list 101 permit udp any any eq 123
    access-list 101 permit udp any eq 123 any
    Пакеты NTP обычно имеют порт источника и порт назначения 123, таким образом, это помогает:

    permit udp any eq 123 any eq 123
  2. Используйте этот ACL для ограничения выходных данных от команды debug ip packet:

    debug ip packet 101
  3. Если проблема с конкретными одноранговыми узлами, сузьте 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 включил, вы видите пакеты, которые получаются и передаются, и вы видите, что NTP реагирует на те пакеты. Для каждого полученного пакета NTP (как показано debug ip packet), существует соответствующая запись, генерируемая пакетами debug ntp.

Это - выходные данные отладки когда процессуальные работы 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, потому что процесс 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#

Потеря синхронизации

Если дисперсия и/или значение задержки для сервера идут очень высоко, потеря синхронизации могла бы произойти. Максимальные значения указывают, что пакеты занимают слишком много времени добираться до клиента от сервера/узла в отношении root часов. Так, локальный компьютер не может доверять точности подарка времени в пакете, потому что это не знает, сколько времени это взяло для пакета для получения здесь.

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

Если существует насыщенный канал, и буферизация происходит по пути, пакеты задержаны, когда они прибывают к клиенту NTP. Так, метка времени, содержавшаяся в последующем пакете NTP, может иногда варьироваться много, и локальный клиент не может действительно отрегулировать для того различия.

NTP не предлагает метод для выключения проверки этих пакетов, пока вы не используете SNTP (Простой сетевой протокол синхронизации времени). SNTP может не быть большой частью альтернативы, потому что это широко не поддерживается в программном обеспечении.

При испытании потери синхронизации необходимо проверить ссылки:

  • Они насыщаются?
  • Есть ли любые виды падений ваших ссылок глобальной сети (WAN)
  • Шифрование происходит?

Контролируйте значение досягаемости от команды show ntp associations detail. Самое высокое значение 377. Если значение 0 или низко, пакеты NTP получаются периодически, и локальный клиент выходит из синхронизования с сервером.

законность debug ntp

Команда законности debug ntp указывает, отказал ли пакет NTP здравомыслие или проверки достоверности и показывает причину для сбоя. Сравните эти выходные данные с тестами здравомыслия, заданными в RFC1305, которые используются для тестирования пакета NTP, полученного от сервера. Определены восемь тестов:

Тест Маска Пояснение
1 0x01 Повторяющийся пакет получен
2 0x02 Поддельный пакет получен
3 0x04 Несинхронизованный протокол
4 0x08 Одноранговая задержка/дисперсия отказала граничную проверку
5 0x10 Аутентификация однорангового узла отказала
6 0x20 Одноранговые несинхронизованные часы (характерный для несинхронизованного сервера)
7 0x40 Одноранговая страта из связанного
8 0x80 Корневая задержка/дисперсия отказала граничную проверку

Это - пример выходных данных от команды законности debug ntp:

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

Можно использовать пакетную команду debug ntp для наблюдения времени, когда узел/сервер дает вам в полученном пакете. Локальный компьютер времени также определяет время, которое он знает к узлу/серверу в передаваемом пакете.

Поле Пакет 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 пакетом. Одноранговая дисперсия будет в Max. значении 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 debug ntp

Команда sync debug ntp производит одноканальные выходные данные, которые показывают, синхронизировали ли часы, или синхронизование изменилось. Команда обычно выполняется с событиями debug ntp.

Команда событий debug ntp показывает любые события NTP, которые происходят, который помогает вам определять, инициировало ли изменение в NTP проблему, такую как часы, выходящие из синхронизования. (Другими словами, если ваши счастливо синхронизованные часы внезапно сходят с ума, вы знаете, чтобы посмотреть для разнообразия или инициировать!)

Это - пример обеих отладок. Первоначально, клиентские часы синхронизировались. Команда событий debug ntp показывает, что изменение страты NTP peer произошло, и часы тогда вышли из синхронизования.

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 clock-period Вручную Набор

Веб - сайт cisco.com предупреждает что:

"Команда ntp clock-period автоматически генерируется для отражения постоянно изменяющегося поправочного коэффициента, когда команда copy running-configuration startup-configuration введена для сохранения конфигурации к NVRAM. Не пытайтесь вручную использовать команду ntp clock-period. Гарантируйте удаление этой командной строки при копировании файлов конфигурации к другим устройствам".

Значение такта зависит от аппаратных средств, таким образом, это отличается для каждого устройства.

Команда ntp clock-period автоматически появляется в конфигурации при включении NTP. Команда используется для регулировки часов программного обеспечения. 'Значение корректировки' компенсирует 4 интервала галочки мс, так, чтобы с незначительной корректировкой у вас была 1 секунда в конце интервала.

Если устройство вычислило, что его системные часы теряют время (возможно, должна быть компенсация частоты от основного уровня маршрутизатора), это автоматически добавляет это значение к системным часам для поддержания его синхронности.

Примечание: Эта команда should not быть измененным пользователем.

NTP clock-period по умолчанию для маршрутизатора 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 clock-period вставляется на новом устройстве. Когда это происходит, NTP на новом клиенте всегда выходит из синхронизования с сервером с высоким одноранговым дисперсионным значением.

Вместо этого очистите NTP clock-period ни с какой командой 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.

Дополнительные сведения

TAC Authored

Создано инженерами Cisco

  • Mani Ganesan and Krishna Nagavolu
    Cisco TAC Engineers.

Помог ли этот документ?

Обратная связь

Позвольте нам помочь