[c-nsp] New feature, can't find it documented - NTP using DNS

[Jared Mauch]

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
>