Explaining
Clock Stratum
NTP uses
a hierarchical structure to refer to different levels of NTP servers or time
sources these levels are referred to as a “stratum”. The stratum number indicates your distance
from the time source or reference clock, which is called level 0.
Logically
if you are at stratum level 6 you are referencing a level 5 stratum time source,
level 0 to 15 stratum are considered valid, level 16 is considered invalid.
Explaining Leap Seconds:
Even though atomic clocks are very accurate they drift away from solar
time. This means that over a period of
time UTC drifts from solar time. In
order to compensate for this a second is added every now and then to
compensate.
“Since the adoption of
this system in 1972, firstly due to the initial choice of the value of the
second (1/86400 mean solar day of the year 1900) and secondly to the general
slowing down of the Earth's rotation, it has been necessary to add 21s to
UTC.” Directly from the GMT website
If you are synchronising to an external stratum 1 clock then
this is done for you, however if you are building your own NTP architecture
then you can use the following command to add your own leap
Configuring a Cisco Router as an NTP Server
Plan:
- 1Configure master 1 as a server
- Configure NTP Client 2 as a client
- Configure Master 2 as a secure server
- Configure Client 2 to authenticate against Master 2 and prefer it.
Requirements:
3 x 3725 routers or equivalents with an IOS that supports
the following commands:
I have attached my GNS3 files here:
https://drive.google.com/file/d/0B_pDrKQiRFqacHF6RHF4QnFDem8/edit?usp=sharing
Network Diagram:
Step 1: Basic Configuration
Configure each device according to the following table:
NTP_MASTER_1
|
FA 0/0
|
10.10.10.1 /24
|
NTP_MASTER_2
|
FA 0/0
|
10.10.10.2 /24
|
NTP_CLIENT_1
|
FA 0/0
|
10.10.10.3 /24
|
From NTP_CLIENT_1 ping both NTP servers to confirm
connectivity.
STEP 2: Configure NTP_MASTER_1 as the NTP Server
In order for a
cisco device to configure itself as an authoritative source for NTP clients you
utilise the ntp master command.
The
stratum option refers to the table above and is optional.
Issue
this command on NTP_MASTER_1
NTP_MASTER_1(config)#ntp
master
NTP_MASTER_1(config)#exit
NTP_MASTER_1#show
ntp status
Clock
is synchronized, stratum 8, reference is 127.127.7.1
nominal
freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18
reference
time is C0294404.7AE29B59 (00:04:20.480 UTC Fri Mar 1 2002)
clock
offset is 0.0000 msec, root delay is 0.00 msec
root
dispersion is 1875.02 msec, peer dispersion is 1875.02 msec
NTP_MASTER_1#show
ntp associations
address ref clock st
when poll reach delay
offset disp
*~127.127.7.1 127.127.7.1 7
3 64 377
0.0 0.00 0.0
* master (synced), # master (unsynced), +
selected, - candidate, ~ configured
NTP_MASTER_1#
Note: NTP_MASTER_1 is
synchronised to itself by using a local loopback address of 127.127.7.1.
Note: for all of you Microsoft students who have grown up to
believe that 127.0.0.1 is the local loopback address the truth is that any
address in the 127 range can be used as above.
If you don’t believe me try pinging any address that starts with 127
from the cmd prompt you will get a reply.
Note: the local loopback is designed for hosts not routers,
unless you set up a specific loopback address and have a route to that address
the router will not respond (just accept it and you will be fine deep deep
breaths).
Step 3: Configure NTP_CLIENT_1 to synchronise
time with NTP_MASTER_1
NTP_CLIENT_1(config)#ntp server 10.10.10.1 ?
NTP_CLIENT_1(config)#ntp server 10.10.10.1 source
fastEthernet 0/0
NTP_CLIENT_1(config)#exit
NOTE: the source is
optional and defines which interface to use, if omitted it will utilise the
first interface with a valid address.
NTP_CLIENT_1#show ntp status
Clock is synchronized, stratum 9, reference is 10.10.10.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz,
precision is 2**18
reference time is C02947F2.4197CD86 (00:21:06.256 UTC Fri
Mar 1 2002)
clock offset is 12.7158 msec, root delay is 28.12 msec
root dispersion is 3892.49 msec, peer dispersion is
3879.75 msec
NTP_CLIENT_1#show ntp associations
address ref clock st
when poll reach
delay offset disp
*~10.10.10.1
127.127.7.1 8 3
64 377 20.2
-2.32 9.8
* master (synced),
# master (unsynced), + selected, - candidate, ~ configured
In the output from the command show ntp associations observe that the ref clock is showing as
127.127.7.1 the loopback address utilised on NTP_MASTER_1.
Another useful
troubleshooting command is the debug ntp packet command:
NTP_CLIENT_1#
Mar 1 00:30:28.219: NTP: xmit packet to
10.10.10.1:
Mar 1 00:30:28.219: leap 0, mode 3, version 3, stratum 9, ppoll
128
Mar 1 00:30:28.223: rtdel 0422 (16.144), rtdsp 065C (24.841),
refid 0A0A0A01 (10.10.10.1)
Mar 1 00:30:28.223: ref C02949E4.3F4C409C (00:29:24.247 UTC Fri Mar
1 2002)
Mar 1 00:30:28.223: org C02949E4.428D5426 (00:29:24.259 UTC Fri
Mar 1 2002)
Mar 1 00:30:28.223: rec C02949E4.3F4C409C (00:29:24.247 UTC Fri
Mar 1 2002)
Mar 1 00:30:28.227: xmt C0294A24.382188DB (00:30:28.219 UTC Fri
Mar 1 2002)
Mar 1 00:30:28.243: NTP: rcv packet from
10.10.10.1 to 10.10.10.3 on FastEthernet0/0:
Mar 1 00:30:28.247: leap 0, mode 4, version 3, stratum 8, ppoll
128
Mar 1 00:30:28.247: rtdel 0000 (0.000), rtdsp 0002 (0.031), refid
7F7F0701 (127.127.7.1)
Mar 1 00:30:28.247: ref C0294A10.7ADBE1B2 (00:30:08.479 UTC Fri
Mar 1 2002)
Mar 1 00:30:28.247: org C0294A24.382188DB (00:30:28.219 UTC Fri
Mar 1 2002)
Mar 1 00:30:28.251: rec C0294A24.3E7B7E3B (00:30:28.244 UTC Fri
Mar 1 2002)
Mar 1 00:30:28.251: xmt C0294A24.3E7BEAB7 (00:30:28.244 UTC Fri
Mar 1 2002)
Mar 1 00:30:28.251: inp C0294A24.3E5300A2 (00:30:28.243 UTC Fri
Mar 1 2002)
You can see from this debug output that an NTP packet has
been xmit and rec between the ntp client and master. Interestingly although the masters ref clock
is 127.127.7.1 the 10.10.10.1 on interface fa 0/0 of NTP_MASTER_1 is utilised
for the exchange.
Step 4: Configure NTP With MD5 Authentication:
NTP_MASTER_2(config)#ntp authentication-key 1 md5 TIME
NTP_MASTER_2(config)#ntp
master 1
Client Configuration:
NTP_CLIENT_1#conf
t
NTP_CLIENT_1(config)#ntp
authentication-key 1 md5 TIME
NTP_CLIENT_1(config)#ntp
trusted-key 1
NTP_CLIENT_1(config)#
ntp server 10.10.10.2 prefer source fastEthernet 0/0 key 1
Verifying your
configuration:
NTP_CLIENT_1#show
ntp associations detail
10.10.10.2
configured, authenticated, our_master, sane, valid, stratum 1
ref ID .LOCL.,
time C0295478.6C7AE76C (01:14:32.423 UTC Fri Mar 1 2002)
our mode client,
peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00
msec, root disp 0.03, reach 377, sync dist 22.507
delay 27.86 msec,
offset -2610.6546 msec, dispersion 8.54
precision 2**18,
version 3
org time
C029547E.A0C70860 (01:14:38.628 UTC Fri Mar 1 2002)
rcv time
C0295481.40AC248E (01:14:41.252 UTC Fri Mar 1 2002)
xmt time
C0295481.397FFA36 (01:14:41.224 UTC Fri Mar 1 2002)
filtdelay = 27.86
35.68 31.89 35.95
32.06 32.12 27.98
32.12
filtoffset =
-2610.6 -2610.5 -2620.6 -2618.4 -2624.5 -2624.5 -2618.4 -2624.5
filterror = 0.02
0.99 1.57 2.55
3.52 3.54 3.56
3.57
10.10.10.1
configured, insane, invalid, stratum 8
ref ID
127.127.7.1, time C0295410.7AD064B5 (01:12:48.479 UTC Fri Mar 1 2002)
our mode client,
peer mode server, our poll intvl 512, peer poll intvl 256
root delay 0.00
msec, root disp 0.03, reach 377, sync dist 19.913
delay 16.14 msec,
offset -8.6274 msec, dispersion 10.77
precision 2**18,
version 3
org time
C029543D.39517280 (01:13:33.223 UTC Fri Mar 1 2002)
rcv time
C029543D.3D981B7C (01:13:33.240 UTC Fri Mar 1 2002)
xmt time
C029543D.39752B19 (01:13:33.224 UTC Fri Mar 1 2002)
filtdelay = 16.14
28.06 32.15 35.95
28.14 32.15 20.14
20.14
filtoffset = -8.63
-10.79 15.95 13.73
-2.72 -4.99 -3.41
13.40
filterror = 0.02
1.08 3.04 4.99
6.94 8.90 10.85
14.76
There are several useful pieces of information from the
output of the command: show ntp
associations detail
SECURITY:
Security Advice: Unless you have a requirement to synchronise externally I avoid it, especially with recent NTP DDos exploits! Additionally if you are setting up an external NTP server follow the latest patching advice etc..
here is a great article on the subject:
http://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks
No comments:
Post a Comment