Making Veeam use a specific NIC only

[resruss]

Hi everyone,

I added a Routing and Remote Access role to our Veeam B&R and Proxy server today.
Backups were running at 500KB/s to local storage and I couldn't work out why.
I stopped the RRAS service and the backup jobs stopped, mentioned something about network issues.
I then rebooted and chose to use an alternative backup proxy, backups are running at 50MB/s again.

Ideally, I want to keep RRAS on the Veeam server, but once a user connects, a new virtual interface is created and Veeam seems to pick that up to use.

Just wondering if there's a PowerShell command or registry key I can add or adjust to force it to bind only to a particular NIC so I can enable RRAS again.

Thanks.

[Vitaliy S.]

Hello,

There is no such PowerShell cmdlet, since Veeam B&R relies on Windows routing layer. If you want to force using specific NIC, try adding your repository via IP address of this NIC.

Thanks!

[resruss]

Thanks Vitality.

I should have mentioned, everything's on the same subnet, it's once the RAS PPP Adapter is added that there's a problem, and this is added dynamically once a user connects to the VPN.
It won't show up in a list of NICs in Control Panel, but will show up in ipconfig:

Windows IP Configuration

PPP adapter RAS (Dial In) Interface:

IPv4 Address. . . . . . . . . . . : 192.168.1.96
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :

Ethernet adapter Local Area Connection:

IPv4 Address. . . . . . . . . . . : 192.168.1.90
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1

My workaround at this point is to have the B&R server leverage another backup proxy to do all the grunt work, I was just hoping to bind to a specific NIC or set an IP address for the Veeam services.

Is this worth opening a support case? Or am I out of luck?

[Vitaliy S.]

Not sure our support team can assist you with this, since it's more like a Windows-related routing problem.

However, if I got you right Veeam services are picking up this IP address 192.168.1.96 instead of 192.168.1.90 and this makes your job crawl, right? Please take a look at the existing topic that explains how to use "Run server on this side" option, that might help you: Multiple NIC's on Veeam server [Not Load Balancing]

[MrScaffoldIT]

Interesting...
I have 2x different networks setup on my Hyper-V servers.
One is the main all users network, the second is only comunication between servers.
Ping server 2 from server 1 and you get the server network.

However I have just caught Veeam sending the replication data over the main network, from server 1 to Server 2.

The VM's themselves are NOT on the server network.

But it was the Veeam process running on server 1 that was using the main network.

[soncscy]

Hey Nathan,

Have you tried setting preferred networks for the Veeam traffic in the Veeam console? If it's between two Veeam infrastructure items, then Veeam can try to prefer such connections: https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Do I get it right your traffic route of concern is from the HyperV hosts to the repositories for backup? If so, then you should see success with this.

[MrScaffoldIT]

Hey Soncscy,

I DID do that, and it seemed to have worked.

However a possible new issue is the VPN for the backup network drops out.
The Veeam traffic then jump on to the main network.
this can kill the main as it slows down the connection.

When the VPN comes back up Veeam stays using the main connection not automatically jumping on the backup network.

I have to BREAK the main network like (disable the NIC) and restore it once the Veeam data has switched to the Backup network.

Thanks,

Nathan

[soncscy]

Hi Nathan!

Glad it assisted initially. With the switching between networks, in my opinion it's by design; an application typically isn't going to watch for network paths like that and is just going to initiate the connection from the beginning and continue using that. Especially with encrypted traffic, I think this would just be a real mess to re-establish a secure connection on another network, so it kind of makes sense from my point of view. But likely if the job was completely stopped and then restarted, it would take the primary connection. Keep in mind, with Windows at least, the automatic metrics for the network stack will rank "the cost" of each available connection, and typically present the cheapest one as the idea connection.

I would work with your team to stabilize the VPN connect as much as possible, and maybe change or alter retries for the jobs going over VPN to either wait longer for the retry (give the VPN time to recover) or just not retry at all given the risk.

But ultimately you need to get the VPN connection stable I think there's no avoiding that.