Welcome to the new Schneider Electric Community

It's your place to connect with experts and peers, get continuous support, and share knowledge.

  • Explore the new navigation for even easier access to your community.
  • Bookmark and use our new, easy-to-remember address (community.se.com).
  • Get ready for more content and an improved experience.

Contact SchneiderCommunity.Support@se.com if you have any questions.

Close
Invite a Co-worker
Send a co-worker an invite to the Exchange portal.Just enter their email address and we’ll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
84805members
354262posts

DCE - 3rd party device communication lost after reboot using SNMPv3

EcoStruxure IT forum

A support forum for Data Center Operation, Data Center Expert, and EcoStruxure IT product users to share knowledge on installation, configuration, and general product use.

DCIM_Support
Picard
Picard
0 Likes
1
199

DCE - 3rd party device communication lost after reboot using SNMPv3

This question was originally posted on DCIM Support by Mate Fekete on 2018-12-12


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.

(CID:137111243)

Tags (1)
1 Reply 1
DCIM_Support
Picard
Picard
0 Likes
0
199

🔒 Closed

This question is closed for comments. You're welcome to start a new topic if you have further comments on this issue.