Idea Details

SNMPv3 Discovery with Context

Last activity 11-19-2019 07:30 AM
JIANN SIANG TAN's profile image
10-24-2014 03:05 AM

For model discovery, we found that Spectrum is not able to read the bridge table in SNMPv3 switches without the CONTEXT string. Thus Spectrum is not able to discover the connectivity between models. I suggest that when creating SNMPv3 profiles, CONTEXT string is one of the parameters in the GUI.



07-13-2017 11:29 AM

Is there interest in having CA PM support SNMPv3 contexName capability as well?

01-29-2016 02:38 AM

This is indeed a very helpful command, but it's not available on some older Cisco devices (or IOS versions?). And sometimes  Cisco has completely forgotten to implement the context syntax (e.g. in some NXOS versions or in the first IOS releases für 89x Routers.)

If "match" isn't  supported, you need  1 line per configured vlan:

     snmp-server group <group name> v3 priv context vlan-1111

     snmp-server group <group name> v3 priv context vlan-1112


01-28-2016 03:16 PM

You can just use something like this to the hardware config:


snmp-server group <group name> v3 priv context vlan- match prefix


I'm using that to capture all of the vlans on all of our Cisco gear with no trouble.  I don't specify the contexts in Spectrum, and Spectrum polls all of the vlan-# contexts automatically.

01-25-2016 02:31 AM

the documentation say one context is possible, but when you have multiple VLANs on the cisco (data, voice, ...) is does not really help:

Adding Context Name Information

You can add the SNMPv3 context name value to be sent with SNMPv3 messages for a particular



1. Right click on the device model to display a pop-up menu.

2. Select Model Information.

The Model Information window appears.

3. Enter Edit mode by choosing Edit from the File menu.

4. Insert the context name value in the Community Name field. For example, if the current

community string is:


To insert the a contextName value of “quark”, add “-quark” to the community string as follows:


5. Once you have added the appropriate context name value, choose to Save All Changes in the

File menu.

By the way, snmp version 2 had a similar behaviour.


There are four VLANs in this example. The show cam dynamic output shows all the addresses, but snmpwalk only shows the ones in VLAN 1.

You need to use community string indexing in order to get the
entries for each of the VLANs. The syntax to use is: snmpwalk read_community@vlan_number .


07-07-2015 02:23 PM



I will be away on overseas leave from 4th Jul 2015 till 17th July 2015. I will have limited network access. For urgent matters, please call 62837378.




07-07-2015 02:22 PM

I have the same problem. In my case it it a Juniper SRX Firewall where we only could see one virtual interface of the accessable context.

If we get the option to specify the Context ( compareable to the option -n in many Net-SNMP-Tools) we could  discover these...


I need that feature to discover many firewalls....


a Device only with one interface doesn´t make sense...

06-08-2015 07:22 PM

Jiann, did you open a ticket with CA SPECTRUM Support in order to get the functionality working as desired?  It's looking like we can close this one as "DELIVERED".

11-12-2014 11:02 PM

Hi Greg,

    I have tested your idea that Spectrum will walk through all the VLAN Contexts in a switch. It did not work in our environment as you had presented. We are running Spectrum version 9.4.

   Can you share in detail your test environment and how we can setup up in our Spectrum to discover all the VLAN Contexts? Thanks.



Jiann Siang

10-27-2014 10:35 PM

Hi Greg,

   You are saying that in the latest version of Spectrum, the discovery will query all VLANs available in a switch as SNMPv3 CONTEXTs automatically without having to configure CONTEXT in Spectrum? If this is true, we will try the discovery again with the latest version. In Spectrum 9.3, we are sure that Spectrum will not query VLAN as SNMP CONTEXT automatically.





Jiann Siang

10-27-2014 02:15 PM

Hi Jiann,


As mentioned the SpectroSERVER does query for a list of vlans and then will attempt to poll the instanced bridge table by specifying the vlan id for the context. So this is automated and you do not need to specify the vlan contexts to the SpectroSERVER. You will however, need to grant the SNMP v3 user defined on the device access to the contexts.


Ex. from a Cisco Forum post


snmp-server group v3group v3 auth

snmp-server group v3group v3 auth context vlan-1

snmp-server group v3group v3 auth context vlan-100

snmp-server user userv3 groupv3 v3 auth md5 userv3pw123


I tested a discover connections on a v3 device, you will see the SpectroSERVER in this one request was querying the vlan-1208 context.


Simple Network Management Protocol

    msgVersion: snmpv3 (3)


    msgAuthoritativeEngineID: <ENGINE ID>

    msgAuthoritativeEngineBoots: 1506646

    msgAuthoritativeEngineTime: 846

    msgUserName: AuthPrivUser

    msgAuthenticationParameters: <AuthParam>

    msgPrivacyParameters: <PrivParam>

    msgData: encryptedPDU (1)

        encryptedPDU: <Encrypted PDU>

            Decrypted ScopedPDU: <Scoped PDU>

                contextEngineID: <ENGINE ID>

                contextName: vlan-1208

                data: get-next-request (1)


                        request-id: 3201

                        error-status: noError (0)

                        error-index: 0

                        variable-bindings: 2 items

                   Value (Null)

                                Object Name: (iso.

                                Value (Null)

                   Value (Null)

                                Object Name: (iso.

                                Value (Null)



10-25-2014 11:00 AM

Hi Greg,

    Our experience tells us that an access switch port of an SNMPv3 Cisco Catalyst Switch (Cat3750) configured in a separate VLAN different from the default VLAN will belong to a separate SNMPv3 CONTEXT. There is no need for network admin to configure an SNMPv3 CONTEXT.


   In this situation, Spectrum will not be able to see the bridge info, especially MAC addresses in that VLAN. So the network topology of that VLAN cannot be mapped out in Spectrum.


  Thus, it is crucial for this CONTEXT string to be included in the discovery so that users like us can discover the topology first time round and not having to configure that SNMPv3 string with CONTEXT after discovery. We are handling thousands of SNMPv3 devices/models, so it only make sense to include the CONTEXT string from the beginning, that is during discovery.


   Actually, CONTEXT string in SNMPv3 device discovery is quite a common practice now. I am not sure why CA Spectrum product team is not interested in including it. Is it a lack of understanding or Spectrum is no longer developing new features?  Thanks.



Jiann Siang

10-24-2014 11:24 AM

When using SNMPv3 the SpectroSERVER does use contexts when trying to read the  transparent bridge tables.


It will use vlan-<VLAN_ID> for each of the vlans discovered on the device

   ex. vlan-1



The SNMPv3 user on the device in question needs to be configured with these contexts to allow the request.



10-24-2014 04:59 AM

Make CONTEXT string available please, fault management solution must cater for all SNMPv3 devices as well

10-24-2014 03:09 AM

This One Should be made available in Spectrum as most of the Free Software available in the Market have this feature.