Suppose you want to know what vlans are configured/allowed on individual ports in one of recent Cisco Catalyst switches – quite basic information. SNMP seems to be right protocol for this task. Structure of most Catalyst switches can be discovered using ENTITY-MIB and that’s good news. In entPhysicalTable you can find ports, modules, chassis and many other parts with defined relationships between them. Now you want to find vlans for discovered ports and this is where scary part starts. Since port can have many vlans and vice versa, such mapping can be done in SNMP using one column table with row index build by combination of two numbers (portID.vlanID). As value of this row could be:
- 1 meaning native vlan
- 2 meaning tagged vlan
Lack of port-vlan combination in table would mean that this port isn’t present in given vlan. Simple? Yes, but too simple for Cisco engineers.
Cisco found another solution. In order to get via SNMP vlans per port information for Cat2950, Cat2970, Cat4500 and Cat6500 (with recent IOSes) you have to correctly combine following tables:
ifTable from IF-MIB
entPhysicalTable from ENTITY-MIB,
entAliasMappingTable from ENTITY-MIB,
vtpVlanTable from CISCO-VTP-MIB,
vlanTrunkPortTable from CISCO-VTP-MIB,
vmMembershipSummaryTable from CISCO-VLAN-MEMBERSHIP-MIB,
dot1dBasePortTable from BRIDGE-MIB
Some of those tables are 3D, have thousands of columns (one bit per column) and all of them use different, non-continuous indexes. But that would be still to easy. To get mapping from ports in vmMembershipSummaryTable to ports in ifTable you have to query dot1dBasePortTable using separate SNMP community for every vlan.