UPS Communication alarm

[DCIM_Support]

Hi,

I have a Struxureware Central 7.0.0 install - most all my PDU, and Cooling devices are on a private network, we have moved our UPS ( a PX250 ) from the private network 192.168.x.x. network to our mgmt. network.

The appliance is also on the MGMT network and that is how we access Struxureware Central.

We get an alarm that Communication with the UPS has been lost, but we can right click on the UPS and launch to it, as well as see all the settings. In DeviceView I have the correct IP address on the MGMT network showing up under hostname.

My questions are:

How do I resolve the error?

We only have one network card in the UPS and it needs to be on the MGMT network so we can do remote server shutdowns.

We do not show any sensor values showing up if I view the device sensors

(CID:89555801)

[DCIM_Support]

Hi Dave, I assume you have already deleted the old devices and readd'ed using the new ip? Otherwise I would recommend doing so to make sure the device is correctly rediscovered by DCE. It might also be worth trying to do it one more time of only done once. If that doesn't solve the issue I would think the error might be found in the timeout settings on the connection to the device. The network answer time might change slightly going from one network segment to another. It is possible to edit the SNMP scan settings (timeout) for the specific device. This can be done using the menu “Device->SNMP Device communication settings->Device Scan Settings” in the table locate the failing UPS and click bottom right button “Edit Device Scan Settings”. The menu will allow you to increase the timeout value.

(CID:89555845)

[DCIM_Support]

Tried those suggestions - one thing to note, the UPS is now on the public LAN side of the StruxureWare Central server, not on the private side. Can it still be discovered? Do I need to have 2 network management cards in the UPS? One to shut down servers on my management network, and another so it can report into StruxureWare Central? Add your comment here...

(CID:89556682)

[DCIM_Support]

Hi Dave, It should be fine with one interface card in the UPS and also fine to discover the UPS on the public LAN. Still seeing the communication error issue I guess? Are there any restrictions on the public LAN in terms of traffic or ports that are not allowed?

(CID:89556684)

[DCIM_Support]

Yes, still no communication - I have tried both SNMP v1 and SNMP v3 discoveries with no luck after I removed the device. I can hit the UPS admin web interface directly from my machine on the MGMT network. When I had it defined before I deleted it I could even right click and launch to it.

(CID:89556722)

[DCIM_Support · Accepted solution]

Hi Dave,

Is this the only device you have on your network on the public LAN? If not, have you tried another device to see if the same behaviour exists, so we can isolate it, to this UPS?  Does the device come up as failure on DCE under status? Is it a constant UPS Communication Alarm? Are you able to ping the UPS successfully from your laptop without using DCE?  

Are you now having trouble discovering the device after deleting it? If so, it might have to do with incorrect SNMP community names. Usually if you can launch to a device and also right click to view the device sensors they might shown something along the lines of sensor value "unplugged". Is this what you were seeing initially? 

I would advise that you check the SNMP community names (I would leave these as the default for testing purposes public/private) that you are using to discover the device on DCE and the SNMP access control on the device itself matches up. If they don't match up, you will not be able to discover the device, if these SNMP community names changed on the device, it will show a failure status and the UPS will be in a lost communication state, although you are still able to launch to the device. I would also for testing purposes leave the NMS IP/Hostname to 0.0.0.0 (this is on the web interface of the NMC). Make sure that the port you are using is the correct one and that it is not blocked. 

There is a KBase that is very helpful for troubleshooting SNMP problems. The KBase umber is FA226273. The KBase link is below for your convenience: 

http://www.apc.com/site/support/index.cfm/faq/

If the above KBase does not help you may need to give us more information on the way your network is set up. Do you have a network diagram that you could possibly send on to us? I would also request the config.ini file from the NMC itself and also the capture logs from the server. To get these, type in the following in a web browser /capturelogs. A packet capture might also be helpful here. 

Just an FYI, we are currently on DCE 7.2.4. If you have a software support contract, I would advise that you contact technical support for the upgrade links to the newer version of DCE. 

Hope this helps. 

Regards,

B

(CID:89556737)

[DCIM_Support]

Hi Dave, I also noticed you commented on needing 2 NMC's (one for the private LAN and the other for the public LAN to shutdown remote servers). Are you using PCNS? There is an app note on the below link that outlines the communication process of PCNS. http://www.apcmedia.com/salestools/TDOY-5UQVBV/TDOY-5UQVBV_R4_EN.pdf Is the only reason why you are putting the UPS on the public side is for remote server shutdown? Basically it shouldn't matter if the PCNS agent is communicating on the private LAN with an NMC on the public side. As long as the NMC can route the UDP packets to the PCNS agent, and that PCNS can connect to the NMC over HTTP/HTTPS. If there are comms issues by doing this, it would come down to a router/firewall configuration issue.

(CID:89556760)

[DCIM_Support]

Yes, I could ping it from my laptop. I went thru and checked the community names - they were default. I tried both V1 and V3 discovery last week and no luck One thing I did last week toward the end of my troubleshooting was allow the NMS IP to get a DHCP address and then try to discover on that address. It still did not work. Today I went back thru and changed the NMS address back to 0.0.0.0 as it was last week and as you talked about in your email. I then tried to run the discovery again and this time it did discover. Don't know why toggling that worked but it is back in and reporting fine now so I am happy. Thanks to both you and Soren for providing troubleshooting hints!

(CID:89556787)

[DCIM_Support]

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