RME 4.2: bogus Out-of-Sync report

Unanswered Question
Feb 18th, 2009

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joe Clarke Wed, 02/18/2009 - 13:25

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

yjdabear Thu, 02/19/2009 - 06:59

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?

Joe Clarke Thu, 02/19/2009 - 15:16

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.

Joe Clarke Thu, 02/19/2009 - 15:15

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).

yjdabear Fri, 02/20/2009 - 12:23

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.

Attachment: 
g.meerkoetter Mon, 02/23/2009 - 03:39

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!

g.meerkoetter Mon, 02/23/2009 - 07:05

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?

yjdabear Mon, 02/23/2009 - 07:31

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

g.meerkoetter Mon, 02/23/2009 - 08:37

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

Joe Clarke Mon, 02/23/2009 - 10:02

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.

yjdabear Mon, 02/23/2009 - 11:04

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.

Joe Clarke Mon, 02/23/2009 - 11:08

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.

yjdabear Mon, 02/23/2009 - 11:18

I made a stealth edit: It's another 6500. No 3750 involved. I've opened a TAC case last week, but TAC is still hung up on what LMS versions/OS I'm on, which I had addressed pre-emptively when I opened the case.

g.meerkoetter Tue, 02/24/2009 - 05:34

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

Joe Clarke Mon, 02/23/2009 - 09:58

No. There is a separate issue when the config is fetched using SCP or RCP. The banner delimiter ('\003') is replaced with '&' in both the startup and running configs. It will not result in an out-of-sync, but it can mess up the banner if you are already using '&' as a delimiter.

g.meerkoetter Tue, 02/24/2009 - 06:31

That's not what I have seen when I tried to use the scp transport. I was not using a "&" anywhere in my configuration. Nevertheless I got an out of sync report, because only the first "\003" delimiter in the motd banner got replaced by an "&". The second one was simply dropped.

See attached screenshot (where the config diff viewer has once again replaced the delimiters by double quotes)

Actions

This Discussion