Configure agent to use alternate NIC

[Provogeek]

Is there any way to configure the agent to use an alternate NIC when sending backup data to a repo?

I can not find any network configuration settings in the veeam.ini for the Linux agent. Is there another location where I can tell the agent what interface to use when connecting to the backup repository? My physical Linux servers are managed by Veeam B&R and were added to the Inventory using DNS name. My physical Linux servers have a physical NIC attached to the production network (1GB) and a second physical NIC attached to a backup network (10GB). The IP addressing is there, the agent should be able to find the repo on the backup network it has a physical NIC attached too. However, the agent is sending backup data to the Veeam B&R server, and it is the Veeam B&R server that is writing the backup data to the repo. Any way to have the agent use the backup network and send the backup data directly to the repo? The repo is an Exagrid using Veeam shares.

regards

[PTide]

Hi,

Currently there are My physical Linux servers are managed by Veeam B&R and were added to the Inventory using DNS name

The name resolves into IP address from the production network and the agents operate in "Managed by backup server" mode, is that correct?

<...>and it is the Veeam B&R server that is writing the backup data to the repo.<...>The repo is an Exagrid using Veeam shares.

Would you elaborate more details, please? Did you add Exagrid as a simple shared folder repository or as an Exagrid repo? It seems like VBR is used as a gateway server for some reason.

Thanks!

[Provogeek]

Hello,

The name resolves into IP address from the production network and the agents operate in "Managed by backup server" mode, is that correct?

That is correct. The physical Linux servers name resolve to a production IP address and the agent does operate in "Managed by backup server" mode

Would you elaborate more details, please? Did you add Exagrid as a simple shared folder repository or as an Exagrid repo? It seems like VBR is used as a gateway server for some reason.

Exagrid was added as an Exagrid repo. Tracing the connection, I do not find any connections going to the Exagrid from the physical Linux server using the Veeam agent. When I trace the connections on the physical Linux server, the Veeam process only shows a connection to the Veeam B&R server.

thank you

[PTide]

I have a few more questions to ask : )

Exagrid was added as an Exagrid repo.

Are you positive that ExaGrid-Veeam Accelerated Data Mover transport (see page 9) option is enabled for the share that you created when you were adding Exagrid to VBR console?

And just to double-check:

- Exagrid has only 10Gb interface, and is also added to VBR via DNS, and its name resolves to an IP address that sits on a 10Gb interface?

- Any preferred network rules enabled?

Thanks!

[Provogeek]

Yes, I am very sure the Exagrid was added as an ExaGrid-Veeam Accelerated Data Mover transport The Exagrid has 4 x 1Gb interfaces and 2 x 10Gb interfaces. Only one 1GB interface is in use for management, backup traffic excluded. Then only one of the 10Gb interfaces is setup for backup traffic. One network preference is enabled, preferring the backup network for backup traffic.

[Provogeek]

Went ahead and opened case 03365659

The answer is no, you can not redirect the backup traffic to an alternate NIC.

From Veeam Support

Unfortunately there is no native way to perform this change to have your data go one way or the other in respect to the dedicated NIC.

[PTide]

The thing that concerns me the most in your case, is that it seems that no datamover has been deployed on Exagrid. Had it been deployed, the agent would have attempted to connect to the appliance directly instead of sending traffic to VBR.

The fact that the traffic flows via VBR means that the datamover has been spin-up on VBR. Provided that Exagrid is configured correctly, that behaviour is unexpected. I want to ask our team to investigate that, however they'll need logs. As far as I can see the engineer hasn't requested you to provide logs, so please either reopen the case and attach the logs, or reopen a new one and let me know the case ID.

As a sidenote: although there is no built-in option to order VAL to send backup traffic via a particular interface, "Preferred Network" settings ensure that VAL will first try to send data to the prioritized IP address. Agent does not decide which NIC will be used as it is determined by routing rules on the machine.

Thanks!

[Provogeek]

PTide, In the thread "Veeam Agent Linux and backup network"

You stated

I've checked with the team and it turns out that networking rules do not apply to the agent jobs. I've noted this thread as a feature request.

Was the agent updated since that 9/19/2018 post to correct this and enable the agent to use the Preferred Networks setting in the Global Network Traffic Rules?

[PTide]

The case had been reinvestigated since then and it turned out that there is no bug in fact and that the rules actually apply to agent jobs as well. I'll update my older message with that information, thank you for pointing that out.

[ViciousXUSMC]

Out of Band Backup with Veeam.
This can be done on your Operating System level.

Example.
Data Server 1
Production IP: 10.0.2.12
Backup IP 10.240.0.15

Veeam Server
Production IP 10.0.2.13

You need a DNS Entry or Host File for the Veeam Server and/or Backup Repository to talk to Data Server 1 over the Backup IP. This is so that we try to talk to the NIC that is on the backup network.

On the actual Data Server, you need a static route that tells the machine what gateway (NIC) to use to reach a specific destination.

In my example above that would be done like this.
route ADD 10.0.2.13 MASK 255.255.255.255 10.240.0.1 -p

Add a static route, to host at 10.0.2.13/32 using the gateway of 10.240.0.1 and save this static route as persistent.

From this point forward if you do a tracert you will see that traffic to your backup server goes out the 2nd NIC, and from your Veeam server it will resolve to the IP on the backup NIC as well.

UPDATE: Oops, with multiple tabs open I just noticed this was the Linux agent not Windows agent, so my answer above is not correct.
Same principle applies however, you need to setup a static route on your OS.