A few months ago Johannes Weber sent me a short email saying “hey, I plan to write a few NTP posts” and I replied “well, ping me when you have something ready”.
In the meantime he wrote a veritable NTP bible - a series of NTP-related blog posts covering everything from Why Should I Run My Own NTP Servers to authentication, security and monitoring - definitely a MUST READ if you care about knowing what time it is.
Default NTP settings on Cisco IOS allow intruders to change the router’s time or even current year as soon as the router is not synchronized directly with a primary (stratum 1) NTP server. In the Secure Time Management article, I'm describing a very simple NTP attack on an unprotected network and the safeguards you can put in place to prevent similar attacks.
The presentation part of this e-lesson describes NTP basics and IOS implementation details. The hands-on remote exercise enables you to configure multi-tier NTP implementation on Cisco routers.
This is part of the problem with NTP. It's way more complicated then it needs to be. You shouldn't have to understand so much of it to use it on your routers. Take a look at openntpd. It's free and runs on bsd or linux.
I have to disagree with him on several counts:
- NTP is supposed to solve a pretty hard problem of synchronizing multiple independent time sources over communication paths with unpredictable delay and jitter. Considering the limitations it's faced with, it does an amazingly good job.
- NTP configuration on IOS is no more complex than the openntpd configuration if the only thing you want is to do is to configure an upstream NTP server. The only commands you need are ntp server and ntp master.
However, the most important point, in my opinion, is the difference between "aiming for a short recipe" and "understanding the technology". If the only task you ever need to perform is to configure upstream NTP servers, don't even bother to read the IOS documentation or my article, you don't need more than a single configuration command … but then, when things really break, you'll be in trouble.
Likewise, the only thing some people want to know about OSPF are the following two commands:
router ospf 1
0.0.0.02518.104.22.168 area 0
There are others, however, that might need a slightly more in-depth understanding of OSPF design, configuration and troubleshooting (that's why we developed an OSPF course and corresponding set of remote lab exercises and Tom Thomas wrote a whole book about it).
A while ago I've been involved in an interesting discussion focusing on NTP authentication and whether you can actually implement it reliably on Cisco IOS. What I got out of it (apart from a working example :) was the feeling that NTP and it's implementation in Cisco IOS was under-understood and under-documented, so I planned to write an article about it.
However, as I did my research, I figured out there's so much I didn't know about NTP (do you know what's the essential difference between a peer and a server?)that I decided to start with an introductory article explaining the basics of NTP, SNTP and their IOS implementation. It's been published under the name “It’s Good to be on Time” in the IP corner section of our company's web site.
SNTP multicast/broadcast client mode works in combination with NTP
NTP process could be running even if your running configuration has no NTP-related commands. It starts automatically whenever you enter NTP-related configuration (ntp logging configuration command is enough) and is not stopped when the last NTP-related configuration command is removed. You have to reload the router to kill it.
The answer was quite interesting: he's running NTP on his firewall router and thus needs to accept incoming NTP responses from an external NTP server. While that could be easily achieved with the following configuration (only the relevant bits-and-pieces are shown), he didn't want to make the access-list too generic (allowing NTP from the external server to any IP address).
ip inspect name DEFAULT100 tcpThis problem nicely illustrates a broader issues: the router does not inspect it's own traffic and thus does not prepare conduits for the return packets; you have to specify all the return traffic you're expecting in the incoming access list. This drawback has been fixed in IOS release 12.3(14)T with the introduction of the Inspection of Router-Generated Traffic feature. In our scenario you only need to change the inspect rules:
ip inspect name DEFAULT100 udp
ip access-group 102 in
ip inspect DEFAULT100 out
access-list 102 remark #### Dialer0 incoming ####
access-list 102 remark #### non-relevant lines deleted
access-list 102 permit udp host 22.214.171.124 eq ntp any eq ntp
ip inspect name DEFAULT100 tcp router-traffic... and the router synchronizes to an external NTP server:
ip inspect name DEFAULT100 udp router-traffic
sp#show ip inspect sessionsNote: This article is part of You've asked for it series.
Session 474032B4 (192.168.1.3:123)=>(10.0.0.1:123) udp SIS_OPEN
01:04:34: %NTP-5-PEERSYNC: NTP synced to peer 10.0.0.1
01:04:34: %NTP-6-PEERREACH: Peer 10.0.0.1 is reachable