Stuck with DMS endpoint connectivity failures? We can help you.

Generally, with this error, we can’t connect to the AWS Database Migration Services endpoints.

Here, at Bobcares, we assist our customers with several AWS queries as part of our AWS Support Services.

Today, let us see why the test connection fails, and how we can troubleshoot these connectivity issues.

DMS endpoint connectivity failures

It is always a good practice to test the connectivity from the AWS DMS replication instance to the endpoints.

However, we perform this before the AWS DMS migration task. It helps make sure that the task doesn’t fail due to connectivity issues with the endpoint.

The security group must include outbound rules for the endpoint’s IP addresses for the specific port, for the AWS DMS replication instance to connect to the source and target endpoints

Suppose, the outbound rules are correct. In that case, we check the inbound network or security configuration on the source or target database.

On the other hand, if the issue was with denial of access to the database, the errors will be as follows:

Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 08001 NativeError: 101 Message: [unixODBC]FATAL: password authentication failed for user "dmsuser" ODBC general error.

Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider ODBC general error., Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HY000 NativeError: 2005 Message: [unixODBC][MySQL][ODBC 5.3(w) Driver]Unknown MySQL server host 'mysql1.chulbfpmdg0x.us-east-1.rds.amazonaws.com' (22) ODBC general error.

To resolve them, we need to confirm the following endpoint details are set correctly:

• Username and Password
• ServerName (DB instance endpoint name)
• Port

At times, the error can cause by network configuration or timeouts. Then the error will be like this:

Test Endpoint failed: Application-Status: 1020912, Application-Message: Failed to connect Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: HYT00 NativeError: 0 Message: [unixODBC][Microsoft][ODBC Driver 13 for SQL Server]Login timeout
expired ODBC general error.

Test Endpoint failed: Application-Status: 1020912, Application-Message: Cannot connect to ODBC provider Network error has occurred, Application-Detailed-Message: RetCode: SQL_ERROR SqlState: 08001
NativeError: 101 Message: [unixODBC]timeout expired ODBC general error.

To resolve them, we check the resolution for the NativeError for the endpoint’s database engine.

The source or target database is hosted on AWS

In this case, we confirm the database has a security group configuration. It must allow incoming traffic from the AWS DMS replication instance’s IP address.

Our Support Techs recommend the steps below to verify the public and private IP address:

1. Initially, we open the AWS DMS console and select Replication instances from the navigation pane.
2. Then we select the name of the replication instance.
3. We can check the Public and Private IP address of the replication instance from the Details tab. Or, we can run describe-replication-instances:

Private IP address:

aws dms describe-replication-instances
--filters Name=replication-instance-id,Values=<DMS replication instance name> "ReplicationInstances[*].ReplicationInstancePrivateIpAddress" --output=text

Public IP address:

aws dms describe-replication-instances --filters Name=replication-instance-id,Values=<DMS replication instance name> "ReplicationInstances[*].ReplicationInstancePublicIpAddress" --output=text

Then, we confirm that the Network ACL rules don’t restrict incoming traffic to the source or target databases and the replication instance.

Finally, we confirm that the route table for the subnet has sufficient entries that allow either public or private network traffic.

The source or target database is hosted on-premises

We need to check with the network administrator to check if the database allows incoming connections from the AWS DMS replication instance.

Then we verify if the DNS configuration is set up correctly. In addition, we make sure there isn’t a firewall blocking communication to the source or target database.

Suppose, we can’t identify the issue in the network connectivity. Then we create a new Amazon EC2 instance in the same VPC.

But it should be of the same network configurations as the AWS DMS replication instance.

From the new test EC2 instance, to further troubleshoot the network connectivity we run:

telnet <IP address of host database server> <port number>
nslookup <Fully qualified domain name for the database server>
tracert <IP address of host database server> <ip address of host database server> <port number> <fully qualified domain name for the database server> <ip address of host database server>

[Need help with the connectivity issues? We’d be happy to assist]

Conclusion

In short, we saw how our Support Techs fix the connectivity issues with the DMS endpoint.