Solved: MAC Notification Traps and Dot1d interface mapping problem

jhilfiker · ‎03-21-2008

Hi,

We have a customer with several Catalyst 3750s running IOS 12.2. They would like to enable MAC Notification Traps. Once enabled, we can see the MAC Notification traps being sent to our snmp host. The packet for the trap contains the MAC address, and the port. The port contained in the packet appears to always be the dot1dBasePort Index.

The problem is we attempt to resolve the dot1dBasePortIndex from the trap to the ifIndex by doing a lookup of the ifIndex mapping in the dot1dBasePortTable. For these particular devices, the dot1dBasePortTable doesn't appear to contain all of the ports for the device. Thus we cannot make the mapping to the ifIndex for the ports that are missing from this table.

Does anyone know why the dot1dBasePortTable wouldn't contain all of the physical interfaces for these devices?

They are stacked if that is a consideration.

Joe Clarke · ‎03-21-2008

You need to use community string indexing to get all of the ports. For example, if your community string is public, and a port is in VLAN 6, you will need to walk dot1dBasePortTable with the string public@6.

View solution in original post

Joe Clarke · ‎03-21-2008

You need to use community string indexing to get all of the ports. For example, if your community string is public, and a port is in VLAN 6, you will need to walk dot1dBasePortTable with the string public@6.

jhilfiker · ‎03-21-2008

Yup.. That was it. Thanks. I never would have figured that one out.. Just out of curiosity, do you know why cisco does this? Makes it awefully difficult to just walk the dot1d table.

Joe Clarke · ‎03-21-2008

The BRIDGE-MIB was created before the age of VLANs. In order to handle multiple instances of the MIB (one per VLAN/STP instance) we had to introduce community string indexing. This isn't necessary with SNMPv3 as there is a standard way of accessing multiple instance MIBs (SNMPv3 contexts).