We have a closed network (no connectivity to the internet) and we have a Core router setup as the NTP Master for the rest of the network.
All network devices are getting the time synced as intended but we are having issues getting the Primary Domain Controller (PDC) registering to it as a valid NTP time source.
The problem we have is that we are affected by IOS bug CSCed13703 which rejects the PDC as an NTP associated device. Short of changing the IOS on the Router which is the main router feeding 30 other sites I would like to point the PDC at a different switch (an NTP Client switch) as it’s NTP source, rather than it going to the actual NTP Master.
I have changed the values in the PDC to point to a different switch (3750) that has it’s time synced with the NTP master, but the PDC doesn’t want to know. I assume it will only accept the time from an official NTP Master .
Could any of you fine people advise if what I am trying to do is possible and if so how I would go about it. I was thinking of setting the 3750 with the NTP Master command also, but I don’t want to confuse the other cisco devices in the network
Thanks in advance
I believe a PDC time source needs to be Stratum 2 (or better). What's your 3750 shwoing up as?
I can confirm the Stratum on the 3750 is set to 15. This is due to the NTP Time source being an internal router and not an authoritative time source out on the internet. When setting the clock and using the NTP Master command on my internal router it sets the Stratum level to 14.
I have pointed the PDC at the Router (Stratum 14) and it does successfully sync time, but won't trust it as a valid source after the first sync. Upon reading I believed this to be the IOS bug as the symptoms are identical. Your theory of the PDC requiring a Stratum 2 time source is logical (especially in this scenario) but I have seen them use Stratum 4 before and it worked just fine.
I guess I could change the Router acting as a time source for the network to be NTP Master 1 which should force Stratum 1 giving the PDC and all other switches pointing to it a Stratumlevel of 2 which would prove it either way. I don't mind pointing the PDC at the router instead of the switch so long as it gets the time synced and trusts it from that point on.
I was going to make the 3750 switch an NTP Master for the Network and point the PDC to it (as per my previous post) but I have noticed this morning that the NTP Master command isn't available on the 3750 as it has no hardware clock!
Are you aware of any other way of forcing the 3750 to become a time source for the PDC without using the NTP Master command? I have looked at the NTP Peer command and I have ruled this out already and I still need the switch to be a client of the NTP Master Router on the network
Cheers for getting involved,
Have you considered using a GPS-synchronized time source?
I used to be responsible for a similar environment and we had a pair Datum Tymeserve (now Symmetricom) appliances with an optically isolated roof-mounted GPS antenna as our primary time reference. That solution passed muster for DCID6/3-accredited systems. When synced with GPS, they provide a Stratum 1 source. The ones we had even provided IRIG-B for our SONET and TDM systems' reference clock.
We use a GPS time source on our main network, but this is a carrier network facilitating the main network which the customer deems low priority (even though it connects all the sites together) and therefore will not spend the money on an additional GPS time source for this carrier network. As a result I am where I am looking for a workaround without additional cost
I have progressed this a little further in that I know if I set the 3750 or another router as an NTP Master in the network that it will stop taking it's time sync from the original NTP Master and will start using itself as the time authority it believes to be correct. This could cause complications in the network.
Instead I have configured my lab to have an NTP Master router as Stratum 8 (Default for platform type) and then a second router as an NTP Client which recieves Stratum 9. I have then pointed another router to the NTP Client router and this has actually syncronised with the NTP Client as the Master (Master that it knows of) and everything is working fine at stratum 10! No config required other than pointing to the NTP Client router using the standard ntp server x.x.x.x source fa0/0 command.
From here I am thinking that I can just point my PDC at an NTP Client router in my network (that doesn't have the IOS bug) and it should sync it's time up and continue to be associated with the NTP Client router with a stratum of 10.
I will post the outcome on Monday as my Wintel guys have gone home for the weekend
I repointed the Domain Controller to the other Cisco router with the non-affected IOS using:
When running the time sync command:
w32tm /config /manualpeerlist:
w32tm /config /update
w32tm /resync /nowait
From the cmd line after entering the above we get "the computer did not resync because no time was available" and this has returned the following in the windows event log on the server:
Event ID 38 - The time provider ntp client cannot reach or is currently recieving invalid time data
Whilst forcing a resync from the PDC (above) I ran a debug on the ntp client router it was peering to and I get the following:
ntp_receive: dropping message: AM_NEWPASS, passive association disabled..
I have Googled this but I see mixed results all going off on a tangent. Does anyone know definitevely what passive association disabled means? I assume it is saying that as the router is a client of the NTP Master in the network, and that it has not been set up to provide time to other clients on the network as a passive participant. However, I have labbed this up using routers only (no PDC) and the ntp client router can provide time to other routers without any additional config required.
Thanks in advance,
In addition to my last I have rerun the sync command using the following:
w32tm /config /manualpeerlist:
I have logged onto the NTP Master router for the LAN and I can see under show ntp assoc that the PDC is showing as an associated device but showing stratum 16 and INIT. for the reference clock. I believe this to be an old value however from when I was poiting the PDC directly at the NTP Master and we were getting affected by the IOS bug.
RESOLVED: Ladies and Gents, I have resolved this one eventually
I believe the initial root-cause was the IOS bug and then since repointing the PDC to a different router (an NTP Client) with a different IOS, the problem has been with Stratum levels as the NTP Master Router was set to Stratum 14 (form some reason) and the NTP Client router I was pointing the PDC at was receiving Stratum 15 which would have left the PDC receiving Stratum 16 (which is what I guess the Event viewer was referring to was it said it was receive no or invalid time!)
I changed the stratum value set on the NTP Master router from 14 to 8 > This gave Stratum 9 to the NTP Client Router > this would leave the PDC with a Stratum level of 10.
Once I made the change (ntp master 8) on the NTP Master Router and the clock had resynchronized to it’s own internal hardware clock the rest of the network resynchronized without further configuration changes being required. This took a few minutes to resync even for the adjacent devices.
I then check the PDC (Windows 2003) and the Eventvwr showed:
EVENT ID 37
The time provider NtpClient is currently receiving valid time data from
Followed by ……
EVENT ID 35
The time service is now synchronizing the system time with the time source
I hope this is of some help to someone sometime, but either way I have learned a lot about NTP over the last few days!
I ended up with this problem after migrating from an old 4507 chassis as my core L3 switch to a pair of 4500-X L3 switches. Windows just would not sync with the 4500-Xs and the switches would call my PDC insane as well.
Ended up syncing the PDC against a 3750 stack running 12.2(44)SE5 and using a similar solution to the original poster's. The 4500-Xs run IOS-XE 03.08.01.E. Even another stack of 3650s running 03.06.04.E didn't like this PDC.
As per Cisco's 'recommendation' in CSCed13703, ripping out an OS component and installing a third-party version is not a good idea. Maybe Cisco and MS need to bash heads on this and get this fixed. I'll be raising a similar complaint over at the MS whiningsupport forum..