江苏省建设部网站,wordpress模板 图片站,桂林市是哪个省的,邀请推广app最近在使用SNMP4J的过程中发现一个缺陷#xff0c;不知道应不应该算是个bug#xff0c;但我想终究算是一个不完善的地方。 问题描述如下#xff1a; 在通过SNMP4J去获取某些交换机上的MAC地址转发表(dot1dTpFdbTable, OID为1.3.6.1.2.1.17.4.3#xff09;时#xff0c;发现… 最近在使用SNMP4J的过程中发现一个缺陷不知道应不应该算是个bug但我想终究算是一个不完善的地方。 问题描述如下 在通过SNMP4J去获取某些交换机上的MAC地址转发表(dot1dTpFdbTable, OID为1.3.6.1.2.1.17.4.3时发现结果不全这里说其不全是与net-snmp提供的snmpwalk取的结果相比较而言的snmpwalk也提供了相同的功能可以获取snmp table。不过直接用snmpwalk取的时候实际上也碰到了一个问题例如假设交换机IP地址为192.168.1.1支持SNMPv2c且其团体字符串为public则取MAC地址转发表的命令行如下 snmpwalk -c public -v 2c 192.168.1.1 .1.3.6.1.2.1.17.4.3 在对上述的那些交换机通过上述命令行获取其mac地址转发表的时候会返回以下结果 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.1.205.11 Hex-STRING: 00 03 0F 01 CD 0B SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.238.195 Hex-STRING: 00 03 0F 0D EE C3 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.238.219 Hex-STRING: 00 03 0F 0D EE DB SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.239.119 Hex-STRING: 00 03 0F 0D EF 77 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.239.131 Hex-STRING: 00 03 0F 0D EF 83 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.239.191 Hex-STRING: 00 03 0F 0D EF BF SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.13.239.231 Hex-STRING: 00 03 0F 0D EF E7 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.17.254.48 Hex-STRING: 00 03 0F 11 FE 30 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.6 Hex-STRING: 00 03 0F 12 08 06 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.124 Hex-STRING: 00 03 0F 12 08 7C SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.178 Hex-STRING: 00 03 0F 12 08 B2 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.186 Hex-STRING: 00 03 0F 12 08 BA SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.190 Hex-STRING: 00 03 0F 12 08 BE SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.8.210 Hex-STRING: 00 03 0F 12 08 D2 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.18.9.234 Hex-STRING: 00 03 0F 12 09 EA SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.38.92 Hex-STRING: 00 03 0F 13 26 5C SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.46.100 Hex-STRING: 00 03 0F 13 2E 64 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.46.154 Hex-STRING: 00 03 0F 13 2E 9A SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.65.82 Hex-STRING: 00 03 0F 13 41 52 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.65.106 Hex-STRING: 00 03 0F 13 41 6A SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.66.158 Hex-STRING: 00 03 0F 13 42 9E SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.66.158 Hex-STRING: 00 03 0F 13 42 9E Error: OID not increasing: SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.66.158 SNMPv2-SMI::mib-2.17.4.3.1.1.0.3.15.19.66.158 第23行中可以看到错误提示OID not increasing的错误原来某些设备对SNMP支持的原因会导致返回结果的OID不是递增的其实不应该说是递增只能说是增大。查看snmpwalk的man手册后找到了解决方法 -Cc Do not check whether the returned OIDs are increasing. Some agents (LaserJets are an example) return OIDs out of order, but can complete the walk anyway. Other agents return OIDs that are out of order and can cause snmpwalk to loop indefinitely. By default, snmpwalk tries to detect this behavior and warns you when it hits an agent acting illegally. Use -Cc to turn off this check. 即在snmpwalk中增加-Cc选项后即可解决该问题因为加上该选项后snmpwalk将不再检查OID的升序问题但有可能产生一个新问题就是导致snmpwalk陷入死循环。死循环的问题这里暂且不表。 不知道SNMP4J里面有没有对这个问题的解决方法即类似snmpwalk中的-Cc选项的功能。后面有时间会再看看SNMP4J的源代码给出一个答案也希望知道的朋友能够提示一下。 转载于:https://blog.51cto.com/njulinq/289265
