cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1045
Views
0
Helpful
3
Replies

Should I be using the SNMP Query probe?

Josh Morris
Level 3
Level 3

I am running v2.2 patch 14.

I currently am using the following profiling probes: HTTP, Radius, NMAP, SNMPQuery, AD. I have a total endpoint database of ~41,000 endpoints, with only about 18,000 active. As I go through my contect visibility trying to clean pu stale endpoints, I see that I have 19,000 endpoints learned via Radius, and another 19,000 learned by SNMP. I was able to see this by exporting the entire endpoint database from the CLI.

 

Many of these show up as inactive for long periods, and show no relevant profiling info. (See attached image). This leads me to question whether or not the SNMPQuery profile is actually helping me. I do think it is providing valuable information for some endpoints, but I think the bulk of what it is doing is just clogging up my context visibility with stale endpoints. 

 

I'm thinking that since I'm using NMAP with the Common Ports selected, that I can grab SNMP info from unknown or other devices using the NMAP scan action. Thoughts?

 

 

 

 

1 Accepted Solution

Accepted Solutions

A feature enhancement request that could come from this is a purge policy rule that allows a global exemption for "static identity group = true". Or if there was a user defined description true/false option.

I manually create "Never Purge" rules for static identity groups, and name my static identity groups with an identifiable string. It takes a bit more time setting up, but that way I know I'm not going to purge something that is being used in an authorization policy.

Certainly more than one way to accomplish similar goals, just how I have gone about it.

View solution in original post

3 Replies 3

Damien Miller
VIP Alumni
VIP Alumni
More information is always better from a profiling stand point, assuming you see no issues with load.

The benefit of running the SNMP Query probe is that if device sensor is not working for some reason, it will also grab the same information. It also does periodic polling of the NAD whereas device sensor is auth dependent.

I would handle the stale endpoints via endpoint purge policies.

Thanks for your input. I like your thought of controlling the stale endpoints with endpoint purge rules, but my issue there is how ISE forces you to use profile policies to identify what gets purged. For example, the devices I showed in my attached image would work if I used the 'Unknown' profile. But a rule with the Unknown group would also delete endpoints that I have statically configured to groups. I know that I could put a time limit in the rule to help 'Inactive Days > 90', but I'm hesitant to do anything where a statically configured device would be deleted. 

 

I think if I could create a purge rule that met the following criteria, it would work...but I'm struggling to get the SNMP part working. The rule below should purge the endpoint in the image.

Endpoint Profile = Unknown

Inactive Days >= 30

EndpointSource = SNMPQuery Probe

 

snmp2.PNG

EDIT: I think I figured out how to use the EndpointSource in a purge rule.

snmp3.PNG

A feature enhancement request that could come from this is a purge policy rule that allows a global exemption for "static identity group = true". Or if there was a user defined description true/false option.

I manually create "Never Purge" rules for static identity groups, and name my static identity groups with an identifiable string. It takes a bit more time setting up, but that way I know I'm not going to purge something that is being used in an authorization policy.

Certainly more than one way to accomplish similar goals, just how I have gone about it.