Site-to-Site Bandwidth Calculator

Maybe you upgraded to a higher-speed internet circuit only to find out your VoIP calls still get garbled. It doesn’t make sense, but there is more to bandwidth than just bits per second, there are many kinds of traffic competing for bytes on the wire. When a company connects two sites, rarely does this mean there is simply a download pipe from one location to another. More likely, there are all sorts of voice packets that is sensitive to delay. There are also heavy backup job running during off hours and tunneling protocols adding weight to each packet that goes down the wire.

Before you size or buy a link, the capacity estimator above consider several factors. These include QoS reserve, tunnel overhead, replication, and compression. It also accounts for real-time streams, backups, and VPN user. The first thing most folks do is count heads: how many users are in each branch office? Multiply that times some generic per-user bandwidth number. That’s fine as a beginning but it doesn’t reflect busy-hour reality. Not all your users are going to hit the network at exactly the same instant… but you’ll still have enough to clog things up if you don’t account for concurrency.

How to Choose the Right Internet Speed

The tool lets you play with peak concurrency percent… Which models this reality: half your team might hop on a conference call, while somebody else starts a big file transfer. To avoid dropping any packets, you want some headroom to allow for these kinds of coincidences. But then there’s the cost of encryption, the secret cost. Encrypting your traffic adds extra work and headers to each packet. It’s not free space.

The table on the page lays it all out by showing how much additional bandwidth each kind of tunnel consume. Depending on your configuration, you could be adding ten percent overhead with a simple WireGuard setup and pushing closer to thirty-five percent with something like a nested IPsec plus GRE configuration. That can make the difference between a smooth connection and one where everything constanty hits the ceiling. When you size a circuit, don’t ignore the weight of the protocol. The ISP doesn’t see your plaintext data. They see the encrypted blob and they charge you for every bit of it.

The other wrinkle is backup traffic. If you’re not compressing and shaping your large nightly backups correctly, you can very easily swamp a link. By assuming this job runs over an eight-hour window, the calculator has forced you to consider if your existing bandwidth are enough to shift your daily deltas within this period. Compression helps at this stage, however, provided you have compressable data. Highly optimised media files or archives that are already encrypted won’t help you here. Which brings me back to my point about understanding your workload being more important than pursuing theoretical speeds. A twenty-megabit pipe may well feel speedy when surfing the web but attempt to push fifty gigabytes of raw database logs across it without compression and it’s going to feel like molasses.

In contrast, voice and video are something else altogether. These applications don’t require huge amounts of throughput, they absolutely can’t deals with latency spikes or jitter, though. That’s where the idea of reserving capacity for Quality of Service comes in. In other words, if your network gets busy, you want to know that critical traffic like this will still get through. With the calculator, you can set aside a reserve percentage to keep these streams protected from being buried by bulk data transfers. It may be a small thing but it will prevent the sort of laggy video meetings that make remote work feel like torture.

And lastly, think about how unbalanced most home or small business connections are. In site-to-site situations, upload speed is frequently the choke point, particularly if you’re replicating local data to a destination such as the cloud, or backing things up. Having lots of download capacity won’t help if your upload sucks. Don’t trust ISP marketing figures; test what you actualy get at peak usage times. Measure the real world, not the brochure.

A WAN link isn’t so much choosing a large number as it is finding a balance among conflicting needs. How long can you tolerate backup? How much should you pay for the circuit? How far away does your site has to be from the other end of the tunnel to get good performance? Does it need to support high throughput or low latency? Is the connection sensitive to jitter?

Strike the correct balance and the line will stand up to load. Miss the mark and you’ll be running out to upgrade your cable, only to continue chasing latency problems because the root cause was congestion. You would of wanted a network that seems fast while working hard.