I have two stacks of Cisco 3850's and both of them are reporting that the temperature is around 4 degrees Celsius. I have had both Solarwinds Support and Cisco Support look at this.
We did a SNMPWALK to check the MIB's and they seem correct, but when it comes to posting the temperatures in NPM, they are way off.
The switches say they are a happy 25 degrees Celsius. That I can beleive becasue my closet is at a comfortable temerature.
Solved! Go to Solution.
I have my answer. Cisco notified me that there is a bug in the current OS versions 3.2.0SE, 3.2.1, 3.2.2 and that they are working on correcting it.
This is actually a known defect on these platforms that is currently being worked on. You can review the defect details here:
Multiplying the result by 10 will give you the correct reading.
You can also poll the "Envmon MIB" which will give you the correct temperature.
As a side note: those of you running NPM 11.5 no longer need to edit the .config file. Under Admin > Thresholds & Polling > Orion Polling Settings is now a Hardware Health section with a Preferred Cisco MIB setting. You can chose between CISCO-ENVMON-MIB (legacy - where 3850 switches are reported on correctly) and CISCO-ENTITY-SENSOR-MIB.
After changing to CISCO-ENVMON-MIB the temperature got fix.
IOS XE 3.6.2aE fixes the wrong temperature but is not recommended by cisco,
Just stumbled on to this thread. We have some 3850s in a closet and have been yellow since last year when installed. I thought it was right just because it gets hot in there. Changed SW to Cisco-envmon-mib and went from yellow to green. Switch1 Temp 2 looks like it lines up with the Hotspot Temp value of 40C. Running 03.03.05.SE
On our side, we upgraded to IOS-XE 03.06.03E and temp sensor switch to green. We are using NPM 11.0.1 . We have 2 more 3850 switches who is still running IOS-XE 03.03.03SE and the issue is still there. The values are correct on the switch side and on SW side, but SW still showing warning for INLET TEMPRATURE and HOTSPOT TEMPERATURE..
Can someone tell me if changing the .config file <add key="IgnoreCiscoNewEntityMib" value="false"/>" to <add key="IgnoreCiscoNewEntityMib" value="true"/> will correct both the temperature value AND status, or just the status?
I finally had a rainy day project day today. I was not able to schedule stack upgrades on my 3850 but I did delve into SW. I made the above change to the .config file. Stopped all services on the server and then started all services. After about 20 minutes and then the hardware health status cleared. Now, I know which switches are really too hot.
Per Cisco, the specified bug (CSCuh55760) is now fixed in IOX-XE 3.3(2)SE & 3.6(0)SE - At least in regards to reporting the value as 1/10th of actual. But while the 10th of the actual temperature issue may be resolved, the temperature reporting in NPM does not seem to be correct per se & still shows a "Warning" as of NPM 10.7 (and IOS-XE 3.6.0). It's also unfortunate that the only hardware information reported on the 3850's are temperature sensors but that's a different gripe and topic post if so inclined (3750 platform may have been better to stay at for several reasons).
So, the next question is who's problem is it now - If this Cisco bug was solely on previously being 1/10th of the actual value then Cisco would seem to be absolved, and it's the way NPM is getting its info that's the problem... however, NPM should just be retrieving whatever value is in the MIB... so as mentioned - who's reporting the (false) warning now?
On my test 3850 [running 3.6.0], I show NPM [10.7] reporting a Major Warning of 24C and 41C (and a third sensor showing 38C), while a "show environment temperature status" returns those same values - apparently for Inlet temp and Hotspot temp respectively (where NPM is polling the 38C from I have no idea... it's too bad the actual sensor name isn't given in NPM) but the Warning thresholds are 41C and 105C - So the actuals are far below a Warning and NPM should be showing green. ...But it doesn't, and I continue to have additional conditions in my hardware component alert to filter out temperature as a result (less than ideal). Sure would be nice for this to be remedied and support of the 3850 switch in full effect.
Is anyone else getting correct values / no warnings? - If so, what version of IOS-XE and/or NPM are you running or other details would be appreciated.
I have been unable to find a thread related to this comment you made above, "It's also unfortunate that the only hardware information reported on the 3850's are temperature sensors but that's a different gripe and topic post if so inclined". Therefore I did create a thread for this here: https://thwack.solarwinds.com/thread/68733. Will the workaround discussed on this thread resolve this issue as well? If so, will it cause any additional issues monitoring any other types of devices? I don't want to fix this just to break something else.
I've got the same issue, updated to IOS-XE 3.3.3 and despite an SNMP walk showing the correct values, the Orion chart showing the correct values I'm still getting warnings.
I suspect Orion must be also monitoring another SNMP MIB then just the temperature value (a monitor state MIB?) and it's either being incorrectly reported by the switch or incorrectly interpreted by Orion. I've just logged a case with Solarwinds support with an SNMP walk so hopefully they can nail this where it's going wrong. I'll try to remember to update this when I hear back from them.
I have been working on this with Solarwinds Support (AnKian), to disable the errant warning you can do the following:
Edit C:\Program Files (x86)\SolarWinds\Orion\HardwareHealth\SolarWinds.HardwareHealth.Pollers.dll.config and change "<add key="IgnoreCiscoNewEntityMib" value="false"/>" to <add key="IgnoreCiscoNewEntityMib" value="true"/>.
This will make Orion use CISCO-ENVMON-MIB instead of CISCO-ENTITY-SENSOR-MIB. Support have confirmed this will not result in a loss of functionality. I'm about to look a little further in to the two different MIBs and see if there is a difference in values being reported and whether there is a bug involved.
With the assistance of Cisco TAC we believe that bug CSCun78227 (Incorrect temperature thresholds reported via SNMP) is being experienced, this is marked as resolved in 3.6.0(E). The full details of the published bug are below, I will be able to test this on a test switch over the next week but won't be near putting it on to a production switch for at least a fortnight. I would be interested to hear the experiences of others upgrading to this version.
I've updated a test switch to 3.6.0E, it doesn't resolve the issue with IgnoreCiscoNewEntityMib set to the default of false. The update does correctly resolve CSCun78227, but I now suspect there is a bug (possibly unidentified). About to start another TAC case.
That was quick. Cisco TAC have identified that CISCO-ENTITY-SENSOR-MIB:entSensorValue is reporting the correct sensor status of "1" for green/good. Based on conversation I've had with SolarWinds support it seems that Orion is using CISCO-ENTITY-SENSOR-MIB:entSensorThresholdSeverity which is not the actual status.
I've just contacted SolarWinds support again to confirm and to suggest they use entSensorValue if that is the case.
SolarWinds are looking at it internally and one of the product managers has reached out to me for SNMP walk so they can build better support for the device. In the meantime: update to 3.6.0E and edit C:\Program Files (x86)\SolarWinds\Orion\HardwareHealth\SolarWinds.HardwareHealth.Pollers.dll.config and change "<add key="IgnoreCiscoNewEntityMib" value="false"/>" to <add key="IgnoreCiscoNewEntityMib" value="true"/>.
I saw this morning that v 3.3.4 was released on Sept 3. Looking through the release notes, the bug is supposed to be fixed in this release! We shall soon find out.
Thanks for the research!! I saw that 3.6 was released but had not looked into upgrading my switches to it quite yet since 3.3.3 was the recommended version to use. I might upgrade a single remote switch to 3.6 before upgrading my stacks. It's kind of hard to get a window to upgrade the stacks anyway.
I modified the line you mentioned in your last post and it seemed to work.
After I changed it, I did not see a change in the warnings list so I stopped/started the services and about five minutes later the warnings went away.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.