ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

Robots registering with 127.0.0.1 Loopback IP/169.x APIPA/DHCP address

book

Article ID: 145428

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

One or more robots has registered itself with the IP address 127.0.0.1, or 169.x.x.x which has prevented the robot from properly submitting data and alerts to the hub.

Can this be prevented?

Cause

- known issue

Environment

Robot - prior to 9.20 for 127.0.0.1

Robot - prior to 9.35 for 169.x.x.x

Resolution

Rebooting of servers would sometimes bring up the robot using the loopback address (127.0.0.1) on the server. In some cases, this seems to be caused by a 'race condition' between UIM starting and the network going active. So it may also still be worth setting the Nimsoft Robot Watcher service to 'Automatic (Delayed Start),' on Windows if the upgrade and parameters listed below do not avoid the issue of the robot taking the loopback or APIPA address.

Additionally, it is common when adding a virtual adapter in VMware running Windows in that the adapter will initially go live with a default IP configuration which includes DHCP. It is also common to leave the adapter disconnected from a virtual switch until configured which will prevent it from reaching a DHCP server. If the server or UIM is restarted, then on startup it seems to be fairly likely that the controller will bind to the 169.x.x.x DHCP failure address in this case.

Please refer to to robot (controller) release notes:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/it-operations-management/ca-unified-infrastructure-management-probes/GA/alphabetical-probe-articles/controller/controller-release-notes.html

**********
Fixed an issue in which when a robot was unable to find a valid IP address in the robot.cfg or DNS, it was taking the loopback address. This was disrupting the communication. This issue has been resolved in this release. To resolve this issue, two configurable parameters have been added to robot.cfg:

max_retry_IfLoopBack_attempt
Specifies the maximum number of retries that controller can use to find the system IP address. In the case of loopback IP address, if robot_ip is not configured in robot.cfg, then controller tries to get the system IP. It tries to find the IP address for the number of retries that are specified in the parameter. After trying for the specified count, controller starts again with the loopback IP, resulting into the same initial behavior. The default value is 10. 

sleep_btwRetry_IfLoopBack_attempt
Specifies the maximum interval for which controller waits before trying again for the subsequent attempt. The default value is 2 seconds.

Several UIM admins indicated that this appears to occur after the robot IP address is changed and the system is rebooted. Note that other UIM customers have noticed this behavior after a reboot as well.

In robot_update 9.20 to 9.34, these parameters will cause the robot to engage in the above behavior when its IP address is 127.0.0.1.

In robot_update 9.35 and higher, these parameters also detect the issue with 169.x addresses.

To further ensure that the robot will no longer use the loopback/APIPA address after an IP change and subsequent reboot, in the robot.cfg controller section, you can try the following parameters:

max_retry_IfLoopBack_attempt = 10

sleep_btwRetry_IfLoopBack_attempt = 5

If you expect outages to be significantly longer you can set the number of retries higher, and sleep time higher to accommodate longer periods.