Spectrum unable to read Transparent Bridge Table


Article ID: 195668


Updated On:


CA Spectrum


When trying to view the 'Transparent Bridge Table' view for Cisco Catalyst switches Spectrum seems to be unable to read the transparent bridge table correctly.  Spectrum Discovery also utilizes the Transparent Bridge table for discovering connections.  If not configured properly, Spectrum is not able to read the transparent bridge table and therefore cannot discover connections between devices.

   - In the Transparent Bridge Table > Forwarding Table sub-view nothing is shown.
   - After clicking the Per VLAN button to select the VLAN to show the table for, the only VLAN that even shows in the list is "default(0)" and none
        of the actual VLANs on the device appear in the list.




The devices were not allowing access when contexts were passed in SNMPv3 polling.


Release : 10.x

Component : Spectrum Core / SpectroSERVER


Devices will instance the transparent bridge ( tables to present views for the individual vlans
  configured on the device.


When polling via SNMPv2 these instances are accessed by appending @<VLANID> to  the community string in the request


When polling via SNMPv3, the instanced data is accessed by providing a 'context' string along with the request. The context name is
   in the form of vlan-<VLAN ID>


In the case of SNMPv3, it is not enough to configure an SNMPv3 user but access needs to be granted to requests using the context ids.


FIX: update the SNMPv3 configuration granting access to the v3 contexts


snmp-server group v3group v3 auth context vlan- match prefix

Note: Older versions of IOS may not support the match prefix and may require to add each vlan separately


After configuring the devices to allow access to the vlan contexts the 'Transparent Bridge Table' view completely populated and
  presented all vlans in the 'perVlan' dialog


Additional Information

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