DCE: SNMP V1 Device discovery problem

[DCIM_Support]

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)

[DCIM_Support]

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]

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]

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]

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]

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]

Thank you Steve!

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

(CID:119637845)

[DCIM_Support]

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]

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

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

xmlcore.xml

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]

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]

I hope my experience will be useful.

If you have questions, please ask.

(CID:120129849)

[DCIM_Support]

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]

Hi rafael.pereira,

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

With respect.

(CID:120131775)

[DCIM_Support]

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]

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