Thanks to SD-WAN, most enterprise networks now use more than one kind of connection to keep branch offices and data centers (and cloud applications) talking to each other. A combination of broadband, a cellular backup link, and a leased line can be brought up simultaneously at a single site. The problem is not the number of links available, but how to map traffic to a single link at a time.
That is exactly the challenge SD-WAN was designed to address. Unlike legacy WANs that require static configurations to route all traffic down a single path, SD-WANs constantly evaluate the state of every available connection and route traffic based on live performance rather than on a set of immutable, rarely revisited rules.
For readers interested in how does SD-WAN works for routing, a detailed explanation of the underlying architecture is available beyond the scope of this article.
Grasping the mechanics of this traffic management feature goes a long way toward explaining why SD-WAN has become such a staple of modern network design.
The Fundamental Architecture of Multi-link Management
SD-WAN separates the control plane from the data plane; the former decides where traffic is sent, while the latter carries it. Having a control plane and data plane separation allows a central controller to handle routing policies across the entire network, while edge devices at each location forward packets only according to these policies.
An SD-WAN appliance or virtual instance at each branch location continuously monitors all available connections. This monitoring, traditionally, keeps track of the latency, jitter and packet loss on every link by sending small test packets periodically. That data, in turn, keeps the platform constantly informed about the state of its connections: what is healthy and what has degraded.
This approach to managing traffic flow across a network has roots in earlier traffic engineering concepts. The MPLS traffic engineering requirements document, published by the IETF, laid out many of the foundational ideas around directing traffic intelligently across available network resources rather than relying purely on static, shortest-path routing.
How Traffic Classifications Happen and Where They Go
After an SD-WAN platform observes link performance, it needs to determine which traffic to use. And this is where application-aware routing comes in. It identifies what kind of traffic is flowing through it, such as whether it is a video call, file transfer, or just pretty much any web request, and then applies policies based on the sensitivity of that traffic to the capabilities of each candidate link.
For example, voice and video traffic is very sensitive to latency and jitter, so these are generally routed over the least latent connection available at any time. Since bulk data transfers or scheduled background traffic can deal with more variance, they tend to be diverted over options that are less than optimal, allowing capacity on high performers for the traffic that needs it most.
This classification occurs continuously, rather than at the start of a session. The platform can even shift voice traffic from one link to another during a user session, often without the user noticing anything is wrong when a voice connection suddenly experiences increased latency. Such dynamic behavior is among the most apparent differences between SD-WAN and previous older WAN architectures that required manual reconfiguration to adapt to changing conditions.
Load Balancing Across Available Links
But yes, for many SD-WAN deployments, there is also a way to shard traffic across multiple links when conditions warrant. It is useful if we want to load balance connections when a single connection does not have enough aggregate bandwidth for the full traffic but one or more combined will.
Depending on the traffic and the platform there are different types of load balancers. Some methods evenly distribute traffic across links that are up and running, while others weight shares based on each link’s bandwidth or current performance. The more sophisticated implementations can divide a single large data transfer into multiple pieces and send the data via different paths concurrently, with reassembly occurring at the receiving end.
This kind of multi-path awareness is not unique to SD-WAN, but the way it gets applied at the WAN edge, combined with continuous performance monitoring, is what makes it practical for everyday enterprise use rather than a specialized capability reserved for service providers. Maintaining this resilient multi-link behavior in practice requires careful attention to failover policies, since redundancy alone does not guarantee that traffic will actually use a backup path correctly when something goes wrong. The network redundancy failover lessons shared in this account of real-world outages illustrate how policy misconfigurations can prevent a healthy backup link from being used even when it is fully functional.
Failover and Resilience in Practice
SD-WAN platforms respond immediately, detecting a link failure more quickly than data showing performance degradation and rerouting impacted traffic to any remaining working connection. The time it takes to failover at this layer is dependent on how often the platform checks for link health, and how the configuration is set up to respond when a failure is detected.
Sub-second failover detection is used in some SD-WAN deployments, a capability that can maintain active sessions like voice calls without any perceptible interruption. Others use a slightly longer detection interval as a compromise against false positives, which would cause an otherwise temporary outlier in performance to erroneously trigger a failover.
These threshold configurations require a balance of response time to stability. A system that responds to every microsecond change in latency will end up endlessly moving traffic from one link to another, and that can also cause performance issues. If a platform is too slow to react, real disruptions may happen before failover.
The Importance of Centralized Visibility in Traffic Management
Without centralized visibility into what is taking place across the network, none of this traffic management takes place very efficiently. SD-WAN platforms usually include dashboards displaying the real-time status of every link at every site, and can be used to glean patterns over time (for example, a connection that only degrades predictably on certain hours of the day.)
The fact that you can see something also helps with capacity planning. If the administrators can see that a particular site is always pegging its primary link during certain hours, they will know if they need to add bandwidth or change routing policies, and that will be simpler than letting the problem become permanent.
In the end, SD-WAN’s power to manage traffic comes not only from continuous monitoring and intelligent classification but also the fact that a centralized policy applies across the board. It is not the case that one part does all the heavy lifting but rather that it is those pieces working together to provide a network that will route traffic across multiple links in such a way so as always favor performance and reliability over fixed, rigid paths.
Frequently Asked Questions
Are all links of equal type of connection for SD-WAN?
No. SD-WAN can run over multiple types of connections concurrently (such as broadband, fiber, cellular, and leased lines), applying the same monitoring and routing logic to each independently of the transport in use.
How fast will the SD-WAN solution pick up a lost link?
Depends, of course, on which platform (and configuration) you are using, but many error-coded SD-WAN deployments can detect a failure and immediately reroute critical traffic over an alternate path in < 1 second.
Is SD-WAN traffic management application-aware?
Yes. Application-aware routing policies are usually applied at the application level, meaning an administrator can set performance requirements for many classes of traffic down to the level of a specific application.
