Wrong IP list for Linux Repo for Agent?

[millardjk]

Support case: 04841334

I'm running 5.0.0.4301 - Workstation Edition against VBR 11.0.0.837 via NFR. Manual backup job (not a managed endpoint). Recently, Agent has started to fail (inconsistently), and looking at logs, it indicates inability to connect to the VBR (Linux-based) repository that was selected--"actively refused connection." Upon further inspection, I realized that Agent's discovery of repository IP addresses is incorrect.
When the discovery is right, the backup works fine (there's something on the repository that's "listening" at tcp/2500), but when it's incorrect, it predictably fails.
Specifically, the Linux repository is at 10.200.1.26 (from the perspective of the VBR server), and has additional VLAN IPs at 10.201.1.26, 10.202.1.26, and 192.168.106.26; the Agent is able to reach the repository at 192.168.106.26 via NAT gateway.
From the log (when successful):

Code: Select all

[01.06.2021 11:00:39] Info [ProxyAgent] Starting client agent session, id '2a8b3a4d-5621-4bba-93b6-dfa641692365', host '10.200.1.26', agent id 'ecabc4d3-ecf3-402e-955d-2fbc8b13069c', IPs '10.200.1.26:2500;10.201.1.26:2500;10.202.1.26:2500;192.168.106.26:2500', PID '5081'

Agent then goes through the list of IPs and can successfully connect to the waiting repository agent running via 192.168.106.26.

When the discovery is incorrect, it does attempt to connect to the right repository, but gets the secondary IP addresses of a different repository.
From the log:

Code: Select all

[02.06.2021 07:39:37] Info [ProxyAgent] Starting client agent session, id 'c7d5fee9-effb-4629-9102-eb28c2be8b41', host '10.200.1.26', agent id '32a84117-b12a-4285-b257-2eed7eaa6652', IPs '10.200.1.26:2500;10.200.1.24:2500;10.201.1.24:2500;10.202.1.24:2500;192.168.106.24:2500', PID '19738'
...
[02.06.2021 07:41:07] Error Failed to connect to agent's endpoint '192.168.106.24:2500'. Host: '10.200.1.26'.
[02.06.2021 07:41:07] Error No connection could be made because the target machine actively refused it 192.168.106.24:2500 (System.Net.Sockets.SocketException)

Note that the list shows .24, not .26 for the final octets; this is a valid repository, but not for this job.

I do not know why the Agent is occasionally getting the wrong set of IPs from VBR for the repository, and because this is an unmanaged agent, I can't figure out where I'd find the logging for the IP discovery. Also: this is the only Agent (managed or unmanaged) that has this issue.

[wishr]

Hi Jim,

It's hard to say what's going on there without knowing all the details, so I would recommend performing a deep investigation with our technical support team.

In general, it sounds like a network misconfiguration on the NAT side, but keeping in mind just one machine has the issue, the root cause may also be in the agent machine.

Just a wild guess, but have you checked the ...\etc\hosts file on the agent machine? Also, maybe there are some manually added routes on the other links of the network chain that are specific for that agent machine?

Thanks

[Dima P.]

Jim,

Can you please clarify if the Linux repo was added via it's host name or one of the IP addresses? Do you have any network rules configured within Veeam B&R? Thanks!

[millardjk]

The Linux systems--three repositories based on Synology boxes--are all managed by VBR based on IP address.

[Dima P.]

Thanks! To make sure I got it right: Synology is registered as a Linux repository or as NFS/SMB share in Veeam B&R console? If latter, can you clarify what is set as a gateway server for the SMB/NFS repository?

[millardjk]

Synology is registered as a Linux repository.

[Dima P.]

Hello Jim,

Mind me asking why you've decided to go with such setup instead of mentioned file share setup or mounting the iSCSI target from these Synology boxes?

Regrading the problem, I'd check NAT as routing might be an issue. I'd also try to use the host names instead of IP addresses and rely on IP address resolution logic if possible. Thanks!

[millardjk]

Mind me asking why you've decided to go with such setup instead of mentioned file share setup or mounting the iSCSI target from these Synology boxes?

Regrading the problem, I'd check NAT as routing might be an issue. I'd also try to use the host names instead of IP addresses and rely on IP address resolution logic if possible. Thanks!

1) file share setup requires a gateway server; unnecessary complication when the Agent can "talk" directly to the Linux repo
2) For Agent, what would be the benefit of an iSCSI target? At a minimum, that's another machine (even if it's the VBR server); it's unnecessary complication. Also: iSCSI target performance on this generation of Synology (RS2413xs) is awful.
3) What is doing the IP discovery? That's the apparent problem, because the list of IPs is incorrect. And it's not the Agent machine, because it can't reach the repo on the management address; the VBR server must be "telling" it via its own interrogation.