Vendor product managers love discussing mythical use cases to warrant complex functionality in their gear. Long-distance VM mobility was one of those (using it for disaster avoidance was Mission Impossible under any real-world assumptions), and high-volume network-based backups seems to be another. Here’s what someone had to say about that particular unicorn in a LinkedIn comment when discussing whether we need traffic engineering in a data center fabric.

When you’re dealing with a large cluster on a fabric, you will see things like inband backup. The most common one I’ve seen is VEEAM. Those inband backups can flood a single link, and no amount of link scheduling really solves that; depending on the source, they can saturate 100G. There are a couple of solutions; IPv6 or eBGP SID has been used to avoid these links or schedule avoidance for other traffic.

It is true that (A) in-band backups can be bandwidth intensive and that (B) well-written applications can saturate 100G server links. However:

• Backup traffic is usually sent from many clients to a few servers, which must save the received data onto reasonably priced storage.

• The total amount of the backup traffic in a fabric is thus limited by the performance of backup servers- and storage.
• It’s somewhat challenging to push 100G through a single TCP session, and the moment the backup system uses more than one TCP session, there’s a chance that the affected switches will spread the load across multiple links.
• The most likely network bottleneck of a backup system is the link between the backup server and the adjacent switch, not the uplinks of that switch or the other links in the system.
• Assuming you’re using the pretty standard 1:4 speed ratio between server links and fabric links, all traffic to a single backup server could saturate 25% of a single uplink of the adjacent switch, and the saturation of other links in the data center fabric would usually be even lower.
• Many data center switches use ASICs that support dynamic load balancing. Reshuffling the ECMP load distribution to avoid a congested uplink is thus just a question of having properly written software. For example, Cisco ACI (supposedly) does that automatically.
• Even if you were experiencing congestion issues when using a large cluster of backup servers connected to the same set of switches, you could use traditional routing tricks to spread the load across the uplinks.

Long story short: while I’m positive there must be data center fabrics that experience network-wide congestion due to backup traffic, the “we need traffic engineering in data center fabrics to deal with backups” is a myth for most well-designed mainstream environments. That does not mean you don’t have to take backup traffic into account when designing your network, though ;)

Keep It Simple and Separate (KISS)

Bela Varkonyi described an old-style solution in his comment:

This approach has just one drawback: the separate network has to be a layer-2 network or at least look like a single subnet to the servers¹.

Most servers don’t use VRFs or don’t have the means of making generic applications VRF-aware, so you can’t have two default routes, one for backup and another for the rest of the traffic. That’s why VMware mandated a layer-2 vMotion network² until they figured out how to spell VRF.