RME 4.2: bogus Out-of-Sync report

[yjdabear]

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?

[yjdabear]

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]

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]

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]

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)