10-29-2016 04:17 AM - edited 03-08-2019 07:58 AM
Hi all!
We have 2 WS-C4500X-16 SFP+ bundled as VSS running cat4500e-universalk9.SPA.03.05.03.E.152-1.E3.
Try to poll lldp topology from it and can't figure out how to map lldp port id to the ifindex of the interface. For example:
ifIndex list:
.1.3.6.1.2.1.2.2.1.1.1 [INTEGER] = 1
.1.3.6.1.2.1.2.2.1.1.344 [INTEGER] = 344
LLDP Neighbors (lldpRemChassisId):
.1.0.8802.1.1.2.1.4.1.1.5.0.11.2 [Hex-STRING] = A8 F9 4B 95 C7 00
.1.0.8802.1.1.2.1.4.1.1.5.0.12.4 [Hex-STRING] = A8 F9 4B E8 05 C0
.1.0.8802.1.1.2.1.4.1.1.5.0.1291.1 [Hex-STRING] = A8 F9 4B 95 C7 00
.1.0.8802.1.1.2.1.4.1.1.5.0.1292.3 [Hex-STRING] = A8 F9 4B E8 05 C0
Local port naming (lldpLocPortId):
.1.0.8802.1.1.2.1.3.7.1.3.11 [STRING] = Te1/1/11
.1.0.8802.1.1.2.1.3.7.1.3.12 [STRING] = Te1/1/12
.1.0.8802.1.1.2.1.3.7.1.3.1291 [STRING] = Te2/1/11
.1.0.8802.1.1.2.1.3.7.1.3.1292 [STRING] = Te2/1/12
So we have lldp ports 11,12,1291,1292. LLDP MIB says:
A port number has no mandatory relationship to an
InterfaceIndex object (of the interfaces MIB, IETF RFC 2863).
If the LLDP agent is a IEEE 802.1D, IEEE 802.1Q bridge, the
LldpPortNumber will have the same value as the dot1dBasePort
object (defined in IETF RFC 1493) associated corresponding
bridge port. If the system hosting LLDP agent is not an
IEEE 802.1D or an IEEE 802.1Q bridge, the LldpPortNumber
will have the same value as the corresponding interface's
InterfaceIndex object.
And here is a dot1dBasePort and dot1dBasePortIfIndex poll:
.1.3.6.1.2.1.17.1.4.1.1.2561 [INTEGER] = 2561
.1.3.6.1.2.1.17.1.4.1.1.2562 [INTEGER] = 2562
.1.3.6.1.2.1.17.1.4.1.1.2563 [INTEGER] = 2563
.1.3.6.1.2.1.17.1.4.1.1.2570 [INTEGER] = 2570
.1.3.6.1.2.1.17.1.4.1.1.2623 [INTEGER] = 2623
.1.3.6.1.2.1.17.1.4.1.1.2624 [INTEGER] = 2624
.1.3.6.1.2.1.17.1.4.1.1.2651 [INTEGER] = 2651
.1.3.6.1.2.1.17.1.4.1.1.2652 [INTEGER] = 2652
.1.3.6.1.2.1.17.1.4.1.2.2561 [INTEGER] = 41
.1.3.6.1.2.1.17.1.4.1.2.2562 [INTEGER] = 42
.1.3.6.1.2.1.17.1.4.1.2.2563 [INTEGER] = 43
.1.3.6.1.2.1.17.1.4.1.2.2570 [INTEGER] = 45
.1.3.6.1.2.1.17.1.4.1.2.2623 [INTEGER] = 46
.1.3.6.1.2.1.17.1.4.1.2.2624 [INTEGER] = 47
.1.3.6.1.2.1.17.1.4.1.2.2651 [INTEGER] = 337
.1.3.6.1.2.1.17.1.4.1.2.2652 [INTEGER] = 338
Not only the output does not map lldp port to bridge port, but the bridge ports does not contain ALL ports. 41-47, 337,338 are ifIndexes of Portchannels and not individual physical ports. Does any one know something about this issue, maybe newer software?
Solved! Go to Solution.
10-31-2016 01:16 AM
Hi,
our 4500-X-VSS running 03.06.04.E shows all dot1dBasePortIfIndex objects corresponding to (trunk)ports with VLAN 1 allowed and active when I use the community string without adding a '@<VLAN-ID>' context. As you probably know, VLAN 1 is the default context.
With <community>@0 I see all of the ports - same behavoir as yours. So perhaps you also have vlan allowed-lists on some of your trunks or non-VLAN1 access ports?
Btw: Irrespective of the snmp behavior I'd recommend to upgrade your IOS.
10-29-2016 12:31 PM
Alexander,
I cannot test this myself, since I don't have a 4500X, but what happens to the polling after you globally configure 'snmp-server ifindex persist' ?
10-30-2016 04:08 AM
this option does not affect anything. All numbers are the same.
10-30-2016 11:50 AM
The answer was as simple as weird. One can poll for all interfaces with snmp requests in context '0'. For example,
.1.3.6.1.2.1.17.1.4.1.2.1 [INTEGER]: 2
.1.3.6.1.2.1.17.1.4.1.2.2 [INTEGER]: 3
.1.3.6.1.2.1.17.1.4.1.2.3 [INTEGER]: 4
.1.3.6.1.2.1.17.1.4.1.2.4 [INTEGER]: 5
.1.3.6.1.2.1.17.1.4.1.2.5 [INTEGER]: 6
.1.3.6.1.2.1.17.1.4.1.2.6 [INTEGER]: 7
.1.3.6.1.2.1.17.1.4.1.2.7 [INTEGER]: 8
.1.3.6.1.2.1.17.1.4.1.2.8 [INTEGER]: 9
.1.3.6.1.2.1.17.1.4.1.2.9 [INTEGER]: 10
.1.3.6.1.2.1.17.1.4.1.2.10 [INTEGER]: 11
.1.3.6.1.2.1.17.1.4.1.2.11 [INTEGER]: 12
.1.3.6.1.2.1.17.1.4.1.2.12 [INTEGER]: 13
.1.3.6.1.2.1.17.1.4.1.2.13 [INTEGER]: 14
.1.3.6.1.2.1.17.1.4.1.2.14 [INTEGER]: 15
.1.3.6.1.2.1.17.1.4.1.2.15 [INTEGER]: 16
.1.3.6.1.2.1.17.1.4.1.2.16 [INTEGER]: 17
.1.3.6.1.2.1.17.1.4.1.2.1281 [INTEGER]: 18
.1.3.6.1.2.1.17.1.4.1.2.1282 [INTEGER]: 19
.1.3.6.1.2.1.17.1.4.1.2.1283 [INTEGER]: 20
.1.3.6.1.2.1.17.1.4.1.2.1284 [INTEGER]: 21
.1.3.6.1.2.1.17.1.4.1.2.1285 [INTEGER]: 22
.1.3.6.1.2.1.17.1.4.1.2.1286 [INTEGER]: 23
.1.3.6.1.2.1.17.1.4.1.2.1287 [INTEGER]: 24
.1.3.6.1.2.1.17.1.4.1.2.1288 [INTEGER]: 25
.1.3.6.1.2.1.17.1.4.1.2.1289 [INTEGER]: 26
.1.3.6.1.2.1.17.1.4.1.2.1290 [INTEGER]: 27
.1.3.6.1.2.1.17.1.4.1.2.1291 [INTEGER]: 28
.1.3.6.1.2.1.17.1.4.1.2.1292 [INTEGER]: 29
.1.3.6.1.2.1.17.1.4.1.2.1293 [INTEGER]: 30
.1.3.6.1.2.1.17.1.4.1.2.1294 [INTEGER]: 31
.1.3.6.1.2.1.17.1.4.1.2.1295 [INTEGER]: 32
.1.3.6.1.2.1.17.1.4.1.2.1296 [INTEGER]: 33
.1.3.6.1.2.1.17.1.4.1.2.2561 [INTEGER]: 41
.1.3.6.1.2.1.17.1.4.1.2.2562 [INTEGER]: 42
.1.3.6.1.2.1.17.1.4.1.2.2563 [INTEGER]: 43
.1.3.6.1.2.1.17.1.4.1.2.2569 [INTEGER]: 44
.1.3.6.1.2.1.17.1.4.1.2.2570 [INTEGER]: 45
.1.3.6.1.2.1.17.1.4.1.2.2575 [INTEGER]: 321
.1.3.6.1.2.1.17.1.4.1.2.2623 [INTEGER]: 46
.1.3.6.1.2.1.17.1.4.1.2.2624 [INTEGER]: 47
.1.3.6.1.2.1.17.1.4.1.2.2651 [INTEGER]: 337
.1.3.6.1.2.1.17.1.4.1.2.2652 [INTEGER]: 338
Why there was a need to do like that? I have a bunch of other cisco switch models and none of them does not even respond to '0' context.
10-30-2016 12:22 PM
Weird indeed. You are using SNMP v3 I assume ? I wonder if the same happens in v2, or v1...
10-31-2016 12:06 AM
I use v2. I think that v3 will work the same, but I'll check asap.
10-31-2016 01:16 AM
Hi,
our 4500-X-VSS running 03.06.04.E shows all dot1dBasePortIfIndex objects corresponding to (trunk)ports with VLAN 1 allowed and active when I use the community string without adding a '@<VLAN-ID>' context. As you probably know, VLAN 1 is the default context.
With <community>@0 I see all of the ports - same behavoir as yours. So perhaps you also have vlan allowed-lists on some of your trunks or non-VLAN1 access ports?
Btw: Irrespective of the snmp behavior I'd recommend to upgrade your IOS.
10-31-2016 01:16 AM
Thanks for sharing. So it seems like IOS version issue, cause I have trunks with ALL vlans allowed.
11-13-2016 11:31 PM
I had a lot of additional work to do to make upgrade from 3.5 to 3.6, cause it does not support issu.
But now it's done and I can confirm that in 3.6.5E all is working good. :)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide