CA UIM - Port requirements for CA Admin Console <-> Remote Hub <-> Robot - Robot Functions Fail

Document ID : KB000107080
Last Modified Date : 17/09/2018
Show Technical Document Details
Issue:
We have a firewall issue when attempting to run various functions from the UIM Admin Console (running on the Primary Hub) to some UIM robots via a secondary/remote Hub. 

The robots are able to login to the secondary Hub but when the following functions are actioned they all fail: 

1. Admin Console->get robot environment variables 
2. Admin Console->view robot log 
3. Admin Console->get info 
4. Admin Console->configure probe 

From network traces we can see that the robot uses fairly random ports between 40000 and 50000 when executing the above functions. We have obviously read over the UIM port requirements and we don't believe that this is mentioned. 


 
Environment:
UIM 8.51 
Latest Hub and Robot versions
Cause:
Ultimately this depends upon the presence (or absence) of hub-to-hub tunnels, it's easiest to explain this by illustrating the two scenarios: 

** Scenario 1 - no tunnels ** 

Hub A hosts the Admin Console; 
Hub B is a hub that is in the same environment but is NOT connected to Hub A via a tunnel; 
Hub B has numerous robots attached. 

In such a scenario, it is expected that, since Hub A and Hub B can communicate without tunnels, Hub A should be able to communicate directly with the robots under Hub B as well. Hub B serves only as a "pointer" to its robots, similar to the way a DNS server works. 

In this scenario, if you use the "nametoip" callback mentioned before vs. Hub A's hub probe, and put in the address for one of Hub B's robots, you will note that you will get the actual address of the robot, port 48000. This is the address Hub A will try to use to communicate with the robot. 

The communication, in other words, will not "pass through" Hub B to get to its robots. It would go straight from Hub A to the robots. 

** Scenario 2: With tunnels ** 

Hub A hosts the Admin Console; 
Hub B is a remote hub that IS connected to Hub A via a tunnel; 
Hub B has numerous robots attached. 

In this scenario, the traffic intended for Hub B's robots *would* in fact "pass through" Hub B. A "nametoip" callback giving one of Hub B's robots as the address to resolve would result in either Hub A or Hub B's address (depending on the exact tunnel setup) on a 48xxxx (but NOT 48000) port. This would be an indicator that the traffic is passing over the tunnel to reach the robots. 

In this scenario the Admin Console does *not* need direct access to the robots on Hub B; because of the presence of the tunnel, Hub A will assume it cannot talk to Hub B's robots directly and will instead use the tunnel to route the traffic to Hub B, which will in turn talk to its robots. 

If there is a tunnel between the hubs, but the communication is still trying to go straight to the remote hub's robots, then most likely we need to: 

- disable broadcasting on the hubs 
- delete the hubs.sds files on both hubs and restart them 

This should (in theory) force the hubs to use the tunnel connection. 

If there is not a tunnel between hubs, then the solution would be to create one in order to route the traffic as they might expect. 
 
Resolution:
Create a tunnel between the Primary Hub and the Remote Hub. The server end of the tunnel is configured on the Primary Hub, the client end of the tunnel is configured on the Remote Hub. The tunnel setup is standard, using defaults 

Tests: 
1. From IM, log into the primary hub 
2. Click on the hub probe on the primary hub 
3. Press CTRL+P to bring up the probe utility 
4. Run callback: nametoip 
4a. For the parameter to this callback put the full addr (/Domain/hub/robotname/controller) for the controller probe on the remote robot which you are having trouble configuring 
5. Make note of the IP:port combination which is returned 

Successful Test: 
The traffic intended for the Remote Hub's robots would in fact "pass through" the Remote Hub. A "nametoip" callback to one of the Remote Hub's robots results in a Hub's address (depending on the exact tunnel setup) on a 48xxxx (but NOT 48000) port. This would be an indicator that the traffic passes over the tunnel to reach the robots. In this scenario the Admin Console does *not* need direct access to the robots on the Remote Hub; because of the presence of the tunnel, the Primary Hub will assume it cannot talk to the Remote Hub's robots directly and will instead use the tunnel to route the traffic to the Remote Hub, which will in turn talk to its robots. 

Failed Test: 
If there is no tunnel between the Hubs (or the tunnel is not running properly) the “nametoip” callback from Infrastructure Manager from the Primary Hub to one of the robots will return the ipaddress of the robot and port address 48000.