snmp traps / syslog message for optical values out normal range

[Peder_Bach]

How can I get my XOS device to send snmp-trap or syslog message if the optical values are out of normal range?


show port 1:1 transceiver information

Port Temp TxPower RxPower TxBiasCurrent Voltage-Aux1/ Voltage-Aux2
(Celsius) (dBm) (dBm) (mA) Vcc (Volts) (Volts)
================================================================================
1:1 39.81 2.02 0.53* 8.86 3.31 N/A
================================================================================
N/A - parameter not applicable to transceiver connected to the port
* - value is out of normal range
-inf - negative infinity, parameter not defined

[FredrikB]

Hi!

The SE left Extreme for another job, so I’m afraid the request was dropped. I’ll see if I can get a customer or two to add this to their feature request lists. I brushed off the old email conversation and sent it again to the new SE among others, so we’ll see what happens. You’re more than welcome to remind me again in some time! I’ll try to remember to update you on the progress.

/Fredrik

[Peder_Bach]

Fredrik, did u get any response from the Swedish Extreme team? 

[FredrikB]

Traps are all good, but I'd very much like to see an OID tree where I can read optical levels of the SFPs. I'll have the Swedish Extreme team dig into this and hopefully we'll be the drop that overflows the glass 🙂

Also, I saw EtherMAN was using 21.4.1.4. We discovered a bug in that release that gave us the following symptoms:

xos0070961 - Broadcast SNMP get/set-request are being processed by switch eventhough no IP configured on any VLAN

The switch interprets and executes snmp for packets just going through a switch on a plain L2 VLAN, and even if there is no ip connectivity between the snmp client and the switch. You should NOT use generic communities like public and, specifically, not private, even if you think your switches' management IP is protected from the clients. We did a test where an SNMP packet was sent to the broadcast address with the correct SNMP SET community and we could then manipulate anything we wanted via these packets. I'm not sure in what release this was fixed, but we mitigated this with specific ACLs.

/Fredrik

[EtherMAN]

thanks for the link M.Nees. this is a good work around but many of us have asked for snmp based mibs to support this. Right now it seems the only switch in the fleet that is putting out log messages are the G2 series.

Real question still remains is why a EXOS switch is sending out a trap as a ENTERASYS-MIB-NAMES|etsysModuleName-5624-1-2.85.1.0.2 when is should be not send out trap at all or sending out a private vendor trap as a EXOS switch