Introduction to Cisco Software-Defined WAN (SD-WAN)
Shifting focus from a network-centric model to a business intent-based WAN network is a very powerful change. The WAN architecture can provide simplicity in terms of application deployment and management. However, the mindset must shift from a network topology focus to an application services topology. A common challenge for network operations staff is to support new and existing applications on the WAN. As mentioned previously in this chapter, these applications consume tremendous amounts of bandwidth and are very sensitive to variations in the quality of bandwidth that’s available. Things such as jitter, loss, and delay impact most applications, which makes it more important to improve the WAN environment for these applications. Furthermore, cloud-based applications such as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) are placing bandwidth demands on the WAN. Non-flexible connectivity options to keep up with the growing amount of cloud applications requiring bandwidth make it costly and difficult to provision new applications and services. Most businesses today have to rely on service providers for MPLS L3VPN to control their WAN routing and network SLAs. This impacts their ability to change and adapt to application delivery methods such as cloud and SaaS. Service providers could take months to implement the necessary changes to their environment in order to support these applications. In addition, some service providers will charge their customers a large amount of money to make these changes, and some may not make the changes at all. Because service providers currently have control of the WAN core, there’s no way to instantiate VPNs independent of the underlying transport. Because of this, implementing differentiated service levels for individual applications becomes extremely difficult, if not impossible.
This is why the concept of hybrid WAN was originated. Hybrid WAN is where additional non-MPLS links are acquired by businesses and added to the WAN to provide alternate paths that the applications can take across the WAN environment. These are circuits that businesses have complete control over—from routing control to application performance. Typically, VPN tunnels are created over the top of these circuits to provide secure transport over any type of link. Examples of these types of links are commodity broadband Internet, L2VPN, wireless, and 4G/LTE. This provides what is called transport independence. This allows for the capability to use any type of transport underneath the VPN and get deterministic routing and application performance. This means that some applications can be sent over these commodity links versus the traditional service provider–controlled L3VPN MPLS links. This provides unique granularity of traffic control, redundancy, and resiliency. Figure 1-5 illustrates some common hybrid WAN topologies.
FIGURE 1.5 Common Hybrid WAN Topologies
Hybrid WANs need connectivity that is based on a service topology and can be centrally managed using policies. Currently, WAN connectivity is based on the network topology and managed using a peer-to-peer model. This means routing relationships are established by multiple control planes that operate independently of each other. Routing protocols such as Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP) are used to establish site VPN routes, and IPsec is commonly used to secure the transport. These routing and security control planes run independently of each other and have their own scaling limitations, convergence requirements, and policy enforcement. This means each control plane is required to have its own independent policy and configuration. As a result, when a configuration change is required in the network, it has to be provisioned and propagated across all the control plane peers, for all transports, which creates operational pitfalls. This also creates the potential risk of misconfigurations or missing configuration that might cause applications to suffer.