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%5Farticle%5Fview&sysparm%5Farticle=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 aliases2) Assign credentials to specific Mid-Servers

3) Set all schedules, which do not utilise SNMPv1/v2 to use exclusively SNMPv3