For decades, WAN resilience has largely been built around a simple principle: provide a second path in case the first one fails.
A site might have a primary fibre, MPLS or carrier Ethernet service backed by another terrestrial circuit, mobile connectivity or, increasingly, satellite. If the primary service disappears, routing changes and traffic moves to the secondary connection.
It works. It is well understood. But it is increasingly an incomplete way of thinking about WAN resilience.
Software-Defined Wide Area Networking, or SD-WAN, changes the question from "Is the primary link available?" to something considerably more useful:
Which available path is best for this application, at this moment?
That distinction is more important than it first appears.
SD-WAN is often described as a better way of implementing WAN failover, but failover is only one part of the architecture. The bigger change is that network decisions can be based on application requirements, real-time path performance and centrally defined business policy rather than simply interface state and routing metrics.
For network architects designing distributed environments, particularly those containing remote or operationally critical sites, that changes what WAN resilience can look like.
Traditional redundancy is mostly concerned with failure
Consider a remote site with two WAN connections:
- a terrestrial carrier service as the primary connection
- a satellite service providing backup connectivity
A conventional design may monitor the terrestrial connection and switch to satellite when that service becomes unavailable.
Conceptually, the decision is straightforward:
Terrestrial available → use terrestrial
Terrestrial unavailable → use satellite
There is nothing inherently wrong with this architecture. The problem is that networks do not always fail cleanly.
A circuit can remain technically operational while its performance has deteriorated to the point where applications are barely usable.
Imagine a terrestrial WAN service reporting:
- interface: UP
- latency: 420 ms
- packet loss: 12%
- jitter: 180 ms
From a basic routing perspective, the path may still exist.
From the perspective of a voice call, virtual desktop session or interactive clinical application, the connection may effectively be broken.
This is commonly described as a brownout, as opposed to a complete network blackout.
Application-aware routing in SD-WAN platforms can continuously measure characteristics such as packet loss, latency and jitter across available paths. Cisco, for example, documents its Application-Aware Routing capability as using these measurements to select paths and detect both hard failures and degraded, or brownout, conditions.
This allows the network to respond to degradation rather than waiting for complete failure.
The question is no longer simply whether a path exists. The question becomes whether that path is currently good enough for the traffic being placed on it.
There may no longer be one best WAN path
Traditional IP routing is exceptionally good at answering a particular question:
What is the best route to this destination?
Routing protocols use information such as prefixes, metrics, path attributes, topology and administrative preference to reach that decision.
SD-WAN introduces another dimension.
Instead of selecting one preferred WAN path for everything, the network can potentially select different paths for different applications.
Consider a site with both terrestrial and satellite connectivity. A policy might specify that clinical systems prefer the terrestrial connection with satellite as an alternative, while voice uses whichever path currently offers acceptable latency and jitter. Collaboration traffic such as Teams or Webex could use the best-performing path, while backup traffic remains restricted to terrestrial connectivity.
Microsoft 365 traffic might use direct Internet access, while guest Internet traffic follows a separate breakout policy.
All of these decisions can exist simultaneously.
A backup system might continue using terrestrial connectivity while a voice application has already moved to satellite because the terrestrial path no longer meets its latency or packet-loss requirements.
This is a fundamental change in how the WAN can be treated.
MEF's standardised SD-WAN architecture describes the SD-WAN Edge as classifying packets into Application Flows, applying policy and selecting how those flows are forwarded across available underlay connectivity services.
The unit of decision is moving closer to the application rather than simply the circuit.
The underlay becomes interchangeable
Another important SD-WAN concept is the separation of the underlay from the overlay.
The underlay is the network actually carrying the packets. That could include:
- MPLS
- carrier Ethernet
- business Internet
- fibre
- 4G or 5G
- fixed wireless
- LEO satellite
- GEO satellite
SD-WAN creates an overlay across those underlying services.
MEF's SD-WAN framework accommodates multiple Underlay Connectivity Services and defines the SD-WAN service independently from the technology used to provide those underlying connections.
That abstraction matters.
Instead of designing the enterprise WAN entirely around the characteristics of one carrier network, architects can increasingly treat connectivity as a collection of available transports.
A remote location could potentially use terrestrial carrier connectivity, Internet and satellite, while a metropolitan office might use carrier Ethernet, business Internet and 5G.
The underlying technologies are different, but the SD-WAN overlay can present a common policy and operational model across both locations.
This makes physical diversity considerably easier to exploit.
A second terrestrial circuit may still share fibre routes, exchanges, power infrastructure or carrier backhaul with the first. A satellite service introduces a fundamentally different transport path and can therefore provide valuable diversity for locations where terrestrial infrastructure represents a common failure domain.
SD-WAN provides the intelligence needed to make better use of that diversity.
Active-active becomes more useful than primary and backup
WAN redundancy has traditionally been described using the terms primary and backup.
The backup circuit may spend almost its entire life doing very little.
SD-WAN makes an active-active model considerably more practical. Both connections can remain available to the SD-WAN fabric, with different traffic using each path according to policy and current conditions.
A terrestrial service might carry most corporate application traffic while Internet-bound SaaS traffic exits through another connection. Voice could use whichever path currently provides the lowest jitter, while bulk data transfers remain on the cheapest or highest-capacity service.
This means additional connectivity does not necessarily have to sit idle waiting for a disaster.
It can become part of the normal operating architecture.
Application-aware routing can then readjust those decisions when network conditions change and return traffic to preferred paths when conditions recover.
Resilience becomes dynamic rather than binary.
Some traffic can even be sent twice
One of the more interesting examples of what becomes possible with multiple active paths is packet duplication.
For selected traffic, some SD-WAN implementations can transmit copies of the same packet across separate overlay tunnels.
Conceptually:
Critical packet → terrestrial path
and simultaneously:
Critical packet → alternate path
If one copy is lost, the destination can still receive the copy travelling over the other path. If both arrive successfully, the unnecessary duplicate is discarded.
Cisco documents this capability in Catalyst SD-WAN, where duplicate packets can be transmitted simultaneously across another IPsec tunnel and redundant copies discarded by the receiving edge.
This comes with a bandwidth cost and would not normally be appropriate for every application.
For selected low-bandwidth, high-value traffic, however, it demonstrates something architecturally important.
Resilience no longer has to mean detecting failure and recovering afterwards.
Multiple paths can be used proactively to protect traffic before a failure occurs.
Policy begins to replace device-by-device configuration
The architectural change is not limited to forwarding.
Traditional WAN environments can involve large numbers of individually configured routers containing combinations of:
- BGP
- OSPF
- access control lists
- QoS
- VPN configuration
- policy-based routing
- interface configuration
- tracking objects
- failover logic
These technologies do not disappear with SD-WAN.
What changes is where much of the network intent is expressed.
Instead of thinking:
Configure Router 47 to prefer interface A unless condition B occurs.
the desired outcome can increasingly be expressed as policy:
- Voice should use a path meeting a defined SLA.
- Backup traffic must not consume satellite capacity.
- Critical applications should avoid paths experiencing packet loss above a defined threshold.
- Approved SaaS applications can use direct Internet breakout.
That policy can then be distributed through an SD-WAN controller or orchestrator rather than independently implemented at every location.
This is one of the most significant operational advantages of software-defined networking.
The network is increasingly being told what outcome is required, while the platform determines how that intent should be implemented across the available infrastructure.
Internet breakout challenges the traditional branch architecture
SD-WAN also arrived at an important point in the evolution of enterprise applications.
Traditional branch networking often assumed that most important resources lived inside corporate data centres.
Internet traffic from a branch might therefore travel:
Branch → corporate WAN → data centre → security stack → Internet
That architecture made considerable sense when applications were predominantly hosted inside the enterprise.
It becomes less intuitive when the destination is Microsoft 365, Salesforce, ServiceNow or another SaaS platform already sitting on the Internet.
Sending that traffic hundreds or thousands of kilometres through a corporate WAN simply so it can turn around and head back towards a cloud provider can introduce unnecessary latency and consume WAN capacity.
SD-WAN can support local Internet breakout, allowing selected application flows to access the Internet directly while corporate traffic continues through the enterprise WAN.
Internet Breakout is explicitly defined within MEF's SD-WAN service model as application flows forwarded directly to the Internet from an SD-WAN UNI rather than being delivered to another SD-WAN site.
That capability has also contributed to the convergence between networking and security architectures.
Once applications can leave the traditional corporate perimeter directly from distributed sites, organisations need security controls that can follow users and applications rather than relying entirely on a central data-centre security stack.
This is one of the architectural drivers behind the broader move towards Secure Access Service Edge (SASE).
Visibility becomes part of the routing decision
There is another subtle but important change.
Traditional network monitoring might tell an operations team:
Interface Gi0/1 is up.
Utilisation is 42%.
No interface errors detected.
Meanwhile, users at the site are reporting that Teams is unusable.
SD-WAN path monitoring can provide a much richer view:
WAN 1
Latency: 32 ms
Jitter: 4 ms
Loss: 0.1%WAN 2
Latency: 61 ms
Jitter: 11 ms
Loss: 0.4%Voice application
Preferred path: WAN 1
SLA: PASS
The same telemetry used to make forwarding decisions can therefore become operationally valuable.
Network operations teams can see not merely whether connectivity exists, but how individual paths are performing and why traffic is being directed in a particular way.
This closes part of the gap between network availability and application experience.
SD-WAN does not make bad architecture disappear
None of this means installing an SD-WAN appliance automatically creates a resilient network.
The underlying engineering principles remain.
Two WAN services using the same fibre conduit are still vulnerable to the same excavator. Two carrier services sharing the same exchange may still have a common failure domain. A terrestrial service and satellite service connected to the same unprotected power supply can still disappear together during a power failure.
An organisation also needs to consider the SD-WAN edge itself, LAN switching, firewalling, satellite terminals, antenna placement, DNS, authentication dependencies and upstream services.
There are also important questions around failover that should never be hidden behind the word "seamless":
- How quickly is a degraded path detected?
- Do existing TCP sessions survive?
- Does the public source IP change?
- What happens to NAT?
- Are overlay tunnels continuously established across both transports?
- What happens to voice calls already in progress?
- How does return traffic find the new path?
- What happens when the preferred connection returns?
SD-WAN provides sophisticated mechanisms for addressing many of these problems.
It does not remove the need to design them properly.
The standards are catching up with the architecture
SD-WAN is not itself a single networking protocol in the way that BGP or OSPF is.
Implementations vary between vendors, particularly around control planes, orchestration, application identification, tunnelling and security.
There is, however, an established industry service framework.
MEF 70.2, SD-WAN Service Attributes and Service Framework, defines the externally visible behaviour, key concepts and service attributes of a standardised SD-WAN service. It superseded MEF 70.1 and provides a common framework for describing the relationship between SD-WAN edges, application flows, overlay connectivity and the underlying WAN services.
This standardisation is important because the underlying architectural idea is deliberately transport-independent.
The value of SD-WAN comes partly from being able to place an intelligent overlay across networks that may have little in common underneath.
Beyond failover
The easiest way to understand SD-WAN is initially as intelligent WAN failover.
But that description quickly becomes inadequate.
Traditional redundancy asks:
Is my primary circuit still available?
SD-WAN can ask a much broader set of questions:
- Which paths are available?
- How well are they performing?
- What application is generating this traffic?
- What level of performance does that application require?
- Which path currently satisfies that requirement?
- What does organisational policy allow us to do with it?
The result is a WAN architecture that can react not only to outages but also to degradation; use multiple heterogeneous transports simultaneously; steer applications independently; exploit direct Internet connectivity; centralise network intent; and, in some implementations, protect important traffic across multiple paths at the same time.
The traditional WAN was largely built around circuits.
SD-WAN is increasingly built around applications.
The real change introduced by SD-WAN is not simply software-defined routing. It is changing the unit of decision from the circuit to the application.
No comments:
Post a Comment