As soon as Resilio agents are added to a Synchronization job or Distribution/Consolidation job run is started, the Agents use built-in mechanisms to discover other agents in the job and connect to them.
The number of discovered agents appears in column "Peers connected" in a job run and is revealed with details in connectivity map. If no other agents are discovered, the Agent will report status 'no peers' in the job run.
This guide consists of two blocks:
1) Explains the standard peer discovery mechanism
2) Covers most possible and seen reasons and places to doublecheck when troubleshooting connectivity
Peer discovery
Agents try to connect to the tracker server from the Agent Profile on the IP and port of the tracker.
Once connected, they communicate their own local and public IP addresses and bind port (port 3839 by default). They also receive the list of IP addressed and ports of other agents in the job.
The Agent will try to establish connection on each of the learned addresses directly.
Agents also try to connect directly to the hosts from "Known hosts" parameter in the Agent profile, on the given IP address and port.
Agents will be trying all the protocols from "Tunnel protocols" parameter in the Agent profile.
Agent located in LAN will send multicast or broadcast packets as per LAN discovery in the Agent profile.
Also, proxy server might be used in a restricted network.
Combination or either of these mechanisms allow to discover as many agents as possible or on the contrary to shape the mesh (see guidelines to disable peer-to-peer).
Possible reasons for the connectivity problem
1) Misconfiguration.
As simple as it sounds, it's quite a frequent case. Check that there are no typos in the address of tracker servers, known hosts. Check that agents have at least one common discovery mechanism and at least one common protocol enabled in their Agent Profiles.
Make sure that the agents, discovered through tracker server, are not filtered by "Allowed peers" parameter in the Agent Profile.
2) Networking.
Depending on the chosen mechanism, check that all the required ports and protocols are open and forwarded in the firewalls, NAT, routers between the agents.
For example, if a tracker server is used, make sure that the entered tracker's address is indeed reachable by all the agents in the job. The Agent that does not reach out to the tracker remains unknown for others.
If you use DNS names for trackers or known hosts, make sure that the name is resolved into a reachable address for all the agents.
Multiple network interfaces on an Agent machine can also play their role. Check that the attempted addresses are routed properly though a necessary gateway. This is especially a valid case when VPN is in use.
Looking at the Agent's connectivity map helps to understand by what addresses and protocols the Agent tries to actually connect to the others.
(image is clickable)
3) There's a priority_peers setting in the Agent profile.
While the agent might be still connected to others, apart from the main server (per priority_peers parameter), the Agent will report "no peers" if there's no connection to the main server. See here for more details. Using the suggestions above, check that connection to the main server is also possible.