Thanks for your input.
In my case, the issue with CSCvo33423 is not just the spam in the console or logs, but the side-effect it has on my monitoring system.
I use Icinga for monitoring, and it raises an alert whenever it detects that the running-config differs from the startup-config. This check is based either on syslog events (like %SYS-5-CONFIG_P: Configured programmatically by process EPM IAL) or on the SNMP counters from CISCO-CONFIG-MAN-MIB (ccmHistoryRunningLastChanged vs ccmHistoryStartupLastChanged).
The problem is:
Every time the EPM IAL process triggers these logs, Icinga interprets it as if the configuration had been changed but not saved.
As a result, I get a false alarm in the monitoring, even though no real configuration changes were made.
Regardless of not changing the log records so that the message does not appear, when I give the ‘show running-config’ command, I still see as if the changes had been executed.
So for me it’s not only about suppressing “useless spam” for cosmetic reasons, but about preventing false positives in the monitoring system.
I could use a logging discriminator on the switch, but that won’t prevent the SNMP counters from being updated. On the other hand, if I adjust my Icinga checks, I risk ignoring legitimate configuration changes.
That’s why I was hoping this bug would eventually be fixed properly: because right now the monitoring integration is affected, not just the log output.
