1. r&s ccnpv5 - ntp

8/7/2019 1. R&S CCNPv5 - NTP

1/4

Home | Members | About Us | My Cart

Contact Us | 1-877-224-8987

Instructor-Led Self-Paced Training Packages Rack Rentals

CCIE Lab Preparation Resources

by: Brian McGahan, CCIE #8593

Introduction:

Network Time Protocol (NTP) is a UDP based protocol used to synchronize time clocks amongst network devices. NTP is

especially useful to ensure that timestamps on log messages are consistent throughout the entire network. NTP is a

standards based protocol, and is defined in RFC 1305, Network Time Protocol Version 3.

NTP uses a stratum, or hop count, in order to determine how close a device is to a master time source. A lower stratum is

better, and devices with a stratum of 1 are assumed to be the authoritative time source. Devices which receive their time

directly from a stratum 1 device have a stratum of 2, and so on and so forth.

Time advertisements in NTP are always sent in UTC, also known as Greenwich Mean Time (GMT). Time zone information is

always locally significant to a device running NTP.

Since NTP is used to ensure accurate log file timestamp information, NTP poses a security risk. If malicious users were able

to falsify NTP information passed over the network, timestamp information could be falsified to the advantage of said

attacker. In order to deal with this vulnerability, NTP optionally implements an authentication mechanism.

To implement an attack on NTP, a hacker could make a rogue host appear to be a valid NTP server, and inject false time into

the network. Therefore, the NTP authentication model is opposite of the typical client-server authentication model.

NTP authentication is used to authenticate the time source, not the recipient.

Objective:

To demonstrate how NTP authentication works in Cisco IOS software

Overview:

R1 and R2 are Cisco 2610 series routers running Cisco IOS version 12.2(15)T5. R1 will be configured as an NTP

master clock with a stratum of 1. R2 will be an NTP client of R1. The following combinations of NTP authentication will be

used to demonstrate the proper configuration:

Note: The NTP specification dictates that a client can only update its clock a certain amount of time per clock period.

Understanding Network Time Protocol (NTP) Authentication

The local-clock process operates upon the offset data produced by the update procedure and adjusts the phase and

frequency of the local clock using the mechanisms described in Section 5. This may result in either a step-change or a

gradual phase adjustment of the local clock to reduce the offset to zero.

The key phrase to note is that the adjustment "may result in either a step-change or a gradual phase adjustment of the local

clock to reduce the offset to zero." This means that depending on how far off the local clock is, the local device will either

completely replace the local clock with the value that the peer is advertising (step change) or move the local clock closer and

closer to what is being advertised (gradual phase adjustment).

A common problem when configuring NTP is that synchronization takes a long time. Also, you may have noticed in your

studies that NTP will synchronize after reloading your routers. The reason that synchronization happens immediately after the

reload is because the 2x00 series routers don't have a hardware clock. This means that when they reload, the clock is reset

to the default (00:00:00 UTC Mon Mar 1 1993). Since the NTP devices in question now have clocks that are relatively close to

each other, the gradual phase adjustment and synchronization process will happen very quickly.

On the other hand, if the local clock is very different than the clock source, it may take a long time for this gradual

adjustment to happen, hence a long time until synchronization.

To solve this problem, make sure that you configure the correct time (in UTC) on all devices before starting NTP

configuration. This will ensure that the change in offset during synchronization is minimal, hence a short time to

Page 1 of 4CCIE R&S Recommended Reading | INE

28/1/2011http://www.ine.com/resources/01700369.htm

8/7/2019 1. R&S CCNPv5 - NTP

2/4

synchronization.

Case I: No authentication

Configuration:

R1:

R1#clock set 00:00:00 1 Jan 2000

R1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)#ntp master 1

R2:

R2#clock set 00:00:00 1 Jan 2000

R2#conf t


R2(config)#ntp server 12.0.0.1

Verification:

R1#show ntp status

Clock is synchronized, stratum 1, reference is .LOCL.

nominal freq is 249.5901 Hz, actual freq is 249.5901 Hz,

precision is 2**18

reference time is BC17C2B4.EDC6DA36 (00:03:00.928 UTC Sat Jan 1 2000)

clock offset is 0.0000 msec, root delay is 0.00 msecroot dispersion is 0.02 msec, peer dispersion is 0.02 msec

R2#show ntp status

Clock is synchronized, stratum 2, reference is 12.0.0.1


precision is 2**18

reference time is BC17C2BC.B07E8007 (00:03:08.689 UTC Sat Jan 1 2000)

clock offset is 1.1910 msec, root delay is 3.42 msec

root dispersion is 2.20 msec, peer dispersion is 0.98 msec

As we can see from the above output, R1 is the master server with a stratum of 1, whose reference clock is the local device.

R2 is synchronized with the clock 12.0.0.1, and has a stratum of 2.

Case II: Authentication on Master (R1) Only

Configuration:

R1:

R1#conf t



R1(config)#ntp authenticate

R1(config)#ntp authentication-key 1 md5 CISCO

R2:

R2#conf t


R2(config)#ntp server 12.0.0.1

Verification:

R1#sh ntp statusClock is synchronized, stratum 1, reference is .LOCL.


precision is 2**16

reference time is BC17C241.A9F22584 (00:01:05.663 UTC Sat Jan 1 2000)



R2#sh ntp status



precision is 2**16

reference time is BC17C238.6FBA7873 (00:00:56.436 UTC Sat Jan 1 2000)



R2#sh ntp association detail

12.0.0.1 configured, our_master, sane, valid, stratum 1

ref ID .LOCL., time BC17C201.AAC02E8E (00:00:01.666 UTC Sat Jan 1 2000)

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 1.724

delay 3.33 msec, offset 0.2074 msec, dispersion 0.03

precision 2**16, version 3



8/7/2019 1. R&S CCNPv5 - NTP

3/4

org time BC17C238.6F5ABAA7 (00:00:56.434 UTC Sat Jan 1 2000)

rcv time BC17C238.6FBA7873 (00:00:56.436 UTC Sat Jan 1 2000)

xmt time BC17C238.6EDB7F53 (00:00:56.433 UTC Sat Jan 1 2000)

filtdelay = 3.33 3.33 3.34 3.36 3.33 3.36 3.33 3.33

filtoffset = 0.21 0.19 0.18 0.16 0.16 0.13 0.13 0.11

filterror = 0.02 0.03 0.05 0.06 0.08 0.09 0.11 0.12


R2 is synchronized with the clock 12.0.0.1, and has a stratum of 2. Although authentication is enabled on the master, this

session has not been authenticated.

Case III: Authentication on Client (R2) Only

Configuration:

R1:

R1#clock set 00:00:00 1 Jan 2000

R1#conf t



R2:

R2#clock set 00:00:00 1 Jan 2000

R2#conf t




R2(config)#ntp trusted-key 1

R2(config)#ntp server 12.0.0.1 key 1

Verification:

R1#sh ntp status



precision is 2**16

reference time is BC17C21E.E2025C2A (00:00:30.882 UTC Sat Jan 1 2000)



R2#sh ntp status

Clock is unsynchronized, stratum 16, no reference clock


precision is 2**16reference time is BC17C478.70F636C7 (00:10:32.441 UTC Sat Jan 1 2000)




12.0.0.1 configured, insane, invalid, unsynced, stratum 16

ref ID 0.0.0.0, time 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)

our mode client, peer mode unspec, our poll intvl 64, peer poll intvl 64




org time BC17C21D.A98986BD (00:00:29.662 UTC Sat Jan 1 2000)

rcv time BC17C215.F9D7D2C3 (00:00:21.975 UTC Sat Jan 1 2000)

xmt time BC17C215.F8F5A889 (00:00:21.972 UTC Sat Jan 1 2000)

filtdelay = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filtoffset = 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

filterror = 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0


R2 is not synchronized, reports that the clock 12.0.0.1 is insane, and has a stratum of 16. Since the server is not responding

to the clients authentication request, synchronization is not achieved.

Case IV: Authentication on Master (R1) and Client (R2)

Configuration:

R1:

R1#clock set 00:00:00 1 Jan 2000

R1#conf t




R2:

R2#clock set 00:00:00 1 Jan 2000

R2#conf t





8/7/2019 1. R&S CCNPv5 - NTP

4/4


R2(config)#ntp trusted-key 1

R2(config)#ntp server 12.0.0.1 key 1

Verification:

R1#sh ntp status


nominal freq is 249.5901 Hz, actual freq is 249.5901 Hz, precision is 2**16

reference time is BC17C250.CBF1C712 (00:01:20.796 UTC Sat Jan 1 2000)

clock offset is 0.0000 msec, root delay is 0.00 msecroot dispersion is 0.02 msec, peer dispersion is 0.02 msec

R2#sh ntp status


nominal freq is 249.5901 Hz, actual freq is 249.5899 Hz, precision is 2**16

reference time is BC17C223.9538661E (00:00:35.582 UTC Sat Jan 1 2000)




12.0.0.1 configured, authenticated, our_master, sane, valid, stratum 1

ref ID .LOCL., time BC17C210.CBB5CB7E (00:00:16.795 UTC Sat Jan 1 2000)

our mode client, peer mode server, our poll intvl 64, peer poll intvl 64




org time BC17C223.94D4F0AA (00:00:35.581 UTC Sat Jan 1 2000)

rcv time BC17C223.9538661E (00:00:35.582 UTC Sat Jan 1 2000)

xmt time BC17C223.944184E3 (00:00:35.579 UTC Sat Jan 1 2000)

filtdelay = 3.43 3.51 3.42 3.46 3.43 3.51 3.43 3.42

filtoffset = 0.20 0.15 0.18 0.17 0.17 0.09 0.10 0.10

filterror = 0.02 0.03 0.05 0.06 0.08 0.09 0.11 0.12


R2 has authenticated the clock 12.0.0.1, has synchronized with it, and has a stratum of 2. This is the correct configuration

for NTP authentication.

Review:

This exercise has demonstrated that NTP authentication is initiated by the client. An NTP association may be formed without

authentication, without the client initiating authentication, and with the client initiating authentication and the server

responding. NTP synchronization cannot occur if the client requests authentication and the server refuses.

2003 Internetwork Expert, Inc.


28/1/2011http:// ine com/reso rces/01700369 htm

1. r&s ccnpv5 - ntp

Documents