05-19-2008 02:54 AM - edited 03-05-2019 11:04 PM
Last year our RSM /Cat5509 failed and a decision was made to replace it with a layer 3 switch ie: Cat4948 rather than try to source another RSM/Cat5509.
Our telemetry server logs have highlighted that although NTP was being distributed out from our clock unit plugged into the cat5509/RSM before the change out. Once the Cat4948 was installed NTP stopped being distributed to the rest of the network. The NTP configuration was copied directly from the RSM to the new 4948.
The clock/sync unit is plugged directly into one of the ports on the Cat4948 and NTP is being picked up by the Cat4948 (see below). However, the 3660 that is directly connected into the Cat4948 (Ethernet port to Ethernet port) does not seem to be picking NTP up from the Cat4948.
It appears that whilst the Cat4948 is able to pick up NTP from the sync unit, the Cat 4948 is not re-distributing NTP
Original config on the RSM:
R_BAC_RSM
!
ntp clock-period 17179974
ntp update-calendar
ntp server 149.191.41.29
!
END
-------------------------------------------------------
Current config on the Cat4948
L3_BAC_4948_COMMS#
!
ntp clock-period 17179292
ntp update-calendar
ntp server 149.191.41.29
!
END
A 'show ntp status' on the Cat4948 reveals correctly that it is getting sysnc from the clock unit (149.191.41.29) on the 41 subnet vlan
L3_BAC_4948_COMMS# sh ntp status
Clock is synchronized, stratum 2, reference is 149.191.41.29
nominal freq is 250.0000 Hz, actual freq is 250.0083 Hz, precision is 2**18
reference time is CBCD7FF0.FC3CD1E5 (14:34:40.985 UK Thu May 8 2008)
clock offset is -974.0229 msec, root delay is 4.71 msec
root dispersion is 982.67 msec, peer dispersion is 8.64 msec
L3_BAC_4948_COMMS#
------------------------------------------------------------------------------------
3660 (connected to the Cat4948 via an ethernet port)
R_BAC_3660#
!
!
ntp clock-period 17180228
ntp server 149.191.41.29
!
END
R_BAC_3660#
R_BAC_3660# sh ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 249.9947 Hz, precision is 2**24
reference time is CAE5A980.B4E2B4EA (17:06:08.706 UTC Wed Nov 14 2007)
clock offset is 0.6322 msec, root delay is 2.59 msec
root dispersion is 0.95 msec, peer dispersion is 0.32 msec
R_BAC_3660#
05-19-2008 03:52 AM
Suhale
The information that you posted shows clearly that the 4948 is learning NTP time from the server at 149.191.41.29. And it shows that the 3660 is attempting to learn NTP from the same server but is not. There are several things that might cause this:
- is there an IP connectivity issue? Can the 3660 ping the NTP server? Did something perhaps change in the routing logic on the 4948?
- is there something that is filtering traffic (firewall or interface access list) that might be filtering the NTP attempt from the 3660 or filtering responses back from the server?
One alternative to consider might be to change the config of the 3660 and have it learn NTP from the 4948 rather than from the same server that the 4948 is learning from.
HTH
Rick
05-20-2008 04:56 AM
Hi Rick -
Thanks for your informative reply. I will carry out your recommendations and let you know what happens :-)
Suhale
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide