[c-nsp] New feature, can't find it documented - NTP using DNS
Jared Mauch
jared at puck.nether.net
Wed Nov 25 00:34:26 EST 2009
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.com>
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
>
More information about the cisco-nsp
mailing list