SNMPv3 上下文陷阱是否有任何用例

SNMPv3 上下文陷阱是否有任何用例

假设我想向管理器发送 SNMP v3 trap/inform 消息。通常我使用 USM SHA 授权和 AES 加密。命令如下:

snmpinform -v 3 -e 0x111111111 -u myuser -a SHA -A mypass1 -x AES -X mypass2 -l authPriv udp:example.com:162 '' 1.0

而且它工作得很好。但是 SNMP 手册和帮助提到 traps/informs 支持“-n”命令行开关来指定 SNMP 上下文。这个选项的文档记录不全。我找不到任何关于如何使用它以及为什么要使用它的示例。如果我只是在上面的命令中添加一些上下文,那么 INFORM 将无法到达我的经理。

所以我的问题是如何正确使用此选项,以及是否有任何使用带有陷阱的 SNMP 上下文的用例

答案1

  1. 首先引用 RFC3411

例如,托管对象类型 ifDescr [RFC2863] 被定义为网络接口的描述。要识别设备 X 的第一个网络接口的描述,需要四条信息:提供对设备 X 的管理信息的访问的 SNMP 实体的 snmpEngineID、contextName(设备 X)、托管对象类型(ifDescr)和实例(“1”)。

每个上下文在管理域内具有(至少)一个唯一标识。同一项管理信息可以存在于多个上下文中。一项管理信息可以具有多个唯一标识。当一项管理信息存在于多个上下文中时会发生这种情况,当一个上下文具有多个唯一标识时也会发生这种情况。

contextEngineID 和 contextName 的组合可以明确地标识管理域内的上下文;请注意,contextEngineID 和 contextName 可能有多个唯一的组合可以明确地标识同一个上下文。

  1. 用例

IETF(RFC 1850)定义的 OSPF MIB 设计为仅与给定路由器上的一个 OSPF 进程/实例一起工作。

例如,只有一个 ospfRouterId 对象,而不是一个包含这些对象的表。为了处理多个实例,RFC 4750 建议您使用 SNMPv3 上下文来提供每个实例的视图。

关联使用 SNMP 上下文管理 OSPF 的多个实例

本知识库提供了有关如何从位于非默认路由实例中的 SNMP v3 服务器轮询信息的解决方案

关联如何从非默认路由实例 Juniper 中提取 SNMP v3 信息

因此,在很多情况下您可能会使用 snmp 上下文:安全性、一个物理上的单独逻辑实体等等。

相关内容