Inefficiencies of Traditional WAN

In recent years, businesses are embracing digital transformation more rapidly than ever expected. Remote working and online meetings are now standards. Many applications are moved to the public cloud and many services are now available over the Internet. Companies want to reduce costs and manage their infrastructure more effectively. However, the traditional wide-area network (WAN) was designed to connect users at remote sites to applications hosted in the company's data center. Dedicated leased lines and MPLS circuits were used to provide secure and reliable connectivity to the DC. Although some applications are now in public clouds and the Internet, the traffic from the remote sites must come to the DC first and then be routed to the Public Cloud and back. This concept is visualized in figure 1. 

Traditional WAN architecture - Centralized Connectivity
Figure 1. Traditional WAN architecture - Centralized Connectivity

This WAN design no longer works well in a digital world where applications are out of the data center, and the users consuming those applications are using a diverse set of mobile devices. As businesses are rapidly adopting Software-as-a-service (SaaS) and Infrastructure-as-a-service (IaaS) models, it is pretty common to have ERP applications hosted in AWS, office applications such as Office 365 being used over the Internet, company-specific apps hosted in the HQ data center, and 3rd party applications hosted in another datacenter. In this scenario, the traditional WAN connectivity between the branches and the DC is not the most effective way to connect to all applications and creates the following inefficiencies:

  • Costs - Increased bandwidth demands are forcing companies to upgrade their private WAN circuits, which is expensive;
  • Higher Latency - Moving the traffic from remote sites to the DC and then to the Cloud increases the overall round-trip times;
  • Availability - Running everything through the company's data center creates a Single-point-of-failure;
  • Velocity - Deploying private MPLS circuits is a slow and tedious process that usually slows down the roll-out of new remote sites.

With the adoption of Public Cloud, companies started rethinking their WAN designs. Organizations decided to equip their remote site with Direct Internet Access links and to offload cloud-native applications directly over the Internet. Internet availability then becomes a very important part of the branch/campus operations.

But how do you make sure all remote sites have an Internet connection in 99.99% of the time? Well, the answer is - you purchase at least two independent Internet connections from at least two service providers. Combining this with the emergence of 4G/5G and having in mind that commodity internet circuits offer higher capacity at significantly lower price points, it is a natural consequence that companies started exploring ways to rely less on Private WAN and take advantage of the Internet circuits.

Software-Defined WAN architecture - Decentralized Connectivity
Figure 2. Software-Defined WAN architecture - Decentralized Connectivity

Software-defined WAN (SD-WAN) solutions have been designed to address these challenges. SD-WAN is part of the broader technology trend called software-defined networking (SDN). This is a new centralized approach to network management that abstracts the underlying network infrastructure away from the services and applications that run over the network. 

De-centralized Network Management

For many years, networks have been deployed and operated in a decentralized manner, meaning each device is individually managed and operated by network administrators. Let's compare this to a centralized approach. If I take you back to the old days of personal computers. Installing new hardware or software required users to configure the individual elements of the PC. For example, you bought a new sound card for your PC. You install the card and then you must go to the website of the manufacturer and download the drivers for your operating system. Then you install the drivers and resolve any incompatibility issues. And only then you start listening to music, eventually. 

Personal Computer as a System
Figure 3. Personal Computer as a System

Now compare this to the process nowadays. You just plug the hardware component you bought and the PC handles everything else for you. You just signify the intent to listen to music and the operating system configures all underlying components necessary to play the music. You are using a personal computer as one system and not as a group of individual components.

And the one million dollar question is - Why can't we apply this logic to IP Networks? Why the network can't be thought of and administered as a system instead of a collection of individual devices such as routers, switches, and firewalls?

    Using Traditional Networks
    Figure 4. Using Traditional Networks

    As of today, most networks in the world are still being operated and configured manually using traditional "per device" methods. Although many of us will agree that this device per device approach has many significant drawbacks such as:

    • Risk of human error - Many kinds of research have been made over the years that shows that most network outages happen because of a configuration error (ultimately a human error). 
    • Services velocity - Many network engineers would agree that the network is the slowest of all technology verticals when it comes to enabling a new feature or service. Configuring each network device one by one using CLI is just not a scalable approach. Don't get me wrong, we all love the command line, but it was not designed to make massive scale configuration changes to multiple devices at the same time. 
    • Analytics - In traditional networks, where devices are managed in a decentralized manner, almost no one knows the "big picture". In many cases, different devices are operated by different teams, and a centralized collection of analytic data and network-wide configuration sanity is a very hard task.

    Benefits of SD-WAN

    Many business and technical researchers agree that the next-generation networks would be deployed and operated As-a-System and not as a collection of individual network devices. Software-Defined WAN (SD-WAN) is a centralized approach to managing and operating large-scale WAN networks.

    Single Management Plane

    One of the main ideas of SD-WAN is to administrate the WAN through a single centralized management plane, and the system itself to manage the underlying network devices. This would provide many benefits, business opportunities, and a better overall user experience.

    Using Networks in an Intent-Based manner
    Figure 5. Using Networks in an Intent-Based manner

    Let's look at the most obvious advantages:

    • Automation - Operating and administrating a network as a system in a centralized manner removes most of the complexity of large-scale networks. The whole idea of centralized management is to use Automation. It creates simplified consistent deployment and operational models. 
    • Reduced cost - SD-WAN's automation allows leveraging any combination of transport services such as Broadband Internet circuits, 4G/5G, MPLS, and any other public transport – to securely connect users to applications.
    • Improved uptime - Centralized management and automation could eliminate most human errors such as misconfigurations, wrong designs, and deployments. This would significantly improve the overall uptime of the network.
    • More secure - Centrally managed networks can easily apply end-to-end security policy across the enterprise network which is very hard to do using the box-to-box approach.
    • Better analytics - To be honest, in traditional large-scale networks, very few people (often nobody) know and could grasp the big picture. Because of the high number of network devices and the large volume of analytics data, most of the time the data is very hard to read and interpret quickly. Treating a network as one system enables a single management console that presents data from multiple sources in a unified display. 

    Forwarding based on auxiliary information

    In traditional WAN networks, routers make forwarding decisions based on a limited set of information. Traditional routing protocols usually consider only the link bandwidth and link status. However, having multiple different WAN transport attached to a remote site and wanting to use them in an active-active manner requires a more complex routing forwarding process. I have read one of the best analogies of this in the Cisco book "Cisco SD-WAN Cloud scale architecture".

    Consider the analogy of traveling by car. Prior to the emergence of navigation software such as Google Maps, for the travel from New York to Boston, a paper road map was typically used to identify the best route. If there was road closure or delay along the route, the driver would be forced to find an alternative route based on limited information. This is the way WAN routers operate in a traditional WAN network. Each router makes its own autonomous decisions about how to route the packets, based on a limited view of the topology around it.

    Analogy between routing decisions and road navigation
    Figure 6. Analogy between routing decisions and road navigation

    Now compare this approach to today's road navigation with GPS. Navigation software such as Google Maps can help a driver to avoid road closures, accidents, travel delays, and inefficient routes. This is possible because the navigation software relies on satellites in the sky that have a real-time sophisticated view of the road network. With SD-WAN, edge routers can now rely on the centralized control/management plane for auxiliary information on how to forward the traffic. In the same way, as the GPS helps drivers avoid travel delays, SD-WAN helps routers avoid jitter, packet loss, and latency in the network.

    Cisco's SD-WAN solutions

    Cisco offers two different SD-WAN products through its acquisitions of Meraki and Viptela. Both products are full-fledged SD-WAN solutions and have several overlapping features. However, Cisco has made it clear that Meraki and Viptela are geared toward two different markets.

    • Meraki is designed for small and mid-sized companies that want simplicity and ease of use above everything else. Deploying the Meraki SD-WAN solution is easier than Viptela and if the organization does not have any specific niche requirements, it would definitely be the right choice.
    • Viptela has more advanced features available and requires a sophisticated network design and architecture. The product is designed for large-scale enterprise-level networks and has a high degree of customization.
    Cisco's SD-WAN solutions
    Figure 7. Cisco's SD-WAN solutions

    In this course, we are going to deep-dive into the Cisco Viptela SD-WAN and won't cover the Meraki product.