Read LLDP information using SNMP on stacked IE 5000 switches

[gerrit.til]

Hi All,

We are using 2 Cisco IE-5000-12S12P-10G switches in a stacked configuration in our systems. The software version is "Cisco IOS Software, IE5000 Software (IE5000-UNIVERSALK9-M), Version 15.2(8)E1, RELEASE SOFTWARE (fc8)".

For our systems we are required to supervise all connections between devices and report a fault (containing the local port ID and the remote port ID) when a link is missing. We do that by reading the LLDP information using SNMP. This is working fine for a single IE5000 switch but we don't know how to get this working when the IE5000 switches are configured as stacked. 

The data we read for remote devices (LLDP-MIB::lldpRemSysName, LLDP-MIB::lldpRemPortId, LLDP-MIB::lldpRemPortDesc) contains an index which represents the local port, this index points to an entry in the local port list (LLDP-MIB::lldpLocPortTable). 

When we read the data on stacked switches we get something like this:

./snmpwalk -v 2c -c public 192.168.10.1 LLDP-MIB::lldpRemSysName
LLDP-MIB::lldpRemSysName.0.3.13 = STRING: Device-1
LLDP-MIB::lldpRemSysName.0.3.15 = STRING: Device-2
LLDP-MIB::lldpRemSysName.0.4.5 = STRING: Device-3

This shows that on port 3 a device Device-1 is found but also Device-2, on port 4 the device Device-3 is found. But Device-2 is connected to port 3 on switch 1, Device-1 is connected to port 3 on switch 2. I tried reading the whole table (LLDP-MIB::lldpRemTable) and could not find anything that gives me the switch number. 

Also the table LLDP-MIB::lldpLocPortTable (the number above is the index of an entry in this table) only contains the ports of switch 1, it does not contain the ports of switch 2. We read this table for the local port description and ID.

If we read the table IF-MIB::ifDescr we do get all ports of both switches but this table contains extra data at the beginning so the index returned by LLDP-MIB is not usable for this table even if we could see from which switch it is.

Is there another way to find the local port data for remote devices? Is something not configured correctly in the switches?

I also checked CISCO-STACK-MIB, LLDP-EXT-MED-MIB, LLDP-EXT-PNO-MIB and LLDP-EXT-DOT3-MIB but did not find the data I need. 

Thanks in advance,

Gerrit Til

[Georg Pauwen]

Hello,

you posted the same question a few months ago, and did not get an answer, which is obviously not good.

I wonder if EEM scripting would be an alternative, which basically means your switch sends an alert when a link is unavailable. I don't know in how far that fits into your current network monitoring strategy, but it could be a (temporary) workaround.

[gerrit.til]

Hi,

Thank you for the reply.

Yes I posted the same question a while ago and did not get an answer except that is was the wrong community. So I posted it again in this community hoping someone knows more.

We did try to contact technical support (and are still trying) but we also did not get an answer there. 

I will look into EEM scripting and see if we can do something with that. But we still prefer a SNMP solution if possible because we also need to support other brands of switches and have the SNMP solution already in place for those. 

Regards,

Gerrit

[Georg Pauwen]

Hello,

with technical support you mean TAC ?

[gerrit.til]

Hello,

I don't know yet if we have a support contract with Cisco. It's a bit unclear, nobody seems to know in my company. We did order the switch with support but we don't know which support and/or from who. 

We are in contact with technical support of the supplier of the switches but did not get much more than "have a look in LLDP-MIB and LLDP-EXT-MED-MIB" which we did. We did send them a snmpwalk of LLDP-MIB::lldpLocPortTable and LLDP-MIB::lldpRemTable to show the issue but after that we did not get any response. Maybe they are in contact with TAC, I don't know. 

[gerrit.til]

We got a reply from TAC: They checked and determined that LLDP-MIB::lldpRemSysName, LLDP-MIB::lldpRemPortId and LLDP-MIB::lldpRemPortDesc are not supported on the Stack setup.

We found a workaround by using the LLDP data we do get combined with the port status, for now this seems to work. A feature request is issued to get LLDP-MIB supported on a Stack setup.