- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2018 07:03 AM
Here is my scenario. We have multiple devices with both port 22 and 161 open. I have my Port Probes classification priority set to scan for snmp first and ssh second to prevent devices for which we have no credentials from start loggin authentication errors (switches and routers being the main example). Now the snmp classify is oviously launching but not the Unix classify. When it come to servers, we need to launch all the linux probes, but since the snmp port is open Discovery goes on the SNMP classify path.
I imagine this is something basic many of you have experienced and could provide some guidance, which I will greately appreciate. Thanks
Solved! Go to Solution.
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2018 08:27 AM
If you set property glide.discovery.ip_service_affinity = true, Discovery will remember the last successful probe.
So, your Linux servers will try snmp first. If they fail, they will try ssh, succeed, and store the IP / service pair in the ip_service_affinity table.
So, assuming they fail snmp on the Linux servers, all will be well.
If they don't you can cobble around it by manually running an SSH probe to the relevant servers, or else you can create new ip_service_affinity records for those IPs.
It's a bit of a pain, and it can even be fragile when ssh fails one time and an affinity gets set for snmp, but it at least makes it somewhat manageable.
- Tim.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2018 08:27 AM
If you set property glide.discovery.ip_service_affinity = true, Discovery will remember the last successful probe.
So, your Linux servers will try snmp first. If they fail, they will try ssh, succeed, and store the IP / service pair in the ip_service_affinity table.
So, assuming they fail snmp on the Linux servers, all will be well.
If they don't you can cobble around it by manually running an SSH probe to the relevant servers, or else you can create new ip_service_affinity records for those IPs.
It's a bit of a pain, and it can even be fragile when ssh fails one time and an affinity gets set for snmp, but it at least makes it somewhat manageable.
- Tim.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-28-2018 12:07 PM
hi carloschaluisant,
you can try discovery behaviour, if you want to skip a particular type of probes or want to run only for a particular type of probe.
use behaviour (ssh only ) in phase 0.
it will then only goes and check for port 22 and launches further probes accordingly.