2

我的团队遇到这样一种情况，即每两周左右 SNMP SET 会失败一次。由于此设置是自动发生的，因此我们不一定会在它失败时立即注意到它，这可能会导致配置不一致以及相关的哀嚎和咬牙切齿。计划是通过让我们的软件在失败时自动重试 SET 来解决此问题。

问题是，我们不确定为什么会发生故障。我对 SNMP 的（极其有限的）知识对于诊断这个问题并不是特别有帮助，所以我想我会向 StackOverflow 寻求一些建议。我们认为，每隔一段时间，网络流量的峰值就会导致 SET 失败。由于 SNMP 使用 UDP 进行通信，我认为如果在短时间内流量很高，命令会相对容易被淹没。但是，我不知道这有多普遍。我们有一个带有单个 cisco 路由器的小型网络，并且该网络上只有不到十几个 SNMP 控制的设备。除了 SNMP 流量之外，还有一些从各种设备加载的状态网页。如果它有所作为，我相信我们正在使用适用于 Java 的 AdventNet SNMP API 4.0.4 版。

偶尔会丢失一些 SET 命令听起来合理吗，还是我们应该寻找其他原因？

4

1 回答 1

3

SNMP 被设计为不可靠的。它使用 UDP 作为其传输协议。当路由器有高优先级的工作要做时，它们会丢弃 SNMP 数据包。所以是的，偶尔删除 SET 命令听起来很合理:)

首先升级到最新版本的 SNMP 库（如果有）。

然后您可以设置重试机制：使用 GET 验证每个 SET。如果此操作失败，请将 SET 排队等待稍后尝试。这需要精心设计的排队机制：相同设置的后续 SET 应该在现有排队 SET 之后或之上排队。

另一种选择是每小时同步整个状态；使用 GET 进行设置，如果已更改，请设置它。可以使用警报系统报告超过 3 小时未完成的更改。

还有更多选择，但如果您平均每周只有 1 次失败，我会选择最简单的一种：使用 GET 验证 SET，重试 5 次，如果仍然失败，发送电子邮件。

于 2010-04-02T20:45:12.690 回答