Cisco’s NTP authentication is b0rked

 | 25 Jul 2006 11:35

Master:
ntp authentication-key 14 md5 ladida
ntp authenticate (see comment below)
ntp source Loopback0
ntp master
ntp server source FastEthernet0/0
ntp trusted-key 14 (see comment below)

Client:
ntp authentication-key 14 md5 ladida
ntp authenticate
ntp source Loopback0
! ntp trusted-key 14 (only required when not specifying a key on the line below)
ntp server key 14

Debug on the client:

21:05:03: NTP: rcv packet from 134.14.1.1 to 134.14.7.7 on Loopback0:
21:05:03: leap 0, mode 4, version 3, stratum 2, ppoll 64

21:05:03: Authentication key 0
21:05:03: NTP: packet from 134.14.1.1 failed validity tests 10
21:05:03: Authentication failed
21:06:06: NTP: xmit packet to 134.14.1.1:
21:06:06: leap 3, mode 3, version 3, stratum 0, ppoll 64

21:06:06: Authentication key 14

The Client does send authenticated packets but the Master doesn’t. Mind you configuring a ‘peer’ is symmetric (same stratum) and ‘server’ is asymmetric (ntp stratum hierarchy). Apparently Cisco knows about it for years but it’s too low a priority to fix it, so don’t bother running to TAC with this…

Even configuring peers so one can set the key on the master doesn’t help. The authentication error disappears but no association forms.

%d bloggers like this: