Cisco Nexus Config Comparasion

Watching.  I see this, too, and not only on Nexus.

I don't have a way to test the theory at present; but there is a known issue with Cisco ASAs doing the same thing, the fix is to add a `terminal width` command to the device template if I remember correctly. You can verify by comparing the default "Cisco IOS" device template to the "Adaptive Security Appliance" one.

Thanks for the info. I read on another post that the "terminal width" command is not valid on the Cisco Nexus so cant be used:

Cisco NXOS-1.3.6.1.4.1.9.ConfigMgmt-Commands

I have a number of Nexus switches.  "Term width" is allowed:

Thanks for the correction.

I have the "terminal width" in the template now, however its still coming up as a config conflict when the start v run configs are in different orders.

What specifically is out of order?   You can customize what Orion ignores while doing a comparison, taking what is showing as a conflict and adding it to that should work.

Hi Craig, when you look at the running and startup config on the nexus we can see some of the config lines don’t match up. For example in the show start config the bfd commands
are on line 23 but in the running configs its on line 50. Due to this when solarwinds backs up the running and start up configs and does a compare its sees them out of sync when in fact they are not  its just the order of the commands are on different lines. I am trying to figure out how in Solarwinds we can ignore this so that it doesn’t flag up as different.

I have that same issue with NCM and a few Machine Types.  In some cases I've been able to edit the Comparison Criteria and get better reporting and alerts.  You can manage that here:

You might also consider having different config comparison jobs--one that only compares the Running-config files, another for only the Startup-config files.  I know, this defeats the purpose of ensuring your running-config and startup-configs are identical.

You might get around that by having a daily NCM Job that issues the "write memory" command to all devices.  If you schedule it to run before NCM downloads the configs, then the two Jobs' reports (running-config changes and startup-config changes) should look good.

But even if you don't write memory regularly, reporting the config change differences between startup-configs should show you changes.

This kluge does not address device manufacturers' differences startup and running config syntax order.  If you figure THAT out, I'm all up for learning what you did to conquer that beastie.

Have you received the resolution for this? I am facing same issue.