vScope performs a SNMP Walk which is a series of SNMP GETBULK commands. By default, vScope requests 10 OIDs (keys) from the SNMP Tree with every GETBULK request. If the device has 10000 values, then there will be 1000 requests performed.
The SNMP Tree consists of MIBs (Management Information Base) which are default MIBs present on most devices but also vendor specific MIBs provided by the device manufacturer.
Reading default MIBs is usually not a problem. They are reasonably simple and contain common values.
Some switches (like Cisco) contain routing tables and other custom information which on request is compiled into a table and sorted by the switch before made available in the SNMP Tree as OIDs. Compiling and sorting information can be CPU intensive.
A SNMP Walk is a common procedure and should not impose any problems. If you notice that your device has CPU spikes you should try scanning the same device with another tool to rule out that the CPU spike is caused by vScope.
You can use SNMP Tester (https://www.paessler.com/tools/snmptester) to perform a SNMP Walk towards the target. See the screenshot on how to configure a SNMP Walk using SNMPv2c.
- Device IP/Port: Your IP
- SNMP Version: SNMP v2c
- Community: public (or your secret public string)
- Select Walk and enter 1 into the edit box
- Hit Start to start the test. The software will perform a full SNMP walk
Monitor the CPU usage on your device and see if you can reproduce the CPU spikes.
The CPU spikes can be reproduced
If you get similar results with the tool as with vScope then the reason for the CPU spikes are probably due to some parts (OIDs) of the SNMP Tree that are expensive to read.
To find out which OIDs might be causing the CPU spikes you can send us the logs for analysis.
Send us:
- The log from SNMP Tester (Save log to file or copy/paste)
- vScope debug logs. Files named debug.log, debug.log.1 etc located in c:\vScopeData\log. Make sure you attempt a scan towards the device in vScope before sending us the logs.
If you’d rather analyse the logs yourself you can open the vScope debug.log and search for the IP address you are trying to scan.
You could find entries like:
[2017-02-13 10:24:59,962]DEBUG [discovery-2-Target:192.168.1.100] - com.infrasight.discovery.probe.snmp.ProbeSNMPBase.snmpWalk(?:?) - Long running requests: [GETBULK[requestID=556875618, errorStatus=Success(0), errorIndex=10, VBS[1.3.6.1.4.1.9.9.249.1.2.1.1.2.1000.1 = Null]]=8187, GETBULK[requestID=556866128, errorStatus=Success(0), errorIndex=10, VBS[1.3.6.1.4.1.9.9.109.1.3.1.1.9.1000.11330.11372 = Null]]=4102, GETBULK[requestID=556865250, errorStatus=Success(0), errorIndex=10, VBS[1.3.6.1.4.1.9.9.109.1.2.3.1.30.2000.19 = Null]]=2017]
[2017-02-13 10:24:59,962]DEBUG [discovery-2-Target:192.168.1.100] - com.infrasight.discovery.probe.snmp.ProbeSNMPBase.snmpWalk(?:?) - SNMP (192.168.1.100:161) (udp) (Snmpv2cCredential(public)) (ProbeResult:OK) (107969 OIDs) (Average response time: 7ms)
The section starting with “Long running requests” logs which requests towards the device took a long time to complete. Here we can see that the request for 1.3.6.1.4.1.9.9.249.1.2.1.1.2.1000.1 took 8187 milliseconds (8 seconds) to complete.
The most common reasons for a request to be long running are
- The request required the device to perform some work to compile (gather) the data
- Network delay
If you have identified request that are taking a long time to complete, please send us the OIDs (like 1.3.6.1.4.1.9.9.249.1.2.1.1.2.1000.1 above) and we will investigate why this OID could cause long running requests. A solution in vScope might be to ignore the MIB (section of SNMP Tree) containing the OID.
The CPU spikes cannot be reproduced
If you cannot reproduce the spikes using the tool then the reason for the spikes might be that the device is being scanned several times simultaneously by vScope. This can occur if the switch has several management interfaces connected to the same subnet. Example: 192.168.1.100 and 192.168.1.105.
Since vScope scans multiple IP addresses simultaneously then it would be likely that both these addresses (that are reasonably close in range) are scanned by vScope at the same time. Try to exclude one of the addresses in vScope from being scanned.