admin 管理员组文章数量: 887019
SNMP
基本示例
此类请求包含三个主要元素 - 从何处检索此信息、与请求关联的管理信息以及实际需要哪些信息：
% snmpget -v 2c -c demopublic test.net-snmp.org SNMPv2-MIB::sysUpTime.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (586731977) 67 days, 21:48:39.77
在此示例中，test.net-snmp.org是要查询的代理的主机名，使用 SNMP 协议的第 2 版和社区字符串“demopublic”。请求的 OID 是来自 MIB 模块SNMPv2-MIB 的sysUpTime.0。
相同的基本命令也可用于从表中检索单个元素：
% snmpget -v 2c -c demopublic test.net-snmp.org SNMPv2-MIB::sysORDescr.1
SNMPv2-MIB::sysORDescr.1 = STRING：SNMPv2 实体的 Mib 模块
该snmptranslate教程中介绍的几个方法来指定OID，和大多数讨论也适用于此（以及大多数其他的Net-SNMP命令行工具）。一个显着的区别是snmpget （和大多数其他工具）默认会应用“随机查找”，因此没有必要指定 MIB 的名称。上面的两个命令同样可以表示为：
% snmpget -v 2c -c demopublic test.net-snmp.org sysUpTime.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (586731977) 67 days, 21:48:39.77
% snmpget -v 2c -c demopublic test。 net-snmp.org sysORDescr.1
SNMPv2-MIB::sysORDescr.1 = STRING：SNMPv2 实体的 Mib 模块
SNMP 版本和管理
最初的 SNMPv1 和后来的 SNMPv2c 都使用明文“社区字符串”作为事实上的密码，以指示是否应授权特定请求。第一个示例的 SNMPv1 等效项几乎相同：
% snmpget -v 1 -c demopublic test.net-snmp.org sysUpTime.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (586731977) 67 days, 21:48:39.77
SNMPv3 使用明显不同的身份验证机制，通常基于用户名和密码，并允许正确验证 SNMP 请求，甚至加密管理客户端和 SNMP 代理之间的流量。有关详细信息，请参阅SNMPv3 选项教程。
使用的默认版本将取决于软件首次编译时的配置方式。通常，Net-SNMP 套件可能默认使用 SNMPv3，但始终明确指定版本是最安全的。
失败的请求
上面的例子显示了从目标系统成功检索信息。但是不成功的请求呢？SNMP 如何处理失败的请求？
使用snmpget命令时的一个常见错误是忘记所请求数据的索引（或“实例子标识符”）。从表中检索值时，这种情况不太可能发生，因为在表中很自然地将索引作为 OID 的一部分包含在内。但是对于标量对象，只有一个值，因此似乎没有必要指定索引 - 当然仅 MIB 对象名称就足够了？
然而，SNMP 在要求所有MIB 对象（甚至是标量对象）的实例方面是一致的。在这种情况下，实例子标识符始终是一个简单的.0（零），如上面的第一个示例所示。
省略这会导致错误：
% snmpget -v 1 -c demopublic test.net-snmp.org sysUpTime
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
This name doesn't exist: sysUpTime
请注意，SNMPv2c 提供了一条信息量稍大的消息：
% snmpget -v 2c -c demopublic test.net-snmp.org sysUpTime
SNMPv2-MIB::sysUpTime = No Such Instance currently exists
另一个可能的失败原因是代理根本不支持请求的 MIB 对象。对于 SNMPv1，错误完全相同（“ noSuchName ”）。SNMPv2c 对这种情况使用了稍微不同的指示：
% snmpget -v 2c -c demopublic test.net-snmp.org .1.3.6.1.2.1.1.99.0
SNMPv2-MIB::system.99.0 = No Such Object available on this agent at this OID
超时
另一种可能的失败类型是请求可能超时而不返回任何信息。假设远程系统实际上正在运行 SNMP 代理，最可能的原因是远程代理的访问控制设置。
多个值
到目前为止，所有示例都使用单个值。但是snmpget也可以在单个请求中检索多个 MIB 值：
% snmpget -v 2c -c demopublic test.net-snmp.org sysUpTime.0 sysLocation.0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (586903243) 67 days, 22:17:12.43
SNMPv2-MIB::sysLocation.0 = UCDavis
这对于所有版本的 SNMP 都以相同的方式工作。当请求的 OID 之一无效时，SNMPv1 和更高版本之间的差异就变得很明显。SNMPv2c（和 SNMPv3）将显示它们可以显示哪些信息：
% snmpget -v 2c -c demopublic test.net-snmp.org sysUpTime.0 sysLocation # No instance .0
SNMPv2-MIB::sysUpTime.0 = Timeticks: (586903243) 67 days, 22:17:12.43
SNMPv2-MIB::sysLocation = No Such Instance currently exists
而等效的 SNMPv1 请求只会失败：
% snmpget -Cf -v 1 -c demopublic test.net-snmp.org sysUpTime.0 sysLocation
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
This name doesn't exist: sysLocation
（-Cf标志来防止snmpget自动更正此问题并重试请求 - 从而破坏了本示例的重点！）
本文标签： SNMP
版权声明：本文标题：SNMP 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/jishu/1687090375h62737.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论