NTP Access group

I will call this NTP blog NTP Scenario 2: NTP with access-group filtering.

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 :)