UIM 23.4.1 - NEW configuration reader service -- mcs issue now with firewall'd robots.

[Pat O'Connor]

Hello,

Prior to our uim 23.4.1 upgrade, we had no issues with our firewall'd robots, with the introduction of this new configuration reader service, now when we use our MCS to push profiles to the firewall'd servers group, all profiles are in PENDING state, we have applied the configuration reader service update provided by support, however to no avail.

in further research, this new config reader service from MCS now has the robot do a pull to get profile information, prior to it, mcs just pushed and we have no issues, we have our source as the robot and destination as the hub with our 48000-48050 ports open both ways.

with this new config reader service, is the source now the hub and the dest the robot?

regards,

Pat O'Connor

------------------------------
Pat O'Connor
Performance Team
DCSS
[JobTitle]
[CompanyName]
[City] [State]
------------------------------

[Kurt Mairamhof]

Hi Pat,

we had the same issue and also ran into this change of behavior. Opening more ports on the robot side helped. In our situation we had limited the robot incoming traffic to 48000-48020 and we saw that traffic tried to connect to 48029. The config reader service is actively polling the robot's probe configuration.
regards,
Kurt

[Pat O'Connor]

thanks Kurt for taking the time to reply, ya, we have 48000-48050 open, will continue to work on this issue...


Regards,

Patrick O’Connor

Batch Operations, Performance and Planning

[phone]

[California Child Support Services Logo]<https: childsupport.ca.gov/="">

[Thomas Linder]

Hi Patrick

To add to Kurt's reply (he was helping us finding those issues on our infrastructure), we also had a situation with dual-homed hosts, where the communication from config reader service was trying to take the "wrong" route from robot to hub.

Reason was, the hub-robot was resolving to the IP on the 2nd network, monitoring ports were only open for the 1st network on the robot firewalls (outgoing traffic allowed from robot to hub). As the robot resolved the hub IP to be on the 2nd network, traffic got blocked by the firewall. In our case, we resolved this by switching the hub IP by setting the robot address in hub controller to explicitly be on the 1st network.

Regards,

Thomas.