Network Time Protocol Lab

Why guarantee time synchronization across your network ?

Time synchronization is very important in an IT environment . Firstly because it ensures that all employees and their devices (computers, phones…) have all the same time. Secondly because the operating systems and network devices must be synchronized for security reason: when you analyze and correlate log information, timestamps are very precious.

NTP Protocol

NTP stands for Network Time Protocol. The current version number is 4. This protocol will get the time from an external time source and will propagate it in the local area network. To retrieve the time, NTP will request high stratum time servers. Strata are a hierarchical division of time servers. Strata represent the distance from the time server in term of accuracy. For example, Stratum 0 is the most accurate time resource (it is composed of atomic clock, satellites…). As we cannot ask directly stratum 0 devices, Stratum 1 is the most accurate time source. Stratum 1 is composed of servers directly attached to atomic clocks. Then you have stratum 2 servers querying stratum 1 servers and stratum 3 servers querying stratum 2 servers, and so on so forth.

You can get a list of available time servers for you time zone at http://www.pool.ntp.org/zone/us or at http://support.ntp.org/bin/view/Servers/StratumOneTimeServers".

NTP stratum

To ensure client-server synchronization, NTP uses a round-trip delay time mechanism to calculate the time the request spend on the wire and the time it take to process it http://en.wikipedia.org/wiki/Round-trip_delay_time.

Because a picture is worth a thousand words:

NTP RTD

For those who want to go further, follow this interesting link: http://www.isi.edu/touch/pubs/mirage/ch4.pdf

Note that NTP is sending UTC time (Coordinated Universal Time).

NTPd
NTPd is the traditional NTP daemon on Linux systems. NTPd is used for both server and client use. For openBSD, you can get openNTPd http://www.openntpd.org. In the following article I detail the configuration of a NTP server and client running Debian Linux operating system.

NTP operation modes

Symmetric active: the server sends NTP updates to its clients or to other servers periodically. It actively provides synchronization and could also be synchronized.
Symmetric passive: a server in this mode waits a NTP message before synchronizing clients or being synchronized.
client: in this mode, a server or a workstation periodically sends messages to be synchronized.
server: this mode is activated on a server when a NTP client message is received
broadcast/multicast: used in local area network to provide time for the clients
manycast: used in redundant / complex scenarios (clients and servers use multicast and unicast messages, http://www.eecis.udel.edu/~mills/autocfg.html

Server configuration

# cp /etc/ntp.conf /etc/ntp.conf.bak
# vim /etc/ntp.conf


driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example
## Stratum 1 servers
server nist1-la.WiTime.net
## Stratum 2 servers
server ac-ntp1.net.cmu.edu
server ac-ntp0.net.cmu.edu

# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool: 
# server 0.north-america.pool.ntp.org iburst
# server 1.north-america.pool.ntp.org iburst
# server 2.north-america.pool.ntp.org iburst
# server 3.north-america.pool.ntp.org iburst

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details. The web page 
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
# restrict default ignore ? forbid access for everyone, you need to add each server 
# manually
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust
restrict 192.168.2.0 mask 255.255.255.0 nomodify notrap

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.2.0

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines. Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

Do not forget to set the timezone (NTP sends UTC time!)

# ln -s /usr/share/zoneinfo/Americas/New_York /etc/localtime

# tzselect

Start the service:

# /etc/init.d/ntp restart

Verify:

==============================================================================
 64.147.116.229 .ACTS. 1 u 1 64 1 169.365 -101.47 0.000
 AC-NTP1.NET.CMU 128.237.148.140 2 u 4 64 1 142.434 -109.43 0.000
 AC-NTP0.NET.CMU 128.237.148.140 2 u 3 64 1 142.474 -110.73 0.000

remote: address / domain name of the peer
refid: what is your peer time source (another NTP server or an internal clock, here ACTS means Automated Computer Time Service
st: stratum
t: type of the relation (unicast, broadcast, multicast, local)
when: when the peer was last heard (seconds)
poll: polling interval (seconds)
reach: status of the reachability
delay: latest delay in milliseconds
offset: latest offset in milliseconds
jitter: latest jitter in milliseconds

Client configuration

Linux

Installation commands :

# aptitude install ntp ntpdate
# service ntp stop
# ntpdate –u 192.168.2.106
# service ntp start
# date

Cisco IOS

R1(config)#ntp ?
  access-group        Control NTP access
  authenticate        Authenticate time sources
  authentication-key  Authentication key for trusted time sources
  broadcastdelay      Estimated round-trip delay
  clock-period        Length of hardware clock tick
  logging             Enable NTP message logging
  master              Act as NTP master clock
  max-associations    Set maximum number of associations
  peer                Configure NTP peer
  server              Configure NTP server
  source              Configure interface for source address
  trusted-key         Key numbers for trusted time sources

R1(config)#ntp server 192.168.2.106 version 3 prefer
R1(config)#ntp source fastEthernet 0/0
R1(config)#ntp logging

R1#show ntp associations

      address         ref clock     st  when  poll reach  delay  offset    disp
*~192.168.2.106    64.147.116.229    2    56    64    1    12.1   50.91  15875.
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

R1#show ntp status
Clock is synchronized, stratum 3, reference is 192.168.2.106
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18
reference time is D4495700.41E7C0D7 (22:43:12.257 UTC Sat Nov 10 2012)
clock offset is 50.9131 msec, root delay is 181.38 msec
root dispersion is 16492.39 msec, peer dispersion is 15875.02 msec

R1#show ntp associations detail
192.168.2.106 configured, our_master, sane, valid, stratum 2
ref ID 64.147.116.229, time D4495687.73B8E54A (22:41:11.452 UTC Sat Nov 10 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 169.28 msec, root disp 566.47, reach 2, sync dist 16532.166
delay 12.10 msec, offset 50.9131 msec, dispersion 15875.02
precision 2**23, version 3
org time D4495740.545E93BB (22:44:16.329 UTC Sat Nov 10 2012)
rcv time D4495740.4A0E1B51 (22:44:16.289 UTC Sat Nov 10 2012)
xmt time D4495740.46ED4678 (22:44:16.277 UTC Sat Nov 10 2012)
filtdelay =    12.10    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filtoffset =   50.91    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filterror =     0.02 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0

R1#debug ntp events
NTP events debugging is on
Mar  1 00:33:22.135: NTP: 192.168.2.106 reachable
Mar  1 00:33:22.135: %NTP-6-PEERREACH: Peer 192.168.2.106 is reachable
Nov 10 22:42:08.273: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:35:30 UTC Fri Mar 1 2002 to 22:42:08 UTC Sat Nov 10 2012, configured from NTP by 192.168.2.106.
Nov 10 22:42:08.273: NTP: peer stratum change
Nov 10 22:42:08.273: NTP: clock reset
Nov 10 22:43:12.257: NTP: 192.168.2.106 synced to new peer
Nov 10 22:43:12.261: %NTP-5-PEERSYNC: NTP synced to peer 192.168.2.106
Nov 10 22:43:12.261: NTP: sync change
Nov 10 22:43:12.261: NTP: peer stratum change
Nov 10 22:43:12.261: NTP: 192.168.2.106 reachable
Nov 10 22:43:12.261: %NTP-6-PEERREACH: Peer 192.168.2.106 is reachable

Juniper JunOS

# edit system ntp
[edit system ntp]
# set ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> authentication-key   Authentication key information
  boot-server          Server to query during boot sequence
> broadcast            Broadcast parameters
  broadcast-client     Listen to broadcast NTP
> multicast-client     Listen to multicast NTP
> peer                 Peer parameters
> server               Server parameters
  source-address       Use specified address as source address
+ trusted-key          List of trusted authentication keys
[edit system ntp]
# set server 192.168.2.106
[edit system ntp]

> show ntp ?
Possible completions:
  associations         Show status of peers
  status               Show internal variables returned by peers

Caveats If there is too much delay between your time source and your server, it might raise an error saying that it cannot synchronize. It is advised not to set a stratum 1 or stratum 2 time source.

Links

NTP version 4 RFCs :

RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification
RFC 5906: Network Time Protocol Version 4: Autokey Specification
RFC 5907: Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)
RFC 5908: Network Time Protocol (NTP) Server Option for DHCPv6

NTP version 3 RFCs :

RFC 1305: Network Time Protocol (Version 3) Specification, Implementation and Analysis