Waring message: WARN : Remote DSA '<dsaname>' failed address check

Products

• CA Directory

Issue/Introduction

Two DSAs setup in MW replication on two different nodes. You may see the following WARN message in DSA warning log and wonder what it means.
WARN : Remote DSA '<dsaname>' failed address check

e.g.
DSA1 on HOST1 with IP xx.xxx.xx.xxx
DSA2 on HOST2 with IP yy.yyy.yy.yyy

You have already confirmed the fact that correct hostnames are specified within the KNOWLEDGE .dxc files of each DSA as well as the fact that when running OS commands such as 'nslookup' etc. also confirms the configuration at network level is correct. Still DSA1 is not able to replicate the data to DSA2 while showing:

WARN : Remote DSA 'DSA2' failed address check

Environment

Release : 14.1

Component : CA Directory

Resolution

The above messages is logged when there is a conflicting information presented to DSA from OS/network layer. To find out exactly what/where DSA1 is seeing DSA2 running, enable trace level of DSA1 to 'all' briefly for 5 minutes from DXconsole (aka DSA console) and let it produce this message again. Once done, re-init DSA1 (causing no outage) so the trace level goes back to whatever you have configured (default is 'error').

i.e.
telnet localhost <DSA1_console_port>
dsa> set trace=all;
dsa> logout;

After 5 minutes or so, run 'dxserver init DSA1' to reinitialize this DSA for logging level revert back to whatever is configured on the system.

Review the TRACE log (e.g. DSA1_trace.log), where further details will be revealed such as:

> [0]     nsap = zz.zzz.zz.zzz:42142
> [0]
> [0]   flags = IDU_FLAGS_USE_SSL
> [0]
! [0] MW-DISP creating ctx 0x7ff290068e68
! [0] MW-DISP creating ctx for bind 0x7ff290068e68
? [0] 20220107.145512.583 WARN : Remote DSA 'DSA2' failed address check

As shown above, somehow DSA1 has a knowledge of DSA2 running on IP address zz.zzz.zz.zzz while it should be running on yy.yyy.yy.yyy hence the message. At this point you need to work with your network team of system administrator team to troubleshoot this further to find out what node IP 10.113.10.113 belongs to and remediate the situation.