Mailing List Archive: Cisco: NSP

New feature, can't find it documented - NTP using DNS

Index | Next | Previous | View Threaded

Charles.Church at harris

Nov 23, 2009, 6:23 AM

Post #1 of 11 (1651 views)
Permalink

New feature, can't find it documented - NTP using DNS

Hey all,

Ran across this by accident on a 871 running 12.4(24)T2:

DE-Atlanta(config)#ntp server ?
A.B.C.D IP address of peer
WORD Hostname of peer
X:X:X:X::X IPv6 address of peer
ip Use IP for DNS resolution
ipv6 Use IPv6 for DNS resolution
vrf VPN Routing/Forwarding Information

DE-Atlanta(config)#ntp server ip ?
WORD Hostname of peer

DE-Atlanta(config)#ntp server ip pool.ntp.org ?
burst Send a burst when peer is reachable
iburst Send a burst when peer is unreachable
key Configure peer authentication key
maxpoll Maximum poll interval
minpoll Minimum poll interval
prefer Prefer this peer when possible
source Interface for source address
version Configure NTP version
<cr>

DE-Atlanta(config)#ntp server ip pool.ntp.org
Translating "pool.ntp.org"...domain server (12.127.16.67) [OK]

DE-Atlanta#sh run | i ntp
ntp server ip pool.ntp.org
ntp server 64.73.32.134
ntp server 207.46.197.32
DE-Atlanta#sh ntp ass

address ref clock st when poll reach delay offset disp
~38.229.71.1 192.168.0.16 2 3 64 7 0.000 658.174 1938.4
~64.73.32.134 4.213.182.128 2 40 64 3 0.000 665.796 3937.7
~207.46.197.32 169.229.70.64 3 44 64 3 0.000 655.923 3949.7
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
DE-Atlanta#
-----------------------------------------------------------------------------------------------------------------
Been wanting this for years. Any idea what this feature is called? Didn't see anything in the release notes or feature navigator about it. Curious if it honors DNS TTLs, etc. I do see that it's negotiated V4 on these peers, but I don't think it's a function of NTP V4.

Thanks,

Chuck

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

oboehmer at cisco

Nov 23, 2009, 7:53 AM

Post #2 of 11 (1618 views)
Permalink

Re: New feature, can't find it documented - NTP using DNS [In reply to]

> Hey all,
>
> Ran across this by accident on a 871 running 12.4(24)T2:
>
>
> DE-Atlanta(config)#ntp server ip ?
> WORD Hostname of peer
>
> DE-Atlanta(config)#ntp server ip pool.ntp.org ?
> burst Send a burst when peer is reachable
> iburst Send a burst when peer is unreachable
> key Configure peer authentication key
> maxpoll Maximum poll interval
> minpoll Minimum poll interval
> prefer Prefer this peer when possible
> source Interface for source address
> version Configure NTP version
> <cr>
>
> Been wanting this for years. Any idea what this feature is called?
Didn't
> see anything in the release notes or feature navigator about it.

Looks like it's part of the NTPv4 feature commit.

> Curious if
> it honors DNS TTLs, etc. I do see that it's negotiated V4 on these
peers,
> but I don't think it's a function of NTP V4.

I think the config doesn't honor TTL, so the implementation is rather
"basic"..

oli
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

justin at justinshore

Nov 23, 2009, 12:19 PM

Post #3 of 11 (1604 views)
Permalink

Re: New feature, can't find it documented - NTP using DNS [In reply to]

Oliver Boehmer (oboehmer) wrote:
> I think the config doesn't honor TTL, so the implementation is rather
> "basic"..

Would that be basic as in it only resolves the FQDN once when the config
is entered, once per boot, or possibly on a schedule later on in the
lifecycle of the router?

I noticed other changes between 24T1 and 24T2 that bit me this weekend
when I upgraded 2 routers that are my NTP servers. First off all the
NTP config that was moved way up in the config in an earlier release
suddenly got moved back to where it was. Not a big deal but it makes
RANCID unhappy. Second, and this is a bad problem, it removed my "ntp
source <int>" command from the config. I didn't notice until today that
my NTP servers weren't syncing up right. Reviewing the RANCID diff
pointed out the problem.

This happened on both of the routers that I upgraded from 24T1 to 24T2.
I haven't rebooted either router to see if the problem will happen
after every 24T2 reboot or if it's tied to the moving around of the
config between 24T1 and 24T2. My guess would be the latter, at least I
hope that's the case. I've contacted TAC to report this bug.

Justin

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

jared at puck

Nov 23, 2009, 12:36 PM

Post #4 of 11 (1606 views)
Permalink

Re: New feature, can't find it documented - NTP using DNS [In reply to]

On Nov 23, 2009, at 3:19 PM, Justin Shore wrote:

> I noticed other changes between 24T1 and 24T2 that bit me this weekend when I upgraded 2 routers that are my NTP servers. First off all the NTP config that was moved way up in the config in an earlier release suddenly got moved back to where it was. Not a big deal but it makes RANCID unhappy. Second, and this is a bad problem, it removed my "ntp source <int>" command from the config. I didn't notice until today that my NTP servers weren't syncing up right. Reviewing the RANCID diff pointed out the problem.
>
> This happened on both of the routers that I upgraded from 24T1 to 24T2. I haven't rebooted either router to see if the problem will happen after every 24T2 reboot or if it's tied to the moving around of the config between 24T1 and 24T2. My guess would be the latter, at least I hope that's the case. I've contacted TAC to report this bug.

Cisco does not have a coherent config order that will be output.

This is something people need to continue to repeat to Cisco that this stuff actually matters. The folks that do testing of software rarely perform anything from a non-console connection. This has implications on the ability for them to watch and control this. People don't understand that moving lines of code have real-world implication on diff based utilities used to manage routers.

*sigh*

- Jared
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

mtinka at globaltransit

Nov 23, 2009, 6:38 PM

Post #5 of 11 (1609 views)
Permalink

Re: New feature, can't find it documented - NTP using DNS [In reply to]

On Tuesday 24 November 2009 04:36:58 am Jared Mauch wrote:

> Cisco does not have a coherent config order that will be
> output.

Like when we moved from SRC3 to SRC5 earlier this month, RANCID
reported minor but strange changes to the configuration order,
e.g., the 'police' command under a policy-map has been given one
extra <TAB> indent. This looks very weird if you also have a 'set
mpls experimental' command right above it because it now looks like
the 'police' command is a sub-command of the 'set mpls experimental'
command:

policy-map XXX-XXX-XXX-60Mbps
description XXX XXX XXX
class XXX-XXX-XXX
set dscp 63
set mpls experimental imposition 0
police cir 60000000 bc 11250000 be 22500000 conform-action transmit exceed-action drop violate-action drop

Previously, as in the case of moving from SXH3 to SXI2a also, IPv6
static routing and ACL commands keep moving up and down the
configuration.

I wouldn't be surprised if this has been noticed and gets
fixed in SRC6 or later, and then we have RANCID crying all over
again.

Mark.

Attachments:

signature.asc (0.82 KB)

justin at justinshore

Nov 23, 2009, 7:43 PM

Post #6 of 11 (1603 views)
Permalink

Re: New feature, can't find it documented - NTP using DNS [In reply to]

Jared Mauch wrote:
> On Nov 23, 2009, at 3:19 PM, Justin Shore wrote:
>
>> I noticed other changes between 24T1 and 24T2 that bit me this weekend when I upgraded 2 routers that are my NTP servers. First off all the NTP config that was moved way up in the config in an earlier release suddenly got moved back to where it was. Not a big deal but it makes RANCID unhappy. Second, and this is a bad problem, it removed my "ntp source <int>" command from the config. I didn't notice until today that my NTP servers weren't syncing up right. Reviewing the RANCID diff pointed out the problem.
>>
>> This happened on both of the routers that I upgraded from 24T1 to 24T2. I haven't rebooted either router to see if the problem will happen after every 24T2 reboot or if it's tied to the moving around of the config between 24T1 and 24T2. My guess would be the latter, at least I hope that's the case. I've contacted TAC to report this bug.
>
> Cisco does not have a coherent config order that will be output.
>
> This is something people need to continue to repeat to Cisco that this stuff actually matters. The folks that do testing of software rarely perform anything from a non-console connection. This has implications on the ability for them to watch and control this. People don't understand that moving lines of code have real-world implication on diff based utilities used to manage routers.

Yeah, I've noticed config lines move after code updates before too and
it's really annoying. Usually it's something small like adding or
removing exclamation points. Occasionally things get re-ordered. This
was the first wholesale move of all related lines I've seen in a while.

I talked with TAC about the problem. It took a while to get the
engineer to understand the problem but I think we got there. If not I
will requeue. He pointed me to a known bug: CSCsx21595. He kept
saying that this problem was fixed in 24T2 and only affected 3800s. To
the best of my knowledge the problem (removal of existing 'ntp source'
config line) was created by 24T2. I never encountered it prior to that
on any of my routers, including those running 24T and 24T1. I also
experienced the problem on a 7206 (G1). Clearly this isn't isolated to
just 3800s. I haven't had a chance to test it on anything else but I
fully expect to see the same results on all routers I test it on. I
have no reason to expect otherwise.

Anyway, the problem is known. I'll give it a few days and push on it if
nothing happens. To recreate the problem I imagine one would just need
to have a basic NTP config with the ntp source interface defined as a
virtual interface (the bug said it depended on that) so use an SVI or
loopback. Then upgrade to 24T2. I suspect one would need to upgrade
from 24T first and then upgrade to 24T2. I suspect the problem is in
the parser when IOS first loads the config from the older release. I'd
bet money that the startup-config was intact when I booted and that only
the running-config was altered after that first boot.

Justin

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

justin at justinshore

Nov 23, 2009, 7:50 PM

Post #7 of 11 (1601 views)
Permalink

Re: New feature, can't find it documented - NTP using DNS [In reply to]

Mark Tinka wrote:
> Like when we moved from SRC3 to SRC5 earlier this month, RANCID
> reported minor but strange changes to the configuration order,
> e.g., the 'police' command under a policy-map has been given one
> extra <TAB> indent. This looks very weird if you also have a 'set
> mpls experimental' command right above it because it now looks like
> the 'police' command is a sub-command of the 'set mpls experimental'
> command:
>
> policy-map XXX-XXX-XXX-60Mbps
> description XXX XXX XXX
> class XXX-XXX-XXX
> set dscp 63
> set mpls experimental imposition 0
> police cir 60000000 bc 11250000 be 22500000 conform-action transmit exceed-action drop violate-action drop
>
> Previously, as in the case of moving from SXH3 to SXI2a also, IPv6
> static routing and ACL commands keep moving up and down the
> configuration.
>
> I wouldn't be surprised if this has been noticed and gets
> fixed in SRC6 or later, and then we have RANCID crying all over
> again.

I forgot to mention the other non-NTP config change I noticed in 24T2.
My IOS object-groups were changed. When I first created object-groups
in IOS there wasn't an option to define just a single host. It was
added in a later T release. To get around this I defined a range of a
single IP (ie, 1.2.3.4 to 1.2.3.4). I never went back and changed them
after the 'host' option was added. When I upgraded to 24T2 it changed
all those range lines to host lines. Not a bad change but another
unexpected one.

Justin

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

oboehmer at cisco

Nov 23, 2009, 10:37 PM

Post #8 of 11 (1600 views)
Permalink

Re: New feature, can't find it documented - NTP using DNS [In reply to]

> Oliver Boehmer (oboehmer) wrote:
> > I think the config doesn't honor TTL, so the implementation is
rather
> > "basic"..
>
> Would that be basic as in it only resolves the FQDN once when the
config
> is entered, once per boot, or possibly on a schedule later on in the
> lifecycle of the router?

the name seems to be resolved every time the command is parsed, i.e.
when it is entered and when the router reloads.

oli

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

justin at justinshore

Nov 24, 2009, 7:49 PM

Post #9 of 11 (1593 views)
Permalink

Re: New feature, can't find it documented - NTP using DNS [In reply to]

> I talked with TAC about the problem. It took a while to get the
> engineer to understand the problem but I think we got there. If not I
> will requeue. He pointed me to a known bug: CSCsx21595. He kept
> saying that this problem was fixed in 24T2 and only affected 3800s. To
> the best of my knowledge the problem (removal of existing 'ntp source'
> config line) was created by 24T2. I never encountered it prior to that
> on any of my routers, including those running 24T and 24T1. I also
> experienced the problem on a 7206 (G1). Clearly this isn't isolated to
> just 3800s. I haven't had a chance to test it on anything else but I
> fully expect to see the same results on all routers I test it on. I
> have no reason to expect otherwise.
>
> Anyway, the problem is known. I'll give it a few days and push on it if
> nothing happens. To recreate the problem I imagine one would just need
> to have a basic NTP config with the ntp source interface defined as a
> virtual interface (the bug said it depended on that) so use an SVI or
> loopback. Then upgrade to 24T2. I suspect one would need to upgrade
> from 24T first and then upgrade to 24T2. I suspect the problem is in
> the parser when IOS first loads the config from the older release. I'd
> bet money that the startup-config was intact when I booted and that only
> the running-config was altered after that first boot.

I did some testing in the lab tonight. This problem is certainly not
limited to 3845s. I can recreate this problem on every single IOS
device I tried that can run 12.4T without fail. I recreated the problem
on an 871W, 881, 2811, 2821, and 2 3845s.

The problem appears to happen when the device is running a 24T release
prior to 24T2 (ie, only 24T or 24T1) and upgrades to 24T2. I tried
upgrading from 22T to 24T2 and the problem did not appear. For grins I
fixed a 24T2 config and then downgraded to 24T and 22T on the 2 3845s.
The problem didn't show up. I also did the same thing with the 3845s
running 24T to 22T so that the NTP config would be in the weird location
right above the interface config prior to the downgrade. THE PROBLEM
CAME BACK. I think that confirms my theory that the NTP config being
moved ahead of the interface config is what's causing this problem.
When the parser on a IOS version that doesn't place the NTP config ahead
of the interface config reads the NTP config, the virtual interfaces
haven't yet been created. Thus it rejects that config line. That's my
theory and tonight's testing seems to support it. Who knows for sure.
I'll let Cisco figure it out.

At boot the 'ntp source' command is stripped out every time. During the
boot sequence right before the "Press RETURN to get started" line this
error is printed:

ntp source Loopback0
^
% Invalid input detected at '^' marker.

Note how it points specifically to the number in the interface name.
That makes me wonder if the regex in the boor parser was screwed up to
expect a space between the interface type and number. It's a thought.

I've run out of routers to test this on that can run 12.4(24)T2. I
might be able to try it on a 7201 and 7206 later this week but I fully
expect the same results. It's a parser bug that needs to be squashed,
though it may not manifest again if the DEs don't ever arbitrarily move
the NTP config around in the running-config. I'm convinced that it's
the cause or certainly part of the problem.

Justin

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

jared at puck

Nov 24, 2009, 9:34 PM

Post #10 of 11 (1594 views)
Permalink

Re: New feature, can't find it documented - NTP using DNS [In reply to]

There is also the issue of the fact that the parser has a startup mode
vs a running mode that may contribute to the error seen. Another case
where this random experience has hurt operators.

Jared Mauch

On Nov 24, 2009, at 10:49 PM, Justin Shore <justin [at] justinshore>
wrote:

>> I talked with TAC about the problem. It took a while to get the
>> engineer to understand the problem but I think we got there. If
>> not I will requeue. He pointed me to a known bug: CSCsx21595. He
>> kept saying that this problem was fixed in 24T2 and only affected
>> 3800s. To the best of my knowledge the problem (removal of
>> existing 'ntp source' config line) was created by 24T2. I never
>> encountered it prior to that on any of my routers, including those
>> running 24T and 24T1. I also experienced the problem on a 7206
>> (G1). Clearly this isn't isolated to just 3800s. I haven't had a
>> chance to test it on anything else but I fully expect to see the
>> same results on all routers I test it on. I have no reason to
>> expect otherwise.
>> Anyway, the problem is known. I'll give it a few days and push on
>> it if nothing happens. To recreate the problem I imagine one would
>> just need to have a basic NTP config with the ntp source interface
>> defined as a virtual interface (the bug said it depended on that)
>> so use an SVI or loopback. Then upgrade to 24T2. I suspect one
>> would need to upgrade from 24T first and then upgrade to 24T2. I
>> suspect the problem is in the parser when IOS first loads the
>> config from the older release. I'd bet money that the startup-
>> config was intact when I booted and that only the running-config
>> was altered after that first boot.
>
> I did some testing in the lab tonight. This problem is certainly
> not limited to 3845s. I can recreate this problem on every single
> IOS device I tried that can run 12.4T without fail. I recreated the
> problem on an 871W, 881, 2811, 2821, and 2 3845s.
>
> The problem appears to happen when the device is running a 24T
> release prior to 24T2 (ie, only 24T or 24T1) and upgrades to 24T2.
> I tried upgrading from 22T to 24T2 and the problem did not appear.
> For grins I fixed a 24T2 config and then downgraded to 24T and 22T
> on the 2 3845s. The problem didn't show up. I also did the same
> thing with the 3845s running 24T to 22T so that the NTP config would
> be in the weird location right above the interface config prior to
> the downgrade. THE PROBLEM CAME BACK. I think that confirms my
> theory that the NTP config being moved ahead of the interface config
> is what's causing this problem. When the parser on a IOS version
> that doesn't place the NTP config ahead of the interface config
> reads the NTP config, the virtual interfaces haven't yet been
> created. Thus it rejects that config line. That's my theory and
> tonight's testing seems to support it. Who knows for sure. I'll let
> Cisco figure it out.
>
> At boot the 'ntp source' command is stripped out every time. During
> the boot sequence right before the "Press RETURN to get started"
> line this error is printed:
>
> ntp source Loopback0
> ^
> % Invalid input detected at '^' marker.
>
> Note how it points specifically to the number in the interface name.
> That makes me wonder if the regex in the boor parser was screwed up
> to expect a space between the interface type and number. It's a
> thought.
>
> I've run out of routers to test this on that can run 12.4(24)T2. I
> might be able to try it on a 7201 and 7206 later this week but I
> fully expect the same results. It's a parser bug that needs to be
> squashed, though it may not manifest again if the DEs don't ever
> arbitrarily move the NTP config around in the running-config. I'm
> convinced that it's the cause or certainly part of the problem.
>
> Justin
>
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

gert at greenie

Nov 24, 2009, 11:39 PM

Post #11 of 11 (1592 views)
Permalink

Re: New feature, can't find it documented - NTP using DNS [In reply to]

Hi,

On Tue, Nov 24, 2009 at 09:49:37PM -0600, Justin Shore wrote:
> At boot the 'ntp source' command is stripped out every time. During the
> boot sequence right before the "Press RETURN to get started" line this
> error is printed:
>
> ntp source Loopback0
> ^
> % Invalid input detected at '^' marker.
>
> Note how it points specifically to the number in the interface name.

Well, "Loopback" is fine, but there is no Loopback *0* yet. So it makes
sense to complain about the 0...

(Well, there is no Loopback at all, at this point, but the parser might
not be *that* smart).

[..]
> I've run out of routers to test this on that can run 12.4(24)T2. I
> might be able to try it on a 7201 and 7206 later this week but I fully
> expect the same results. It's a parser bug that needs to be squashed,
> though it may not manifest again if the DEs don't ever arbitrarily move
> the NTP config around in the running-config. I'm convinced that it's
> the cause or certainly part of the problem.

I don't think it's a parser bug - it's a confgen bug. The NTP config
being stored before the interface config will inevitably result in exactly
the problem you have seen: you can't reference "lo0" because it does not
exist yet.

(Stupid enough that such things are done carelessly, but I can't see ANY
justification for doing this in between T sub-releases. T1->T2 should
only ever get bug fixes, not gratious code changes "just because we can").

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert [at] greenie
fax: +49-89-35655025 gert [at] net

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads