SD-WAN changes the WAN from a collection of independently configured branch routers into a centrally controlled overlay. Traditional WAN operations usually focused on static routing, MPLS reachability, per-device QoS, and manual failover logic. SD-WAN keeps the underlay links, but moves path selection, segmentation, application policy, and operational visibility into a controller-driven system.
The important shift is not only MPLS replacement. A real SD-WAN design can use MPLS, broadband internet, LTE, 5G, or other transports at the same time, then steer traffic based on application identity, SLA measurements, route preference, policy, and security requirements. Voice, SaaS, internet-bound traffic, inter-branch traffic, and data-center traffic do not need to follow the same path.

This also changes troubleshooting. You still need routing skills, because OSPF, BGP, route redistribution, VPN segmentation, and underlay reachability remain part of the design. The new work is proving whether the controller state, overlay routes, tunnel health, SLA probes, templates, certificates, and centralized policy all agree with the intended forwarding behavior.
Vendors use different names for similar ideas. Cisco Catalyst SD-WAN uses vManage, vBond, vSmart, WAN Edge, TLOCs, OMP, templates, and centralized or localized policies. Fortinet builds Secure SD-WAN around FortiGate, FortiManager, SD-WAN zones, performance SLAs, ADVPN, IPsec, and BGP. Versa uses vDirector, vAnalytics, vController, templates, tenants, forwarding profiles, SLA monitoring, and path policies. Palo Alto integrates SD-WAN into PAN-OS and Panorama using plugins, device groups, templates, tags, zones, VPN clusters, BGP, traffic distribution profiles, security policy, and reporting.
| Design area | Traditional WAN approach | SD-WAN operational model |
|---|
| Transport | MPLS often carries most critical traffic; internet links are secondary or used mainly for breakout. | MPLS, broadband, and wireless links can all participate in forwarding decisions. |
| Control | Each branch is configured and changed device by device. | Controllers, templates, and centralized policy push intent to many sites. |
| Routing | OSPF, BGP, static routing, and redistribution define reachability directly on routers or firewalls. | Underlay routing still exists, but overlay routing, tunnel state, and policy affect final forwarding. |
| Application handling | Traffic normally follows route metrics, policy-based routing, or QoS marking. | Application-aware routing can use measured loss, latency, jitter, SLA class, cost, and business policy. |
| Segmentation | VRFs, VLANs, ACLs, and firewall policy are designed per site or per domain. | Service VPNs, zones, tenants, templates, and central policies make segmentation repeatable at scale. |
| Security | Security is often inserted through data centers or separate firewall service paths. | Security can be integrated at the branch through firewall policy, DIA, service insertion, IPS, URL filtering, SIG, or vendor-specific NGFW features. |
| Troubleshooting | You inspect routing tables, interface counters, ACLs, QoS queues, and tunnel status on each node. | You also inspect controller reachability, certificates, overlay routes, SLA probes, templates, policy order, and tunnel health. |