HUAWEI S5700-52X Support dBm & temperature value #4279

Closed
kristoferus75 opened this Issue Aug 30, 2016 · 24 comments

Projects

None yet

3 participants

@kristoferus75

Hi !

I have told to Rosiak on IRC that for the my Huawei Switch there are no Dbm & temperature value avalaible !

Model: S5700-52X-LI-48CS-AC Huawei

HUAWEI-ENTITY-EXTENT-MIB:

snmpwalk -c xyz1234 -v 2c 10.10.10.10 -m +HUAWEI-ENTITY-EXTENT-MIB .iso.org.dod.internet.private.enterprises.huawei.huaweiMgmt.hwDatacomm.hwEntityExtentMIB

snmpwalk_huawei.txt

Please implement this Switch !

Thanks !!!!

kind regards

kristoferus75

@laf
Member
laf commented Oct 16, 2016

Please provide output of snmpbulkwalk -OUneb -v2c -c COMMUNITY HOSTNAME .

@kristoferus75

Ok here the output of the snmpbulkwalk !
snmpbulk_hawei.txt

@laf
Member
laf commented Oct 17, 2016

did you mean to close this?

@kristoferus75

Sorry no !

@kristoferus75 kristoferus75 reopened this Oct 17, 2016
@laf laf added the New-Device label Oct 17, 2016
@laf
Member
laf commented Dec 5, 2016

It looks like the info we need is in .1.3.6.1.4.1.2011 and below but your walk doesn't have that. Can you try:

snmpbulkwalk -OUneb -v2c -c COMMUNITY HOSTNAME .1.3.6.1.4.1.2011.5.25.31.1.1

@kristoferus75
kristoferus75 commented Dec 6, 2016 edited
@laf
Member
laf commented Dec 24, 2016

The entPhysicalX stuff isn't in this walk either :(

Can you do another walk:

snmpbulkwalk -OUneb -v2c -c COMMUNITY HOSTNAME .1.3.6.1.2.1.47.1.1.1

@kristoferus75

hi laf !

no problem here the new snmpwalk !

kind regrads kristoferus75
newwalk.txt

@kristoferus75

Hi Laf !

The values of dbm are wrong -> Current i see only one dbm value on an interfaces and this is also wrong -> it should be two values one transmit dbm and one receive value dbm (the current value for gigabitethernet0/0/1 is +2.59dBm in librenms) ! It also should be a minus value see below:

display transceiver interface GigabitEthernet 0/0/1 verbose

GigabitEthernet0/0/1 transceiver information:

Common information:
Transceiver Type :1000BASE_BX10_SFP
Connector Type :LC
Wavelength(nm) :1490
Transfer Distance(m) :10000(9um)
Digital Diagnostic Monitoring :YES
Vendor Name :HUAWEI
Vendor Part Number :02315204
Ordering Name :

Manufacture information:
Manu. Serial Number :CD50QQCXD
Manufacturing Date :2016-05-27
Vendor Name :HUAWEI

Diagnostic information:
Temperature(¡ãC) :25.40
Temp High Threshold(¡ãC) :90.00
Temp Low Threshold(¡ãC) :-5.00
Voltage(V) :3.30
Volt High Threshold(V) :3.57
Volt Low Threshold(V) :3.00
Bias Current(mA) :6.00
Bias High Threshold(mA) :90.00
Bias Low Threshold(mA) :0.50
RX Power(dBM) :-5.86
RX Power High Threshold(dBM) :-1.99
RX Power Low Threshold(dBM) :-24.94
TX Power(dBM) :-6.06
TX Power High Threshold(dBM) :-2.99
TX Power Low Threshold(dBM) :-11.00

kind regards

kristoferus75

@laf
Member
laf commented Jan 8, 2017

Can you update my branch and try again please.

If it's still wrong can re-provide the info above on power levels + a screenshot of the graph sensors in LibreNMS

@kristoferus75
kristoferus75 commented Jan 8, 2017 edited

Hi laf !

the dbm values are wrong i see in librenms now for the interface Gi0/0/1:

2.55dBm
2.47dBm

but with the command line i see:

-5.86
-6.06

here the whole snmpwalk for that switch:

snmpwalk.ftth.txt.tar.gz

@laf
Member
laf commented Jan 8, 2017

Unless I'm being totally daft I think this might be a firmware bug.

The values in your walk are:

.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67305550 = STRING: "-588.89"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67305614 = STRING: "-533.13"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67305678 = STRING: "-568.64"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67305742 = STRING: "-548.98"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67305806 = STRING: "-602.58"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67305870 = STRING: "-Inf"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67305934 = STRING: "-Inf"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67305998 = STRING: "-676.54"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67306062 = STRING: "-568.15"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67306126 = STRING: "-1178.49"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67306190 = STRING: "-737.31"
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32.67306254 = STRING: "-Inf"

Those OIDs don't exist in HUAWEI-ENTITY-EXTENT-MIB and should be:

.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67305550 = INTEGER: 257
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67305614 = INTEGER: 293
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67305678 = INTEGER: 270
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67305742 = INTEGER: 282
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67305806 = INTEGER: 249
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67305870 = INTEGER: 0
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67305934 = INTEGER: 0
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67305998 = INTEGER: 209
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306062 = INTEGER: 270
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306126 = INTEGER: 66
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306190 = INTEGER: 183
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306254 = INTEGER: 0
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306318 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306382 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306446 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306510 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306574 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306638 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306702 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306766 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306830 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306894 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67306958 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307022 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307086 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307150 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307214 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307278 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307342 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307406 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307470 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307534 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307598 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307662 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307726 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307790 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307854 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307918 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67307982 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67308046 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67308110 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67308174 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67308238 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67308302 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67308366 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67308430 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67308494 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67308558 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67338318 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67338382 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67338446 = INTEGER: -1
.1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8.67338510 = INTEGER: 30
@kristoferus75

I will ask huawei tommorow and i will update the issues as soon as possible !

@RaduMC
RaduMC commented Jan 12, 2017 edited

Hello laf,

Can you please double-check how the values are calculated?
1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8 will give you hwEntityOpticalRxPower in uW (integer).
The formula used is uW = (10^(dBM/10))*1000.

So (10^(-5.86/10))*1000 = 259.41 which is close to the 257 uW value you are getting in the SNMP walk. This is to be expected if the two values were not captured at the same time.

Regarding the other OID, 1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32 is for hwEntityOpticalLaneRxPower
This object indicates the optical module input power of multiple fibers. The unit is dBm but the value is 100 times the actual receive power of an optical module. Therefore, actual value = (hwEntityOpticalLaneRxPower/100) (dBm).

@kristoferus75
kristoferus75 commented Jan 12, 2017 edited

Hi !

The answer from Huawei ! ok see that huawei have answered above Cool :-)

It looks like the values obtained via SNMP are correct, but they need to be converted in order to obtain dBM units.

1.3.6.1.4.1.2011.5.25.31.1.1.3.1.8 will give you hwEntityOpticalRxPower in uW (integer).
The formula used is uW = (10^(dBM/10))*1000.

So (10^(-5.86/10))*1000 = 259.41 which is close to the 257 uW value you are getting in the SNMP walk. This is to be expected if the two values were not captured at the same time.

Regarding the other OID, 1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32 is for hwEntityOpticalLaneRxPower
This object indicates the optical module input power of multiple fibers. The unit is dBm but the value is 100 times the actual receive power of an optical module. Therefore, actual value = (hwEntityOpticalLaneRxPower/100) (dBm).

I have shared this information with the developer and I'm also sending you a full description of the hwOpticalModuleInfoTable for reference. This information is also available in our product documentation:

http://support.huawei.com/ehedex/pages/DOC1000101619DEF0414R/04/DOC1000101619DEF0414R/04/resources/dc/dc_s_mib_entity-extent_0007.html

kind regards

kristoferus75

@laf
Member
laf commented Jan 14, 2017

This is correct then:

(hwEntityOpticalLaneRxPower/100) (dBm).

The code does exactly that and the output is in dBm not uW which is what you are expecting.

@laf
Member
laf commented Jan 15, 2017

Their is no update. The values are reported correctly as per the info from huawei.

@kristoferus75

ok i have send again a mail to huawei !

@laf
Member
laf commented Jan 16, 2017

I'm not sure what for, the first email they sent clearly shows the calculation and what we should expect, which is what we get back.

@kristoferus75

Hi Laf !

Im not sure but -> is this right what huawei have sent to me ? See below:

I think what the developer means is that their software reads the correct value for hwEntityOpticalRxPower (in uW) but it does not convert from uW to dBM.

The conversion can be accomplished with some simple math:
P(dBm) = 10 x log10( P(uW) / 1000uW )

It is up to the NMS developer to implement this, but it may not be simple because not all vendors use the same units or value format.
I can't really speak on the developer's behalf regarding this matter; all I can say is that the values are indeed correct.

@laf
Member
laf commented Jan 18, 2017

Thanks for the info, if you pull my updates into your branch it should now be fine - please note this is updated against current master so you should update your install in general either before or after you try this branch again.

@kristoferus75

ok thanks laf ! now it looks better ! I will update this case tommorow if I'm 100% sure if now all values are correct !

@kristoferus75

Hi Laf !

All values are now correct ! Thanks again for your work ! Please inform me if the changes are also in the master branch ! kind regards kristoferus75

@laf laf closed this in #5247 Jan 19, 2017
@laf
Member
laf commented Jan 19, 2017

All merged - thanks @kristoferus75

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment