NetXMS Support Forum

I have 2 4500x switches which are coupled as one logical unit with VSS technologie.
And in the event log I see that this switch keeps rediscovering 'new' (in fact old) peers every 30 minutes like so:

Quote
18399   25.10.2016 08:40:59   core-sw         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Te1/1/11 is switch9 interface te1/0/48 (A8:F9:4B:95:C7:30)      0
18398   25.10.2016 08:40:59   switch9         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface te1/0/48 is core-sw interface Te1/1/11 (7C:0E:CE:25:50:22)      0
18397   25.10.2016 08:40:59   core-sw         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Te2/1/11 is switch9 interface te1/0/47 (A8:F9:4B:95:C7:2F)      0
18396   25.10.2016 08:40:59   switch9         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface te1/0/47 is core-sw interface Te2/1/11 (58:F3:9C:96:0B:FA)      0
18395   25.10.2016 08:39:37   core-sw         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Te1/1/12 is switch92 interface te1/0/48 (A8:F9:4B:E8:05:F0)      0
18394   25.10.2016 08:39:37   switch92      0   SYS_IF_PEER_CHANGED   Normal   New peer for interface te1/0/48 is core-sw interface Te1/1/12 (7C:0E:CE:25:50:23)      0
18393   25.10.2016 08:39:37   core-sw         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Te2/1/12 is switch92 interface te1/0/47 (A8:F9:4B:E8:05:EF)      0
18392   25.10.2016 08:39:37   switch92      0   SYS_IF_PEER_CHANGED   Normal   New peer for interface te1/0/47 is core-sw interface Te2/1/12 (58:F3:9C:96:0B:FB)      0
18391   25.10.2016 08:39:19   rt2            0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Gi0/0/2.2365 is switch1 interface Gi4/5 (00:0D:65:04:25:1E)      0
18390   25.10.2016 08:39:19   switch1         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Gi4/5 is rt2 interface Gi0/0/2.2365 (88:43:E1:1D:D9:02)         0
18389   25.10.2016 08:32:13   rt2            0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Gi0/0/2.2365 is switch3 interface Gi0/2 (88:F0:77:D1:20:02)      0
18388   25.10.2016 08:32:13   switch3         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Gi0/2 is rt2 interface Gi0/0/2.2365 (88:43:E1:1D:D9:02)         0

18387   25.10.2016 08:10:50   core-sw         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Te1/1/11 is switch9 interface te1/0/48 (A8:F9:4B:95:C7:30)      0
18386   25.10.2016 08:10:50   switch9         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface te1/0/48 is core-sw interface Te1/1/11 (7C:0E:CE:25:50:22)      0
18385   25.10.2016 08:10:50   core-sw         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Te2/1/11 is switch9 interface te1/0/47 (A8:F9:4B:95:C7:2F)      0
18384   25.10.2016 08:10:50   switch9         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface te1/0/47 is core-sw interface Te2/1/11 (58:F3:9C:96:0B:FA)      0
18383   25.10.2016 08:09:32   core-sw         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Te1/1/12 is switch92 interface te1/0/48 (A8:F9:4B:E8:05:F0)      0
18382   25.10.2016 08:09:32   switch92      0   SYS_IF_PEER_CHANGED   Normal   New peer for interface te1/0/48 is core-sw interface Te1/1/12 (7C:0E:CE:25:50:23)      0
18381   25.10.2016 08:09:32   core-sw         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Te2/1/12 is switch92 interface te1/0/47 (A8:F9:4B:E8:05:EF)      0
18380   25.10.2016 08:09:32   switch92      0   SYS_IF_PEER_CHANGED   Normal   New peer for interface te1/0/47 is core-sw interface Te2/1/12 (58:F3:9C:96:0B:FB)      0
18379   25.10.2016 08:09:03   rt2            0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Gi0/0/2.2365 is switch1 interface Gi4/5 (00:0D:65:04:25:1E)      0
18378   25.10.2016 08:09:03   switch1         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Gi4/5 is rt2 interface Gi0/0/2.2365 (88:43:E1:1D:D9:02)         0
18377   25.10.2016 08:02:07   rt2            0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Gi0/0/2.2365 is switch3 interface Gi0/2 (88:F0:77:D1:20:02)      0
18376   25.10.2016 08:02:07   switch3         0   SYS_IF_PEER_CHANGED   Normal   New peer for interface Gi0/2 is rt2 interface Gi0/0/2.2365 (88:43:E1:1D:D9:02)         0

Maybe netxms is getting confused by the fact that this switch is a logical stack of 2 switches that are connected by te1/0/47, te1/0/48 on both switches.

I just noted that in the event log at 11:40 new peers appeared again and interface table showed correct peer information, but in several minutes (around 7-8 minutes) some records in the interface table just disappeared and event log does not show any information about that.

Forced topology poll shows me that it found 10 connections but in the following list there are only 8 connections.

Quote
[25.10.2016 11:58:53] Link layer topology retrieved (10 connections found)
[25.10.2016 11:58:53] Updating peer information on interfaces
[25.10.2016 11:58:53]    Local interface Te1/1/1 linked to remote interface xxx:Te3/1
[25.10.2016 11:58:53]    Local interface Te1/1/2 linked to remote interface yyy:Gi1/8
[25.10.2016 11:58:53]    Local interface Te1/1/3 linked to remote interface zzz:Gi2/0/1
[25.10.2016 11:58:53]    Local interface Te1/1/10 linked to remote interface bbb:Gi2/0/24
[25.10.2016 11:58:53]    Local interface Te2/1/1 linked to remote interface xxx:Te4/1
[25.10.2016 11:58:53]    Local interface Te2/1/2 linked to remote interface yyy:Gi2/8
[25.10.2016 11:58:53]    Local interface Te2/1/3 linked to remote interface zzz:Gi3/0/1
[25.10.2016 11:58:53]    Local interface Te2/1/10 linked to remote interface bbb:Gi1/0/24

If I do topology poll on the 4500x the peers in interface table disappear, if I do topology poll on the disappeared peer the interface table is populated again and is correct.

In the logs found inconsistent data:

Quote[25-Oct-2016 13:57:22.731] [DEBUG] LLDP: collecting topology information for node vss [819]
[25-Oct-2016 13:57:22.855] [DEBUG] LLDP: 36 entries in connection database for node vss [819]
[25-Oct-2016 13:57:22.855] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): remoteId=4@A8F94B95C700 remoteNode=m9-1 [270]
[25-Oct-2016 13:57:22.855] [DEBUG] LLDPTopoHandler(m9-1 [270]): FindRemoteInterface: idType=5 id=7465312F302F3438 (
[25-Oct-2016 13:57:22.855] [DEBUG] LLDPTopoHandler(m9-1 [270]): FindRemoteInterface: getLldpLocalPortInfo found port: 48 "Ethernet Interface"
[25-Oct-2016 13:57:22.855] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): lookup bridge port: localPort=11 iface=(null)
[25-Oct-2016 13:57:22.855] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): added connection: objectId=270 ifRemote=48 ifLocal=-1
[25-Oct-2016 13:57:22.855] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): remoteId=4@A8F94BE805C0 remoteNode=m9-2 [272]
[25-Oct-2016 13:57:22.855] [DEBUG] LLDPTopoHandler(m9-2 [272]): FindRemoteInterface: idType=5 id=7465312F302F3438 (
[25-Oct-2016 13:57:22.855] [DEBUG] LLDPTopoHandler(m9-2 [272]): FindRemoteInterface: getLldpLocalPortInfo found port: 48 "Ethernet Interface"
[25-Oct-2016 13:57:22.855] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): lookup bridge port: localPort=12 iface=(null)
[25-Oct-2016 13:57:22.855] [DEBUG] LinkLayerNeighbors::isDuplicate: inconsistent data: LLDP(ifLocal=-1 remote=270/48) LLDP(ifLocal=-1 remote=272/48)
[25-Oct-2016 13:57:22.855] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): added connection: objectId=272 ifRemote=48 ifLocal=-1
[25-Oct-2016 13:57:22.856] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): remoteId=4@A8F94B95C700 remoteNode=m9-1 [270]
[25-Oct-2016 13:57:22.856] [DEBUG] LLDPTopoHandler(m9-1 [270]): FindRemoteInterface: idType=5 id=7465312F302F3437 (
[25-Oct-2016 13:57:22.856] [DEBUG] LLDPTopoHandler(m9-1 [270]): FindRemoteInterface: getLldpLocalPortInfo found port: 47 "Ethernet Interface"
[25-Oct-2016 13:57:22.856] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): lookup bridge port: localPort=1291 iface=(null)
[25-Oct-2016 13:57:22.856] [DEBUG] LinkLayerNeighbors::isDuplicate: inconsistent data: LLDP(ifLocal=-1 remote=270/48) LLDP(ifLocal=-1 remote=270/47)
[25-Oct-2016 13:57:22.856] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): added connection: objectId=270 ifRemote=47 ifLocal=-1
[25-Oct-2016 13:57:22.856] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): remoteId=4@A8F94BE805C0 remoteNode=m9-2 [272]
[25-Oct-2016 13:57:22.856] [DEBUG] LLDPTopoHandler(m9-2 [272]): FindRemoteInterface: idType=5 id=7465312F302F3437 (
[25-Oct-2016 13:57:22.856] [DEBUG] LLDPTopoHandler(m9-2 [272]): FindRemoteInterface: getLldpLocalPortInfo found port: 47 "Ethernet Interface"
[25-Oct-2016 13:57:22.856] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): lookup bridge port: localPort=1292 iface=(null)
[25-Oct-2016 13:57:22.856] [DEBUG] LinkLayerNeighbors::isDuplicate: inconsistent data: LLDP(ifLocal=-1 remote=270/48) LLDP(ifLocal=-1 remote=272/47)
[25-Oct-2016 13:57:22.856] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): added connection: objectId=272 ifRemote=47 ifLocal=-1
[25-Oct-2016 13:57:22.856] [DEBUG] LLDP: finished collecting topology information for node vss [819]

Still can't figure out why this happening with this switch. Put some logs here, maybe someone take a look at this.
This is what happen when  I do topology poll on both sides of the peer connection.

Quote
======== one side =======
first port
[27-Oct-2016 15:47:33.543] [DEBUG] ProcessLLDPConnectionEntry(m9-2 [272]): remoteId=4@0008E3FFFC28 remoteNode=vss [819]
[27-Oct-2016 15:47:33.543] [DEBUG] LLDPTopoHandler(vss [819]): FindRemoteInterface: idType=5 id=5465322F312F3132 (
[27-Oct-2016 15:47:33.544] [DEBUG] LLDPTopoHandler(vss [819]): FindRemoteInterface: getLldpLocalPortInfo found port: 1292 "TenGigabitEthernet2/1/12"      <--- 1292 seems INCORRECT, cause interface table does not contain port information
[27-Oct-2016 15:47:33.544] [DEBUG] ProcessLLDPConnectionEntry(m9-2 [272]): lookup bridge port: localPort=47 iface=te1/0/47                                  <---- these numbers look right
[27-Oct-2016 15:47:33.544] [DEBUG] ProcessLLDPConnectionEntry(m9-2 [272]): added connection: objectId=819 ifRemote=29 ifLocal=47                  <---- and these numbers look right
second port
[27-Oct-2016 15:47:33.544] [DEBUG] ProcessLLDPConnectionEntry(m9-2 [272]): remoteId=4@0008E3FFFC28 remoteNode=vss [819]
[27-Oct-2016 15:47:33.544] [DEBUG] LLDPTopoHandler(vss [819]): FindRemoteInterface: idType=5 id=5465312F312F3132 (
[27-Oct-2016 15:47:33.544] [DEBUG] LLDPTopoHandler(vss [819]): FindRemoteInterface: getLldpLocalPortInfo found port: 12 "TenGigabitEthernet1/1/12"  <---looks good
[27-Oct-2016 15:47:33.545] [DEBUG] ProcessLLDPConnectionEntry(m9-2 [272]): lookup bridge port: localPort=48 iface=te1/0/48
[27-Oct-2016 15:47:33.545] [DEBUG] ProcessLLDPConnectionEntry(m9-2 [272]): added connection: objectId=819 ifRemote=13 ifLocal=48
=============
======== other side =======
[27-Oct-2016 15:48:05.197] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): remoteId=4@A8F94B95C700 remoteNode=m9-1 [270]
[27-Oct-2016 15:48:05.197] [DEBUG] LLDPTopoHandler(m9-1 [270]): FindRemoteInterface: idType=5 id=7465312F302F3438 (
[27-Oct-2016 15:48:05.197] [DEBUG] LLDPTopoHandler(m9-1 [270]): FindRemoteInterface: getLldpLocalPortInfo found port: 48 "Ethernet Interface"
[27-Oct-2016 15:48:05.197] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): lookup bridge port: localPort=11 iface=(null)
[27-Oct-2016 15:48:05.197] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): added connection: objectId=270 ifRemote=48 ifLocal=66150018

[27-Oct-2016 15:48:05.197] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): remoteId=4@A8F94BE805C0 remoteNode=m9-2 [272]
[27-Oct-2016 15:48:05.198] [DEBUG] LLDPTopoHandler(m9-2 [272]): FindRemoteInterface: idType=5 id=7465312F302F3438 (
[27-Oct-2016 15:48:05.198] [DEBUG] LLDPTopoHandler(m9-2 [272]): FindRemoteInterface: getLldpLocalPortInfo found port: 48 "Ethernet Interface"
[27-Oct-2016 15:48:05.198] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): lookup bridge port: localPort=12 iface=(null)
[27-Oct-2016 15:48:05.198] [DEBUG] LinkLayerNeighbors::isDuplicate: inconsistent data: LLDP(ifLocal=66150018 remote=270/48) LLDP(ifLocal=66150018 remote=272/48)
[27-Oct-2016 15:48:05.198] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): added connection: objectId=272 ifRemote=48 ifLocal=66150018

[27-Oct-2016 15:48:05.198] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): remoteId=4@A8F94B95C700 remoteNode=m9-1 [270]
[27-Oct-2016 15:48:05.198] [DEBUG] LLDPTopoHandler(m9-1 [270]): FindRemoteInterface: idType=5 id=7465312F302F3437 (
[27-Oct-2016 15:48:05.198] [DEBUG] LLDPTopoHandler(m9-1 [270]): FindRemoteInterface: getLldpLocalPortInfo found port: 47 "Ethernet Interface"
[27-Oct-2016 15:48:05.198] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): lookup bridge port: localPort=1291 iface=(null)
[27-Oct-2016 15:48:05.199] [DEBUG] LinkLayerNeighbors::isDuplicate: inconsistent data: LLDP(ifLocal=66150018 remote=270/48) LLDP(ifLocal=66150018 remote=270/47)
[27-Oct-2016 15:48:05.199] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): added connection: objectId=270 ifRemote=47 ifLocal=66150018

[27-Oct-2016 15:48:05.199] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): remoteId=4@A8F94BE805C0 remoteNode=m9-2 [272]
[27-Oct-2016 15:48:05.199] [DEBUG] LLDPTopoHandler(m9-2 [272]): FindRemoteInterface: idType=5 id=7465312F302F3437 (
[27-Oct-2016 15:48:05.199] [DEBUG] LLDPTopoHandler(m9-2 [272]): FindRemoteInterface: getLldpLocalPortInfo found port: 47 "Ethernet Interface"
[27-Oct-2016 15:48:05.199] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): lookup bridge port: localPort=1292 iface=(null)
[27-Oct-2016 15:48:05.199] [DEBUG] LinkLayerNeighbors::isDuplicate: inconsistent data: LLDP(ifLocal=66150018 remote=270/48) LLDP(ifLocal=66150018 remote=272/47)
[27-Oct-2016 15:48:05.199] [DEBUG] ProcessLLDPConnectionEntry(vss [819]): added connection: objectId=272 ifRemote=47 ifLocal=66150018

ok, I figured out why it's inconsistent.
Because netxms does not do correct mapping of lldp port id to ifindex. Here is a quote from my question on cisco support forum (https://supportforums.cisco.com/discussion/13153696/snmp-lldp-port-id-ifindex-mapping-4500x):

QuoteWe 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?

And today I found that one can poll the mapping for all ports by snmpwalk in context '0'. For example,

Quotendd# nxsnmpwalk -c public@0 172.16.x.x .1.3.6.1.2.1.17.1.4.1.2
.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

Unfortunately, this context '0' is not universal across cisco devices. I have several other cisco devices that does not even respond to '0' context requests. So this must be implemented as a hack or maybe move that part to device driver.

It was an IOS version issue. After upgrade it's gone.