Understanding the “NTP access-group” command in IOS.

• June 2, 2013
• IOS  
• Technology  
• Access-group  
• NTP  

NTP has always been one of those things I have found tricky to really lab up. Its fairly easy to setup, but verifying whether everything is working as you expect, can be hard because it takes a while to synchronize (and even unsynchronize).

In this post I will try and shed some light on the “ntp access-group” command set in Cisco IOS.

When you perform a “?” on the command set it looks like the following (on 12.2(33)SRD7):

R1(config)#ntp access-group ?
  peer        Provide full access
  query-only  Allow only control queries
  serve       Provide server and query access
  serve-only  Provide only server access

For each of the options you can specify an access-list:

R1(config)#ntp access-group peer ?
  <1-99>       Standard IP access list
  <1300-1999>  Standard IP access list (expanded range)

The trick to understanding how this lightweight security system works is to understand the following sentence in the documentation:

“If you specify any access groups, only the specified access is granted.”

Along with the ordered list of most open to least open:

peer
query-only
serve
serve-only

Lets illustrate this with an example. If you apply the following:

access-list 90 deny any
access-list 91 permit 10.1.2.10
ntp access-group peer 90
ntp access-group serve-only 91

What you are really doing is telling the router that it cant “peer” with anything (allow time requests and allow the system itself to synchronize). However processing of an incomming time request will go down the list and meet the “ntp access-group serve-only 91” command. This allows time requests from the hosts permitted in the access-list.

In our case host 10.1.2.10 can get its time from the local system.

The example above is for demonstration purposes since the “ntp access-group peer 90” is the same as not having specified the “ntp access-group peer” command in the first place.

So you see, an incomming request goes down the list of things “allowed” and if it finds itself allowed by anything, it succeeds. However if it reach the end of the list and nothing has permitted the request, it is discarded.

Caution

In my example, I have actually locked out any chance for the router itself to synchronize its time. This is due to the fact that since only peer and serve-only is allowed, and the only one of those two that will allow the router itself to synchronize is the peer option and this option denies everything.