Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
None
-
Professional Edition
-
- ExtremeXOS
- Exos
- Observium 17.8.8725 (24th August 2017)
Description
During our debugging session with Extreme LLDP's library we figured out that a non-chassis system from Extreme is removing the "1:" from the ifName in the SNMP reply. This makes Observium unable to display the correct neighbor port, so it replaces the number to a alpha character i.e. G or H because it thinks that the ifName is a hex reply which is not correct.
/usr/bin/snmpbulkwalk -t '5' -r '2' -v2c -c <community> -Pu -OQUs -m LLDP-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'pop1-asr':'161' lldpRemoteSystemsData |
|
|
...
|
lldpRemPortId.0.277.2 = "48" |
lldpRemPortId.0.294.3 = "47" |
lldpRemPortId.0.301.12 = "47" |
...
|
lldpRemSysDesc.0.277.2 = ExtremeXOS (X670G2-48x-4q) version 15.7.4.2 v1574b2-patch1-2 by release-manager on Fri Aug 26 14:25:30 EDT 2016 |
lldpRemSysDesc.0.294.3 = ExtremeXOS (X670-48x) version 15.6.5.2 v1565b2 by release-manager on Wed May 4 08:34:16 EDT 2016 |
lldpRemSysDesc.0.301.12 = ExtremeXOS (X670G2-48x-4q) version 15.7.4.2 v1574b2-patch1-2 by release-manager on Fri Aug 26 14:25:30 EDT 2016 |
A possible workaround it would be possible to convert the result "48" into "1:48", "47" to "1:47" and so on...
We located the issue in the code and were able to find following lines which are causing this problem:
includes/discovery/neighbours/lldp-mib.inc.php
|
...
|
if ($lldp['lldpRemPortIdSubtype'] != 'macAddress') |
{
|
if (preg_match ('/^X.*$/',$lldp['lldpRemSysName'])) { |
$lldp['lldpRemPortId'] = '1:'.$lldp['lldpRemPortId']; |
}
|
// $lldp['lldpRemPortId'] = snmp_hexstring($lldp['lldpRemPortId']); |
}
|
Our custom added preg_match needs to be replaced with a function which is checking if the remote device is running ExtremeXOS and if there is no ":" in ifName string. Chassis based ExtremeXOS are not affected by this problem. If the result is true the original ifName needs to be changed to "1:ifName".
For our test purpose this workaround worked well and the linking function in /map/ is working fine.