The MIBs for FortiOS core, Fortigate, and Fortiswitch (where I really care) seem to lack any OIDs for transceiver diagnostic data. Namely RX strength. We do this sort of monitoring with all our non-Forti networks, typically with LibreNMS. I checked the OID mappings that Aruba/Cisco/Mikrotik tend to use, found no similar spot in an SNMPWALK of a fs-1048e, fs-148f, fs-108f, or FG-201F.
Obviously the switches have the data, as the below command would show.
get switch modules status port49
____________________________________________________________
Port(port49)
temperature 40.539062 C
voltage 3.300300 volts
alarm_flags 0x0040
warning_flags 0x0040
laser_bias 35.442001 mAmps
tx_power -2.726214 dBm
rx_power -18.124792 dBm
options 0x000F ( TX_DISABLE TX_FAULT RX_LOSS TX_POWER_LEVEL1 )
options_status 0x0008 ( TX_POWER_LEVEL1 )Anybody know if it's possible to poll the transceivers for health metrics via SNMP?
This is a fair request but it seems like this OID doesn't exist yet. I would suggest to contact your local Fortinet representative to file a NFR (new feature request) since this would be very helpful to keep an eye on monitoring the fibers health.
For the moment there is support through API for FSW transceivers managed by FGT that you can try if your monitoring system supports API:
GET /switch-controller/managed-switch/tx-rx
Parameters:
mkey * Filter: FortiSwitch ID.
port * Name of the port.
Response:
| tx-power | |
| rx-power |
I was looking for DOM/DMI information in SNMP as well. IMHO it's quite bizarre this isn't implemented
Emirjon,
I submitted NFRs via our partner rep. The initial response was very much "can't you use the API". Could I code some platform to do API checks? Yes. But that answer is essentially "throw out the SNMP monitoring you use for everything else".
Thank you for your feedback! Your request is valid so I believe it will get implemented soon.
There are some monitoring platform that allow monitoring from different sources, (custom scripts, syslog etc.), you can verify maybe there is a way to adapt the information received from API.
Is it already available nowadays?
No. Transceiver monitoring is somewhat implemented in SNMP now, but as expected from Fortinet the implementation is completely broken.
The OIDs are entirely random and you cannot identify which OID belongs to which SFP ports (other than guessing based on port number)
I've reported a bug for this issue, which was accepted, but not yet resolved.
Thank you, I'd seen SNMP updates in release notes but hadn't taken the time to crawl the MIB again.
Created on
‎01-19-2026
12:39 PM
Edited on
‎01-19-2026
09:45 PM
By
Jean-Philippe_P
They have implemented the values in the ENTITY-SENSOR-MIB
So the sensors show up as any other sensor (be it a temp sensor, RPM sensor, power sensor, etc). So there's a new 'mA' (miliamp) sensor OID in the sensor table, with eg. index 30.
But there is no way to determine to which SFP port index 30 belongs. So you can't actually link the values to a specific transceiver without guessing.
And by guessing I mean that you should have a list of the number of sensors for any specific switch model, and count from there. So if a 148F-FPOE has 3 regular sensors (temp, fan, psu) the first SFP port will be index 4.
so as I said.. the implementation is completely useless and not production ready.
Another thing, the ENTITY-SENSOR-MIB has predefined specific datatypes (volt, amps, rpm, degrees). There is no datatype for dBm in the ENTITY-SENSOR-MIB. So Fortinet cannot show dBm values using this MIB and thus this is not implemented.
Honestly I cannot comprehend how terribly they implemented this. The person that signed off on this, should get a demotion.
| User | Count |
|---|---|
| 2913 | |
| 1451 | |
| 852 | |
| 826 | |
| 455 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2026 Fortinet, Inc. All Rights Reserved.