SD-WAN and branch office bandwidth management
Consider a company with 40 branches. Each site has an MPLS circuit back to the data center, a broadband line for internet traffic, and an LTE link for backup. The SD-WAN controller decides, application by application, which link each flow should take. On paper, that keeps every site running well. In practice, the network team still needs answers that go beyond path selection, such as which applications are filling the broadband link at the Pune branch every afternoon, whether the MPLS circuits are oversized now that SaaS traffic goes direct to the internet, and which sites will need more capacity next year.
SD-WAN decides which path a flow takes. It doesn’t decide whether that path has enough capacity. If a policy sends SaaS traffic to the broadband link, the controller can keep steering flows there even when that link is saturated every afternoon, especially when the other paths are busy too or reserved for other traffic. Path selection redistributes the load across the links you have. Knowing whether those links are big enough still takes traffic data.
How SD-WAN changes bandwidth management
In a traditional hub-and-spoke WAN, branch traffic typically travelled over MPLS to the data center, so a few core routers saw nearly everything. SD-WAN changes that in three ways.
- Traffic takes more than one path. The same application can use MPLS in the morning and broadband in the afternoon, depending on link quality. Utilization has to be tracked per link, not per site.
- Branches break out to the internet locally. SaaS and web traffic often leaves directly from the branch instead of passing through the data center, so the core routers no longer see it.
- Overlay tunnels hide what's inside from the underlay. Routers and provider equipment along the path see only encrypted tunnels between edge devices, not the applications inside them. Application visibility therefore comes from the SD-WAN platform itself. Edge devices classify traffic before sending it into the overlay, and many current platforms report that application data through the controller’s own analytics or through flow exports from the edge, so a busy tunnel can still be broken down by application.
The result is that visibility has to come from the branch edge itself.
| Traditional MPLS WAN | SD-WAN | |
|---|---|---|
| Where branch traffic is visible | Data center and core routers | Each branch edge device |
| Paths per application | Usually one primary path, with backup paths on failure | Several, chosen dynamically |
| Internet traffic | Backhauled to the data center | Often sent directly from the branch |
| Provider QoS | Available on MPLS with a service contract | Public internet provides no equivalent end-to-end guarantee. |
| Main monitoring question | Is the circuit full? | Which link is carrying what, and is it the right one? |
What to monitor across WAN paths
Five measurements give a clear picture of how each branch is using its links.
- WAN utilization percentage per link: Measure it against the contracted rate, not the port speed. A branch with a 1 Gbps port on a 200 Mbps circuit that carries 150 Mbps is at 15% of the port but 75% of what it is paying for, and the second figure is the one that predicts congestion.
- Applications per link: Knowing that the broadband link is busy is only half the answer. Flow data shows whether that load is Microsoft 365, video calls, backups, or software updates, and whether it belongs on that link at all.
- Path quality: Latency, jitter, and packet loss decide whether voice and video work well on a given path. These metrics come from SLA probes and SD-WAN telemetry rather than from flow records.
- Backup link usage: Traffic on an LTE link that should be idle points to a failover event or a path selection rule that needs attention, and metered links can also add cost.
- Local internet breakout: Destination data for traffic leaving directly from the branch shows which cloud services each site depends on and how much capacity they take.
QoS still applies within each link, because SD-WAN chooses the path and QoS decides the order on it. For more on that,see what is QoS.
| Monitoring question | Best source of visibility |
|---|---|
| Which device or user is generating the traffic? | Flow data |
| Which application is it? | Flow data with application recognition, such as NBAR2 or AVC, or the SD-WAN platform’s own application classification |
| Which path is the traffic using? | SD-WAN controller telemetry combined with flow data |
| Is the path healthy, in terms of latency, jitter, and packet loss? | SLA probes and SD-WAN telemetry |
| Is the link close to its capacity? | Interface utilization from SNMP, with flow data to show what is filling it |
| Is the internet connection delivering the contracted speed? | Active speed and latency measurements at the site’s internet edge |
| Are QoS policies protecting the right traffic? | CBQoS counters per class |
Planning branch capacity for a hybrid WAN
Whether you are moving from MPLS to SD-WAN or adding new sites, the same four steps help size links correctly.
- Baseline before you change anything. Collect several weeks of per-site, per-application traffic data, including peak hours. This shows how much traffic will move to local internet breakout and how much still needs a private path back to the data center.
- Size each link separately. An SD-WAN design typically splits traffic between transports, so a branch might need a smaller MPLS circuit and a larger broadband line than it had before. Plan each link against the applications expected to use it.
- Use comparable sites as a model. A new branch has no history of its own. An existing site with a similar headcount and application mix gives a realistic starting estimate, which you can refine once the new site is live.
- Review after cutover. Path selection rules change where traffic goes. Compare post-migration utilization with the baseline to confirm each link is carrying the load it was sized for.
Report peaks rather than averages for each of these steps, because a link that averages well below capacity can still saturate at the same time every day.
Notes for common branch platforms
Before choosing a monitoring approach, check which flow format each branch platform exports and where it is enabled.
- Cisco Meraki: Meraki MX appliances can export NetFlow v9, which is enabled from the Meraki dashboard. NetFlow Analyzer monitors Meraki traffic using these NetFlow v9 records.
- Fortinet FortiGate: FortiGate firewalls can export NetFlow v9 and sFlow, so a branch that uses a FortiGate as its edge device can report traffic directly to a flow collector.
- HPE Aruba: Aruba switches support sFlow, and Aruba EdgeConnect SD-WAN appliances, formerly Silver Peak, support flow export as well. Confirm the format and version for your specific models in Aruba's documentation.
Where you enable flow export makes a difference, and the right point depends on the platform. The goal is to capture traffic while the original source, destination, and application are still visible. On interfaces where traffic has already been encrypted into the SD-WAN overlay, flow records may show only the tunnel endpoints between edge devices. Some platforms still report the original flows on WAN interfaces, though. Aruba EdgeConnect, for example, exports outbound WAN traffic by default. Check your platform’s documentation to see which interfaces and directions export the original flow details, and avoid enabling export on both the LAN and WAN sides for the same traffic, because the collector may then count it twice.
Where WAN optimization fits
WAN optimization reduces the amount of data that crosses a link, using techniques such as caching, compression, deduplication, and protocol acceleration. It can help when the same files cross a slow link repeatedly. It does little for traffic that is already compressed or encrypted, such as most video and SaaS traffic, and it adds appliances or software at every site.
Before investing in it, look at the application mix on your busiest links. If most of the load is encrypted SaaS or video, a different path, better prioritization, or a larger circuit may be the more effective answer. If you already run WAN optimization, compare the volume of optimized and unoptimized traffic on each link over the same period, so you can see whether the optimization is actually reducing load where it counts.
How NetFlow Analyzer helps with branch and SD-WAN bandwidth
ManageEngine NetFlow Analyzer collects flow data from branch edge devices and brings every site into one view.
- All sites in one console: Distributed monitoring collects flow data from many locations and reports on them centrally, and IP grouping lets you organize traffic by site or subnet.
- Applications per WAN link: Drill down from a busy branch interface to the applications, hosts, and conversations using it, including on Meraki MX appliances through NetFlow v9.
- Internet link quality per site: The Remote Collector, running as a NetSpeed Tracker, records upload speed, download speed, latency, and jitter at each branch's internet edge.
- Application or network delay: With the Remote Collector running as a Deep Packet Inspection engine, application response time and network response time appear side by side, which shows whether a slow branch application is a WAN problem.
- Service levels for voice and video: IP SLA reports track the performance of VoIP, WAN, and video traffic across Cisco devices.
- Planning ahead: Capacity planning and forecast reports show which links are trending toward their limits, and threshold alerts flag a link before it saturates.
For health and path metrics from SD-WAN controllers, such as tunnel status and per-path quality on Cisco, Meraki, Silver Peak, and VeloCloud platforms, ManageEngine OpManager adds SD-WAN monitoring, and NetFlow Analyzer is also available as an OpManager add-on.
See NetFlow Analyzer's bandwidth management features or learn more about site-to-site traffic monitoring. Download a free 30-day trial of NetFlow Analyzer to try these features hands-on.
Frequently asked questions
Should we keep MPLS after moving to SD-WAN?
It depends on what your traffic data shows. Applications that need provider-backed QoS or a private path, such as voice between sites or traffic to an on-premises data center, may still justify MPLS. If most traffic now goes to SaaS services through local breakout, a smaller circuit or broadband alone may be enough.