How to Monitor show isis neighbors Output in SolarWinds NCM Using a Custom Config Type?

Hi THWACK Community,

I’m trying to build a lightweight solution in SolarWinds NCM to monitor IS-IS neighbor changes using the command show isis neighbors. My goal is to regularly pull this output from our routers, save it in SolarWinds under a custom config type, and detect changes to generate alerts (e.g., when an IS-IS adjacency drops or forms).

What I’ve Done:

I created a new Config Type called ISIS in NCM.
I created an Execute Command Script job with the following content:
diff
CopyEdit
!CONFIGTYPE: ISISshow isis neighbors
The job runs successfully and shows output when tested.
I verified that CLI credentials work and I can download the running config from the same device without issues.
Transfer Status shows “Success”, but when I go to Configuration Management > Device > Config Types, I don’t see the ISIS config type or any stored outputs.
I also tried adding an echo line to force output like this:
bash
CopyEdit
!CONFIGTYPE: ISISecho "=== ISIS Neighbors ==="show isis neighbors

What I Want to Achieve:

Store the output of show isis neighbors under a dedicated ISIS config type
Use config comparison and change detection to track IS-IS neighbor flaps or changes
(Eventually) Set up an alert when that output changes

My Question:

Is this the right method for tracking CLI command output like this in SolarWinds?
Is there something I’m missing that would allow the ISIS config type to appear and store this output?
Are there known limitations with using !CONFIGTYPE: for non-standard CLI commands?

Any help or examples from the community would be much appreciated!

Find more posts tagged with

Accepted answers

All comments

sja

Sound like a function for snmp trap or syslog ..

By the way I find alerting the ISIS neighbor status redundant ...because it's directly running on L2

It's good enough to monitor interfaces status specifically if that p2p ISIS between 2 devices...

sironjs

Thanks for the input, Sja!

Yeah, I get that IS-IS runs directly on L2 and interface monitoring can already give a good indication of link status. I’m just exploring if I can catch neighbor-level changes (like adjacency flaps) more explicitly — especially in cases where the interface stays up but the IS-IS session drops due to config issues or mismatched parameters.

I considered SNMP traps and syslogs too, but I was hoping to keep it all within NCM using config change detection, since we already use it for other CLI-based tracking.

Appreciate the insight though — might be worth revisiting the SNMP/syslog route if this doesn’t pan out. If anyone’s tried something similar with NCM or has a workaround, I’d love to hear more!