IOS does not respond to NTP queries unless client is in "peer" ACL

Question

I have set up NTP on a Cisco IOS device running IOS 15.2M, and this is my bare-bones config used for testing:

ip access-list standard IPV4-ACL-NTP-PEER
 permit <UP.STREAM.NTP.SERVER> log
!
ip access-list standard IPV4-ACL-NTP-SERVE
 permit any log
!
ip access-list standard IPV4-ACL-NTP-SERVE-ONLY
 permit any log
!
ntp logging
ntp access-group peer IPV4-ACL-NTP-PEER
ntp access-group serve IPV4-ACL-NTP-SERVE
ntp access-group serve-only IPV4-ACL-NTP-SERVE-ONLY
ntp update-calendar
ntp server <UP.STREAM.NTP.SERVER>

The routers can sync with the upstream server without any issues:

ROUTER#show ntp associations

  address                 ref clock       st   when   poll reach  delay  offset   disp
*~<UP.STREAM.NTP.SERVER>  .PPS.            1     73    256   377  0.660   0.060  2.591
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

The router does not respond to ntp queries when I use ntpd or ntpdate on a linux machine. I have verified using debugging (and the ACL logging) that the packets do arrive at the router and are seen/processed by the NTP code and that they are matched against the relevant ACL.

Having only "server" or "serve-only" configured does not make a difference.

If I change IPV4-ACL-NTP-PEER to include the client IP, the router responds.

I have read a number of different documents/guides and as far as I can understand, I should not need (and not not want) to put a client in the peer ACL.

(I am mainly trying to understand WHY it works like this and what I am doing wrong, not just put the IP in the peer ACL and "get it working".)

I do not control the upstream NTP server and can not use authentication. I also do not control (most) of the clients.

Answer 1

After doing a "sidegrade" from 15.2M to 12.2SRE on the router, the following configuration now works:

access-list 80 permit <UP.STREAM.NTP.SERVER> log
access-list 81 permit <MY.CLIENT.NETWORK> log
ntp logging
ntp access-group peer 80
ntp access-group serve-only 81
ntp update-calendar
ntp server <UP.STREAM.NTP.SERVER>

..of course, going from 15.2M to 12.2SRE means there is no longer any IPv6 support, but it proves that the issue is an IOS regression. I am going to try the latest 15.2M as soon as possible and then open a ticket with the TAC if the issue persists there.