Please select To the mobile version | Continue to access the desktop computer version
 Forgot password?
 Register now


Wireless

View: 2201|Reply: 1

My mib tool canot gain the device information

[Copy link]

2

Digests

81

Posts

93

Credits

Staff

Credits
93
Post time 2018-4-2 16:23:15 | Show all posts |Read mode
Edited by Levy at 2018-4-2 16:44

hello, guys
I found that my mib tool canot gain the device information
what is the cause and what should I check ?


Reply

Use magic Report

10

Digests

994

Posts

1107

Credits

administrator

Rank: 9Rank: 9Rank: 9

Credits
1107
Post time 2018-4-2 16:43:59 | Show all posts
1. The device SNMPD does not return the obtained MIBpacket.
Symptom:

When SNMP MIB is used to obtain the device information, the device makes noresponse.

Fault Cause:

The device SNMPD is not enabled.

The community name of the device SNMPD or snmpv3 isincorrect.

The SNMP configuration set by SNMP MIB is inconsistent with that set by the device.

Whether there is ACL for the device.

The device SNMPD task is abnormal.

2. The device SNMPD does not return the obtained MIB packet within the specified time.

Fault Causes:

It takes a long time to obtain the information about the MIB node.

Because the device SNMPD is a single-task thread, when information is obtained from few MIB nodes simultaneously, the response from the current MIB node times out because the response from a previous MIB node takes a long time.

Because the device SNMPD is a single-task thread, when the number of MIB nodes from which the device information is obtained exceeds the number of MIB nodes that can be processed by the device per second, the response from the current MIB node times out.

Troubleshooting
2.1 Collecting the Fault Information
For device information obtaining failure at the SNMP MIB node, you need to collect the following fault information:

Trigger the MIB read, and capture packets on the device and SNMP MIB server simultaneously.

Check whether the fault occursat a single node or all nodes:

When the fault occurs at the current MIB node, check whether the fault occurs atother MIB nodes.

2.2 Analyzing the Fault Information
1.Viewing the Device Configuration:
Check the device configuration and confirm whether the ACL filter is configured.

2.Analyzing the Packets Collected from the Device and SNMP MIB Server:
Check whether a packet is returned for the triggeredMIB operation. If no packet is captured, the problem is caused by the first reason; otherwise, it is caused by the second reason.

In case of the first reason, analyze the device configuration.

In case of the second reason, check whether there are many SNMP packets requests and whether the SNMP packets carry many binding variables. If yes, there are a great amount of SNMP requests currently and the problem can be avoided by using the avoidance method. If not, analyzethe information collected by the show snmp process-mib-time command.

3.Analyzing the Information Collected by the show snmp process-mib-time Command:
Collect information mainly from 20 MIB nodes of which the processing time is long, including the information about the processing cycle time and MIB nodes. The cycle time can be used to calculate the specific execution time according to the formula: execution time = cycle time x 10/(device CPU frequency/100). The unit is ms. For example, if the device CPU frequency is 750 MHz, the cycle time is 105841517 ms, then the execution timeis 105841517 x 10/(750 x 10^6/100) = 141 ms, which means the internal processing time for obtaining the specific module of the MIB node is 141 ms. If the result is a large value, contact the module owner of the MIB node to analyze the reason.


2.3 Fault Recovery or Avoidance
Fault Recovery:

If the problem is caused by the device configuration, modify the device configuration. If the problem is caused by other reasons, fix it accordingly.

If the problem is neither caused by the device configuration not caused by the long processing time at a single MIB node, configure snmp-server flow-controlpps to set the packet upper limit to solve this problem. If the problem is caused by the long processing time at a single MIB node, collect more information for confirmation.

Fault Avoidance:

If the problem is neither caused by the device configuration nor caused by the long processing time at a single MIBnode, configure snmp-server flow-controlpps to set the packet upper limit to avoid the problem. You can use the packets collected from the device and SNMP MIB server to analyze the number of bound tasks processed by the device per second. For example, the captured packet shows that the device processes 200 packets per second and each packet is bound to three tasks; then, the number of bound tasks processed per second is 200 x 3= 600. Accordingly, you can set the snmp-server flow-control pps to 600, which may result in high CPU usage of the SNMPD task. Therefore, set the pps to avalue which can be accepted by the CPU.

Reply Support Not support

Use magic Report

You have to log in before you can reply Login | Register now