By Dr. Pranay Jha, infrastructure architect and long-time vExpert, who designs and tests DR for production VCF estates.
A 100 Mbps circuit between two sites is not a bandwidth budget. It is a promise you make about the worst ten minutes of your busiest afternoon, and most sizing spreadsheets never look at that window. The link gets sized on a daily average, replication runs fine for weeks, and then quarter close lands. Change rate triples for three hours, the replication schedule falls behind, and the Site Recovery UI starts posting RPO violation alarms while everyone swears nothing changed.
If you run DR for VCF 9 on VMware Live Recovery, the bandwidth you provision is not a networking detail you can hand to someone else and forget. It is the single input that most often turns a five minute RPO on paper into a forty minute RPO in production. The arithmetic is short. The trap is which number you feed it, and this part is about getting that number right before an outage does the sizing for you.
Dataset size is not what sizes your link
The first instinct on a DR project is to look at how much data you are protecting. Eight terabytes feels like a big number, so people reach for a big pipe. Dataset size matters for exactly one thing: the initial full sync. After that first copy completes, vSphere Replication ships deltas, and the size of those deltas is set by how much data changes inside each RPO period, not by how much data exists.
Change rate is the number that matters
Broadcom states the method plainly: work out the average data change rate within an RPO period, then divide by the link speed. The subtlety that trips people is how vSphere Replication counts a change. If a block is written a hundred times inside one RPO window, it is still transferred once, in its final state, at the moment the bundle is built. The engine registers that a block changed during the period, not how often. A busy database that keeps overwriting the same hot pages can replicate lighter than a smaller application that touches fresh blocks all day. Two workloads of identical size can want wildly different bandwidth, and the only way to know is to measure the churn.
Only about 70% of the link is yours
The docs give a working assumption you should not skip: plan for roughly 70% of a link to be available for replication traffic. On a 10 Mb link that leaves about 3 GB per hour, and on a 100 Mb link about 30 GB per hour. The missing 30% goes to protocol overhead, retransmits, and whatever else shares the circuit. Sizing to the nameplate speed of the link is how you end up saturated the first time a real workload gets busy. Every figure in the worked example below already carries that 70% haircut.
How vSphere Replication moves the bytes
Without VSS quiescing, vSphere Replication can dribble changed blocks onto the wire continuously as they change, which spreads traffic across the RPO period and keeps the peak lower. Turn on VSS to get application-consistent points, and the behaviour flips. The changed blocks are held and shipped as one set when the guest is briefly idle, so the same daily churn arrives in tighter bursts. Application consistency is usually worth it, but you pay for it with a peakier traffic pattern, and a link sized on the smooth case will strain under the bursty one.
Compression is available and it helps, but the ratio depends entirely on the data. Already-compressed media, encrypted volumes, and dense database pages give you almost nothing. Do not fold an assumed compression ratio into the link size and call it done. Treat compression as headroom you might get, not capacity you can count on.
The delta stream is not what breaks sizing. Full syncs are. A host reboot, a stale checksum after a snapshot consolidation, or storage that moved a VMDK can force a full sync that ignores your careful average and tries to ship the entire disk. On that 89 Mbps link at 70% usable you get about 28 GB per hour of real throughput, so a single 2 TB VMDK full sync runs for roughly 73 hours. For three days that VM has no valid recovery point, and if two large VMs re-sync at once they share the same pipe and both slip. Sizing for the steady state is necessary. Capping how many full syncs can run at once is what saves you.
A worked example: 8 TB and a five minute RPO
Take a realistic estate: 8 TB protected, a target RPO of five minutes, and a measured daily change rate of about 5%. That is 400 GB of unique changed blocks per day after vSphere Replication has collapsed repeated writes. Watch what happens as you pick which slice of the day to size against.
Daily average: 400 GB across 24 hours is about 37 Mbps of payload. After the 70% haircut, that is a 53 Mbps link. Comfortable, and wrong.
Busy window: about 70% of the change, 280 GB, lands in the 10 working hours. That is 62 Mbps of payload, or an 89 Mbps link once you apply the haircut.
Afternoon spike: the single busiest two hour block carries roughly 64 GB, which is 32 GB per hour, about 71 Mbps of payload and a 102 Mbps link on its own.
Verdict: a 100 Mbps circuit looks 89% loaded on the window average and quietly tips past 100 during the afternoon block. Provision 200 Mbps, or shape and spread the traffic, and stop sizing to the 53 Mbps daily average.
None of this needs exotic math. The docs anchor it with their own figure: 2 GB of change in one hour is about 4.7 Mbps of theoretical transfer. Everything above is that same calculation applied to the hour that actually hurts. The reason the daily average is so seductive is that it is the number every calculator reports by default, and it is the number that looks fine right up until it does not.
| Daily change rate | Changed data / day | Daily-average link | Busy-window link | Circuit to buy |
|---|---|---|---|---|
| 2% | 160 GB | ~21 Mbps | ~36 Mbps | 50 Mbps |
| 5% | 400 GB | ~53 Mbps | ~89 Mbps | 100 to 200 Mbps |
| 10% | 800 GB | ~106 Mbps | ~178 Mbps | 200 Mbps or more |
Enhanced vSphere Replication changed the path, not the physics
If you are landing on VCF 9, you are on Enhanced vSphere Replication whether you chose it or not. It is now the default and only supported site to site configuration for VMs, and legacy replication is not supported past the 9.0.2.2 configuration. The change is real. Traffic now goes host to host through the hbr-agent service on port 32032 and bypasses the replication appliance. Load balancing distributes replicas across the target cluster and rebalances about every 30 minutes. Network encryption is required. With a VMware Live Recovery subscription the RPO floor drops to one minute, against five minutes on legacy SRM license keys, and Enhanced vSphere Replication scales toward its documented ceiling of 5,000 protected VMs by adding target hosts.
Every one of those is a target-side and control-plane improvement. None of them widens the circuit between your two sites. Load balancing means the receiving hosts share the work of writing replicas, so the target stops being the bottleneck. The WAN is untouched. Encryption adds a little CPU rather than much wire overhead. So the arithmetic from the worked example carries straight over. The one thing enhanced replication genuinely changes for sizing is that a lower RPO floor tempts you to set a lower RPO, and a lower RPO on the same churn means more frequent, smaller transfers that are less forgiving of a thin link.
| Property | Legacy vSphere Replication | Enhanced vSphere Replication |
|---|---|---|
| Minimum RPO | 5 minutes | 1 minute (with VLR subscription) |
| Supported scale | ~500 VMs at 5 min RPO | toward 5,000 VMs with added hosts |
| Data path | through the replication appliance | host to host, port 32032, appliance bypassed |
| Load balancing | none | automatic, rebalances ~every 30 min |
| Encryption | optional | required |
| WAN sizing method | churn within RPO over ~70% of link | unchanged, churn within RPO over ~70% of link |
The built in vSphere Replication calculator asks for an average change rate and returns a single number. Feed it your 24 hour average and it will hand you the 53 Mbps answer with a straight face. The number is correct. It is simply answering the question you asked instead of the one that matters. Ask it about the busy window instead, or run the churn number through the arithmetic yourself, and treat whatever the tool returns as a floor rather than the recommendation.
Measure real churn over at least a full business cycle, including month or quarter end, not a quiet week. Confirm what fraction of that churn lands in your busiest few hours, because that ratio, not the average, sets the link. Check whether VSS quiescing is on for the workloads that matter, since it makes traffic burstier. Verify the outgoing firewall for hbr-agent on port 32032 is open on every source and target host, or enhanced replication will not carry the traffic at all. Finally, confirm the circuit you were promised is the circuit you actually have under load, with a sustained test, not a speed check at 6 a.m.
The initial full sync of a large estate can saturate the WAN for hours or days and starve production traffic that shares the same circuit. Stage it. Sync in batches, throttle where you can, run the heavy copies outside business hours, and cap how many syncs run at once. A full sync that takes down the production link on day one is a self inflicted outage, not a DR project.
Size to the busy-window peak, then add 30 to 40% headroom on top. For the 8 TB example that means buying 200 Mbps, not 100. Cap concurrent full syncs so a re-sync storm cannot eat the whole link. Put replication on a shaped queue so it yields to production during the day if it has to. And set the RPO you commit to based on what the link holds at quarter close, not on the one minute floor the license now allows. I disagree with the common advice to take the calculator's number and the lowest RPO the product supports. An RPO you cannot sustain is worse than an honest one, because the false alarms train your team to ignore the console right before the day it is telling the truth.
Common objections
The vSphere Replication calculator already gave me a number, so why redo it?
Because it sizes on the average change rate you enter, and the average hides the busy window. Give it the peak-hours churn instead, or run the numbers by hand, and use the tool output as a lower bound. The calculator is a floor, not a plan.
Compression will cover the gap, right?
Sometimes, and never reliably. Ratios collapse on already-compressed, encrypted, or dense database data, which is exactly the data that tends to change most. Treat compression as a bonus that buys headroom, not as capacity you can subtract from the link size. A compressed stream still bursts hard during a full sync.
Enhanced replication load-balances, so bandwidth is handled.
Load balancing spreads the receive work across target hosts so the destination cluster keeps up. It does nothing to the WAN between sites. The circuit is still the ceiling, and the arithmetic for that circuit did not change when the data path moved host to host.
If it falls behind we will just raise the RPO.
An RPO you set only after the system has already missed it is worthless as a design target. Size for the peak first, then commit to an RPO you can hold when change rate is at its worst. Retreating on the recovery point mid-incident is the moment you least want to be negotiating with the business.
Where this leaves you
Sizing DR bandwidth for VCF 9 comes down to three honest inputs: the real churn, the busy window it lands in, and the 70% of the link you actually get to use. Get those right and the link holds the RPO you promised. Get lazy with any one of them and the console will let you know, usually on the afternoon you can least afford it. Next in the series we turn to the design mistakes that only surface during a real outage, several of which start with a link that was sized on an average. For the workloads and clusters feeding this replication, the VCF 9 Operations series and the broader VCF 9 series are worth a read. Bandwidth is the one DR number you cannot fake at 3 a.m.
« Previous: Part 11 | VMware Live Recovery Complete Guide | Next: Part 13 »
References
- Bandwidth Requirements for vSphere Replication 9.0.3 (Broadcom TechDocs)
- Calculate Bandwidth For vSphere Replication 9.0.3 (Broadcom TechDocs)
- Protecting VCF 9: Upgrade to Enhanced vSphere Replication (VCF blog)
About The Author
DrJha