SD WAN Tutorial

Firstly, in this SD WAN tutorial, we will address how SD-WAN incorporates a level of abstraction into WAN, creating virtual WANs: WAN virtualization. Now imagine these virtual WANs individually holding a single application running over the WAN but consider them end-to-end instead of being in one location, i.e., on a server. The individual WAN runs to the cloud or enterprise location, having secure, isolated paths with different policies and topologies. Wide Area Network (WAN) virtualization is an emerging technology revolutionizing how networks are designed and managed.

It allows for decoupling the physical network infrastructure from the logical network, enabling the same physical infrastructure to be used for multiple logical networks. WAN virtualization enables organizations to utilize a single physical infrastructure to create multiple virtual networks, each with unique characteristics. WAN virtualization is a core requirement enabling SD-WAN.

• Highlighting SD-WAN

This SD-WAN tutorial will address the SD-WAN vendor’s approach to an underlay and an overlay, including the SD WAN requirements. The underlay consists of the physical or virtual infrastructure and the overlay network, the SD WAN overlay to which the applications are mapped. SD-WAN solutions are designed to provide secure, reliable, and high-performance connectivity across multiple locations and networks. Organizations can manage their network configurations, policies, and security infrastructure with SD-WAN.

In addition, SD-WAN solutions can be deployed over any type of existing WAN infrastructure, such as MPLS, Frame Relay, and more. SD-WAN offers enhanced security features like encryption, authentication, and access control. This ensures that data is secure and confidential and that only authorized users can access the network.

Before you proceed, you may find the following posts helpful for pre-information:

1. SD WAN Security 
2. WAN Monitoring

• A key point: Video on SD-WAN.

In the following video, we will address the basics of SD-WAN and the challenges of the existing WAN. We will also go through popular features of SD-WAN and integration points with, for example, SASE. SD-WAN has taken the concept of software-defined networking (within a local area network) and cloud orchestration and applied it to the WAN. There are, according to Gartner, four requirements for an SD-WAN:

1. First, it must be able to support multiple connection types.
2. Second, it should be able to perform dynamic path selection.
3. Third, it should be able to support VPNs and third-party services (such as firewalls).
4. Fourth, it must have a simple interface.

• SD WAN tutorial: Back to basics. SD WAN requirements with performance per overlay

As each application is in an isolated WAN overlay, we can assign different mechanisms independent of others to each overlay. Such different performance metrics and topologies can be set to each overlay. More importantly, all these can be given regardless of the underlying transport. The critical point is that each of these virtual WANs is entirely independent. SD-WAN solutions offer several benefits, such as greater flexibility in routing, improved scalability, and enhanced security. Additionally, SD-WAN solutions can help organizations reduce cyber-attack risks while providing end-to-end visibility into application performance and network traffic.

SD-WAN Tutorial and SD WAN Requirements: SD-WAN Is Not New

A key point to highlight before we get into the details of this SD-WAN tutorial is that the concepts of SD-WAN are not new and share concepts with the DMVPN phases.  We have had encryption, path control, and overlay networking for some time. However, the main benefit of SD-WAN is that it acts as an enabler to wrap these technologies together and present them to enterprises as a new integrated offering. We have WAN edge devices that forward traffic to other edge devices across a WAN via centralized control. This enables you to configure application-based policy forwarding and security rules across performance-graded WAN paths.

The SD-WAN Control and Data Plane

SD-WAN separates the control from the data plane functions, uses central control plane components to make intelligent decisions, and forwards these decisions to the data plane SD-WAN Edge routers. The control plane components provide the control plane for the SD-WAN network and instruct the data plane devices that consist of the SD-WAN Edge router instructions as to where to steer traffic.

The brains of the SD-WAN network are the SD-WAN control plane components with a fully holistic view that is end-to-end. This is compared to the traditional network where each device’s control plane functions are resident. For example, the data plane is where the simple forwarding occurs, and the control plane, which is separate from the data plane, sets up all the controls for the data plane to forward.

SD WAN tutorial: Removing intensive algorithms

SDN is about taking intensive network algorithms out of WAN edge router hardware and placing them into a central controller. Previously, in traditional networks, this was in individual hardware devices using control plane points in the data path. BGP-based networks attempted to use the same concepts with Route-Reflector (RR) designs. They moved route reflectors (RR) off the data plane, and these RRs were then used to compute the best-path algorithms. Route reflectors can be positioned anywhere in the network and do not have to sit on the data path.

With the controller-based approach that SD-WAN has, you are not embedding the control plane in the network. This allows you to centrally provision and pushes policy down any instructions to the data plane from a central location. This simplifies management and increases scale. SD-WAN can centralize control plane security and routing, resulting in data path fluidity. The data plane can flow based on the policy set by the control plane controller that is not in the data plane. The SD-WAN control plane handles routing and security decisions and passes the relevant information between the edge routers.

SD WAN Tutorial: Challenges With the WAN 

The traditional WAN comes with a lot of challenges. It creates a siloed management effect where different WAN links try to connect everything. Traditional WANs require extensive planning for the logistics of calling. In addition, trying to add a branch or remote location can be costly. Additional hardware purchases are required for each site.

Challenge: Visibility

Visibility plays a vital role in day-to-day monitoring, and alerting is crucial to understanding the ongoing operational impact of the WAN. In addition, visibility enables critical performance levels to be monitored as deployments are scaled out. This helps with proactive alerting, troubleshooting, and policy optimization. Unfortunately, the traditional WAN is known for its need for more visibility.

Challenge: Service Level Agreement (SLA)

A service level agreement (SLA) is a legally binding contract between the service provider and one or more clients that lays down the specific terms and agreements governing the duration of the service engagement. For example, a traditional WAN architecture may consist of private MPLS links with Internet or LTE link as backup. The SLAs within the MPLS service provider environment are usually broken down into bronze, silver, and gold main categories. However, these types of SLA only fit some geographies and should be fine-tuned per location and customer requirements. Therefore, these SLAs are very rigid.

Challenge: Static and lacking agility

The WAN’s capacity, reliability, analytics, and security parts should be available on demand. Yet the WAN infrastructure is very static. New sites and bandwidth upgrades require considerable processing time, and this WAN’s static nature prohibits agility. For today’s type of application and the agility required for business, the WAN is not agile enough, and nothing can be performed on the fly to meet business requirements. When it comes to network topologies, they can be depicted either physically or logically. Common topologies you may have seen include the Star, Mesh, Full, and Ring topologies.

Fixed topologies

In a physical world, these topologies are fixed and cannot be automatically changed. And the logical topologies can also be hindered by physical footprints. The traditional model of operation forces applications to fit into a specific network topology already built and designed. We see this a lot with MPLS/VPNs. The application needs to fit into a predefined topology. This can be changed with configurations such as adding and removing Route Targets, but this requires administrator intervention.

SD WAN tutorial: The old methods of routing protocols

With any SD WAN tutorial, we must address inconsistencies with traditional routing protocols. For example, routing protocols make forwarding decisions based on destination addresses, and these decisions are made on a hop-by-hop basis. As a result, the application can take paths limited to routing loop restrictions, meaning that the routing protocols will not take a path that could potentially result in a forwarding loop. Although this overcomes the routing loop problems, this limits the number of paths the application traffic can take.

The traditional WAN needs help enabling micro-segmentation. Micro-segmentation enhances network security by restricting hackers’ lateral movement in the event of a breach. As a result, it’s become increasingly widely deployed by enterprises over the last few years. It provides firms with improved control over east-west traffic and helps to keep applications running in the cloud or data center-type environments more secure.

Routing support often needs to be more consistent. For example, many traditional WAN vendors support both LAN and WAN side dynamic routing and virtual routing and forwarding (VRF) – some only on the WAN side. Then some only support static routing and other vendors don’t have any support for routing.

SD-WAN Tutorial: Challenges with BGP

The issue with BGP: Border Gateway Protocol (BGP) attributes

Border Gateway Protocol (BGP) is a gateway protocol that enables the internet to exchange routing information between autonomous systems (AS). As networks interact with each other, they need a way to communicate. This is accomplished through peering. BGP makes peering possible. Without it, networks would not be able to send and receive information from each other. However, it comes with some challenges.

A redundant WAN design requires a routing protocol, either dynamic or static, for practical traffic engineering and failover. This can be done in several ways. For example, for the Border Gateway Protocol (BGP), we can set BGP attributes such as the MED and Local Preference or the administrative distance on static routes. However, routing protocols require complex tuning to load balance between border edge devices.

Although these attributes allow granular policy control, they do not cover aspects relating to path performance, such as Round Trip Time (RTT), delay, and jitter. In addition, there has always been a problem with complex routing for the WAN. As a result, it’s tricky to configure Quality of Service (QOS) policies per-link basis and design WAN solutions to incorporate multiple failure scenarios.

Issues with BGP: Lack of performance awareness

Due to the lack of performance awareness, BGP may not choose the best-performing path. Therefore, we must ask ourselves whether BGP can route on the best versus the shortest path. 

Issues with BGP: The shortest path is not always the best path

The shortest path is not necessarily the best path. Initially, we didn’t have real-time voice and video traffic, which is highly sensitive to latency and jitter. We also assumed that all links were equal. This is not the case today, where we have a mix-and-match of connections, such as slow LTE and fast MPLS. Therefore, the shortest path is no longer effective. However, there are solutions on the market to enhance BGP, offering performance-based solutions for BGP-based networks. These could, for example, send out ICMP requests to monitor the network, then, based on the response, modify the BGP attributes such as AS prepending to influence the traffic flow. All this is done in an attempt to make BGP more performance-based. 

• BGP is not performance aware

However, we still need to avoid the fact that BGP needs to be made aware of capacity and performance. The common BGP attributes used for path selection are AS-Path length and multi-exit discriminators (MED). Unfortunately, these attributes do not correlate with the network or application’s performance.

Issues with BGP: AS-Path that misses critical performance metrics

When BGP receives multiple paths to the same destination with default configurations, it runs the best path algorithm to decide the best path to install in the IP routing table. Generally, this path selection is based on AS-Path, the number of ASs. However, AS-Path is not an efficient measure of end-to-end transit. It misses the entire network shape, which can result in long path selection or paths experiencing packet loss. Also, BGP changes paths only in reaction to changes in the policy or the set of available routes.

Issues with BGP: BGP and Active-Active deployments

Configuring BGP at the WAN edge requires the applications to fit into a previously defined network topology. We need something else for applications. BGP is hard to configure and manage when you want active-active or bandwidth aggregation. What options do you have when you want to steer sessions over multiple links dynamically?

Blackout detection only

BGP was not designed to address WAN transport brownouts caused by packet loss. Even with blackouts of complete link failure, the application recovery could take tens of seconds and even minutes to fully operational. Nowadays, we have more brownouts than blackouts. But the original design of BGP was to detect blackouts only. Brownouts can last anywhere from 10ms to 10 seconds, so it’s crucial to see the failure in a sub-second and re-route to a better path. WAN edge protocols must be combined with additional mechanisms, such as IP SLA and even enhanced object tracking, to provide resiliency. Unfortunately, these add to configuration complexity.

SD WAN Tutorial: Major Environmental Changes

The hybrid WAN, typically consisting of Internet and MPLS, was introduced to save costs and resilience. However, we have had three emerging factors – new application requirements, increased Internet use, and the adoption of public cloud services that have put traditional designs under pressure. We also have a lot of complexity at the branch. Many branch sites now include various appliances such as firewalls, intrusion prevention, Internet Protocol (IP) VPN concentrators, WAN path controllers, and WAN optimization controllers.

All these point solutions must be maintained and operated and provide the proper visibility that can be easily digested. Visibility is critical for the WAN. So how do you obtain visibility into application performance across a hybrid WAN and ensure that applications receive appropriate prioritization and are forwarded over a proper path?

The era of client-server  

The design for the WAN and branch sites was conceived in the client-server era. At that time, the WAN design satisfies the applications’ needs. Then applications and data resided behind the central firewall in the on-premises data center. Today, we are in a different space with hybrid IT and multi-cloud designs, making applications and data distribution. Data is now omnipresent. The type of WAN and branch originating in the client-server era was not designed with cloud applications. 

Hub and spoke designs.

The “hub and spoke” model was designed for client/server environments where almost all of an organization’s data and applications resided in the data center (i.e., the hub location) and were accessed by workers in branch locations (i.e., the spokes).  Internet traffic would enter the enterprise through a single ingress/egress point, typically into the data center, which would then pass through the hub and to the users in branch offices.

The birth of the cloud resulted in a significant shift in how we consume applications, traffic types, and network topology. There was a big push to the cloud, and almost everything was offered as a SaaS. In addition, the cloud era changed the traffic patterns as the traffic goes directly to the cloud from the branch site and doesn’t need to be backhauled to the on-premise data center.

Challenges with hub and spoke design.

The hub and spoke model needs to be updated. Because the model is centralized, day-to-day operations may be relatively inflexible, and changes at the hub, even in a single route, may have unexpected consequences throughout the network. It may be difficult or even impossible to handle occasional periods of high demand between two spokes. The result of the cloud acceleration meant that the best point of access is only sometimes in the central location. Why would branch sites direct all internet-bound traffic to the central HQ, causing traffic tromboning and adding to latency when it can go directly to the cloud? The hub and spoke design could be an efficient topology for cloud-based applications. 

Active/Active and Active/Passive

Historically, WANs are built on “active-passive,” where a branch can be connected using two or more links, but only the primary link is active and passing traffic. In this scenario, the backup connection only becomes active if the primary connection fails. While this might seem sensible, it could be more efficient. The interest in active-active has always been there, but it was challenging to configure and expensive to implement. In addition, active/active designs with traditional routing protocols are hard to design, inflexible, and a nightmare to troubleshoot.

Convergence and application performance problems can arise from active-active WAN edge designs. For example, active-active packets that reach the other end could be out-of-order packets due to each link propagating at different speeds. Also, the remote end has to reassemble, resulting in additional jitter and delay. Both high jitter and delay are bad for network performance. The issues arising from active-active are often known as spray and pray. It increases bandwidth but decreases goodput. Spraying packets down both links can result in 20% drops or packet reordering. There will also be firewall issues as they may see asymmetric routes.

• A key point: SD-WAN tutorial and SD WAN requirements and active-active paths.

For an active-active design, one must have application session awareness and a design that eliminates asymmetric routing. In addition, it would help if you slice up the WAN so application flows can work efficiently over either link. SD-WAN does this. Also, WAN designs can be active–standby, which requires routing protocol convergence in the event of primary link failure. Unfortunately, routing protocols are known to converge slowly. The emergence of SD-WAN technologies with multi-path capabilities combined with the ubiquity of broadband has made active-active highly attractive and something any business can deploy and manage quickly and easily.

SD-WAN solution enables the creation of virtual overlays that bond multiple underlay links. Virtual overlays would allow enterprises to classify and categorize applications based on their unique service level requirements and provide fast failover should an underlay link experience congestion or a brownout or outage.

There is traditional routing regardless of the mechanism used to speed up convergence and failure detection. These several convergence steps need to be carried out a ) Detecting the topology change, b ) Notifying the rest of the network about the change, c ) Calculating the new best path, d ) and e) Then switching to the new best path. Traditional WAN protocols route down one path and, by default, have no awareness of what’s happening at the application level. For this reason, there have been many attempts to enhance the WANs behavior. 

A keynote for this SD WAN tutorial: The issues with MPLS

MPLS has some great features but only suits some application profiles. As a result, it can introduce more points of failure than traditional internet transport. Its architecture is predefined and, in some cases, inflexible. For example, some Service Providers (SP) might only offer hub and spoke topologies, and others only offer a full mesh. Any changes to these predefined architectures will require manual intervention unless you have a very flexible MPLS service provider that allows you to do cool stuff with Route Targets.

SD-WAN Tutorial and Scenario: Old and rigid MPLS

I designed a headquarters site for a large enterprise during a recent consultancy. MPLS topologies, once provisioned, are challenging to change. MPLS topologies are similar to the brick foundation of a house. Once the foundation is laid, changing the original structure is easy by starting over. In its simplest form, we have Provider Edge (PE) and P ( Provider ) routers in an MPLS network. The P router configuration does not change based on customer requirements, but the PE router does 

We have several technologies, such as Route Target, to control routers in and out of PE routers. A PE router with matching route targets and configurable variables allows the routes to pass. This created the customer topologies such as a hub and spoke or full mesh. In addition, the Wide Area Network (WAN) I worked on was fully outsourced. As a result, any requests would require service provider intervention with additional design & provisioning activities. 

For example, mapping application subnets to new or existing RT may involve recent high-level design approval with additional configuration templates, which would have to be applied by provisioning teams. It was a lot of work for such a small task. But, unfortunately, it puts the brakes on agility and pushes lead times through the roof. 

BGP community tagging

While there are ways to overcome this with BGP community tagging and matching, which provides some flexibility, we must recognize that it remains a fixed, predefined configuration. As a result, all subsequent design changes may still require service provider intervention.

SD WAN Requirements

In the proceeding sections of this SD WAN tutorial, we will address the SD-WAN driver, which ranges from the need for flexible topologies to bandwidth-intensive applications.

SD-WAN tutorial and SD WAN requirements: Flexible topologies

For example, using DPI, we can have Voice over IP traffic go over MPLS. Here the SD-WAN will look at real-time protocol and session initiation protocol. We can also have less critical applications that can go to the Internet. MPLS can be used only for a specific app. As a result, the best-effort traffic is pinned to the Internet, and only critical apps get an SLA and go on the MPLS path. Now we have better utilization of the transports. And circuits never need to be dormant. With SD-WAN, we are using the B/W that you have available and ensure an optimized experience.

The SD-WAN’s value is that the solution tracks the network and path conditions in real time, revealing performance issues as they are happening. And then dynamically redirect data traffic to the following available path. Then when the network recovers to its normal state, the SD-WAN solution can redirect the traffic path of the data to its original location. Therefore the effects of network degradation, which come in the form of brownouts and soft failure, can be minimized.

SD-WAN tutorial and SD WAN requirements: Encryption key rotation

Data security has never been a more important consideration than it is today. Therefore, businesses and other organizations must take robust measures to keep data and information safely under lock and key. Encryption keys must get rotated regularly (every 90 days is the standard interval) to reduce the risk of compromised data security. However, regular VPN-based encryption key rotation can be complicated and disruptive, often requiring downtime. SD-WAN can offer automatic key rotation, allowing network administrators to pre-program rotations without manual intervention or system downtime.

SD-WAN tutorial and SD WAN requirements: Push to the cloud 

Another critical feature of SD-WAN technology is cloud breakout. This lets you connect branch office users to cloud-hosted applications directly and securely, eliminating the inefficiencies of backhauling cloud-destined traffic through the data center. Given the ever-growing importance of SaaS and IaaS services, efficient and reliable access to the cloud is crucial for many businesses and other organizations. By simplifying how branch traffic is routed, SD-WAN makes setting up breakouts quicker and easier.

The changing perimeter location

Users are no longer positioned in one location with corporate-owned static devices. Instead, they are dispersed; additional latency degrades application performance when connecting to central areas. Optimizations can be made to applications and network devices, but the only solution is to shorten the link by moving to cloud-based applications. There is a huge push and a rapid flux for cloud-based applications. Most are now moving away from on-premise in-house hosting to cloud-based management.

The ready-made global footprint enables the usage of SaaS-based platforms that negate the drawbacks of dispersed users tromboning to a central data center to access applications. Logically positioned cloud platforms are closer to the mobile user. In addition, cloud hosting these applications is far more efficient than making them available over the public Internet.

SD-WAN tutorial and SD WAN requirements: Decentralization of traffic

A lot of traffic is now decentralized from the central data center to remote branch sites. Many branches do not run high bandwidth-intensive applications. These types of branch sites are known as light edges. Despite the traffic change, the traditional branch sites rely on hub sites for most security and network services. The branch sites should connect to the cloud applications directly over the Internet without tromboning traffic to data centers for Internet access or security services. An option should exist to extend the security perimeter into the branch sites without requiring expensive onsite firewalls and IPS/IDS. SD-WAN builds a dynamic security fabric without the appliance sprawl of multiple security devices and vendors.

The ability to service chain traffic 

Also, service chaining. Service chaining through SD-WAN allows organizations to reroute their data traffic through one service or multiple services, including intrusion detection and prevention devices or cloud-based security services. It thereby enables firms to declutter their branch office networks. They can, after all, automate how particular types of traffic flows are handled and assemble connected network services into a single chain.

SD-WAN tutorial and SD WAN requirements: Bandwidth-intensive applications 

Exponential growth in demand for high-bandwidth applications such as multimedia in cellular networks has triggered the need to develop new technologies capable of providing the required high-bandwidth, reliable links in wireless environments. The biggest user of internet bandwidth is video streaming—more than half of total global traffic. The Cartesian study confirms historical trends reflecting consumer usage that remains highly asymmetric as video streaming remains the most popular.

Richer and hungry applications

Richer applications, multimedia traffic, and growth in the cloud application consumption model drive the need for additional bandwidth. Unfortunately, the congestion leads to packet drops, ultimately degrading application performance and user experience. SD-WAN offers flexible bandwidth allocation so that you don’t have to go through the hassle of manually allocating bandwidth for specific applications. Instead, SD-WAN allows you to classify applications and specify a particular service level requirement. This way, you can ensure your set-up is better equipped to run smoothly, minimizing the risk of glitchy and delayed performance on an audio conference call.

SD-WAN tutorial and SD WAN requirements: Organic growth 

We also have organic business growth, a big driver for additional bandwidth requirements. The challenge is that existing network infrastructures are static and need help to respond to this growth in a reasonable period adequately. The last mile of MPLS puts a lock on you, destroying agility. Circuit lead times impede the organization’s productivity and create an overall lag.

SD-WAN tutorial and SD WAN requirements: Costs 

A WAN solution should be simple. To serve the new era of applications, we need to increase the link capacity by buying more bandwidth. However, life is more complex. The WAN is an expensive part of the network, and employing link oversubscription to reduce the congestion is too costly. Bandwidth comes at a high cost to cater to new application requirements not met by the existing TDM-based MPLS architectures. At the same time, feature-rich MPLS comes at a high cost for relatively low bandwidth. You are going to need more bandwidth to beat latency.

On the more traditional side, MPLS and private ethernet lines (EPLs) can range in cost from $700 to $10,000 per month, depending on bandwidth size and distance of the link itself. Some enterprises must also account for redundancies at each site as uptime for higher-priority sites come into play. Cost becomes exponential when you have a large number of sites to deploy.

SD-WAN tutorial and SD-WAN requirements: Limitations of protocols 

We already mentioned some problems with routing protocols, but IPsec left to defaults raises challenges. IPSec architecture is point-to-point, not site-to-site. Therefore, it does not natively support redundant uplinks. Complex configurations and potentially additional protocols are required when sites have multiple uplinks to multiple providers. Left to its defaults, IPsec is not abstracted, and one session cannot be sent over various uplinks. This will cause challenges with transport failover and path selection. Secure tunnels should be torn up and down immediately, and new sites incorporated into a secure overlay without much delay or manual intervention.

SD-WANrequirements: Internet of Things (IoT) 

As millions of IoT devices come online, how do we further segment and secure this traffic without complicating the network design? There will be many dumb IoT devices that will require communication with the IoT platform in a remote location. Therefore will there be increased signaling traffic over the WAN?  Security and bandwidth consumption are vital issues concerning the introduction of IP-enabled objects. Although encryption is a great way to prevent hackers from accessing data, it is also one of the leading IoT security challenges.

These drives like the storage and processing capabilities found on a traditional computer. The result is increased attacks where hackers can easily manipulate the algorithms designed for protection. Also, Weak credentials and login details leave nearly all IoT devices vulnerable to password hacking and brute force. Any company that uses factory default credentials on its devices places its business, assets, customer, and valuable information at risk of being susceptible to a brute-force attack.

SD-WAN tutorial and SD WAN requirements: Visibility

Many service provider challenges include a need for more visibility into customer traffic. The lack of granular details of traffic profiles leads to expensive over-provision of bandwidth and link resilience. In addition, upgrades at both a packet and optical layer often need complete traffic visibility and justification. There are many networks out there that are left at half capacity just in case there is an unexpected spike in traffic. As a result, a lot of money is spent on link underutilization which should be spent on innovation. This link between underutilization and oversubscription is due to a need for more visibility.

• About
• Latest Posts

Matt Conran: The Visual Age

Public Speaker, Author and Consultant at Conran Insight

Matt Conran has more than 25 years of networking and security industry with entrepreneurial start-ups, government organizations, and others. He now focuses on public speaking, authoring content, consulting, and creating Elearning courses.

Latest posts by Matt Conran: The Visual Age (see all)

• Fortinet’s new FortiOS 7.4 enhances SASE - April 5, 2023
• Comcast SD-WAN Expansion to SMBs - April 4, 2023
• Cisco CloudLock - April 4, 2023