Share all details related to your problem, including any error messages you may have received.
“Failed To Connect To Service endpoint” in AWS Connector.
I’m configuring a AWS connector. Followed all the prerequisites as per connector guide.
When performing Test Connection getting Error - “Failed To Connect To Service endpoint”.
So, I thought a Firewall/Proxy is blocking the request. To figure out the AWS URL, enabled the DEBUG logs.
But unable to find the URL in IIQ logs.
So I did ‘strace’ and monitored the network.
During Test Connection I see only one request made to the IP ‘169.254.169.254’.
Traced the method calls as per the IIQ stack trace, Identified the method ‘getHostAddressForEC2MetadataService’ in EC2MetadataUtils class returning the IP for EC2 Metadata Service.
In the same method I see 2 system properties ‘com.amazonaws.sdk.ec2MetadataServiceEndpointOverride’ & ‘AWS_EC2_METADATA_SERVICE_ENDPOINT’ can be used to override this IP.
So, Here are my question,
What should be provided in ‘com.amazonaws.sdk.ec2MetadataServiceEndpointOverride’ OR ‘AWS_EC2_METADATA_SERVICE_ENDPOINT’ variables to get the connector working?
A quick google search shows 169.254.169.254 is a link-local address used by cloud environments to provide metadata to instances running in the cloud environment. But I’m not in any cloud environment, our IIQ servers are on a on-perm data warehouse. What is the correct way to resolve this issue?
Getting any IP that starts with 169.254. tells you that something isn’t working. These are obtained by devices when the device can’t get a valid IP from the router’s DHCP server. The device automatically assigns itself a 169.254 IP address using the APIPA protocol. To assign itself an APIPA address, the device generates a random IP in the 169.254 range and then checks to see if another device on the network is using the generated address. If there is another device using it, then your device will continue the process until it finds an available address.
Verify if DHCP is enabled and configured. Try assigning a static IP if troubleshooting the DHCP isn’t fruitful.
The IIQ servers have static IP configured and running for around 2 years, And we have Azure and many more webservices applications are fetching data from internet.
And we have few systems using IIQ’s SCIM API for operational activities.
If we have any problem with IP we would have noticed by now, Other application & Integrations are working as expected.