According to the Internet standards organization (IETF) SNMP contexts are described as followed:
Within an administrative domain, an SNMP engine is uniquely identified
by an snmpEngineID value [RFC3411]. An SNMP entity, which consists of
an SNMP engine and several SNMP applications, may provide access to
An SNMP context is a collection of management information accessible
by an SNMP entity. An item of management information may exist in
more than one context and an SNMP entity potentially has access to
many contexts [RFC3411]. A context is identified by the snmpEngineID
value of the entity hosting the management information (also called a
contextEngineID) and a context name that identifies the specific
context (also called a contextName).
To identify an individual item of management information within an
administrative domain, a four tuple is used consisting of
- a contextEngineID,
- a contextName,
- an object type, and
- its instance identification.
The last two elements are encoded in an object identifier (OID) value.
The contextName is a character string (following the SnmpAdminString
textual convention of the SNMP-FRAMEWORK-MIB [RFC3411]) while the
contextEngineID is an octet string constructed according to the rules
defined as part of the SnmpEngineID textual convention of the
The SNMP protocol operations and the protocol data units (PDUs)
operate on OIDs and thus deal with object types and instances
[RFC3416]. The SNMP architecture [RFC3411]introduces the concept of
a scopedPDU as a data structure containing a contextEngineID, a
contextName, and a PDU. The SNMP version 3 (SNMPv3) message format
uses ScopedPDUs to exchange management information [RFC3412].
Within the SNMP framework, contextEngineIDs serve as end-to-end
identifiers. This becomes important in situations where SNMP proxies
are deployed to translate between protocol versions or to cross
middleboxes such as network address translators. In addition,
snmpEngineIDs separate the identification of an SNMP engine from the
transport addresses used to communicate with an SNMP engine. This
property can be used to correlate management information easily, even
in situations where multiple different transports were used to
retrieve the information or where transport addresses can change
To retrieve data from an SNMPv3 agent, it is necessary to know the
appropriate contextEngineID. The User-based Security Model (USM) of
SNMPv3 provides a mechanism to discover the snmpEngineID of the remote
SNMP engine, since this is needed for security processing reasons.
The discovered snmpEngineID can subsequently be used as a
contextEngineID in a ScopedPDU to access management information local
to the remote SNMP engine.
To clarify your comment "It also looks like they were removed from IOS at some point after being added."
That is not true. Cisco devices still support SNMP contexts on new IOS, IOS-XE, NXOS etc.
In the past it was required to configure access to each "vlan-*" context. Newer versions of IOS support the "match prefix" syntax that makes scalability easier.
The configuration varies a lot depending on the IOS version and model type.
Cisco 2960/S/X etc. IOS Release 15.X.X(X) (Tested - https://communities.ca.com/thread/100549100):
View Name - View1
Group Name - Group1
Access List - Access1
User - User1
SHA pass - password1
AES pass - password2
Location - Location1
Contact - Contact1
ip access-list standard Access1 (create access list "Access1")
permit any (grant permissions in the list)
snmp-server view View1 system included (create the view "View1", add "system" SNMP info to the view)
snmp-server view View1 internet included (add "internet" SNMP info to the view)
snmp-server group Group1 V3 priv access Access1 (create the group "Group1" with access through access list "Access1")
snmp-server group Group1 V3 priv read View1 (use "View1" with the group)
snmp-server group Group1 V3 priv context vlan- match prefix (add context names to the group, this will add all context names starting with "vlan-" which is what Spectrum wants to see)
snmp-server user User1 Group1 v3 auth sha password1 priv aes 128 password2 (create a user in group "Group1" with SNMPv3 credentials)
snmp-server location Location1 (set the switch location in the SNMP)
snmp-server contact Contact1 (set the switch contact information in SNMP)
Make changes as required ie permission in the access list.
We used view "v1default" and added "system" to it, it already had "internet"
Cisco 3750 IOS version 12.2(55)SE10 (Tested - https://switchportmapper.com/support-mapping-a-cisco-switch-using-snmpv3.htm)
How to enable SNMPv3 in a Cisco Switch IOS CLI
Switch#config term - this allows you to edit the running-config. (note: to remove any of the following 3 commands, use '
no snmp-server view', '
no snmp-server group' or '
no snmp-server user')
- Create a view for the test SNMPv3 user:
Switch(config)#snmp-server view testv3view internet included
- Create a group to access the view:
Switch(config)#snmp-server group testv3group v3 priv read testv3view write testv3view
- Create a user for the group:
Switch(config)#snmp-server user testv3user testv3group v3 auth md5 Passw0rd priv des Passw0rd
- Activate context prefix matching by entering this command:
Switch(config)#snmp-server group yourV3groupName v3 auth context vlan-
match prefix (If you do not do this the Managed Switch Port Mapping
Tool will give error messages claiming it cannot access Bridge Mib
even though the rest of the mapping appears to work. See the next
section if that command is not supported by your version of IOS)
- Optionally save it to the startup config using
Switch#copy running-config startup-config
Problem: my Cisco 3750 switch maps fine using SNMPv1 or v2c, but with
SNMPv3 I no longer see MAC Addresses, IP Addresses, VLANs or
hostnames. What is wrong with the Switch Port Mapper?
Nothing is wrong with the Switch Port Mapper. The problem is in the
switch and its config settings.
Background: Cisco uses 'community name indexing' for SNMPv1 and
SNMPv2c to allow us to get VLAN specific information from BRIDGE-MIB.
In SNMPv3 they use a variation of this technique by making use of
SNMPv3 contexts. The context field is changed for each VLAN requested
so that BRIDGE-MIB will give us the information we need for that
particular VLAN. The problem is not all versions of IOS support
contexts and in order to request context information for each VLAN,
you have to make changes to the running config through CLI. If the
switch is not configured, this software and any other switch mapping
software cannot map the switch with SNMPv3.
First, you need to see if your switch supports contexts. From CLI run
Switch#show snmp context
Assuming your switch does support contexts, next check to see if your
switch supports prefix matching.
In your running config add:
Switch#snmp-server group yourV3groupName v3 auth context vlan- match prefix
(don't forget the dash after vlan)
If the switch does support prefix matching every Cisco switch using
that version of IOS or later and SNMPv3 that you intend to map must
have that command in the config - you can skip the next section - you
If the switch does NOT support prefix matching you have a lot of work
to do. Every VLAN must have a context set up for it. You have to add
this command into running config for EVERY VLAN:
snmp-server group yourV3groupName v3 priv context vlan-(vlanid)
So if you have 10 VLANs on the switch, that command must appear 10
times, once for each VLAN (no parens around 'vlanid' and you may want
to add 'access #' at the end).
Examples for a switch with vlans number 6, 100, 117 and 200 (note the
optional access list statement):
Switch(config)#snmp-server group yourV3groupName v3 priv context vlan-6
Switch(config)#snmp-server group yourV3groupName v3 priv context vlan-100
Switch(config)#snmp-server group yourV3groupName v3 priv context vlan-117
Switch(config)#snmp-server group yourV3groupName v3 priv context vlan-200 access 51
Important note: the 'vlan-' contexts are probably different from the
SNMP contexts you may have used - you must use the vlan- context in
the statements described above in this topic whether using prefix
matching or individual entries. Treat vlan- as 'reserved' contexts to
avoid confusion. The topic before this one is not using SNMPv3
contexts at all.
More questions? see this thread: