I have come across this problem when using SNMP (v2c or v3) to look at spanning tree info on a 4506 with at least 03.08.05a.E on a supervisor 7:
This is the VLAN 300 spanning tree when using the router commandline:
# show spanning-tree vlan 300
<snip - irrelevant for this discussion>
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Te1/3 Desg FWD 4 128.3 P2p
Te1/4 Root FWD 4 128.4 P2p
Po1 Desg FWD 1 128.1281 P2p
Using @<vlan> id community indexing wth SNMPv2 and proper SNMP context vlan-300 when using SNMPv3 I get:
$ snmpbulkwalk -v2c -c COMMUNITY@300 cisco4506.router BRIDGE-MIB::dot1dBasePortIfIndex
BRIDGE-MIB::dot1dBasePortIfIndex.1 = INTEGER: 2
BRIDGE-MIB::dot1dBasePortIfIndex.3 = INTEGER: 4
BRIDGE-MIB::dot1dBasePortIfIndex.4 = INTEGER: 5
BRIDGE-MIB::dot1dBasePortIfIndex.257 = INTEGER: 6
BRIDGE-MIB::dot1dBasePortIfIndex.513 = INTEGER: 24
BRIDGE-MIB::dot1dBasePortIfIndex.2561 = INTEGER: 49
Which indicates that the following interfaces are taking part in the spanning tree when looking at IF-MIB::ifDescr (just including the values from the above table):
$ snmpbulkwalk -v2c -c COMMUNITY@300 cisco4506.router IF-MIB::ifDescr | grep -E '\.(2|4|5|6|24|49) =')
IF-MIB::ifDescr.2 = STRING: TenGigabitEthernet1/1
IF-MIB::ifDescr.4 = STRING: TenGigabitEthernet1/3
IF-MIB::ifDescr.5 = STRING: TenGigabitEthernet1/4
IF-MIB::ifDescr.6 = STRING: TenGigabitEthernet3/1
IF-MIB::ifDescr.24 = STRING: TenGigabitEthernet5/1
IF-MIB::ifDescr.49 = STRING: Port-channel1
Now the BRIDGE-MIB::dot1dStpPort table should name bridge ports taking part in the stp, using the indices named in the above show BRIDGE-MIB::dot1dBasePortIfIndex:
$ snmpbulkwalk -v2c -c COMMUNITY@300 cisco4506.router BRIDGE-MIB::dot1dStpPort
BRIDGE-MIB::dot1dStpPort.3 = INTEGER: 3
BRIDGE-MIB::dot1dStpPort.4 = INTEGER: 4
BRIDGE-MIB::dot1dStpPort.1281 = INTEGER: 1281
As you can seen: Index 1281 appears out of no where. 3 and 4 will map to Te1/3 and Te1/4, matching the command line output. But Po1 is missing. There should be a BRIDGE-MIB::dot1dStpPort.2561 entry.
When looking at the hex representation of 1281 and 2561, I think that the higher octet is shifted by one bit between the tables: 1281=0x501 and 2561=0xA01
This is clearly a bug, and not present in earlier versions of IOS, I cannot reproduce this on late IOS 12.2 versions (Supervisor 6).
We are considering to downgrade the software because of this bug now.
