Designing an MPLS VPN: bandwidth, QoS and node placement

The two most common reasons multi-site MPLS projects get reworked are undersized bandwidth and missing QoS. The first shows up as ERP timing out at peak hours; the second as everything stalling whenever a video call starts.

1. Bandwidth: the hub is the bottleneck

MPLS VPNs are usually hub-and-spoke: all branch traffic converges on headquarters. The hub access link must therefore carry the sum of concurrent branch peaks, not the average.

A working rule: hub bandwidth ≈ number of branches × per-branch bandwidth × 0.6 (concurrency factor). Ten branches at 10 Mbps each implies at least 60 Mbps at the hub. If branches need to reach each other, add capacity for the extra hairpinning through the hub.

2. QoS: three classes are enough

You do not need eight queues. Three classes usually suffice:

• Real-time (highest): VoIP and video conferencing. Low bandwidth but highly loss-sensitive; reserve 20%.
• Business (medium): ERP, OA, CRM. Reserve around 50%.
• Best effort (lowest): file sharing, OS updates, backups. Remaining capacity, throttled first under congestion.

The critical point: low-priority traffic must actually be suppressed under congestion. Many deployments fail because daytime backup jobs saturate the link and squeeze out ERP.

3. Node placement: near the branches

MPLS access node location determines each branch's access distance. If branches cluster in the Pearl River Delta, place nodes in Guangzhou or Shenzhen; for the Yangtze River Delta, Shanghai. Letting branches connect locally and using the carrier backbone to reach the hub is cheaper and more stable than long-haul direct connections.

4. Two things to decide at the same time

Routing: beyond roughly 20 branches, use BGP rather than static routes, otherwise every new branch requires changes on every device.

Backup links: a single MPLS link failing isolates a branch entirely. The usual pattern is broadband plus IPSec VPN per branch, switching automatically when the primary fails.

5. What acceptance should measure

Not just reachability. Measure round-trip latency and jitter per branch, whether QoS guarantees hold under congestion, failover time, and whether alarms actually reach someone.