Header Only - DO NOT REMOVE - Extreme Networks

snmp traps / syslog message for optical values out normal range

  • 9 August 2019
  • 9 replies

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

9 replies

Userlevel 6
Long standing feature request that many of us have requested before. We are still waiting. Only way I can think of is some kind of intelligent script that id's the type of optic, via a telnet session and gives it a pass or fail for your server.

What is bad is that really is not good enough. You need to be able to track the light levels over time and like us in a metro network with thousands of links you have to know what the reading was before you had a fiber event to know if the repair was good. We try and maintain optical readings with dates taken in an open text area in our snmp server views on interconnecting links

Userlevel 6
Really you want the data exposed via SNMP ... which is a feature request: https://gtacknowledge.extremenetworks.com/articles/Q_A/How-to-get-optics-SFP-SFP-XFP-fiberQSFP-DDMI-information-via-SNMP-MIB
Userlevel 6
Yes ... the ability to pull this info just like you pull and chart any other port stats would be a plus. Anyone that exposes their snmp info or network management systems to outside parties or connections should have strict security policies in place not allowing just anyone to have access ...
Userlevel 6
Interesting discovery... My team just informed me there is a new trap being put out only by the 670G2 that is a low light level warning. Problem is that the switch is sending it out as a ENTERASYS-MIB-NAMES|etsysModuleName-5624-1- Since the snmp server associates the switch with a EXOS mib it does not know what to do .... Seems we are closer to getting info.

the switch is logging info too

08/09/2019 10:42:59.40 Port 24 RX Power Sensor=low warning Value= 0.44 mW

Now we just need to get the trap updated to be a EXOS trap and we would be one step closer.
what XOS version are u running on the 670G2?
Any why have they mixed in the enterasys mib?

After my perception, Extreme have no ISP focus at the moment, there is just datacenter..
Userlevel 6
PLW_X670G2_Sugarland_Node.2 # sh vers
Switch : 800546-00-13 1744N-41391 Rev 13 BootROM: IMG:
PSU-1 : Internal PSU-1 800463-00-07 1619W-80009 Rev 07
PSU-2 : Internal PSU-2 800463-00-07 1619W-80010 Rev 07

Image : ExtremeXOS version by release-manager
on Thu Jan 18 08:49:53 EST 2018
BootROM :
Diagnostics : 5.12
Certified Version : EXOS Linux 3.18.48, FIPS fips-ecp-2.0.16
Userlevel 6
You can use a UPM Profile to generate a trap if DDMI warning message occurs.

Here is a example that shows the mechanism:


Userlevel 6
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- when is should be not send out trap at all or sending out a private vendor trap as a EXOS switch
Userlevel 3
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 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.