0

给定以下示例/简单 snmpd.conf（RHEL 7.4 上的 Net-SNMP 5.7.2）

rwcommunity 私人 192.168.56.101

trapsess -Ci --clientaddr=192.168.56.128 -v 2c -c private 192.168.56.101:162

启动 SNMP 守护程序时

snmpd -f -Lo -D -C -c 数据/snmpd_test.conf udp:192.168.56.128:161

我们使用 IP 源192.56.168.1而不是...128获得“启动” InformRequest （下面的 WireShark 快照）

使用源 1 而不是 128 的 InformRequest

这并不奇怪，因为-D选项允许我们输出调试信息，说明

跟踪：netsnmp_config_process_memory_list（）：read_config.c，696：read_config：mem：处理内存：clientaddr 192.168.56.128 跟踪：run_config_handler（）：read_config.c，562：9：read_config：parser：此时未注册clientaddr处理程序

然而，网络消息来源说：

snmp.conf

...在生成通知时，snmpd 也使用此值。

snmpd.conf

trapsess [SNMPCMD_ARGS] HOST 提供了一种更通用的机制来定义通知目标。 SNMPCMD_ARGS 应该是等效的 snmptrap（或 snmpinform）命令发送所需通知所需的命令行选项

我还阅读了一些像这样的旧线程

  • 然而，这个选项与 snmptrap 配合得很好

    snmptrap -D -Lo -Ci --clientaddr=192.168.56.128 -M+path_to_my_mibs -v 2c -c private 192.168.56.101:162 "" .1.3.6.1.4.1.abcdef0 i 0

使用 ip source 128 正确 snmpinform

  • 此选项在放入 snmp.conf 时也有效（请注意这里没有 'd'），然后它适用于 snmpset 和 snmpget（可能还有其他）

所以我的问题是：它是文档错误、错误还是对 Net-SNMP 堆栈的滥用？

4

1 回答 1

0

经过长时间的挣扎，我可能有答案，我写了一个简短的笔记，因为我刚刚找到了一个技巧

似乎在snmpd.conf中的任何地方都没有正确解析clientaddr

（我也试过不在陷阱线内）

但它似乎是snmpd命令行中的有效选项

就像它是snmptrap命令行中的有效选项一样。所以我认为这可能是两者的相同解析机制。

还有一个条件是 IP 地址必须是有效的

意思就是

snmpd -f -Lo -D -C -c 数据/snmpd_test.conf --clientaddr=192.168.56.128 udp:192.168.56.128:161

似乎完全解决了我的问题。

我将进行更多测试，如果格式准确，这个答案会更好一点，但这似乎是一个很好的提示。

于 2018-12-13T23:40:34.880 回答