Building network automation solutions

9 module online course

Start now!

Category: NTP


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.

add comment

Cisco IOS NTP Essentials

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 write It’s Good to be on Time article – you’ll find it somewhere in this list.

see 3 comments

SNTP will not work if you've configured NTP

If you're running NTP and SNTP on the same router, SNTP will never synchronize with a configured SNTP server, as the NTP process captures the reply packet before SNTP has the chance to react.

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.

read more see 4 comments

Inspect router-generated traffic

A while ago a reader has asked me whether you could modify an IP access-list when the interface IP address changes. While that's definitely doable with Tcl and Embedded Event Manager, it's not a trivial task, so I've tried to understand why he would need such a functionality.

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 tcp
ip inspect name DEFAULT100 udp
interface Dialer0
description $FW_OUTSIDE$
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 eq ntp any eq ntp
This 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 tcp router-traffic
ip inspect name DEFAULT100 udp router-traffic
... and the router synchronizes to an external NTP server:
sp#show ip inspect sessions
Established Sessions
Session 474032B4 (>( udp SIS_OPEN
01:04:34: %NTP-5-PEERSYNC: NTP synced to peer
01:04:34: %NTP-6-PEERREACH: Peer is reachable
Note: This article is part of You've asked for it series.
see 3 comments