Re: NTP changes in 12.4T?

Hi Bogdan,

Since IOS 12.4(20)T Cisco implemented NTP based on IETF draft for NTPv4 so I
think it may be the case.
More info here:
http://www.cisco.ws/en/US/prod/collateral/iosswrel/ps8802/ps6968/ps6441/produ
ct_bulletin_c25-409474.html#wp9002575

HTH,

--
Piotr Matusiak
CCIE #19860 (R&S, Security)
Technical Instructor
website: www.MicronicsTraining.com
If you can't explain it simply, you don't understand it well enough -
Albert Einstein
2010/2/27 Bogdan Sass <bogd.no.spam_at_gmail.com>
>     [ I have no idea if this message made it to the list the first time
> I sent it - my apologies if this ends up being a double post... ]
>
> -------- Original Message --------
> Subject:        NTP changes in 12.4T?
> Date:   Fri, 26 Feb 2010 20:36:58 +0200
> From:   Bogdan Sass <bogdan.sass_at_catc.ro>
> To:     CCIE Groupstudy <ccielab_at_groupstudy.com>
>
>
>
>      I have been struggling for a few days now in getting a (very, VERY
> simple) NTP configuration to work. IOS - 12.4(22)T2.
>      I initially tried this with my students, using a router as server
> and an ASA as client. After seeing that this doesn't work, I tried using
> routers (2811) for both the client and the server. Still no go...
>
>      The configs are as follows:
>      -server:
> R1#sh run | i ntp
> ntp authentication-key 1 md5 1511021F0725 7
> ntp authenticate
> ntp master 4
>
>      -client:
> R2#sh run | i ntp
> ntp authentication-key 1 md5 00071A150754 7
> ntp authenticate
> ntp trusted-key 1
> ntp server 10.0.0.1 key 1
>
>      First problem - is it just me, or is the "debug ntp validity"
> missing from this IOS version? (I find that odd, given that it was one
> of the best tools for troubleshooting NTP...)
>
>      Second problem - notice the debug output on the client:
>
> R2#
>
> *Feb 26 18:08:02.175: NTP Core(DEBUG): ntp_receive: message received
> *Feb 26 18:08:02.175: NTP Core(DEBUG): ntp_receive: peer is 0x4707FD10,
> next action is 1.
> *Feb 26 18:08:02.175: NTP Core(NOTICE): ntp_receive: dropping message:
> crypto-NAK.
>
>      Luckily, after a couple of days of messing around with the configs,
> I came across this article:
> http://ccietobe.blogspot.com/2009/02/ntp-how-long-is-too-long.html
>
>      I must admit - it never even crossed my mind to enable "ntp trusted
> key" on the server (given that in NTP, it is the server that needs to
> authenticate itself to the clients). Well, I add the command on the
> server, and amazingly enough...
>
> Feb 26 18:17:10.568: NTP message received from 10.0.0.1 on interface
> 'FastEthernet0/0' (10.0.0.2).
> Feb 26 18:17:10.568: NTP Core(DEBUG): ntp_receive: message received
> Feb 26 18:17:10.568: NTP Core(DEBUG): ntp_receive: peer is 0x4707FD10,
> next action is 1.
> Feb 26 18:17:10.568: NTP Core(DEBUG): receive: packet given to
> process_packet
>
>      Looks good.... and after a few minutes...
> R2#sh ntp status
> Clock is synchronized, stratum 5, reference is 10.0.0.1
>
>      Even more - after this minor addition, even the ASA (second ntp
> client) gets the time correctly:
> ASA1# sh ntp status
> Clock is synchronized, stratum 5, reference is 10.0.0.1
>
>      It looks like the server no longer uses a key that is not marked as
> "trusted" in order to authenticate itself to the clients. But there was
> absolutely nothing in the server debugs that would indicate this problem
> (all I could see on the server was "packet received"... "doing fast
> answer to client").
>
>      As far as I can remember, before switching to this IOS I could use
> the configuration described here (
> http://www.internetworkexpert.com/resources/01700369.htm ) without any
> problems. So my second question is - is this a new change in the IOS?
> And more important - is this documented anywhere? (all I could find on
> the DocCD is the NTP client configuration)
>
>      And maybe a third question - if you need "trusted-key" on both
> client and server, what is the point of having this command anyway? I
> thought the whole idea behind having two commands (ntp
> authentication-key vs ntp trusted-key) was that you could have a set of
> keys used for authenticating received ntp packets (trusted keys), and a
> different set of keys used to authenticate packets sent to clients
> (untrusted keys).
>
>      Thank you,
>
> --
> Bogdan Sass
> CCAI,CCSP,JNCIA-ER,CCIE #22221 (RS)
> Information Systems Security Professional
> "Curiosity was framed - ignorance killed the cat"
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net