Preferred Networks Question - How is a preferred network confirmed valid/details enumerated?

[micoolpaul]

Hi, my google-fu is failing me on this one.

I’m trying to find out the exact process of how the Preferred Networks implementation actually works from a discovery/enumeration perspective, as in, I understand HOW data is sent/received on preferred networks, but I don’t understand HOW VBR identifies when it can use a preferred network.

Scenario 1:

If I had an MPLS backbone between sites with multiple links, and I wanted to use a particular link for backup tasks such as BCJs and replication, how does VBR/ the data movers know that the other servers have an IP address on a preferred network subnet.

Scenario 2:

If I had Veeam Agents on servers that had 2x physical NICs, one for LAN, one for backup. How would the agent know the preferred network IP addresses to target.

Assumptions:
For all of this let’s assume every device has 2x NICs, one LAN, one Backup network.

Core Question/Reason for creating topic:
I’m trying to understand the way(s) that Veeam collects this data to attempt utilising preferred networks. I can’t imagine it using DNS as you wouldn’t want backup records being resolved in production otherwise you’d be using split DNS or hosts files.

As this is only used by data movers it’s also possible to imagine a handshake taking place between the two endpoints, using their normal IP addresses/FQDNs registered within VBR and then returning an IP list to attempt preferred networks.

As you can see though, I’m taking wild guesses and short of attempting to rip through all the logs and perform PCAPs etc, I can’t find any other way of gathering this information.

I’m also aware I could have this completely backwards and nothing I’ve said above is valid, so yeah, any information to elaborate would be appreciated please!

[HannesK]

Hello Michael,
in general, the software is using whatever the operating system (the network itself) is doing with the network packets. The software knows about all IP addresses of its own components. If an IP address is not reachable (because of routing or firewalling), then it tries the next IP after some time. But that's independent from "preferred networks".

I'm a bit lost in the question, because "Preferred network" takes THE preferred network.

Could you maybe give an example with IP addresses and "preferred networks" settings and describe which problem you try to solve?

Best regards,
Hannes
PS: using multiple network cards in one machine is "bypassing firewalls". I always recommend to re-think such designs.

[micoolpaul]

Hi Hannes,

Thanks for the reply, I understand how it can form a packet, but it’s how one endpoint is aware of the IP addresses of the other endpoint in advance.

How does a Veeam Agent know the IP address of a Veeam repository on a backup network, if the DNS records only show them with their LAN IP addresses? That’s the bit I don’t understand. Is Veeam periodically polling this information into its database and checking with VBR before directly communicating? Do they speak on their normal DNS resolved IP addresses and query the available IP addresses of each other and then use their preferred networks if there is a match?

This is the part I’m missing, how do the endpoints become aware they have such network access to each other.

As for the comment RE bypassing firewalls, agreed it’s not appropriate most of the time. In this scenario the customer has a micro segmented network on LAN but a broader segmented network allowing all endpoints to communicate to the VBR resources but not to each other. I’m not going to comment on whether it’s good or bad personally as it’s more about complexity of management at this point, but it’s their existing topology I’m working with.

[HannesK]

Hello,
I would still be interested, which problem you try to solve. Is something not working?

I don't know your configuration, but in general the agent talks to the backup server first. And only after that was successful, it connects to the repository. The backup server knows all IP addresses of a repository and then the "preferred network" is selected.

query the available IP addresses of each other and then use their preferred networks if there is a match?

yep

Best regards,
Hannes

[micoolpaul]

Hi Hannes,

It wasn’t a case of something not working, but that the helpcenter documentation doesn’t explain the requirements for the feature to work.

“ The backup server knows all IP addresses of a repository and then the "preferred network" is selected.” this is the part I was trying to understand, whether it was querying the backup proxy/repo/whichever role necessary, at the time of a backup to find it’s currently available IP addresses, or whether there was a reliance on DNS entries to exist for the roles with these Backup network IP addresses etc.

So, on this basis then, as long as the agent can communicate to the VBR server, it can find all IP addresses of the necessary backup components and attempt to communicate with those on the preferred networks. In which case that makes sense.

Final question out of curiosity then: If I added a backup NIC to an existing topology, would the addition of this IP be polled intermittently or queried when the resource was required, eg during the start of a backup job.

[HannesK]

during the start of a backup job.

yes, that's how I remember it works.

[JaySt]

came here looking with similar question. For me it was pretty critical to know that the logic of selecting a preferred network contains the proces of evaluating available ip addresses on both components (proxy and repository for example) involved in transfer. When they both have a IP address on the preferred network it seems DNS does not play a big role any more from that point. I can see in the logs, during early backup phases, the proxy queries for all ip addresses of the repository and selects one to connect to, no host names involved during that phase. when no preferred network is set on the vbr network traffic rules, it connects to the LAN IP (in my case). Fiddling with dns/hosts files doesnt help here to make it go out another interface. connection is initiated on IP, and fails to select the correct IP regardless of dns/host file.
Only when a preferred network is set, the proxy decides to connect on the secondary IP of the repository which is within that preferred network.
I also needed to confirm that other proxies, which had no IP in the backup (preferred) network, were still able to connect to the repository LAN ip and send data on that network even though the preferred network was set globaly. I was somehow carefull to see whether a proxy on the LAN would try to connect to the repository IP in the preferred network. In my setup, that would actually work due to routing between them.

[appleoddity]

This is an important question, and unfortunately it’s poorly documented and often misunderstood. Many Veeam forum threads attempt to explain preferred networks, but much of the guidance is incomplete or incorrect.

Based on direct experience, Veeam’s preferred network selection does not require both endpoints to be reachable on that network. If a proxy or repository has an IP on a preferred (private) network, Veeam will attempt to use it—even when the initiating server has no access to that network. When the connection can’t be established, Veeam retries each preferred network in sequence before finally falling back to the production network.

Because Veeam establishes separate connections per workload (for example, per VM in an ESXi job), and because real-world environments include many components (agents, hypervisors, file shares across multiple OSes), these delays compound quickly and significantly extend job runtimes.

The commonly suggested “solution” is to ensure unreachable paths return a TCP RST instead of silently dropping packets, allowing Veeam to fail over faster. This is neither practical nor sustainable in complex environments with many systems and network paths.

In practice, this behavior can cause backups to take three times longer (or more), effectively negating the benefit of a dedicated backup network. Preferred networks only work reliably in very simple architectures.

Additionally, IP selection appears to be independent of DNS. Veeam attempts to connect to all IPs on a destination system regardless of DNS records, HOSTS files, NIC priority, or adapter ordering. Connections appear to be attempted in ascending IP order. Adding managed servers by IP instead of hostname does not appear to change this behavior.

As a result, there is a significant amount of misleading advice circulating. While Veeam is an excellent product overall, the preferred networks feature lacks the flexibility and logic required for real-world designs.

To be genuinely useful, preferred networks would need policy-based controls: source and destination IPs, traffic types (data vs. control), and the ability to scope rules to specific components (proxies, repositories) rather than applying them globally.

In most environments, dedicated high-speed storage networks exist for a reason and are intentionally isolated from production. Treating them as universally “preferred” networks is fundamentally incompatible with that design.

[JaySt]

i totally agree with that.
when it's implemented, it seems to work while witnessing delays. At no point i think it's being done in a smart or efficient way and i can't properly explain what happens.
This feature is one of the features that needs way more control to be usefull in enterprises.