Cisco ASA Context Discovery (NPM 12.2 & NCM 7.7)

I am having some of the same issues. According to tech support because of the issues with VPN, well at least for me the site to site VPN, there is supposed to be a hot fix or at least one coming out.

Mine says:

CLI Credentials are missing. To get the information about contexts, security levels and inactive site-to-site tunnels, we need CLI Credentials.

Clicking the Add CLI Credentials link it displays leads to the good ole Edit Properties page. The test button for the Connection Profile works find. I use a pre-defined profile, but I also tried manually entering, and no joy.

I tried doing a List Resources and a Rediscover.

I notice that temperatures are wrong, too - 32F, which is 0C, according to my well worn copy of Bubba's Handbook of Rocket Surgery. I think that means it didn't read the sensor.

It also doesn't detect the High Availability setup (failover pair).

The release notes at: NCM 7.7 Release Notes - SolarWinds Worldwide, LLC. Help and Support

Says:

To access CLI settings

    Choose Settings > All Settings.

    Under Product Specific Settings, choose CLI settings.

But that has just the good ole SSH and Telnet timeout settings. No place to enter the CLI credentials.

For NCM, we usually enter SSH connection settings on Product Specific Settings> NCM Settings > Security, Global Defaults, or Advanced - and that all looks ok.

Note that the ASA High Availability is separate from SolarWinds High Availability. So the settings at Product Specific Settings > High Availability Settings are not for the ASA.

The Access List feature also doesn't work. It probably needs the credentials. too.

So I conclude that as of 10/6/2017, the new ASA features in NCM7.7 are brokeded.

ASA monitoring takes a little more effort than the usual network devices. Here is the additional things that I had to do beyond the usual SNMP. When you go to the edit node page, there is a Cisco ASA section for Advanced Cisco ASA monitoring. Here you put an account that has administrative privileges on your ASA device. On the very bottom, there is a CLI template that you have to select Cisco Adaptive Security Appliance. When you do a list resources there is a section on Cisco ASA NetInsight, please make sure this is selected to get information on platform, interfaces and tunnels. Other than that, I don't know what else could be wrong.

Thanks, hoppingubu !

I totally missed that in the Release Notes!

There's a link to: Network Insight for Cisco ASA Firewalls Getting Started Guide - SolarWinds Worldwide, LLC. Help and Support

So much time, so little to do ...

It doenst list all the contexts, I have 50 plus context on the firewall and it only shows one

Not sure if you did any updates recently...

I installed the Core-v2017.3.5320-HotFix1 and all the problems that I was experiencing with Connections, Bandwidth and site to site VPN cleared up and I have all the contexts showing again.

Circling back to this thread.

We now have:

• Orion Platform 2017.3.4 SP4
• NPM 12.2
• NCM 7.7

But on the summary page for the admin context, it still sees itself, and lists one other context as a grey dot - but that context is already in NPM and NCM. We usually have only a single additional context.

So I conclude that Netinsight still has a problem matching contexts it discovered to objects in NPM and/or NCM.

We have 20 Context and they all have status not monitored

The Context is configured, and if I configured again, then I have the Error, node already be monitored.

We Orion platform 2018.2 and NPM 12.3. We are not using NCM.

My Cisco ASA Admin Contexts all show the other contexts as Grey DOTs, instead of green, even though I've added every context individually to NPM and they are working.  Its just not integrated into the admin context.  Does ANYONE have all their contexts showing green in their admin contexts? 

We now have:

• Orion Platform 2018.2 HF6
• NCM 7.8
• NPM 12.3

This still does not work on any of our installs. Still see grey dots when viewing the Admin context.

I wonder if the reason is the hostname on the context. In the System context with a hostname of ourasa01, we have acommand:

prompt hostname state priority context

So in contexts other than Admin, we use simple names like TEST1, TEST2. The CLI prompts with ourasa01-TEST1 and ourasa01-TEST2.

We have ourasa01-TEST1 and ourasa01-TEST2 in DNS, and that's how we monitor those contexts in NPM and NCM.

In the Admin context, NPM sees a grey icon called TEST1 or TEST2. Of course, if we click the grey icon and try to add it, it will conflict with the existing ourasa01-TEST1 and ourasa01-TEST2.

So perhaps this is a matter of renaming the contexts to have the full hostname, and not use the prompt and DNS entries to make it happen.

Thoughts?

Has anyone had any problems renaming a context?

=Foonly=