Pros and Cons of IP Service Affinity (ip_service_affinity)

[jeremyeperdue]

I think using the ip_service_affinity property to be very valuable and time saving. But this is set false by default so I ask, what are the downsides of using it?

reference : Credentials - ServiceNow Wiki

------------------------------------------------------------------------------------

Update & Summary

I put this together for internal use and thought I would share to see if it can help anyone else. Doug, please correct me if I am incorrect about anything.

With OOB discovery, it tracks the credential that is used for a successful login, but not the device type. An example; A Windows machine is interrogated for the first time. ServiceNow Discovery determines it is a Windows Device and begins trying all the Windows based credentials in the credential table until it finds one that works. There is a credential affinity created here saying, next time you try to discover this device, use the credential that works. All subsequent discoveries will try the last working credential first.

This is great until we see network devices such as a router or switch. In these cases, there are multiple ports open, primarily, SSH and SNMP. Due to the OOB ordering of probes, Discovery tries SSH first because it sees port 22 open. It iterates through all the SSH credentials and because we are not authorized via SSH to discover the device, it ultimately fails then moves to SNMP. Using the same logic mentioned above, if the device has been discovered previously, it attempts to use the SNMP credential set in the affinity table and we authenticate and continue discovery.

The failed UNIX (SSH) attempts at the beginning of the discovery take time. So here is where IP Service Affinity should come in. With IP Affinity, the first time you discover the target and say SSH failed but SNMP was successful in classification we tag that IP to have that port 161 affinity.   So the second, third, tenth time we discover it and see port 161 and port 22 open we go right to the SNMP classification bypassing the SSH classify because we have already learned that it's been successful with SNMP.

My Primary Focus : We are spending time trying to authenticate via SSH when SNMP is the way the devices are setup for discovery. From Routers and Switches, to our Network Appliances (Riverbeds), they all use SNMP to authenticate yet still try SSH first and this can be a time consuming process. Or so I thought. Here are my results;

Step 1) Ran Test Discovery in our DEV instance.

                  Baseline set at 10 hours 41 minutes

Step 2) Set IP Affinity to true and re-ran discovery.

                  This step took 11 hours 1 minute

Step 3) Ran again after the affinities were created.

                  Discovery took 10 hours 58 minutes

Next I reordered SNMP to 2 and SSH to 3 on probe priority, 11 hours 9 minutes.

I am reverting everything to OOB as there was no noticeable improvement in time.

Message was edited by: Jeremy Perdue

[doug_schulze]

For that problem, change the classification priority on your Discovery Definition > port probes.   Swap SNMP and SSH.. this way when you come across a router/switch it does SNMP first and never should try SSH (unless you are having access issues)..

[jasonaranha]

Hi doug.schulze , I have encountered this problem & see it being an issue , we have response recieived from port 135 wmi and port 5989 wbem from IP SCAN, earlier seem like the discovery for the IP was not able to authenicate via windows Credentials to the IP. so the IP_service_affinity for the IP Scan stored "wbem" port as the default port for discovery in IP_service_affinity , now we have proper authorization on this devices with windows Credentials still it is unable to get scanned as default wbem port , i have raise an hi case of this and they have directed me to this blog . Do you know how are other addressing this issue .

[doug_schulze]

Hey Jason, I havent had much of a need to use the IP Service Affinity always thought it would cause grief just as you note above and why we were able to get a property in discovery definition to shut it off...

[jasonaranha]

I removed the entry in Table and was able to discover windows CI successful after that. Seem like either we should give the user a option to run an clean discovery [by deleting all the entry in IP Service Affinity table for that IP ] .   This will make life much easier instead of someone who does not want raise an Hi case to resolve such issue. deleting few entry in IP Affinity Table should be not be a big deal while i can totally understand doing this for large subnet discovery could potentially slow down the discovery process.

[erik_alvarez]

Hi @doug.schulze  and @jeremyeperdue  , firstly thanks for this post, it's very useful. I was wondering if the information in the post has changed withing this two years of last edit?  the concern DOug mentions about reassignation of ip addresses.