cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
956
Views
5
Helpful
18
Replies

RME 4.2: bogus Out-of-Sync report

yjdabear
VIP Alumni
VIP Alumni

A device is listed in Out-of-sync summary, but upon closer inspection. The Startup and Running configs are really identical, except a chunk that starts with the following is not properly recognized in the Running config:

alias exec sniffer show interfaces description | include sniffer

!

line con 0

exec-timeout 15 0

...

As a result, the Running config has empty

line con 0 entries:

Line-Line con 0

Line-Line vty 0 4

Line-Line vty 5 15

A manualy Sync Archive doesn't get RME to refetch the Startup config because it sees no change. Is this any way to remedy this?

18 Replies 18

Joe Clarke
Cisco Employee
Cisco Employee

If you remove the alias command, write mem, and resync, does this problem get corrected?

Thanks. I'll let the users know, but I'm not sure they'd be willing to try it.

Does this mean its a bug with Config Archive's handling of Running Config, which seems to be different than handling Startup Config?

Probably not. The banner termination issue is very localized to the banner delimiter. Both the startup and running configs get the same banner delimiter treatment.

I don't know yet. I am suspecting the '|' character which is why I suggested trying to remove it temporarily. Both running and startup configs are processed the same (though there have been bugs with this).

I opened a TAC case to try to get a bug filed. The TAC engineer noticed a double quote character at the end of the MOTD in the Startup config, which does not exist in the actual Startup config.

Well, that really looks like the same problem,

assuming that SCP is being used.

If you get a bug filed, would you please post the ID here?

Good luck!

I agree. Is CSCsu99748 the bug ID for the SCP bug?

Well, that's beyond my knowledge. Judging from the description for CSCsu99748, I'd say no, because that's clearly flagged as a TFTP problem, while I found an SCP bug.

It may or may not be the same code causing these two malfunctions.

Perhaps Joe can shed some light on this?

The device on which I'm getting this is also afflicted by CSCsu21040, so RME couldn't have been able to get into enable mode. So if it's a TFTP bug, it fits the bill too =P

Here's my other thread that unearths CSCsu21040:

http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=Network%20Management&topicID=.ee71a02&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cd22c80

Well, then RME will fall back to whatever protocol you have configured next for configuration fetch.

To find out what has been used, you may click on the numbers under Config Mgmt > Archive Mgmt > Config Fetch Protocol Usage

The bug, CSCsu99748, is a likely candidate if you have multiple multi-line banners, and you're using TFTP as the config fetch protocol. It will result in out-of-sync configs.

Does it have to multiple multi-line banners? The device here only has one multi-line banner. Also, it's strange that only this device's Running config is hit with the TFTP bug. There's another 6500 running the same code that's been scot-free.

I think you're mixing too many issues here. You've brought up the 6500 enable username bug on this thread as well, and now you're mentioning a 3750. It's probably time you open a TAC service request with the original problem description, running and startup configs from the affected device, and screenshots illustrating the problem.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: