Transition: 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.

Push to the Cloud:

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 traffic patterns, as traffic goes directly to the cloud from the branch site and doesn’t need to be backhauled to the on-premise data center.

**Challenge: 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 means that the best access point 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.

Interest in active-active routing protocols has always existed, but it was challenging to configure and expensive to implement. In addition, active/active designs with traditional routing protocols are complex to design, inflexible, and a nightmare to troubleshoot.

Convergence & Application Performance:

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.

Packet reordering:

The issues arising from active-active are often known as spray and pray. It increases bandwidth but decreases good output. 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.

Key SD-WAN Requirements 

1: SD-WAN requirement and active-active paths

For an active-active design, one must know the application session and 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.

Routing Protocol Convergence

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, a brownout, or an outage.

Example: BFD improving convergence

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, and

d) 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 Wan’s behavior. 

2: 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 better utilize the transports, and circuits never need to be dormant. With SD-WAN, we are using the B/W that you have available to ensure an optimized experience.

The SD-WAN’s value is that the solution tracks network and path conditions in real time, revealing performance issues as they occur. Then, it dynamically redirects data traffic to the following available path.

Then, when the network recovers to its normal state, the SD-WAN solution can redirect the data’s traffic path to its original location. Therefore, the effects of network degradation, such as brownouts and soft failure, can be minimized.

3: 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 be rotated regularly (the standard interval is every 90 days) 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.

4: 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. Applications and network devices can be optimized, 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.

**SaaS-based Applications**

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, hosting these applications on the cloud is far more efficient than making them available over the public Internet.

5: 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.

After all, they can automate handling particular types of traffic flows and assemble connected network services into a single chain.

6: 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. Video streaming is the biggest user of internet bandwidth—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 you don’t manually allocate 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.

7: 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 adequately to this growth in a reasonable period. The last mile of MPLS locks you in, destroying agility. Circuit lead times impede the organization’s productivity and create an overall lag.

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 is expensive to cater to new application requirements not met by the existing TDM-based MPLS architectures. At the same time, feature-rich MPLS is expensive for relatively low bandwidth. You will 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 comes into play. Cost becomes exponential when you have a large number of sites to deploy.

8: SD-WAN requirements: Limitations of protocols 

We already mentioned some problems with routing protocols, but leaving IPsec to default 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 should be incorporated into a secure overlay without much delay or manual intervention.

9: SD-WAN requirements: 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? Many dumb IoT devices 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, customers, and valuable information at risk of being susceptible to a brute-force attack.

10: SD-WAN requirements: Visibility

Many service provider challenges include the 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 the packet and optical layers often need complete traffic visibility and justification.

In case of an unexpected traffic spike, many networks are left at half capacity. As a result, much 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.

**SD-WAN Use Case**

DMVPN: Exploring Single Hub Dual Cloud Architecture

Single Hub Dual Cloud architecture takes the traditional DMVPN setup to the next level. Instead of relying on a single cloud (service provider) for connectivity, this configuration utilizes two separate clouds, providing redundancy and improved performance. The hub device is the central point of contact for all remote sites, ensuring seamless communication between them.

1. Enhanced Redundancy: The Single Hub Dual Cloud configuration offers built-in redundancy with two separate clouds. If one cloud experiences downtime or connectivity issues, the network seamlessly switches to the alternate cloud, ensuring uninterrupted communication.

2. Improved Performance: By distributing the load across two clouds, Single Hub Dual Cloud architecture can handle higher traffic volumes efficiently. This leads to improved network performance and reduced latency for end-users.

3. Scalability: This architecture allows for easy scalability as new sites can be seamlessly added to the network without disrupting the existing infrastructure. The hub device manages the routing and connectivity, simplifying network management and reducing administrative overhead.