SQL Service Broker 2012: the connection was closed by the remote end, or an error occurred while receiving data: '64(The specified network name is no longer available.)'

Question

Anyone can help with the below issue please? Much appreciated.
We have about 2k+ messages in sys.transmission_queue
Telnet to the ports 4022 is working fine.
Network connectivity has been ruled out.
The firewalls are OFF.
We also explicitly provided the permissions to the service account on Server A and Server B to the Service broker end points.
GRANT
CONNECT ON
ENDPOINT <broker> <domain\serviceaccount>
Currently for troubleshooting purposes, the DR node is also out of the Availability Group, which means that we right now have only one replica the server is now a traditional cluster.
Important thing to note is when a SQL Server service is restarted, all the messages in the sys.transmission queue is cleared immediately. After about 30-40 minutes, the errors are continued to be seen with the below
The
connection was
closed by the
remote end,
or an
error occurred while
receiving data:
'64(The specified network name is no longer available.)'

Answer 1

We were able to narrow down the issue to an irrelevant IP coming into play during the data transfer. We tried ssbdiagnose runtime and found this error:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Windows\system32>SSBDIAGNOSE -E RUNTIME -ID 54F03D35-1A94-48D2-8144-5A9D24B24520 Connect to -S <SourceServer> -d <SourceDB> Connect To -S <DestinationServer> -d <DestinationDB>
Microsoft SQL Server 11.0.2100.60
Service Broker Diagnostic Utility
An internal exception occurred: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
P  29830                                 Could not find the connection to the SQL Server that
corresponds to the routing address tcp://XX.XXX.XXX.199:4022. Ensure the tool is connected to this server to allow investigation of runtime events
The IP that corresponds to routing address is no where configured within the SSB. We are yet unsure why this IP is being referred despite not being configured anywhere. We identified that this IP belongs to one of nodes other SQL Server cluster, which has
no direct relation to the source server. We failed over that irrelevant SQL Server cluster and made another node active and to our surprise, the data from sys.transmission_queue started flowing. Even today we are able to reproduce the issue, if we bring
back this node [XX.XXX.XXX.199] as active. Since, its a high business activity period, we are not investigating further until we get an approved downtime to find the root cause of it.
When we get a approved downtime, we will bring the node [XX.XXX.XXX.199] as active and we will be running Network Monitor, Process Monitor and the SSB Diagnose all in parallel to capture the process/program that is accessing the irrelevant IP.
Once, we are able to nail down the root cause, I will share more information.