SNMP v3 on Alcatel Switches & Stack Switches

[Filo]

Hi,

I'm referring to an older question of another User in this Forum (http://www.lansweeper.com/Forum/yaf_postst11320findunread_Any-way-of-debugging-SNMP-v3-queries.aspx#post42246)

We encountered a similar problem, that our Alcatel Switches are not able to be scanned via SNMP v3 through Lansweeper. Even the device-Tester is not able to get a reply from those devices. We double-checked everything, authentication, connection and even with a secondary tool (Paessler) to check if anything is possible.

First thing we found with Paessler:

1.3.6.1.2.1.1.2.0 works
1.3.6.1.2.1.1.2 not

----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 Computername: xxxxxx Interface: (10.XX.X.50)
04.01.2017 14:27:20 (22 ms) : Device: 10.XX.XXX.11
04.01.2017 14:27:20 (49 ms) : SNMP V3
04.01.2017 14:27:20 (54 ms) : Custom OID 1.3.6.1.2.1.1.2
04.01.2017 14:27:20 (183 ms) : SNMP Datatype: SNMP_EXCEPTION_NOSUCHINSTANCE
04.01.2017 14:27:20 (193 ms) : -------
04.01.2017 14:27:20 (216 ms) : Value: No such instance (SNMP error # 223)
04.01.2017 14:27:20 (220 ms) : Done


----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 Computername: xxxxxx Interface: (10.XX.X.50)
04.01.2017 14:27:25 (19 ms) : Device: 10.XX.XXX.11
04.01.2017 14:27:25 (29 ms) : SNMP V3
04.01.2017 14:27:25 (39 ms) : Custom OID 1.3.6.1.2.1.1.2.0
04.01.2017 14:27:25 (151 ms) : SNMP Datatype: ASN_OBJECT_ID
04.01.2017 14:27:25 (157 ms) : -------
04.01.2017 14:27:25 (163 ms) : Value: 1.3.6.1.4.1.6486.800.1.1.2.1.10.1.6
04.01.2017 14:27:25 (169 ms) : Done

Paessler shows that the Custom OID used by Lansweeper device-tester seems to be incorrect / not showing a result. The same OID added with a ".0" gives the result desired.

We already had contact via EMail to Lansweeper support but ended in "Please monitor the traffic between Lansweeper and the device with Wireshark" that then has been too much hassle for us. As shown above the main thing might be the OID.

Would someone be able to assist us in this matter? Could it be that the device-tester needs to be changed / fixed?


Another, second problem:
When those switches are stacked they will be recognized as ONE Element only (we did this with SNMPv2) and if you try to enter the stacks manually they will be merged to the master (without adding hardware-information / serial-no., etc.) to the lansweeper database afterwards.

Is there a chance to get at least the details of the merged element(s) to the entry of the stack?

Thanks in advance for any help,
Martin!

[Filo]

Awesome! I saw it in the changelog today (MD5 / SHA1) - that's solved!
Thanks for the follow-up and keeping alive this thread!

[fjca · Accepted solution]

Hi all,

Just to inform that the latest version, v6.0.100.67, solved our issue with SNMPv3 on Alcatel switches, we are now able to scan our remaining equipment.

[Filo]

Thanks alot for your help - maybe this is the last fragment to sum all up to correct the Query Lansweeper is sending, since we are not able to modify the response from those devices.

Big thanks!

[fjca]

Hello all,

So, a bit late, but as promised, I've managed to get a wireshark dump today.
This is a result of running DeviceTester against a working Alcatel Switch,
in this case, a OS6450, IP 10.x.y.z, running from the Lansweeper server,
with IP 10.a.b.c.


3 13.626656 10.a.b.c → 10.x.y.z ICMP 74 Echo (ping) request id=0x0002, seq=43587/17322, ttl=128
4 13.627246 10.x.y.z → 10.a.b.c ICMP 74 Echo (ping) reply id=0x0002, seq=43587/17322, ttl=63 (request in 3)
5 13.770958 10.a.b.c → 10.x.y.z SNMP 106 get-request
6 13.772695 10.x.y.z → 10.a.b.c SNMP 146 report 1.3.6.1.6.3.15.1.1.4.0
7 13.830274 10.a.b.c → 10.x.y.z SNMP 128 get-request
8 13.856586 10.x.y.z → 10.a.b.c SNMP 145 report 1.3.6.1.6.3.15.1.1.3.0
9 13.959009 10.a.b.c → 10.x.y.z SNMP 106 get-request
10 13.960752 10.x.y.z → 10.a.b.c SNMP 146 report 1.3.6.1.6.3.15.1.1.4.0
11 13.960919 10.a.b.c → 10.x.y.z SNMP 128 get-request
12 13.962648 10.x.y.z → 10.a.b.c SNMP 145 report 1.3.6.1.6.3.15.1.1.3.0
15 14.042195 10.a.b.c → 10.x.y.z SNMP 173 get-request 1.3.6.1.2.1.1.2.0

So, not a lot of help... we get some responses, but not what LS expects or can handle.

I'm sending the complete packet trace to the support email, maybe they can have some idea what is happening.

[Filo]

That sounds awesome, thanks for this!
I would think the wireshark will not have many findings, since sending a query with the wrong OID simply makes the switch tell the requester "No such instance" as we already found out.

But I would be very interested in how this shows up in Wireshark and if this sums up.

Thx again!

[fjca]

Hi, I'm the original poster for that, and I'm still getting that error.

I may squeeze a few minutes of time next week to do more testing and do the Wireshark dump, we are not buying Alcatel anymore, but we still have a lot of them in production...