DCE - 3rd party device communication lost after reboot using SNMPv3
EcoStruxure IT forum
Schneider Electric support forum about installation and configuration for DCIM including EcoStruxure IT Expert, IT Advisor, Data Center Expert, and NetBotz
Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.
You have entered an invalid email address. Please re-enter the email address.
This co-worker has already been invited to the Exchange portal. Please invite another co-worker.
Please enter email address
Send InviteCancel
Invitation Sent
Your invitation was sent.Thanks for sharing Exchange with your co-worker.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-07-0503:20 PM. Last Modified: 2024-04-0311:28 PM
DCE - 3rd party device communication lost after reboot using SNMPv3
Hi,
In DCE I am using SNMPv3 for monitoring wherever device is capable for that. I noticed that after device reboot I get communication lost and it will not resolve anymore in DCE.
I got internal Schneider support and did packet capture on DCE server filter to a ServerTech PDU communicate with DCE and here is the outcome from Schneider:
"This is a fault in the ServerTech PDUs; the DCE is treating this fault exactly as the SNMPv3 standard says it should. Unfortunately this “feature” is part of the security model in SNMPv3, so it would be improper for us to alter this behaviour, as it’d then cause the DCE to weaken security and violate the standards.
Possible solutions: - Run SNMPv3 without authorization (security) on these PDUs, as it’s a misbehaviour in this security that’s causing problems. - Pursue this with ServerTech and see if they have a newer firmware, or any roadmap to a newer firmware that would behave correctly in this case."
Obviously first solution is not an option because I kill the essence of using SNMPv3.
The technical explanation is that vendor (ServerTech) did not implement correctly RFC3414 standard related to the following two values:
snmpEngineBoots “which is a count of the number of times the SNMP engine has re-booted/re-initialized since snmpEngineID was last configured”
snmpEngineTime “which is the number of seconds since the snmpEngineBoots counter was last incrememented”.
The strange thing is that I have the same issue with Cisco devices too. Of course everything is possible, maybe Cisco also wrongly implemented above mentioned RFC standard.
With the same internal support we did packet capture about the Cisco device but I am still waiting for feedback on that.
The reason is why opened this thread to highlight this interesting topic and encourage some other DCE users whose are using not Schneider/APC devices with SNMPv3 monitoring. Can someone test it? It is pretty simple because when you change for example the contact or location field that generate and snmpEngineBoot without any impact to the device.
A troubleshooting solution which solve the problem: restart DCE server.
I am pretty curious what is the experience with other 3rd party devices SNMPv3 monitoring.
By the way it is independent from DCE version because I experienced it with 7.5.0 as well as in the latest 7.6.0.