Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1715
  • Last Modified:

Using a Cisco Switch as the NTP Master time source for a PDC

Hi all,
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

1 Solution
btanExec ConsultantCommented:
This article is nice for troubleshooting NTP related issues (probably you already saw it), I was wondering if the stratum is an factor

NTP: Common issues and troubleshooting

Error: Strata too high - too many indirections from sensor to master NTP server
NTP uses the concept of a "stratum" to describe how many NTP "hops" away a machine is from an authoritative time source. That error message indicates that the NTP stratum reported by the NTP server is too high. The stratum is a number between 1 and 15 that indicates how far removed that server is from a precision reference clock. Generally systems that are directly sync'ed to an atomic clock report their stratum as 1. A host that is synced to a stratum 1 NTP server but is also serving as an NTP server for other hosts would report it's stratum as 2 to those hosts. And so on, with each successive layer of servers having a stratum that is 1 higher than its parent.
If the sensor attempts to sync to a server that reports its stratum as 15, then the sensor's stratum would be 16, which is illegal, so the sensor instead rejects the server and displays the "Strata too high" message.
Also if you are using a Linux host as an NTP server and has hard-coded the stratum that it reports rather than let it calculate the stratum automatically. If it is a linux or unix box, the ntp server is configured by the file /etc/ntp.conf, and the "fudge" command is used to hard-code the stratum. The server always reports a stratum value 1 higher than the fudge value to its clients.

As alternative to w32time PDC/DC time server you can take a look at 3rd party NTP/SNTP time server software such as NTS:

It can be installed to PDC machine and host ntp/sntp/ntsv2 services for all or only "white listed" networks (can be configured). That's it, no matter which client connects to server, joined to domain, stand alone, joined to another domain, hardware equipment etc., access is regulated only to IPs/networks
This is maybe not the answer you're looking for, but for isolated networks you can use a GPS clock to serve as a time source for both network gear and servers.
What we have done in our network is to turn on NTP broadcast on all of our LANs:
interface vlan1
 ntp broadcast

Then use a free NTP client like K9NT on your PDC and it will listen to the broadcasts. This method works extremely well, assuming that the time being broadcast is acceptable to you.
Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

If security concerns allow that, I would recommend to let all the systems (DC's included) sync themselves to free available sources on the internet. That would minimize redundancy problems.

If there are security concerns, I would recommend to use a dedicated NTP server appliance (usually a preconfigured Linux box wit a built in radio controlled clock listening to GPS, DCF77, etc.).

You might find my article on NTP useful.

If you think about a dedicated NTP server box, I have experiences with Meinberg M300 boxes (available for GPS, DCF77 and other time sources) as redundancy cluster (of two boxes) which worked very well (firmware 6.14.12 or above recommended).
canttalkeatingAuthor Commented:
Thanks Frankhelk,

Security is a concern and this is a totally closed carrier network.  We have meinbergs for the real networks being tunnelled accross the carrier network but customer won't entertain spending money on them for the carrier.

I have however resolbved this one myself:
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:



The time provider NtpClient is currently receiving valid time data from <NTP CLIENT SWITCH IP>

Followed by ……



The time service is now synchronizing the system time with the time source <NTP CLIENT SWITCH IP>

btanExec ConsultantCommented:
Thanks for sharing. Indeed stratum has been the common hop wise we even run a dedicated ntp v3 above even for closed network.
canttalkeatingAuthor Commented:
This has been proven to be the correct answer in this scenario and continues to work.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

NEW Internet Security Report Now Available!

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out this quarters report on the threats that shook the industry in Q4 2017.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now