Considerations for monitoring network device in a remote data center from an overseas hub
search cancel

Considerations for monitoring network device in a remote data center from an overseas hub

book

Article ID: 387006

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM) CA Unified Infrastructure Management On-Premise (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

Would there be any adverse monitoring impact if a device is a part of one data center and the hub which to device reports to is far away from that data center. For example, consider that we have a device in Amsterdam and the Hub to which the device reports to is in Las Vegas. Please let us know if there would be any discrepancy with the monitoring of such device with respect to cdm, processes and ICMP Probes.

Environment

  • DX UIM 23.4x

Cause

  • Guidance/Question

Resolution

  • That would depend upon the bandwidth/speed of the network/connection and whether or not there was any significant latency.

  • Run whatever tests you choose to do in each direction.

  • Or use a ping script for 24 hours or a few days, or use net_connect to monitor it to see how it behaves over time.

  • Your network team should also be able to help you, at least to know what to expect 'over the pond'...

  • You can check via ping script and tracert/traceroute and/or you can ask your network team to assess it using their own network tools before you set up the monitoring.

Additional Information

Use "ping" to measure latency, "traceroute" to see the network path, and "iperf" to measure bandwidth throughput; by running these commands on a device in Amsterdam directed towards a server in Las Vegas and vice versa.

  • ping: Lower ping values indicate better latency.  Higher ping values and missed pings are a sign of network issues of some type such as latency, unexpected network routes, etc.

  • traceroute: Look for the correct network route/path, high latency hops on the route, which could indicate network bottlenecks. 

  • iPerf: Higher throughput values represent better bandwidth.

Timestamps of QOS/alarms might be affected.
 
For data time-stamping to work correctly across a distributed UIM deployment, the UIM Server, Operator Console robot, and the Database server should all be set to the same time zone, regardless of the geographic locations of the servers.
 
That said, robot.cfg does allow a Time zone offset override, (tz_offset) in seconds, positive or negative. Default is 0.
 
By design, UIM alarms have "tz_offset" (offset from GMT) property so that the alarm timestamp can be converted in any timezone.