Configure robot in passive mode
Article ID: 415761
Updated On:
Products
Issue/Introduction
Guidance on the steps required to change an active robot from normal mode to passive mode and how to troubleshoot the passive robot setup.
Environment
- DX UIM 20.4, 23.4.0 or higher
- robot 23.4.0 or higher
- passive robot
- Network Address Translation (NAT'd) robot IP
Cause
- Guidance
- Troubleshooting
Resolution
If you install or reinstall the robot successfully and you have confirmed that the robot processes, e.g., controller, hdb and spooler are all running, you can then follow these steps to configure the robot in passive mode.
Change an Active Robot to Passive Mode
These steps explain how to change the mode of an existing robot, disconnect it from its hub, and reconnect it as a passive robot.
Follow these steps:
Note: You need the passive robot's IP address in this procedure.
1. Log on to Infrastructure Manager.
2. Change the robot from active to passive mode:
a. In the navigation tree, locate the active robot and display its probes.
b. Right-click the controller probe and select Configure.
c. In Controller Configuration, navigate to Setup -> Misc.
d. Set the Robot mode to Passive - must be contacted by hub, then click OK.
3. Remove the robot from hub registered robots list:
a. Navigate to the hub that manages the robot, then navigate to the hub probe.
b. Right-click the hub probe and select Configure.
c. Select the Robots tab.
d. In the Registered Robots pane: Take note of the robot’s IP address
e. Right-click on the robot and select Remove.
4. Add the passive robot to hub registered robots list:
a. In the Robots tab, right-click in the Registered Robots pane and select Add Passive Robot.
b. Enter the robot’s IP address and first probe port (default is 48000).
c. Click Verify, then click OK to exit the dialogs.
The robot is now in passive mode, and its parent hub is configured to request messages from it.
Additional Information
Troubleshooting
Please follow the steps and guidance listed below if the robot is deployed within a DMZ/secure zone and/or is using a NAT'd IP address.
Test Basic Connectivity (robot<--Hub)
From the Hub:
Using the real IP address or in a NAT environment, using the NAT'd IP:
- Check if you can ping the robot host/IP from the parent hub (if ping is allowed)
- Check if you can successfully complete a tracert/traceroute from the hub TO the robot.
- Check if you can successfully telnet FROM the hub TO the robot on port 48000
- Check if you can resolve the hostname/IP address via nslookup
-
- ping the robot from the hub if ping is permitted/allowed.
- run a tracert/traceroute to the NAT'd IP address to see if the host can be reached
- telnet to the robot on its NAT'd IP address using the robot port 48000
- If that doesn't work, try the same test using a 'known' open port on the robot to see if you can reach the robot host
Testing Tips
Test to see if the tracert FROM the hub reaches the given network/subnet where the robot sits - does it reach it or does it fail to reach the .## subnet where the robot resides. The requests will time out if it cannot be reached ( * * * Request timed out.)
If the hub cannot reach the robot, you may want to ask the network team why the tracert is failing, show them the results of the tracert and they may run a route add command or change the routing/rules so the hub can find the proper route to the NAT'd IP address.
NAT'd (Network Address Translated) IP still needs a network route, but the routing happens before or after the translation. This depends on traffic direction, with the NAT device (router/firewall) managing the path using its routing table and translation rules to map private IPs to public ones - especially for inbound connections requiring specific port forwarding. Outbound traffic uses the NAT router's route to the internet; inbound traffic relies on routes to the public IP and NAT rules to direct it to the correct internal device.
Note that both TCP and UDP communication are required between the UIM hub and robot. Protocols for all components are TCP except for the controller, hub, and spooler, which also require UDP. UDP broadcast is used for the discovery of the hub, spooler, and controller components. All other core communications are done via TCP.
You may also want to compare/test the tracert results for another robot/passive robot which is having no hub<->robot communication issues and the tracert command finishes successfully in a few hops. Then you can show these results to the network team.
Verify Firewall Rules
A NAT configuration often involves a firewall, therefore ensure the following:
- The hub's side of the network has firewall rules allowing incoming connections from the robot's external IP address on the required ports (typically 48000 and 48003, or other specific ports used for data transfer)
- No local firewall on the robot machine is blocking outbound communication to the hub
- Required open ports for hub<->robot communication are mentioned here:
Firewall Port Reference
Hub and Robot Log Analysis
If you still have trouble with the hub not connecting to the passive robot, e.g., a "no response" error when trying to add the robot to the list of 'Registered Robots' in the hub GUI, please open a support case and follow the steps below.
Set hub and robot loglevel to 5 and set each logsize to 50000.
- _controller.log
- controller.log
- _hub.log
- hub.log
Copy and paste the results of the telnet test as well as the ping, and traceroute/tracert results from the hub->robot when the trace completes so we can observe the basic connectivity results and network route being followed.
Please also run an nslookup [robot_hostname] on the hub to see which IP it returns for the passive (NAT'd) robot.
Attach the logs listed above to the support case.
Avoid Double-NAT Situations
Running a modem/router in 'bridge' mode can sometimes alleviate double NAT issues, allowing for simpler port forwarding. If multiple layers of NAT exist, connection issues become more complex.
Advanced Alternatives
If the standard configuration for passive robots doesn't work as expected, consider these networking solutions-check this with your network team:
Source NAT (SRC-NAT): If the robot only accepts connections from within its own subnet (due to strict security settings), you may need to configure Source NAT on the router to make the traffic appear to originate from the local subnet.
Feedback
