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 · Accepted solution]

Jeremy,

I've been on the fence with this property ever since they started white boarding it.   I do see the value in it especially when you think about how discovery works out of box.. for a refresher for those that may not know for reference...

When we see an active IP address we attempt to classify the target based on the classification priority as defined on the port probes.   So if an IP address showed it had port 135 (WMI) , port 22 (SSH) in a state of open by default order we would attempt to pass windows credentials and when/if that fails we would then move onto the next protocol in order that being SSH. This would happen every time we discover that IP address when the same ports represent as "open" so you are always going to have a WMI authentication error in your discovery logs.

Well what this IP Affinity does is the first time you discover the target and say SSH was successful in classification we tag that IP to have that port 22 affinity.   So the 2nd , third, tenth time we discover it and see port 135 and port 22 open we go right to the SSH classification bypassing the wmi classify because we have already learned that its been successful with SSH.

So you can see the value in that right off the bat, just like our credential mechanics (dscy_credentials_affinity) we have already learned how to talk to that IP and it will help save troubleshooting errors down the line that should be ignored anyway helping your day to day discovery admin'n ..   Im just concerned how that will be represented in fluid IP allocation environments, what if one IP is a windows host today but DHCP or re-allocation of IP ranges makes it a SSH host tomorrow...

I do have no fear though, I trust in our awesome Dev team they've never let me down in the past and trust this will be a value add to day to day discovery work.

Hope that helps!

-Doug

[StephenHey]

Doug,

Perhaps one of the use cases where affinity is a problem might be when SNMP and SSH are both available on a box.   SSH fails due to a creds problem and SNMP works.   Let's say I fix my cred issue, it will never try SSH again unless I clear the affinity cache.

Stephen

[doug_schulze]

Perfect example Stephen!

[jeremyeperdue]

Yes! This was a big concern because of the way we discover some Linux Appliances.

Is there a way to use this feature, but only for devices we want? For example, I see a lot of time wasted on the UNIX Authentication attempts on routers and switches I don't have a behavior for yet. From the way I was reading about it, it seems all or nothing. Would that be correct?