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

[Justin Shore]

> 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