This chapter covers the following topics:
Data Plane: This section discusses the physical and virtual routers that actually carry data traffic.
Management Plane: This section introduces the component that handles most of the day-to-day tasks in managing the Cisco Catalyst SD-WAN fabric.
Control Plane: This section covers the component that handles all policies and routing.
Orchestration Plane: This section introduces the component that facilitates discovery, authentication, and facilitation of the fabric.
Multi-tenancy Options: This section introduces the various multi-tenancy options available in Cisco Catalyst SD-WAN.
Deployment Options: This section covers the various deployment options, including Cisco cloud, private cloud, and on-premises deployments.
This chapter introduces the various components that make up the Cisco Catalyst SD-WAN architecture as well as the various deployment options. At a high level, these components can be grouped based on the purpose they play in Cisco Catalyst SD-WAN:
Data plane
Management plane
Control plane
Orchestration plane
In traditional networks, the management plane, data plane, and control plane are all on the same router, and together they facilitate communication within the network. A traditional router has network interfaces and line cards (which handle forwarding of data packets); this is a data plane. A CPU module, which handles calculating a routing table and advertising networks to the rest of the network, is a control plane, and the command-line interface (CLI) that is used to configure the router is a management plane. At the CLI, you type commands, and those commands program the CPU and line cards to act on your intent. Each router in a network has these three components.
A traditional network has a number of routers, each of which needs to be programmed independently to achieve the desired operational state of the network. As networks get larger, the amount of human intervention required to configure the environment dramatically increases, potentially creating complexity. Each router must calculate its own routing table from its perspective of the network. For example, suppose you have a network with 6000 routes. Whenever there is a change in the network, each router may potentially have to process routing updates for each of these routes. This means the router must have the available CPU and memory required to process these updates, and this creates a lot of overhead. Tuning the routing table on a network with a large number of sites and routes—whether the network is full mesh, hub and spoke, partial mesh, and so on—can quickly become very complex. In addition, because each router is programmed individually, when you program the network on a router-by-router basis, you run the risk of undesired results due to improper design or human error on the CLI.
Cisco Catalyst SD-WAN is a distributed architecture that provides a clear separation between the management plane, control plane, and data plane. Figure 2-1 illustrates how the components fit into the architecture.
)
Figure 2-1 Cisco Catalyst SD-WAN Distributed Architecture
The Cisco Catalyst SD-WAN distributed architecture differs from traditional network architectures in that it allows you to support large-scale networks while reducing operational and computational overhead. Catalyst SD-WAN separates the data plane, the control plane, and the management plane from each other.
Because the control plane knows about all routes and nodes on the network, you have to calculate the routing table only once and can distribute the information to all the necessary nodes as a single routing update rather than have every router send routing updates to the others, with each determining its own Routing Information Base (RIB). This greatly reduces the overhead on the network and enables you to reduce required resources on the routers so that you can bring additional features and capabilities to your edge devices. Because you have a complete view of the network, you can create a common network policy across the entire SD-WAN fabric—and the management plane needs to program it only once. As new devices are added to the network, they receive the same policy as well, ensuring that the network is operating as expected. This book shows how you can create various topologies and policies with ease while increasing scale and capability.
Data Plane
Traditionally, the data plane has been composed of the physical interfaces that the physical layer plugs into (for example, Ethernet, fiber, serial). As mentioned previously, this is analogous to the line cards on routers and switches. In Cisco Catalyst SD-WAN, the data plane consists of WAN Edge devices, which could be Cisco IOS XE SD-WAN routers or legacy Cisco vEdge routers. Data plane devices may be deployed at branches, data centers, large campuses, colocation facilities, or in the cloud. At each site, you can have a single WAN Edge router or multiple WAN Edge routers, depending on your redundancy requirements.
The data plane is where the SD-WAN overlay resides and is the layer that forwards user, server, and other network traffic. Both IPv4 and IPv6 are supported for transport within the data plane. In addition, data policies (such as QoS and Application-Aware Routing) are enforced within the data plane.
Each WAN Edge router forms data plane connections to other WAN Edge routers within the SD-WAN overlay for the purposes of transporting user traffic. Data plane connections are only established between data plane devices. These tunnels are typically secured via Internet Protocol Security (IPsec). As described previously, the data plane has native segmentation. The segmentation information is encapsulated as defined in RFC 4023 and is carried across the SD-WAN overlay. Segmentation allows the network administrator to build separate instances of the data plane, depending on business requirements and regulations. The original data packets are typically encapsulated with IPsec, providing encryption and authentication.
Cisco Catalyst SD-WAN supports GRE as another method of data encapsulation. GRE provides less overhead but lacks all the security that IPsec provides, and it is used less often. Throughout this book, you can assume that IPsec encapsulation is being used unless noted otherwise.
Figure 2-2 illustrates the Cisco Catalyst SD-WAN packet structure.
)
Figure 2-2 Cisco Catalyst SD-WAN Packet Format
Cisco Catalyst SD-WAN can support diverse topologies that are unique to each VPN segment or data plane instantiation. These VPN segments are completely isolated from communicating with each other unless policy explicitly allows communication. These VPNs are carried in a single IPsec tunnel. For example, corporate users could have a full-mesh topology, while PCI or HIPAA requirements could dictate the use of a hub-and-spoke topology for other devices. Figure 2-3 provides a graphical representation of this concept.
)
Figure 2-3 Segmentation and Per-VPN Topologies
On the LAN, or service, side, the data plane supports OSPF, EIGRP, RIPv2, and BGP for routing protocols. For smaller locations that don’t utilize a routing protocol, VRRP is supported to provide first-hop gateway redundancy.
WAN Edge routers have built-in security to prevent unauthorized access from the network. The WAN-facing interfaces only allow connections from authenticated SD-WAN fabric components, such as SD-WAN Manager (formerly vManage) and SD-WAN Controllers (formerly vSmarts) and from other WAN Edge devices in the fabric (as learned from SD-WAN Controllers). For the rest of the traffic, the WAN-facing interface firewall on the WAN Edge router, by default, will block everything coming in from the outside that isn’t allowed explicitly; this is also called an “implicit ACL.” By default, a WAN Edge router only allows inbound DHCP, DNS, ICMP, and HTTP services. Other inbound services that can be enabled are SSH, NETCONF, NTP, OSPF, BGP, SNMP, and STUN.
Bidirectional Forwarding Detection (BFD) is used inside IPsec tunnels between all WAN Edge routers. BFD sends Hello packets to measure link liveness as well as packet loss, jitter, and delay. Each WAN Edge router makes its own determination about how to react to this BFD information. Depending on the policy defined by the management plane, routing across the data plane could be adjusted, such as having applications prefer one transport over the other, depending on the transport performance. BFD operates in echo mode, which means the neighbor doesn’t actually participate in the processing of the BFD packet; instead, the BFD packet is simply echoed back to the original sender. This greatly reduces the impact on the CPU, as the neighbor doesn’t need to process the packets. However, if the neighbor was involved in the processing of the BFD packets, and the remote neighbor’s CPU were busy with some other processing, there could be potential delay in responding to the BFD packet. By eliminating this, you can reduce outage detection time and improve user experience. BFD cannot be turned off, but timers can be tuned in the SD-WAN fabric to identify and illicit a response to potential issues more quickly. Another advantage of using echo mode is that the original packet is echoed back to the original sender, and from this information, the WAN Edge router has a complete round-trip view of the transport.
When the WAN Edge router initially gets connected to the network and has no configuration present, it first tries to reach out to a Plug and Play (PNP) or Zero-Touch Provisioning (ZTP) server. Figure 2-4 provides a high-level overview of the PNP/ZTP process. This process will be discussed further in Chapter 4, “Onboarding and Provisioning,” but for now, you just need to know that this is the process in which the router connects to the orchestration plane, learns about all of the various components in the network, and receives its configuration. Once the control plane is established, the last step is to build data plane connections to all other WAN Edge routers. By default, a full-mesh topology will be built, though policy can be built to limit data plane connections and influence the routing topology. It should be noted, as well, that if PNP or ZTP isn’t available, there are other options available to manually bootstrap the configuration using the CLI or a USB thumb drive.
)
Figure 2-4 High-Level Overview of the PNP/ZTP Process
SD-WAN Supported Platforms
Cisco offers the wide selection of platforms and appliances so that you can deploy SD-WAN anywhere, as illustrated in Figure 2-5. With Cisco Catalyst SD-WAN, you can create a comprehensive fabric and scale your entire network into hybrid and multicloud environments with ease.
)
Figure 2-5 Cisco Catalyst SD-WAN Supported Platforms
In the ever-evolving landscape of networking, keeping up with product offerings can be challenging. At this writing, the leading Cisco Catalyst SD-WAN hardware platforms include Cisco Catalyst 8500, 8300, and 8200 Series Edge platforms, along with Cisco 1100 Series Integrated Services Routers (ISRs). Cisco Catalyst SD-WAN can also be deployed on SD-Branch solutions such as the Catalyst 8200 Series Edge uCPE and Cisco 5000 Enterprise Network Compute System (ENCS) using Network Functions Virtualization (NFV).
While Cisco Catalyst SD-WAN remains compatible with earlier hardware generations, like Cisco 4000 Series ISRs, Cisco Advanced Services Routers (ASRs), and original vEdge routers, it is important to note that these platforms are at different stages of their end-of-life lifecycle. Consequently, they are not recommended for new deployments.
A noteworthy feature of Cisco Catalyst SD-WAN is its seamless integration with public cloud environments, made possible through the Cisco Catalyst 8000V Edge Software and the legacy Cloud Services Router 1000V Series virtual platforms. Deployments in Amazon Web Services, Google Cloud, and Microsoft Azure are supported, offering flexibility and scalability. Virtual platforms can also be deployed in private clouds, running on either VMware ESXi or KVM hypervisors.
When deciding on WAN Edge platform, it’s crucial to assess your specific requirements, including deployment type (physical or virtual), throughput needs, data plane tunnel scalability (such as the number of branches the router will communicate with), and the required interface types.
Some of the most important features supported on Cisco Catalyst SD-WAN routers are for advanced security use cases. While accessing the Internet directly via a local Internet circuit might pose security risks at the branch, overlaying security on top of Cisco Catalyst SD-WAN enables safe implementation of new use cases such as Direct Internet Access (DIA) and Direct Cloud Access (DCA).
Direct Internet Access allows certain Internet-bound traffic (for example, Facebook traffic, YouTube traffic) to be forwarded from the branch directly to the Internet instead of being backhauled to data center via SD-WAN fabric. Direct Cloud Access enables cloud traffic (for example, Office365 traffic, Salesforce traffic, Box traffic, Google traffic) to be sent from the branch directly to the Internet or, optionally, backhauled to data centers based on path performance. Figure 2-6 illustrates these concepts.
)
Figure 2-6 Direct Internet Access/Direct Cloud Access Overview
Security use cases are discussed in more detail in Chapter 11, “Cisco Catalyst SD-WAN Security,” but here is a list of some of the currently supported security features:
DNS security (Cisco Umbrella)
Secure Internet Gateways (SIGs) and Cisco Secure Access integration
Cisco Enterprise Firewall with Application Awareness
Intrusion Prevention Systems (IPSs)
URL Filtering
Cisco Advanced Malware Protection
SSL/TLS Proxy for Decryption of TLS Traffic
Traditionally, security requirements dictated centralization of the Internet access where all Internet traffic is backhauled to data centers, colocation, or regional sites. It was cost-effective to implement security at a central location rather than deal with the management and costs of disparate security components across many sites. With Cisco Catalyst SD-WAN security, businesses can now decentralize security functions, moving them to the branch level. This movement allows organizations to offload Internet access at remote sites. Here are some other areas where a business might see benefits from DIA:
Reduced bandwidth requirements and latency on costly WAN circuits
Guest access
Improved user experience to cloud SaaS and IaaS applications
Chapter 8, “Centralized Data Policies,” discusses DIA in more detail.
When a WAN Edge router joins the fabric, it attempts to build control connections to SD-WAN Control Components across each transport deployed at that site. By default, if a transport doesn’t have control connectivity to any of the SD-WAN Control Components, then it won’t build a data plane connection across that transport either. This may be the case with cloud deployments where the controllers are in a public cloud and MPLS transport has no connectivity to the Internet.