Я пытаюсь настроить коммутатор cisco в качестве клиента ntp, однако я не могу обойтись без состояния show ntp Clock is unsynchronized, stratum 16, no reference clock. Я попытался установить часы, близкие к времени UTC, но я все еще не показываю синхронизацию времени. Сначала я подумал, что это произошло из-за ошибки, о которой я читал, относительно Win32Timeservice или чего-то подобного, однако я подтвердил, что это сервер NTPD (10.0.0.8), работающий в Unix.
Вот рабочая конфигурация
ntp server 10.0.0.8
Вот показать статус ntp
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 119.2092 Hz, actual freq is 119.2092 Hz, precision is 2**17
reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec
Вот покажите ассоциации ntp:
address ref clock st when poll reach delay offset disp
~10.0.0.8 73.0.0.84 16 11 128 377 1.8 24018. 4.7
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
Вот подробные сведения о связях с ntp:
10.0.0.8 configured, insane, invalid, stratum 16
ref ID 73.78.73.84, time D4452E2F.F4727CEA (18:59:59.954 UTC Wed Nov 7 2012)
our mode active, peer mode active, our poll intvl 512, peer poll intvl 256
root delay 0.00 msec, root disp 8.65, reach 377, sync dist 13.535
delay 1.45 msec, offset 24014.6042 msec, dispersion 4.17
precision 2**20, version 3
org time D4452E2F.F472894E (18:59:59.954 UTC Wed Nov 7 2012)
rcv time D4452E17.F0E5117A (18:59:35.940 UTC Wed Nov 7 2012)
xmt time D4452E17.F083A829 (18:59:35.939 UTC Wed Nov 7 2012)
filtdelay = 1.45 2.44 1.80 1.71 1.91 1.72 1.31 2.37
filtoffset = 24014.6 24016.5 24018.8 24021.3 24023.6 24026.1 24028.7 24030.7
filterror = 0.02 0.99 1.79 2.76 3.74 4.71 5.69 6.67
Вот мой отладочный ntp
1d03h: NTP: xmit packet to 10.0.0.8:
1d03h: leap 3, mode 1, version 3, stratum 0, ppoll 64
1d03h: rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
1d03h: ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
1d03h: org D4452CBB.F7C546BE (18:53:47.967 UTC Wed Nov 7 2012)
1d03h: rec D4452CA3.F093A140 (18:53:23.939 UTC Wed Nov 7 2012)
1d03h: xmt D4452CE3.F082CDCD (18:54:27.939 UTC Wed Nov 7 2012)
1d03h: NTP: rcv packet from 10.0.0.8 to 10.0.0.30 on Vlan20:
1d03h: leap 0, mode 1, version 3, stratum 0, ppoll 64
1d03h: rtdel 0000 (0.000), rtdsp 0108 (4.028), refid 494E4954 (73.78.73.84)
1d03h: ref D4452CFB.F76D2086 (18:54:51.966 UTC Wed Nov 7 2012)
1d03h: org D4452CE3.F082CDCD (18:54:27.939 UTC Wed Nov 7 2012)
1d03h: rec D4452CFB.F76B8A2C (18:54:51.966 UTC Wed Nov 7 2012)
1d03h: xmt D4452CFB.F76D2DB1 (18:54:51.966 UTC Wed Nov 7 2012)
1d03h: inp D4452CE3.F0F5FBCA (18:54:27.941 UTC Wed Nov 7 2012)
Я не совсем уверен, куда идти дальше. Я знаю, что в разделе показать подробности ассоциаций ntp, если там есть ненормальный, недействительный или слой 16, коммутатор cisco не будет синхронизировать время.
Вот ntp.conf
server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
restrict 127.0.0.1
Эта строка отладки заставляет меня интересоваться достоверностью вашего мастера NTP:
1d03h: NTP: rcv packet from 10.0.0.8 to 10.0.0.30 on Vlan20:
1d03h: leap 0, mode 1, version 3, stratum 0, ppoll 64
Итак, ваш NTP-сервер объявляет, что это слой 0 - это не сработает.
Я проверил это с помощью двух маршрутизаторов, чтобы убедиться, что формат должен выглядеть на мастере NTP.
.Mar 1 00:55:51.533: NTP: rcv packet from 10.0.0.8 to 10.0.0.30 on Serial0/0:
.Mar 1 00:55:51.537: leap 0, mode 4, version 3, stratum 5, ppoll 64
Обратите внимание на разумную страту от моего мастера NTP (простая конфигурация на главном маршрутизаторе была «ntp master 5»)
NTP - это, конечно, привередливый протокол, но я бы поближе познакомился с вашим мастером NTP. Еще одна вещь, которая может помочь с NTP, - это установить часы сетевых устройств «близко» к часам, которые в конечном итоге предоставит мастер NTP.
Мастера, чьи обновления отключены на очень большом расстоянии от того, что, по мнению коммутатора, должно быть время, также могут быть объявлены безумными или, в лучшем случае, сойдутся долго.