Your ignorance is only superseded by your arrogance. You are misinformed and simultaneously believe you are more intelligent than the engineers that work for Cisco. Quite laughable I must say.

If you had bothered to enter the following two commands into the device acting as the NTP server (i.e. master) it would have worked just fine:

ntp authenticate
ntp trusted-key 14

How do you expect NTP authentication to work if it is not even enabled on the master? If you had actually called TAC they would have quickly pointed out the missing commands.

Well, I can’t deny neither ignorance nor arrogance. Though the latter is something I’d rather be rid of than the first. The more I learn the more I realise how little I know, somehow this doesn’t always translate into a humble approach. I stand corrected on that account, thank you Frank. I’ll add your suggested lines to the post but feel compelled to add the following as well:

During the bootcamp I followed we ran into issues with NTP and authentication. It worked and then one by one all of us ran into issues where authentication would fail and the NTP peering broke. Our tutor confirmed that this was quite common and was known to Cisco. This post was intended to highlight that, it seems I failed at that. So once I get access to some equipment to test this on I’ll have to finalise this post and either stand completely corrected or prove the point I was trying to make.

My current personal take/recollection is that I probably did use the suggested lines when testing, though removed them in an attempt to reconfigure things trying to get NTP authentication to work again. What ever I did, I either did not do my research propperly or I posted too hastilly. As I’m for open communication I do not intend to hide my mistakes as we all make those. I’d rather humble myself and thank Frank for his correction.

To be comtinued…

[…] just been taught a lesson in humility and authorship. My post about Cisco’s NTP authentication implementation received a comment from a certain Frank. I’ve added my comment and need to […]

Here are working configs for NTP client and NTP server.
================================
hostname Server
!
ntp logging
ntp authentication-key 2 md5 071C244F5C0C0D 7
ntp clock-period 17179887
ntp master 10
!
! Upstream non-authenticating NTP server
ntp server 192.168.200.193
================================
hostname Client
!
ntp logging
ntp authentication-key 2 md5 071C244F5C0C0D 7
ntp authenticate
ntp trusted-key 2
ntp server 10.0.0.1 key 2 prefer
================================

I’ll write an in-depth NTP-related article for the IP Corner and will let you know when it’s posted. If you send me an e-mail (use “Send message to Ivan” in my bio page), I’ll send you a preview copy.

I have tested NTP a lot lately and hope I can shed some light on what I think is helpful or just really strange. Basically it mirrors Ivan in the last post. This is what I have and it works:

master:

ntp authentication-key 420 md5 cisco
ntp master 3

client

ntp authentication-key 420 md5 cisco
ntp trusted-key 420
ntp authenticate
ntp server 192.168.100.2 key 420

I don’t need “ntp authenticate” or “ntp trusted-key” on the master.

Packet captures show that the master and client are both sending hashes.
Debug shows client and master both send key 420.
Client is synced.

If I change either of the keys (master or client) authentication fails.
This would seem to be proof of authentication.

If I remove the “ntp trusted-key 420” from the client it fails.

If I remove “ntp authenticate” from client it still works. Go figure…
If I remove “ntp authenticate” from client and change the key it fails. Go figure…

I really think all you needed was “ntp trusted-key 14” on your client.
That should have worked…maybe when you get time you can try it again…