
- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 12-04-2021 04:42 AM
Now, i have not found any summary of this topic. Essentially, when the discovery is used in conjunction with an external credential store you may find a huge performance impact when using SNMPv1/v2 credentials.
This is a short why and how to work around it. The below written content is based on this support entry (which is hard to find and starts with another issue - API access counts - but is based on the same argument: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0965041)
The problem
When using snmpv1/v2 credentials in combination with an external credential store (and in large discovery implementations also without a credential store), you may run into performance issues. This is caused by the snmpv1/v2 technical implication when port scanning devices and the fact, that servicenow does not cache the credentials:
Usually credentials are first used when starting with the Classification Phase. However, in the case of SNMPv1/v2 this is not the case. Here the authentication is already needed in the port scanning phase. This introduces one core issue:
When discovering with snmpv1/v2 credentials EVERY port scan done on SNMP on EVERY ip address which is scanned needs the SNMP credentials. When using an external credential store this means, that the SNMPv1/v2 credential must not be pulled for every active device, but rather for every potentially active device - so for every IP address. With increasing the number of different SNMPv1/v2 credentials, this issue is increased.
Workaround
This is a technical limitation of SNMPv1/v2. The only way to work around this completely, is by not using SNMPv1/v2 credentials. They must be loaded on the port scanning phase.
Now, if SNMPv1/v2 is strictly required, one must explicitly adjust the use:
1) Restrict SNMP credentials to certain Schedules via the use of credential aliases
2) Assign credentials to specific Mid-Servers
3) Set all schedules, which do not utilise SNMPv1/v2 to use exclusively SNMPv3
NOTE: technically, outside of the authentication, SNMPv1/v2 and SNMPv3 do not differ. Most devices support all 3. Therefore, it is highly recommended to urge the customer to switch to the use of SNMPv3 as this is the only "true" way to work around the performance impact - aside from eventually whitelisting the use of SNMPv1/v2 credentials as described above.
- 357 Views