robot does not automatically rollback from its configured secondary hub to its original hub

Products

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

Issue/Introduction

We have observed that, if the designated hub as per the robot.cfg goes down, the device moves to its secondary hub as defined in the robot config file, and once the designated hub is back up again, the robot does NOT rollback from the secondary hub to its originally designated hub automatically.

How can we configure multiple robots to failover to a secondary hub but ensure they automatically fallback to the original hub when it becomes available (online) again?

Environment

DX UIM 23.4 - any CU
Product: DX Unified Infrastructure Management (UIM)
Component: Robot 23.4.x (controller/spooler)

Cause

Exception to the expected robot to hub fallback behavior due to proxy_mode being enabled.

Resolution

Configuring Robot Failover and Fallback for Multiple Robots

To configure failover for multiple robots simultaneously, you can create and deploy a custom "Configuration-Only" package.

Create a Custom Robot Update Package
In Infrastructure Manager (IM), locate a robot's controller probe.
Drag and drop the controller probe to your local Archive.
In the window that opens, rename the package (e.g., robot_update_secondary_hub_cfg).
Right-click the new package in the Archive and select Edit.
Open the robot.cfx file.

Modify the file to include only the secondary hub information, e.g.,

secondary_domain = <Domain_Name>
secondary_hub = <Secondary_Hub_Name>
secondary_hubrobotname = <Secondary_Hub_Robot_Name>
secondary_hubip = <Secondary_Hub_IP>
secondary_hubport = <Secondary_Hub_Port>

Note: Clear the OStype and OS values if you intend for this package to be platform-agnostic.

8. Save the changes and click OK.

9. Deploy the Configuration

10. Distribute the package via drag-and-drop to the target robots. This updates their robot.cfg without requiring a full probe reinstall.

Failover and Fallback Mechanism

Failover Trigger: If the spooler cannot send alarms or QoS messages to its hub, it will switch to the secondary hub immediately. If the spooler has no data to send, there may be a delay before the switch occurs.

Fallback (Return to original/Parent hub): When the hub returns to service, it sends a UDP broadcast on ports 48000 and 48002. Robots receiving this broadcast will switch back to the primary immediately.

Hub Polling: If UDP broadcasts are blocked in your environment, the primary hub will query its internal list of previously connected robots. It will send a checkin command to each robot one by one. This polling process may take time depending on the number of robots.

Key Limitation: Proxy Mode
IMPORTANT: If your environment uses proxy_mode = 1 (to force all traffic through port 48000 for firewall purposes), automatic fallback is not supported. The security design of proxy_mode prevents the controller from moving back to the primary hub automatically.

Requirement: When proxy_mode is enabled, the target robot must be restarted manually to reconnect to the original hub once it is back online.

Additional Information

To limit open ports in firewalled environments, set the following key in the robot.cfg: proxy_mode = 1

IMPORTANT: When proxy_mode = 1 is set for the purposes of passing all traffic through the robot port 48000, as per Engineering, the tighter security design of the proxy mode setting for the controller prevents a complete hub move back to the original secondary/parent hub unless the target robot is restarted.

Limiting the Number of Open Ports

Set the proxy_mode key in the robot.cfg to limit the number of open ports in the environment (for example, in a network with a firewall). In the robot.cfg, set proxy_mode = 1 to send all the traffic through a specific port, for example, port 48000.