EcoStruxure IT forum
Schneider Electric support forum about installation and configuration for DCIM including EcoStruxure IT Expert, IT Advisor, Data Center Expert, and NetBotz
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-07-03 12:05 AM . Last Modified: 2024-04-09 01:01 AM
Good day,
I currently have a UPS sitting offsite (SMX1500 with Mgmt card) from server space and it is configured with an IP so that it can be accessed via a browser and have a random port (82) which allows me to do as such. When I access the Device it goes eg. 192.255.255.1:82. There are other devices connected to this Public IP hence the port forwarding.
If I used DCE and add the UPS then using :
the device does not show up. What am I doing wrong?
(CID:105466229)
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-07-03 12:05 AM . Last Modified: 2024-04-09 01:01 AM
Dear User,
Struxureware Data Center Expert Software discovers the device via SNMP version 1 or SNMP version 3.
In order to discover the device, the following are the ports need to be opened for the device.
Protocol |
Transfer Protocol |
Ports |
Network |
Comments |
HTTP |
TCP (SSL) |
80 (443) |
Network speed of minimum 100 Mbps is recommended. Bandwidth usage between client and server heavily depends on number of discovered devices, alarm configuration and operations carried out in the client e.g. report generation. |
Communication from NetBotz Appliances / DCE Console/Web API and 3rd party integrations. |
SNMP |
UDP |
161 |
The bandwidth needed heavily depends on number of discovered devices, polling interval configured and alarm activity in the system. |
SNMP Communication between discovered devices and DCE |
SNMP (Trap) |
TCP/UDP |
162 |
Specified in device SNMP configuration |
SNMP Communication between discovered devices and DCE |
SMTP |
TCP |
25 |
Network requirements are low. Email traffic from the DCE is depended on alarm policy configuration and number of alarms occurring. |
Communication with e-mail server |
FTP |
TCP |
21 |
Used when device is discovered and DDF file transferred. The network requirements are low. |
Transfer DDF files between devices and DCE |
SCP |
TCP |
22 |
Used when device is discovered and DDF file transferred. The network requirements are low. |
Transfer DDF files between devices and DCE |
DNS |
TCP/UDP |
53 |
Very limited traffic and bandwidth requirement |
DNS server communication |
For more info: http://dcimsupport.apc.com/display/UADCE725/StruxureWare+Data+Center+Expert+Security |
DCE Device Discovery:
Once the device configuration is noted, StruxureWare DCE needs to know these parameters in order to communicate with the device. These settings will be added during discovery of the device or range of devices. Click “Device” and then “Add Devices” or right click and choose “Add Devices” from the monitoring perspective. Here you can choose SNMPv1 or SNMPv3 to add an SNMP device. Please note that SNMPv2c is not supported. Select the proper version and hit next.
Here you can add an IP or range of IPs. If adding a range, only devices using the same community names or SNMP version 3 authentication and encryption settings will be discovered. Incorrect community names will result in an error on the (APC) device noting unauthorized access. Please note there is an option to change the port. Port 161 is the default port and in the case of an APC device, this cannot be changed. Click “Next” if you want to schedule the discovery or “Finish”.
If you hit “Next”, you can now choose to put the device in a specific group or folder. Hit “Next” if you want to schedule the discovery or “Finish”.
If you hit “Next”, you can now enable discovery scheduling. You can run this discovery any day of the week at a specific time. This may be useful if multiple devices are added to the range. When adding a single device, Scheduling will not be helpful and will only cause additional discoveries to be run on devices that you have already discovered.. You can also choose to run the discovery now and hit finish.
If you have chosen to run the discovery now, the discovery should be saved and should run. If you had hit finish on previous screens, the discovery will not run but should still be saved. In either case the device discovery can be run manually. If the saved devices window is not showing, be sure you are on the monitoring perspective and go to the following menus:
WindowàDeviceàsaved Discoveries.
The discovery should tell you when it was run or Never and you can right click the discovery and edit it or run it from this window.
Troubleshooting Failed Discoveries:
The most common reason for a failed discovery is incorrect security parameters. Verify that the SNMP read community name matches the device you are trying to discover. In SNMP version 3, all parameters much match the settings on the device. Be sure to verify there is no specific NMS IP associated with the security profiles or community names. An incorrect IP or any type of Network Address Translation could cause this feature to block SNMP traffic. On an APC Network Management card, the logs should indicate if a system tried to access the device with incorrect security parameters. The IP of the system that attempted this action should also be in the event that was logged.
You may also want to note the port used during the discovery. If this does not match the port configured on the device, discovery will probably fail. As mentioned before, APC devices will use the default port 161. 3rd party configuration however may vary.
Should all your security and port features match and you have ruled out ports, profiles, and community names being the issue. You may want to simplify the settings. If you are using a long complex community name with special characters, try using something simple for testing purposes. There are no known special characters that will cause discovery to fail but we cannot rule out issues with the device. For SNMP version 3, try using a different set of security options or potentially no encryption. If SNMP version 3 continues to fail, perhaps testing with the more simple SNMP version 1 can rule out version 3 configuration issues.
If all of this fails, you may want to look at the network. A packet capture can be helpful in this case. Tools such as “WireShark” can be used to capture network traffic and can help determine if the SNMP packets are actually getting to the device and if so, if the device is responding properly. A system running a packet capture near the StruxureWare server will show if StruxureWare is sending and receiving while a packet capture closer to the device will show if the network is allowing the SNMP packets from StruxureWare all the way to the device. Keep in mind that although utilities such has ping will show if basic network traffic can get from one system to another, this does not rule out the possibility of networks blocking specific ports or protocols.
I hope it helps.
Regards,
Bala
(CID:105466236)
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-07-03 12:05 AM . Last Modified: 2024-04-09 01:01 AM
Dear User,
Struxureware Data Center Expert Software discovers the device via SNMP version 1 or SNMP version 3.
In order to discover the device, the following are the ports need to be opened for the device.
Protocol |
Transfer Protocol |
Ports |
Network |
Comments |
HTTP |
TCP (SSL) |
80 (443) |
Network speed of minimum 100 Mbps is recommended. Bandwidth usage between client and server heavily depends on number of discovered devices, alarm configuration and operations carried out in the client e.g. report generation. |
Communication from NetBotz Appliances / DCE Console/Web API and 3rd party integrations. |
SNMP |
UDP |
161 |
The bandwidth needed heavily depends on number of discovered devices, polling interval configured and alarm activity in the system. |
SNMP Communication between discovered devices and DCE |
SNMP (Trap) |
TCP/UDP |
162 |
Specified in device SNMP configuration |
SNMP Communication between discovered devices and DCE |
SMTP |
TCP |
25 |
Network requirements are low. Email traffic from the DCE is depended on alarm policy configuration and number of alarms occurring. |
Communication with e-mail server |
FTP |
TCP |
21 |
Used when device is discovered and DDF file transferred. The network requirements are low. |
Transfer DDF files between devices and DCE |
SCP |
TCP |
22 |
Used when device is discovered and DDF file transferred. The network requirements are low. |
Transfer DDF files between devices and DCE |
DNS |
TCP/UDP |
53 |
Very limited traffic and bandwidth requirement |
DNS server communication |
For more info: http://dcimsupport.apc.com/display/UADCE725/StruxureWare+Data+Center+Expert+Security |
DCE Device Discovery:
Once the device configuration is noted, StruxureWare DCE needs to know these parameters in order to communicate with the device. These settings will be added during discovery of the device or range of devices. Click “Device” and then “Add Devices” or right click and choose “Add Devices” from the monitoring perspective. Here you can choose SNMPv1 or SNMPv3 to add an SNMP device. Please note that SNMPv2c is not supported. Select the proper version and hit next.
Here you can add an IP or range of IPs. If adding a range, only devices using the same community names or SNMP version 3 authentication and encryption settings will be discovered. Incorrect community names will result in an error on the (APC) device noting unauthorized access. Please note there is an option to change the port. Port 161 is the default port and in the case of an APC device, this cannot be changed. Click “Next” if you want to schedule the discovery or “Finish”.
If you hit “Next”, you can now choose to put the device in a specific group or folder. Hit “Next” if you want to schedule the discovery or “Finish”.
If you hit “Next”, you can now enable discovery scheduling. You can run this discovery any day of the week at a specific time. This may be useful if multiple devices are added to the range. When adding a single device, Scheduling will not be helpful and will only cause additional discoveries to be run on devices that you have already discovered.. You can also choose to run the discovery now and hit finish.
If you have chosen to run the discovery now, the discovery should be saved and should run. If you had hit finish on previous screens, the discovery will not run but should still be saved. In either case the device discovery can be run manually. If the saved devices window is not showing, be sure you are on the monitoring perspective and go to the following menus:
WindowàDeviceàsaved Discoveries.
The discovery should tell you when it was run or Never and you can right click the discovery and edit it or run it from this window.
Troubleshooting Failed Discoveries:
The most common reason for a failed discovery is incorrect security parameters. Verify that the SNMP read community name matches the device you are trying to discover. In SNMP version 3, all parameters much match the settings on the device. Be sure to verify there is no specific NMS IP associated with the security profiles or community names. An incorrect IP or any type of Network Address Translation could cause this feature to block SNMP traffic. On an APC Network Management card, the logs should indicate if a system tried to access the device with incorrect security parameters. The IP of the system that attempted this action should also be in the event that was logged.
You may also want to note the port used during the discovery. If this does not match the port configured on the device, discovery will probably fail. As mentioned before, APC devices will use the default port 161. 3rd party configuration however may vary.
Should all your security and port features match and you have ruled out ports, profiles, and community names being the issue. You may want to simplify the settings. If you are using a long complex community name with special characters, try using something simple for testing purposes. There are no known special characters that will cause discovery to fail but we cannot rule out issues with the device. For SNMP version 3, try using a different set of security options or potentially no encryption. If SNMP version 3 continues to fail, perhaps testing with the more simple SNMP version 1 can rule out version 3 configuration issues.
If all of this fails, you may want to look at the network. A packet capture can be helpful in this case. Tools such as “WireShark” can be used to capture network traffic and can help determine if the SNMP packets are actually getting to the device and if so, if the device is responding properly. A system running a packet capture near the StruxureWare server will show if StruxureWare is sending and receiving while a packet capture closer to the device will show if the network is allowing the SNMP packets from StruxureWare all the way to the device. Keep in mind that although utilities such has ping will show if basic network traffic can get from one system to another, this does not rule out the possibility of networks blocking specific ports or protocols.
I hope it helps.
Regards,
Bala
(CID:105466236)
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-07-03 12:05 AM . Last Modified: 2024-04-09 01:01 AM
Thank you SO MUCH.
(CID:105467433)
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2020-07-03 12:06 AM . Last Modified: 2023-10-31 10:13 PM
This question is closed for comments. You're welcome to start a new topic if you have further comments on this issue.
Link copied. Please paste this link to share this article on your social media post.
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.