为什么使用 gosnmp 发出 snmpwalk 请求会在 29 秒后超时？

Question

我正在使用 gosnmp 来遍历 snmp 接口表 1.3.6.1.2.1.2.2.1 和 1.3.6.1.2.1.31.1.1.1。完成此任务所需的时间存在很大差异，我认为这取决于计算机的负载和网络拥塞。在针对 V1 设备的测试中，我在 29 秒后超时。这是因为构成 snmpwalk 命令的 getnext 请求之一超出了超时吗？ 有没有一种方法可以区分调用繁忙的设备和许多 getnext 请求之一失败（想要更长的超时）与调用死设备（想要更短的超时）。 snmpwalk中途超时后，是否只重试最后一次getnext？ 我假设 gosnmp 的 snmpwalk 包含标准 snmpwalk。重试和超时字段是否仅映射到 -r 和 -t 命令行参数？ 这些是针对同一设备的三个连续测试的日志。

{"已用时间":28596.288132,"时间":"2021-10-11T18:24:14-04:00","消息":"testSnmpWalk 成功"}

{"error":"请求超时（0次重试后）","已用时间":29571.202639,"time":"2021-10-11T18:43:37-04:00","message":"testSnmpWalk失败“}

{"已用时间":14645.645597,"时间":"2021-10-11T18:44:40-04:00","message":"testSnmpWalk 成功"}

Answer 1

我的解决方案是使用exec.Cmd来调用net-SNMP。虽然需要进行一些工作来传输和解析结果，但我对性能感到满意。

Answer 2

我相信我遇到了同样的问题，因为我正在使用 gosnmp 库中的 WalkAll 来请求多个 OID。但是，我可以获取某些 OID 的信息，而其他 OID 则返回超时错误（此行为可能有所不同；例如，如果我再次运行脚本，有效的 OID 可能无法工作）。无论我是否设置了较高的超时值，我得到的错误都是超时。但是，当我尝试从终端查询信息时，我可以获得它。我注意到相同的 OID 可能会快速返回信息，但可能会部分显示，直到命令完成。