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
84766members
354199posts

DCE: SNMP V1 Device discovery problem

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
14
566

DCE: SNMP V1 Device discovery problem

This question was originally posted on DCIM Support by rafael.pereira on 2017-05-31


Hello support,

 

I´ve been working lately with a customer that needs to integrate an Air Conditioner Controller to their DCE. 

The device supports SNMP V1, and we already have the ddf (xml) specific for its gateway, but we are having a lot of problems to add it to DCE.

What happens is that is not found the by discovery process no matter what parameters we configure.

We already tried to add the device using a notebook (with DCE Virtual Demo) connected directly to the gateway, but the result is the same.

We tried, also, to read the OID´s with another SNMP Manager (iReasoning MIB Browser) and it worked smoothly.

The only clue we have on what may be the problem is the fact that the gateway does not respond to GETNEXT commands, but responds normally to GET commands.

Any advice on what else can we try, and what is preventing the DCE to map the device?

(CID:119637806)

14 Replies 14
DCIM_Support
Picard
Picard
0 Likes
5
566

Re: DCE: SNMP V1 Device discovery problem

This answer was originally posted on DCIM Support by Steven Marchetti on 2017-05-31


Hi Rafael,

 

If the device does not respond to getnext commands, it is likely this that is causing the issue. I have specifically seen get and getnext during packet captures watching the discovery process and if the device does not properly respond, that may indeed be the issue, if you're certain the device doesn't support that feature that is, You may want to try running a packet capture during discovery yourself to be certain where it is failing.

 

Thanks,

Steve

(CID:119637814)

DCIM_Support
Picard
Picard
0 Likes
0
566

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by rafael.pereira on 2017-05-31


Hi Steve, thank you for the fast answer!

 

We are already sure about the GETNEXT not being supported as we bumped into this during the DDF development process. Because of it we had to manually describe all OID´s we would need inside the DDF.

 

What we didn´t know is that it would influence on the discovery process also.

 

Is there any hope for we with this device?

(CID:119637817)

DCIM_Support
Picard
Picard
0 Likes
0
564

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by Steven Marchetti on 2017-05-31


Hi Rafael,

Here's an example of some sysoid information DCE pulls during discovery:

I believe this is needed required and if things like this are not responded to, DCE considers the device to not be responding and may attempt again, but will eventually cease the discovery. Again, if you run a packet capture, you will be able to see what DCE polls and where it stops.

 

Steve

(CID:119637826)

DCIM_Support
Picard
Picard
0 Likes
0
566

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by rafael.pereira on 2017-05-31


Hi Steve,

 

Can you give an advice on how to run the packet trace? Sorry for the dummy question, but I´m more an "Engineering guy" than an "IT Guy", so my knowledge on network sniffing is a little limited.

I thought about using Wireshark, but i have no clue on how to apply it on DCE as its a Linux machine (and I´m also ignorant about using this OS). 

I thank you in advance.

 

Rafael

(CID:119637829)

DCIM_Support
Picard
Picard
0 Likes
0
564

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by Steven Marchetti on 2017-05-31


Hi Rafael,

 

A packet capture is done using software specifically designed for looking at network packets. If you don't have something readily available, you could install something like Wireshark on a computer to monitor the network traffic. It is a freely downloadable 3rd party program. There are network devices that are capable of this also.

 

You would then want to then either connect the computer running wireshark to a port that is set to mirror that of DCE (takes some switch / router knowledge) or you can connect both DCE and the laptop to a network hub. A hub does not send data to specific ports so your laptop would then see all the network traffic on the hub.

 

Start a capture and then try to discover the device. Once the discovery stops, you can try it again just to be certain and then stop the capture. At that point, you can look for specific info in the actual capture. 

 

there's also plenty of information on the web about it and wireshark has some pretty decent help files.

 

Thanks,

Steve.

(CID:119637834)

DCIM_Support
Picard
Picard
0 Likes
0
564

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by rafael.pereira on 2017-05-31


Thank you Steve!

I´ll talk to our network technicians to set this up.

(CID:119637845)

DCIM_Support
Picard
Picard
0 Likes
0
564

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by spezialist on 2017-06-01


Hi rafael.pereira,

Three years ago I had a similar task with "dumb" SNMP v1 devices and I successfully solved it. I think that I can help you and am ready to share my experience here, but first I'm interested in knowing the answer to the question:

What happens is that is not found the by discovery process no matter what parameters we configure.

We already tried to add the device using a notebook (with DCE Virtual Demo) connected directly to the gateway, but the result is the same.

That is, upon discovering of new SNMP-device is generally not found? I.e., a new SNMP-device does not appear on the DCE-server. I correctly understood?

Always glad to help.

(CID:120129350)

DCIM_Support
Picard
Picard
0 Likes
2
566

Re: DCE: SNMP V1 Device discovery problem

This answer was originally posted on DCIM Support by spezialist on 2017-06-02


Hi rafael.pereira and Steven Marchetti,

My SOLUTION to this problem is the use of a separate SNMP-proxy server.

As I said before, three years ago I had a similar situation, and I was able to successfully solve it. In order to be clear to everyone, I will briefly describe my situation.

It was necessary to connect to the monitoring system based on the DCE-server three ceiling mounting air conditioners Emerson Liebert HPS 06, which had Powerface controllers. All three air conditioners were combined into a single group with a daily rotation (2+1). A small HiSNMP-adapter was connected to the controller of each air conditioner, which was connected to the local network via the 10Base-T network interface and was to be SNMP polled by the DCE-server according to the SNMP DDF-file created for it. So, these same HiSNMP-adapters only support SNMP v1 and do not support the standard SNMP GETNEXT. To be clear, I'll give you some examples of SNMP polling one of these HiSNMP-adapters from a simple Linux console with the net-snmp package.

1. Polling using snmpwalk was unsuccessful:

bash$ snmpwalk -v1 -cpublic 192.168.1.106 Timeout: No Response from 192.168.1.106

2. Polling of enterprises tree using snmpwalk was also unsuccessful:

bash$ snmpwalk -v1 -cpublic 192.168.1.106 enterprises Timeout: No Response from 192.168.1.106

3. Polling only one OID of sysDescr.0, given here, to this wrong non-standard type:

bash$ snmpget -v1 -cpublic 192.168.1.106 .1.3.6.1.2.1.1.1.0 SNMPv2-MIB::sysDescr.0 = Wrong Type (should be OCTET STRING): OID: SNMPv2-SMI::enterprises

4. Another polling of only one OID sysObjectID.0 value also resulted in an wrong non-standard type:

bash$ snmpget -v1 -cpublic 192.168.1.106 .1.3.6.1.2.1.1.2.0 SNMPv2-MIB::sysObjectID.0 = Wrong Type (should be OBJECT IDENTIFIER): Timeticks: (172121055) 19 days, 22:06:50.55

5. A separate polling of all subsequent SNMPv2-MIB OIDs was unsuccessful:

bash$ snmpget -v1 -cpublic 192.168.1.106 .1.3.6.1.2.1.1.3.0 Timeout: No Response from 192.168.1.106

6. I also found out that the polling of the tree of enterprises.476, it turns out, leads to a successful result! I.e., I saw the entire set of OIDs I needed and their values:

bash$ snmpwalk -v1 -cpublic 192.168.1.106 enterprises.476 SNMPv2-SMI::enterprises.476.1.42.4.3.21.1.1.7.1.0 = INTEGER: 0 SNMPv2-SMI::enterprises.476.1.42.4.3.21.1.1.7.3.0 = INTEGER: 0 SNMPv2-SMI::enterprises.476.1.42.4.3.21.1.1.7.4.0 = INTEGER: 14 SNMPv2-SMI::enterprises.476.1.42.4.3.21.1.1.7.5.0 = INTEGER: 200 ... ... ... SNMPv2-SMI::enterprises.476.1.42.4.3.21.1.1.50.66.0 = INTEGER: 0 SNMPv2-SMI::enterprises.476.1.42.4.3.21.1.1.50.67.0 = INTEGER: 0 SNMPv2-SMI::enterprises.476.1.42.4.3.21.1.1.50.70.0 = INTEGER: 0 SNMPv2-SMI::enterprises.476.1.42.4.3.21.1.1.50.71.0 = INTEGER: 0 End of MIB

This is such a "dumb" device 😀.

Further, when trying to discovering the above three air conditioners with HISNMP-adapters on a DCE-server with an absolutely correct SNMP DDF-file, nothing happened. As a result of the discovering, three SNMP-devices appeared, which in a minute passed from online to offline with the corresponding alarm Link status. In addition, these SNMP-devices did not contain any sensor other than the Link status.

Having understood a little of these HiSNMP-adapters, I understood why on the DCE-server these SNMP-devices did not have any sensors. All because before the new discovered SNMP-device is applied to any specific SNMP DDF-file, this new device must pass, the so-called "General test" from the SNMP DDF-file core.xml:

xmlcore.xml<!-- General test - must be able to get sysobjecid --> <device deviceid="sysobjid"> <preDetectOidMustExist ruleid="sysobjidtest" oid=".1.3.6.1.2.1.1.2.0"/> </device>

Let me remind you that SNMP DDF-file core.xml is, according to its description:

xmlcore.xml<!-- Core DDF for SNMP scanners : this defines common device sections that will apply to many devices Any deviceid and ruleid values in here should be assumed to be "well known", so that other DDFs can access or suppress them, as needed. -->

And since HiSNMP-adapters, for obvious reasons, did not pass this test (see above), then no specific SNMP DDF-files were applied to them later. As a result, we had complete absence of any sensors inside.

Now the main thing is the SOLUTION of this problem is the use of a separate SNMP-proxy server, which I successfully implemented in practice.

I.e., a separate SNMP-proxy server is installed in the monitoring network, and the DCE-server polling not the air conditioner itself with the HiSNMP-adapter (read the "dumb" SNMP v1 device), but the SNMP-proxy server with a specific IP-address and a specific SNMP community string (read the SNMP v2c device). Thus, the DCE-server "thinks" 😀 that it is polling, for example, the air conditioner, but in fact, it polls the SNMP-proxy server, which relays its SNMP-requests directly to the HiSNMP air conditioner adapter. And since I configured the SNMP-proxy server on the basis of the Linux OS and the powerfull net-snmp package, the whole group DCE-server <-> SNMP-proxy <-> HiSNMP-adapter works fine with both "dumb" SNMP v1 devices and with normal SNMP v2c devices, which, unfortunately, the embedded DCE-server software unfortunately can not ☹️. And all this has been working successfully for three years already.

I have long been thinking in detail to share here this practical experience, for example, in the form of the article "USER TIPS AND IDEAS". But still I doubt, because everything is not so simple and elementary, especially for customers of SxW DCE software without any knowledge in this area (Linux, SNMP and etc). If someone is very interesting, then maybe...

Always glad to help.

(CID:120129820)

DCIM_Support
Picard
Picard
0 Likes
0
564

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by rafael.pereira on 2017-06-02


Hey spezialist,

 

Thanks for such a rich answer. I´ll try to search a little more about the idea of using a SNMP Proxy in this case. It may even help with the other device I have problem (the one discovered, but with no sensors).

 

Thanks a lot!

(CID:120129846)

DCIM_Support
Picard
Picard
0 Likes
0
566

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by spezialist on 2017-06-02


I hope my experience will be useful.

If you have questions, please ask.

(CID:120129849)

DCIM_Support
Picard
Picard
0 Likes
0
566

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by rafael.pereira on 2017-06-02


Hi spezialist,

 

Exactly. After the discovery process no device is added to the specified folder (or any other folder on DCE).

 

Thanks again for the help!

(CID:120129842)

DCIM_Support
Picard
Picard
0 Likes
0
566

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by spezialist on 2017-06-07


Hi rafael.pereira,

Tell me, please, have you solved the problem or not?

With respect.

(CID:120131775)

DCIM_Support
Picard
Picard
0 Likes
0
565

Re: DCE: SNMP V1 Device discovery problem

This comment was originally posted on DCIM Support by rafael.pereira on 2017-06-07


Hey spezialist,

 

Unfortunatelly not. Didn´t have time enough on site to try the SNMP Proxy.

 

I´ll give it a try next visit (maybe next week).

 

Our "plan B" is to convert the gateway to Modbus TCP, instead of SNMP. I know we´ll need another DDF, specific for MODBUS, but we have hope that this will be easier than SNMP.

(CID:120131785)

DCIM_Support
Picard
Picard
0 Likes
0
566

🔒 Closed

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