陷阱的 SNMPv3 上下文是否有任何案例
假設我想向管理器發送 SNMP v3 陷阱/通知消息。通常我使用帶有 AES 加密的 USM SHA 授權。該命令如下所示：
snmpinform -v 3 -e 0x111111111 -u myuser -a SHA -A mypass1 -x AES -X mypass2 -l authPriv udp:example.com:162 '' 1.0而且效果很好。但是 SNMP 手冊和幫助提到陷阱/通知支持“-n”命令行開關以指定 SNMP 上下文。此選項的文件記錄很差。我還沒有找到任何範例，我應該如何以及為什麼要使用它。如果我只是在上面的命令中添加一些上下文，那麼 INFORM 將不會到達我的經理。
所以我的問題是如何正確使用此選項，以及是否有任何帶有陷阱的 SNMP 上下文的案例
- 首先引用 RFC 3411
例如託管對像類型 ifDescr
$$ RFC2863 $$, 被定義為網路介面的描述。為了辨識設備-X 的第一個網路介面的描述，需要四個資訊：提供對設備-X 上管理資訊的訪問的 SNMP 實體的 snmpEngineID、上下文名稱（設備-X）、被管理對像類型（ ifDescr）和實例（“1”）。
每個上下文在管理域內（至少）有一個唯一標識。相同的管理資訊項可以存在於多個上下文中。一項管理資訊可能有多個唯一標識。當管理資訊項存在於多個上下文中時會發生這種情況，並且當上下文具有多個唯一標識時也會發生這種情況。
contextEngineID 和 contextName 的組合明確地標識了管理域中的上下文；請注意，可能存在多個唯一的 contextEngineID 和 contextName 組合，它們明確地標識相同的上下文。
- 案例
IETF (RFC 1850) 定義的 OSPF MIB 旨在僅與給定路由器上的一個 OSPF 程序/實例一起工作。
例如，只有一個 ospfRouterId 對象，而不是它們的表。為了處理多個實例，RFC 4750 建議您使用 SNMPv3 上下文來提供每個實例的視圖。
使用 SNMP 上下文連結管理 OSPF 的多個實例
此 KB 提供有關如何從位於非預設路由實例中的 SNMP v3 伺服器輪詢資訊的解決方案
連結如何從非預設路由實例瞻博網路中提取 SNMP v3 資訊
因此，在很多情況下您可以使用 snmp 上下文：安全性、一個物理上的單獨邏輯實體等。