R4, R5, and R6 are connected via full mesh frame-relay
R6 will be the NTP server.
In scenario 1 we set up R4 to sync to R6. In this scenario we
will prevent R5 from syncing with R6 by using ntp access-group command.
I have never used this command before, so I hope I am understanding it correctly. If not, please let me know how else to test this command.
On R6 we have the following ACL:
access-list 1 permit 172.12.45.4
access-list 1 permit 127.127.7.1
172.12.45.4 is the address of R4. 127.127.7.1 is the IP address that a cisco router uses as it's reference when you make the router an NTP master. This must be added to the ACL or it will become unsynchronized with itself.
In global config mode we enter:
ntp access-group serve-only 1
Let's check the current times:
R5#show clock
16:15:04.031 UTC Sat May 31 2008
R6#show clock
16:31:45.687 UTC Sat May 31 2008
R5 is about 15 minutes behind. I don't know a way to debug on R6 to make sure it's working, so what I will do is wait about 10 minutes then add R5's IP address to ACL. I think 10 minutes is sufficient to prove that R6 is not allowing R5 to sync to it.
...
...
Well it's almost 20 minutes now. Let's check if R4 is synchronized:
R4#show ntp status | inc Cloc
Clock is synchronized, stratum 3, reference is 172.12.45.6
How about R5:
R5#sho ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock
Some quick show clocks:
R4#show clock
16:49:06.505 UTC Sat May 31 2008
R5#show clock
16:32:29.755 UTC Sat May 31 2008
R6#show clock
16:49:12.335 UTC Sat May 31 2008
R5 is still unsynchronized and more than 15 minutes behind R6. Let's add R5's address to ACL 1 on R6 and see how long it takes to sync...
R6(config)#access-list 1 permit 172.12.45.5
We'll debug on R5:
R5#debug ntp sync
NTP clock synchronization debugging is on
R5#sho ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock
R5#
May 31 16:33:54.039: NTP: synced to new peer 172.12.45.6
Took less than a minute!
This is the second of many NTP scenarios to come. It really seems so simple, but I have always had problems understanding NTP server/peer relationships and authentication configurations. So these will be the topics of future NTP blogs. Hopefully I (and you!) will become NTP masters in time for CCIE :)
R4, R5, and R6 are connected via full mesh frame-relay
R6 will be the NTP server.
First set the clock on R6:
R6#clock set 15:47:30 31 May 2008
*May 31 15:47:30.003: %SYS-6-CLOCKUPDATE: System clock has been updated from 01:
05:19 UTC Fri Mar 1 2002 to 15:47:30 UTC Sat May 31 2008, configured from consol
e by console.
Verify the time with show clock:
R6#show clock
15:47:36.651 UTC Sat May 31 2008
Configure R6 as the master along with stratum:
R6#conf t
R6(config)#ntp master ?
<1-15> Stratum number
R6(config)#ntp master 3
R6(config)#^Z
Verify that R6 is synced with itself:
R6#show ntp associations
address ref clock st when poll reach delay offset disp
*~127.127.7.1 127.127.7.1 2 22 64 1 0.0 0.00 15875.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
R6#show ntp status
Clock is synchronized, stratum 3, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is CBEBF22C.1583DCD8 (15:50:04.084 UTC Sat May 31 2008)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 15875.02 msec, peer dispersion is 15875.02 msec
Now it's time to configure the clients, let's first check the time on R4:
R4#show clock
*03:03:44.823 UTC Fri Mar 1 2002
R4#conf t
R4(config)#ntp server 172.12.45.6
R4(config)#^Z
R4#show clock
*03:04:52.047 UTC Fri Mar 1 2002
R4#
Notice the time is 6 years behind the current date, I have noticed that NTP will not sync when the times are so far apart (Not sure how this works, but let's manually 'push' R4 a little closer)
R4#clock set 15:30:40 31 May 2008
Now we're about 15 minutes behind. Let's do some debugging:
R4#debug ntp sync
NTP clock synchronization debugging is on
.May 31 15:31:43.107: NTP: synced to new peer 172.12.45.6
Noe that we're synced let's verify on R6 and R4:
R4#show clock
15:59:42.466 UTC Sat May 31 2008
R6#show clock
15:59:41.135 UTC Sat May 31 2008
R6 will be the NTP server.
In scenario 1 we set up R4 to sync to R6. In this scenario we
will prevent R5 from syncing with R6 by using ntp access-group command.
I have never used this command before, so I hope I am understanding it correctly. If not, please let me know how else to test this command.
On R6 we have the following ACL:
access-list 1 permit 172.12.45.4
access-list 1 permit 127.127.7.1
172.12.45.4 is the address of R4. 127.127.7.1 is the IP address that a cisco router uses as it's reference when you make the router an NTP master. This must be added to the ACL or it will become unsynchronized with itself.
In global config mode we enter:
ntp access-group serve-only 1
Let's check the current times:
R5#show clock
16:15:04.031 UTC Sat May 31 2008
R6#show clock
16:31:45.687 UTC Sat May 31 2008
R5 is about 15 minutes behind. I don't know a way to debug on R6 to make sure it's working, so what I will do is wait about 10 minutes then add R5's IP address to ACL. I think 10 minutes is sufficient to prove that R6 is not allowing R5 to sync to it.
...
...
Well it's almost 20 minutes now. Let's check if R4 is synchronized:
R4#show ntp status | inc Cloc
Clock is synchronized, stratum 3, reference is 172.12.45.6
How about R5:
R5#sho ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock
Some quick show clocks:
R4#show clock
16:49:06.505 UTC Sat May 31 2008
R5#show clock
16:32:29.755 UTC Sat May 31 2008
R6#show clock
16:49:12.335 UTC Sat May 31 2008
R5 is still unsynchronized and more than 15 minutes behind R6. Let's add R5's address to ACL 1 on R6 and see how long it takes to sync...
R6(config)#access-list 1 permit 172.12.45.5
We'll debug on R5:
R5#debug ntp sync
NTP clock synchronization debugging is on
R5#sho ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock
R5#
May 31 16:33:54.039: NTP: synced to new peer 172.12.45.6
Took less than a minute!
This is the second of many NTP scenarios to come. It really seems so simple, but I have always had problems understanding NTP server/peer relationships and authentication configurations. So these will be the topics of future NTP blogs. Hopefully I (and you!) will become NTP masters in time for CCIE :)
Basic NTP Configuration
I will call this NTP Scenario 1: Basic NTP with no authentication. There will be more blogs about NTP but this is just to get it started.R4, R5, and R6 are connected via full mesh frame-relay
R6 will be the NTP server.
First set the clock on R6:
R6#clock set 15:47:30 31 May 2008
*May 31 15:47:30.003: %SYS-6-CLOCKUPDATE: System clock has been updated from 01:
05:19 UTC Fri Mar 1 2002 to 15:47:30 UTC Sat May 31 2008, configured from consol
e by console.
Verify the time with show clock:
R6#show clock
15:47:36.651 UTC Sat May 31 2008
Configure R6 as the master along with stratum:
R6#conf t
R6(config)#ntp master ?
<1-15> Stratum number
R6(config)#ntp master 3
R6(config)#^Z
Verify that R6 is synced with itself:
R6#show ntp associations
address ref clock st when poll reach delay offset disp
*~127.127.7.1 127.127.7.1 2 22 64 1 0.0 0.00 15875.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
R6#show ntp status
Clock is synchronized, stratum 3, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is CBEBF22C.1583DCD8 (15:50:04.084 UTC Sat May 31 2008)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 15875.02 msec, peer dispersion is 15875.02 msec
Now it's time to configure the clients, let's first check the time on R4:
R4#show clock
*03:03:44.823 UTC Fri Mar 1 2002
R4#conf t
R4(config)#ntp server 172.12.45.6
R4(config)#^Z
R4#show clock
*03:04:52.047 UTC Fri Mar 1 2002
R4#
Notice the time is 6 years behind the current date, I have noticed that NTP will not sync when the times are so far apart (Not sure how this works, but let's manually 'push' R4 a little closer)
R4#clock set 15:30:40 31 May 2008
Now we're about 15 minutes behind. Let's do some debugging:
R4#debug ntp sync
NTP clock synchronization debugging is on
.May 31 15:31:43.107: NTP: synced to new peer 172.12.45.6
Noe that we're synced let's verify on R6 and R4:
R4#show clock
15:59:42.466 UTC Sat May 31 2008
R6#show clock
15:59:41.135 UTC Sat May 31 2008
