2

let's say I want to send SNMP v3 trap/inform message to the manager. Usually I use USM SHA authorization with AES encryption. The command looks like:

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

And it works great. But SNMP manuals and helps mention that traps/informs support '-n' command line switch for specifying SNMP context. This option is poorly documented. I haven't found any examples how and why should I use it. If I just add some context to the command above, then INFORM will not reach my manager.

So my question is how to properly use this option and if there is any use cases for SNMP contexts with traps

Suic
  • 23
  • 3
  • Welcome on serverfault. First you don't see inform on the snmp server(target server) because manager(snmp target server) may know about different context's. Will expand this to answer, because there exist interesting example's with usage of different context's. – Ivan Gurzhiy Mar 26 '19 at 20:49

1 Answers1

1
  1. First of all quote from RFC3411

For example, the managed object type ifDescr [RFC2863], is defined as the description of a network interface. To identify the description of device-X's first network interface, four pieces of information are needed: the snmpEngineID of the SNMP entity which provides access to the management information at device-X, the contextName (device-X), the managed object type (ifDescr), and the instance ("1").

Each context has (at least) one unique identification within the management domain. The same item of management information can exist in multiple contexts. An item of management information may have multiple unique identifications. This occurs when an item of management information exists in multiple contexts, and this also occurs when a context has multiple unique identifications.

The combination of a contextEngineID and a contextName unambiguously identifies a context within an administrative domain; note that there may be multiple unique combinations of contextEngineID and contextName that unambiguously identify the same context.

  1. Usecases

The OSPF MIB defined by the IETF (RFC 1850) was designed to work with only one OSPF process/instance on a given router.

For example, there is only a single ospfRouterId object, not a table of them. In order to handle multiple instances, RFC 4750 suggests that you use SNMPv3 contexts to provide per-instance views.

Link Manage Multiple Instances of OSPF with SNMP Contexts

This KB provide solution on how to poll information from a SNMP v3 server which is located in a non-default routing-instance

Link How to pull SNMP v3 information from non-default routing-instance Juniper

So there is lot of cases when you may use snmp contexts: security, separate logical entities on one physical, etc.

Ivan Gurzhiy
  • 306
  • 1
  • 1