Troubleshooting UIM Robot Communication Issues Behind NAT or with DNS Latency
search cancel

Troubleshooting UIM Robot Communication Issues Behind NAT or with DNS Latency

book

Article ID: 454422

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

After installing a UIM robot on a Linux machine (especially behind NAT or in complex network topologies), the robot controller or probes are unreachable via Infrastructure Manager (IM) or Operator Console (OC), resulting in intermittent communication errors or timeouts. The following error is displayed:

"unable to reach controller, node  /UIM_domain/UIM_rimary/robot/probe error message: communication errror"

Environment

  • UIM Version: 23.4.0 and later
  • OS: Linux (e.g., RedHat)
  • Network: Robots residing behind NAT or complex network topologies.

Cause

The issue can be caused by a DNS resolution delay (servers configured in resolv.conf resolving the hostname very slowly leading to UIM gethostname timeout) 

Resolution

  1. Check DNS Configuration and Resolution Latency Before complex troubleshooting, verify the local DNS resolution on the Linux host. Misconfigured DNS servers or slow lookups can cause communication delays that trigger timeouts in UIM controller sessions.

    • Verify /etc/resolv.conf: Ensure the DNS servers are reachable and configured correctly.
    • Test Resolution: Use nslookup or dig to verify that the robot can resolve the Hub hostname (and vice versa) without significant latency.
    • Hosts File: If DNS is unreliable, consider adding the Hub and Robot IP mappings to the /etc/hosts file as a temporary diagnostic measure to rule out DNS delay issues.

  2. Verify Robot Configuration (robot.cfg) Ensure the configuration correctly defines the NAT and local IP mappings. Example configuration entries:

    domain = robotip = robotname = robotip_alias = hubip = hub =

  3. Adjust IP Validation and Binding If communication remains unsuccessful after verifying DNS:

      • local_ip_validation = no
      • strict_ip_binding = no (Restart the robot service after saving changes.)
  4. Clear Robot Cache Clear the niscache directory on the robot machine to remove stale registration data that may conflict with NAT address resolution.
  5. Investigate Port Exhaustion In environments with high traffic or complex routing, port exhaustion may occur.
      • Move the robot.sds file out of the robot directory.
      • Restart the primary hub server to reset connection handling.

     6. Review System and Version If the issue persists, ensure the Linux machine itself is healthy (check system logs for network interface issues). If running older versions (e.g., 23.4.0), upgrading to a later version (e.g., 23.4.4+) may address specific NAT/communication handling defects.

Powered by Wolken Software