Avaya ERS Switch/Stack Monitoring Through SNMP

[bylie]

@Slava N:
Thanks for the reply and good to know that this is known already and that there is a solution, but I've gone through the releasenotes of SW 5.5 again and for as far as I can see there's no mentioning of this being a resolved issue. So I'm wondering how would anyone know that this issue is resolved, besides someone telling them? Did you open a supportcase for this issue? Does this issue also involve bogus fan warnings as I can see from you're output that all 4 fans have failed ? Can the bogus temperature readout be cleared somehow besides rebooting the switch probably?

[Slava N]

@bylie:
case on this problem was opened from avaya side when we monitoring temperature through SNMP. Fan status changed to FAIL simultaneously with temperature sensor.
Incorrect temperature readout to be cleared only after reboot.
avaya promised resolve this problem in release 5.5.
after lot of tests on release 5.5 switch temperature readout are correctly.

[bylie]

So I take it you're running SW 5.5 on some/all of your ERS 4500's? What's your overall take on it? A couple of weeks ago we installed the new Avaya COM so we're gradually going to migrate to using that, instead of ESM, for all of our overall networkmanagement which also means we can now start to upgrade our existing networkdevices to EDM enabled software releases.

[Slava N]

we planned update to 5.5 in future. i think we install COM after upgrade all our devices to EDM enabled software.
I thought that COM monitoring and manage devices through SNMP. I'm right?

[bylie]

COM also talks SNMP to the switches, you can start using COM before all the switches are on EDM SW because it will detect this and launch the old JDM when needed.

[bylie]

I've been busy trying to get snmptrap functionality into our Nagios setup and it seems doable although I'm a bit confused concerning some of the snmptraps. I've converted the ERS 2500 4.2.0 MIB's using snmptt's convertscript into snmptt.conf.ers2500 and that went OK but when I test a bad login for example, the OID of the trap does not correspond to anything in the snmptt.conf.ers2500.

When I deliberately login with incorrect credentials I'm getting the following in the /var/log/snmptt/snmpttunknown.log:

Code: [Select]

Wed Aug 24 08:45:16 2011: Unknown trap (.1.3.6.1.4.1.45.5.2.1.0.2) received from <switch_IP> at:
Value 0: <switch_IP>
Value 1: <switch_IP>
Value 2: 46:12:05:49.43
Value 3: .1.3.6.1.4.1.45.5.2.1.0.2
Value 4: <switch_IP>
Value 5: <trapcommunity>
Value 6: .1.3.6.1.4.1.45.5.2.1
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.45.5.2.1.2.0=1
Ent Value 1: .1.3.6.1.4.1.45.5.2.1.3.0=1
Ent Value 2: .1.3.6.1.4.1.45.5.2.1.4.0=0A 0A 6A 16
Ent Value 3: .1.3.6.1.4.1.45.5.2.1.5.0=RW
This seems to correspond to the bsnObjects   (.1.3.6.1.4.1.45.5.2.1) OID from the BAY-STACK-NOTIFICATIONS-MIB but when I look in that MIB everything under that OID seems to be defined as an OBJECT-TYPE. I guess what I was expecting is a trap with the bsnLoginFailure .1.3.6.1.4.1.45.5.2.2.0.6 OID as this is defined in the MIB as a NOTIFICATION-TYPE and is infact in the snmptt.conf.ers2500 file generated from running the snmptt convertscript. Am I forgetting something here?

[Michael McNamara]

If you want to verify the data from snmptt you can run a quick packet trace (tcpdump -s0 port snmptrap) and then examine the output in WireShark.

If WireShark reports the same OID values then the ERS 2500 might not report the same as say the ERS 4500 or ERS 5000 series.

Cheers!

[bylie]

So I did a tcpdump using the following options "# tcpdump -n -vvv udp dst port 162" and deliberately tried to login to the switch using a wrong password:

Code: [Select]

08:53:58.694894 IP (tos 0x0, ttl 63, id 36446, offset 0, flags [none], proto UDP (17), length 154) <switch_IP>.1025 > <server_IP>.162:  { SNMPv1 C=<trapcommunity> { Trap(107)  .1.3.6.1.4.1.45.5.2.1 <switch_IP> enterpriseSpecific s=2 419126993 [|snmp] } }
Trying to login to a ERS 4524GT using a wrong password produces the following:

Code: [Select]

09:00:37.809728 IP (tos 0x0, ttl 63, id 37042, offset 0, flags [none], proto UDP (17), length 154) <switch_IP>.1121 > <server_IP>.162:  { SNMPv1 C=<trapcommunity> { Trap(107)  .1.3.6.1.4.1.45.5.2.2 <switch_IP> enterpriseSpecific s=6 673008002 [|snmp] } }
09:00:39.682364 IP (tos 0x0, ttl 63, id 37044, offset 0, flags [none], proto UDP (17), length 78) <switch_IP>.1121 > <server_IP>.162: [udp sum ok]  { SNMPv1 C=<trapcommunity> { Trap(31)  .1.3.6.1.4.1.45.5.2.2 <switch_IP> enterpriseSpecific s=1 673008190 } }
Also the /var/log/snmptt/snmpttunknown.log entry from the ERS 4524GT:

Code: [Select]

Fri Aug 26 09:00:38 2011: Unknown trap (.1.3.6.1.4.1.45.5.2.2.0.6) received from <switch_IP> at:
Value 0: <switch_IP>
Value 1: <switch_IP>
Value 2: 77:21:28:00.02
Value 3: .1.3.6.1.4.1.45.5.2.2.0.6
Value 4: <switch_IP>
Value 5: <trapcommunity>
Value 6: .1.3.6.1.4.1.45.5.2.2
Value 7:
Value 8:
Value 9:
Value 10:
Ent Value 0: .1.3.6.1.4.1.45.5.2.1.2.0=1
Ent Value 1: .1.3.6.1.4.1.45.5.2.1.3.0=1
Ent Value 2: .1.3.6.1.4.1.45.5.2.1.4.0=0A 0A 6A 16
Ent Value 3: .1.3.6.1.4.1.45.5.2.1.5.0=RW
So it seems the ERS 2500 is using a different OID. Very strange because when I follow the OID tree upwards beginning from "bsnLoginFailure" in the BAY-STACK-NOTIFICATIONS-MIB.mib from the ERS 2500 SW v4.2.0 it should be the following:

• bsnLoginFailure = 6
• bsnNotifications0 = 0
• bsnNotifications = 2
• bayStackNotificationsMib = 2
• bayStackMibs = 1.3.6.1.4.1.45.5

[bylie]

As promised the current Pythonscript we're using to check our ES/ERS switches and stacks in Nagios. It only comes with the "hey, but it works for us" guarantee .

Note that I had to change the file extension from .py to .txt in order to attach it.