Domino server trace not finding other server

I have a Domino server where it will successfully do the domino server command trace to other servers and they work but it will not work to this one particular server. The “from” server is INTERNOTES02/DEKKO. A working “to” server is INTERNOTES3/DEKKO. The failing “to” server is INTERNOTES4/DEKKO.

INTERNOTES3/DEKKO
Fully qualified Internet host name: INTERNOTES3.DEKKO.COM
Ports, Net address: INTERNOTES3.DEKKO.COM
Internet Protocols, HTTP, Basics Host name(s): internotes3.dekko-1

INTERNOTES4/DEKKO
Fully qualified Internet host name: INTERNOTES4.dekko.com
Ports, Net address: INTERNOTES4.dekko.com
Internet Protocols, HTTP, Basics Host name(s): INTERNOTES4.DEKKO.COM

There is no connection document going from INTERNOTES02 to INTERNOTES3.
There is no connection document going from INTERNOTES02 to INTERNOTES4.

From a dos command line on INTERNOTES02:

C:\Users\rob>ping internotes4.dekko.com

Pinging internotes4.dekko.com [201.174.117.199] with 32 bytes of dat
Reply from 201.174.117.199: bytes=32 time=77ms TTL=124
Reply from 201.174.117.199: bytes=32 time=77ms TTL=124
Reply from 201.174.117.199: bytes=32 time=80ms TTL=124
Reply from 201.174.117.199: bytes=32 time=77ms TTL=124

Ping statistics for 201.174.117.199:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 77ms, Maximum = 80ms, Average = 77ms

C:\Users\rob>ping internotes3.dekko.com

Pinging internotes3.dekko.com [208.87.182.66] with 32 bytes of data:
Reply from 208.87.182.66: bytes=32 time=1ms TTL=60
Reply from 208.87.182.66: bytes=32 time=1ms TTL=60
Reply from 208.87.182.66: bytes=32 time=1ms TTL=60
Reply from 208.87.182.66: bytes=32 time=1ms TTL=60

Ping statistics for 208.87.182.66:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms

From the Domino console

trace internotes4
09/29/2016 07:32:01 AM Network: Determining path to server INTERNOTES4
09/29/2016 07:32:01 AM Network: Available Ports: TCPIP
09/29/2016 07:32:01 AM Network: Checking normal priority connection documents only…
09/29/2016 07:32:01 AM Network: Local network connection document found for INTERNOTES4/DEKKO
09/29/2016 07:32:01 AM Network: Verifying address ‘INTERNOTES4’ for INTERNOTES4/DEKKO on TCPIP
09/29/2016 07:32:01 AM Network: Requesting IP Address for INTERNOTES4 from DNS
09/29/2016 07:32:03 AM Network: DNS did not return an IP address for INTERNOTES4
09/29/2016 07:32:03 AM Network: Unable to connect to INTERNOTES4/DEKKO on TCPIP (The remote server is not a known TCP/IP host.)
09/29/2016 07:32:03 AM Network: Unable to find any path to INTERNOTES4 because The remote server is not a known TCP/IP host.

trace internotes3
09/29/2016 07:32:07 AM Remote console command issued by Rob Berendt/DEKKO: trace internotes3
09/29/2016 07:32:07 AM Network: Determining path to server INTERNOTES3
09/29/2016 07:32:07 AM Network: Available Ports: TCPIP
09/29/2016 07:32:07 AM Network: Checking normal priority connection documents only…
09/29/2016 07:32:07 AM Network: Allowing wild card connection documents…
09/29/2016 07:32:07 AM Network: Enabling name service requests and probes…
09/29/2016 07:32:07 AM Network: Address found in local TCPIP names table for INTERNOTES3
09/29/2016 07:32:07 AM Network: Connecting to INTERNOTES3/DEKKO over TCPIP
09/29/2016 07:32:07 AM Network: Using address ‘208.87.182.66’ for INTERNOTES3/DEKKO on TCPIP
09/29/2016 07:32:07 AM Network: Connected to server INTERNOTES3/DEKKO
09/29/2016 07:32:07 AM Network: Attempting Authenticated Connection
09/29/2016 07:32:07 AM Network: Compression is Disabled
09/29/2016 07:32:07 AM Network: Encryption is Disabled

INTERNOTES02/DEKKO is running on Windows Server 2012 R2

The C:\Windows\System32\drivers\etc\hosts file on INTERNOTES02 does not have a single nonblank line which doesn’t begin with #

Subject: Solution

Create a agent in address book like this

Field $SavedAddresses := @unavailable;
Field $SavedDate := @unavailable;
Field $SavedPorts := @unavailable;
Field $SavedServers := @unavailable;
Field $SavedTriedDate := @unavailable;

Run the agent against all the location docs

Subject: I can “train” it.

I can train it by doing this:

trace internotes4.dekko.com

works

trace internotes4

now that works.

but a

restart server

makes me run the trace internotes4.dekko.com before the trace internotes4 will work again.

Subject: $SavedAddresses

Thanks for the link about this: http://www-01.ibm.com/support/docview.wss?uid=swg21094111 http://www-01.ibm.com/support/docview.wss?uid=swg21094111

And, yes, there is some strange stuff in there for $SavedAddresses. I see how to display them. How does one clear them out?

Subject: $SavedAddresses

Might be far-fetched, and you may have tried this already, but look for $Savedxxx fields on the Server Document for INTERNOTES02/DEKKO. I’ve seen cases where these (stupid) $Savedxxx fields prohibit the server from using the actual DNS supplied addresses.

The specific fields to look for are:

$SavedAddresses

$SavedDate

$SavedPorts

$SavedServers

$SavedTriedDate

I’ve seen the same thing happen when users try to connect to a server.

www-01.ibm.com/support/docview.wss?uid=swg21094111

Subject: Is your question why would this happen, or what can I do to fix?

Why? Server documents also participate in name resolution, so if your server document for 3 resolves to the proper DNS name or IP address the connection doc isn’t necessarily required. Same for entries in the hosts file. I assume DNS doesn’t know your hosts by the simple name.

The connection docs are still used under certain circumstances even if they’re not set for the particular server. It sounds like the connection doc to 4 does not have an IP address specified in it, so it goes out to DNS and asks, fails, and tells you. In the case of 3, it sounds like the connection doc to 3 has an IP address specified on it. It’s possible that something else caused the server to reach out and discover server 3 by IP address, but this would be the most straightforward reason for the difference between 'em.

So, check the connection docs to see whether 3 has an alternate IP address; and whether 4 doesn’t have an alternate IP address.

Why’s it happen after you connect directly to the server? Well, if you reach out to the server even by IP address, the server responds by sharing its name. At that point, the name is available to the source server, and any common name for that server will resolve to the IP address that says, “Hey, I’m that server.”

What can you do to fix? Add the IP address to the connection doc, if they’re not there for 4

Subject: No IP addresses

I double checked. We do not store IP addresses in server documents. Nor do we store them in Connections documents. We have this network guy who likes to change the IP address associated with servers periodically and I have enough places to change without having to look there also. We have another such renumbering coming up when we do a data center move.

If the address is not blank it is the fully qualified name (ie internotes4.dekko.com) and not an IP address.

Subject: well, somewhere along the way it’s getting a name translation.

Might even be that the short name is being translated to the long name.

In point of fact, the Notes client will even cache these relationships so that, if sometime in the past they were connected, it’ll remember. (queue eerie music.) Seriously, that’s in the locations document, I think under “ServerAddress” or something like that.

Somewhere the short name is being connected with the IP name for 3, and it isn’t so translated for 4.

The trace report for 4 is telling me the following:

09/29/2016 07:32:01 AM Network: Checking normal priority connection documents only…
09/29/2016 07:32:01 AM Network: Local network connection document found for INTERNOTES4/DEKKO

It’s saying here, that you have a network connection document that the server recognizes, it translates from “internotes4”.

09/29/2016 07:32:01 AM Network: Requesting IP Address for INTERNOTES4 from DNS

It’s saying here that it hasn’t found the IP address translation locally, so it’s checking with DNS. Later messages show it’s failed to translate to an IP address this way.

The trace report for 3 is telling me the following:

09/29/2016 07:32:07 AM Network: Checking normal priority connection documents only…

Lack of any connection doc found shows that 3 really doesn’t have a connection document the server is capable of using. You’d have to check over the connection doc carefully to recognize why.

09/29/2016 07:32:07 AM Network: Address found in local TCPIP names table for INTERNOTES3

The short server name & IP address is found & used from the local hosts table.