I'm trying to understand switch mapping using SNMPv3. It's come to my attention that the group(user) who is authenticating needs access to thecontext for mapping out VLANs. I've figures out this can be accomplished with the command:

 snmp-server group [groupname] v3 priv context [vlanID / match]

However the matching function doesn't seem to be supported on all IOS versions, and the context feature also doesn't appear to be be present in all Cisco IOS versions. Can anyone help me get a better understanding of the context of all this? (no pun intended)

  • 1
    Sorry i don't fully understand your question. Do you need help configuring snmpv3 contexts or do you want to know more about why you would use contexts in snmpv3? If your device supports the command show snmp context then it'll fully support contexts. Older switches and IOS versions do not support it, but that's got to be really old. There's also recently been a bug, that would screw up the context in snmpv3 if a host was configured using the same user for authentication as the group context. – user56700 May 12 '19 at 12:39
  • I guess I'd just like to know some basics about how contexts are used. I've been having a very tough time understanding them from the material i've been able to find. It also looks like they were removed from IOS at some point after being added. – SWM May 13 '19 at 14:17

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 multiple contexts.

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

  1. a contextEngineID,
  2. a contextName,
  3. an object type, and
  4. 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 SNMP-FRAMEWORK-MIB [RFC3411].

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 dynamically.

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

conf t
ip access-list standard Access1 (create access list "Access1")
permit any (grant permissions in the list)

conf t
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

  1. Switch>enable
  2. 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')
  3. Create a view for the test SNMPv3 user: Switch(config)#snmp-server view testv3view internet included
  4. Create a group to access the view: Switch(config)#snmp-server group testv3group v3 priv read testv3view write testv3view
  5. Create a user for the group: Switch(config)#snmp-server user testv3user testv3group v3 auth md5 Passw0rd priv des Passw0rd
  6. 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)
  7. Switch(config)#Ctrl-z
  8. 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 this command:

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#config term
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 are finished.

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 term
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: https://supportforums.cisco.com/thread/2036734

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.