博馬娛樂城

博馬娛樂城

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.

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.

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.

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.

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.

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.

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.

Management Plane

As mentioned previously, network devices of the past were managed individually via the CLI. Cisco Catalyst SD-WAN, however, introduces SD-WAN Manager (formerly vManage), which is a network management system (NMS) that provides a single pane of glass to manage Catalyst SD-WAN. SD-WAN Manager can be used for device onboarding, provisioning, policy creation, software management, troubleshooting, and monitoring.

While SD-WAN Manager offers a rich feature set, if the preference is to interface with it programmatically, SD-WAN Manager also supports communication via REST APIs. In fact, the SD-WAN Manager GUI is fully API driven, meaning that actions performed in it are executed using REST API calls. With full access to SD-WAN APIs, users can automate tasks, build scripts, and interface with SD-WAN Manager programmatically.

As you can see in Figure 2-7, SD-WAN Manager provides an intuitive and easy-to-consume dashboard. When you first log in to SD-WAN Manager, you are presented with an overview of the current state of the network.

vManage deployment options range from standalone nodes to three- or six-node clustered setups, offering enhanced scale and redundancy. A single SD-WAN Manager can potentially handle up to 1000 to 1500 devices, and a six-node SD-WAN Manager cluster may support more than 10,000 devices. It’s important to note that these numbers may vary based on a number of factors, such as SD-WAN Manager resources (instances/CPU/RAM/storage), the statistics load, and the version of SD-WAN software in use. (Numbers mentioned in this chapter are specific to Version 20.12.) For more accurate specifications, please consult the “Recommended Computing Resources for Cisco Catalyst SD-WAN Control Components” document for the SD-WAN software version you are using or are planning to use, available on the Cisco website.

An SD-WAN Manager cluster is designed to tolerate the failure of a single server, but for high availability, a standby cluster should be implemented to handle a complete cluster failure. Typically, it is deployed in a geographically redundant location, such as a secondary data center in another region.

SD-WAN Manager can use multiple authentication sources, including RADIUS, TACACS, and SAML 2.0, for external user connectivity. By default, SD-WAN Manager is deployed in a single-tenant mode; however, if the requirements call for support of a service provider model, multi-tenancy may be used.

All configuration for the SD-WAN fabric should be performed via SD-WAN Manager in order to maintain consistency and scalability. As discussed further in Chapter 4, you can build device configurations in SD-WAN Manager via configuration groups, feature templates, or CLI templates. You can also configure policies to control things such as network topology, routing, QoS, and security in SD-WAN Manager. SD-WAN Manager is also where you perform troubleshooting and monitoring of the network. Network administrators can simulate traffic flows to show data paths, troubleshoot WAN impairment, analyze traffic flows in the network with Network-Wide Path Insights (NWPI), and access real-time operational information (such as routing tables) for all network devices. This greatly simplifies operations as there is no longer a need to log in to each WAN Edge router individually. Instead, troubleshooting can be accomplished via a single dashboard.

Each WAN Edge router forms a single management plane connection to SD-WAN Manager. If a device has multiple transports available, only one will be used for management plane connectivity to SD-WAN Manager. If a cluster is in place, the control connection will be load balanced across cluster nodes. If a transport hosting the management plane connection experiences an outage, the WAN Edge router will briefly lose connectivity to SD-WAN Manager, and any changes made will be pushed when the device reconnects.

The last component in the management plane is SD-WAN Analytics (formerly vAnalytics). As shown in Figure 2-8, SD-WAN Analytics gives the network administrator predictive analytics to provide actionable insight into the WAN. With SD-WAN Analytics, the business can perform trending and capacity planning of circuits, and it can review how application performance is trending globally. With capacity planning, you can see how new applications may interact on your WAN before actually deploying them, allowing your business to right-size connectivity. SD-WAN Analytics ingests data from the network and uses machine learning to predict capacity trends. SD-WAN Analytics is cloud based, it requires additional licensing, and it is not enabled by default.

Control Plane

Previously, you learned how the control plane has traditionally been separated from the data plane. SD-WAN Controller (vSmart) is the component that provides control plane functionality and is the brain of the SD-WAN fabric. It is highly scalable and can handle up to 5000 control connections per instance, with up to 12 SD-WAN Controllers in a single production deployment (as of SD-WAN Version 20.12). With these numbers, a deployment can support very large SD-WAN networks.

SD-WAN Controller is responsible for the implementation of control plane policies, centralized data polices, service chaining, and VPN topologies. It also handles key management, which is an important part in the security and encryption of the fabric.

Separating the control plane from the data and management planes allows a solution to achieve greater scale while simplifying network operations. With Cisco Catalyst SD-WAN, all SD-WAN Controllers learn all the routing information. Then they calculate the routing table and distribute it to the WAN Edge routers, taking into consideration applicable centralized control policies.

A WAN Edge router can connect to multiple SD-WAN Controllers at a time but needs connectivity to only one to get its routing and policy information.

The protocol that SD-WAN Controllers use to communicate all this information is called Overlay Management Protocol (OMP). Although OMP handles routing, it would be a disservice to consider it simply a routing protocol. OMP is used to manage and control the overlay beyond just routing (key management, configuration updates, and so on). As illustrated in Figure 2-9, OMP runs between SD-WAN Controller and WAN Edge routers inside a secured tunnel. When a policy is built via the management plane, it is distributed to SD-WAN Controller via NETCONF, and SD-WAN Controller then distributes this policy via an OMP update to WAN Edge routers.

SD-WAN Controller operates similarly to a BGP route reflector in iBGP. It receives routing information from each WAN Edge router and can apply policies before advertising this information back out to other WAN Edge routers. One example of these policies is the creation of distinct per-VPN topologies. To achieve it, the control policy is defined in SD-WAN Manager, which then distributes the policy through the management plane. Then, SD-WAN Controller applies the policy to the fabric. In this example, topology modification is achieved by manipulating what routes get distributed and how the data plane is built between WAN Edge routers.

The control plane also plays an important role in the encryption of the fabric. In legacy WAN technologies, securing the network required a considerable amount of processing power, as each device would compute its own encryption keys per peer and distribute those keys to peers by using a protocol such as ISAKMP/IKE. For more efficient scaling in Cisco SD-WAN networks, key exchange and distribution have been moved to the SD-WAN Controller, and no IKE is implemented since identity has already been established between the WAN Edge routers and SD-WAN Control Components. Each WAN Edge router computes its own set of keys per transport and sends them to SD-WAN Controllers. SD-WAN Controllers then distribute them to each WAN Edge router, according to the defined policy. This process repeats when IPsec security associations (SAs) expire and new keys are generated. By moving the key exchange to a centralized location, you achieve greater scale as each WAN Edge router doesn’t need to handle key negotiation or distribution. (Refer to Figure 2-9 for an overview of how the control and data planes are built.) Chapter 3, “Control Plane and Data Plane Operations,” covers this in more detail.

If control connectivity has been established but has been lost due to an outage, data plane connectivity continues to work. By default, WAN Edge routers continue forwarding data plane traffic in the absence of control plane connectivity for up to 12 hours, utilizing the last-known state of the routing table, although this is configurable, depending on your requirements. When control plane connectivity is reestablished, WAN Edge routers are updated with any policy changes that were made during the outage. When the control connection is restored, the routing table is refreshed, and any stale routes are flushed.

For redundancy, it is the best practice to deploy at least two geographically dispersed SD-WAN Controllers. They should have identical policy configuration to ensure network stability. If these configurations differ, there’s a risk of suboptimal routing and potential blackholing of traffic. SD-WAN Controllers maintain a full mesh of OMP sessions among themselves and exchange control and routing information, although each operates autonomously (that is, there is no database synchronized between them).

Figure 2-10 shows how OMP is established between multiple SD-WAN Controllers and WAN Edge routers. SD-WAN Controllers form a full mesh among themselves, which ensures that they stay synchronized. WAN Edge routers establish one OMP session to each of two (by default) SD-WAN Controllers, but they do not create OMP sessions with each other. When there are more than two SD-WAN Controllers in the network, their selection is based on an algorithm to ensure that load balancing occurs. In the event of the total failure of an SD-WAN Controller, the sessions are redistributed between the remaining SD-WAN Controllers to maintain network continuity and stability.

By default, each WAN Edge router establishes multiple secure control connections, one over each available transport, to each selected SD-WAN Controller. However, only one OMP session is established between the WAN Edge device and each SD-WAN Controller, using one of those control connections as a transport.

Orchestration Plane

The final, and probably the most important, component in Cisco Catalyst SD-WAN is SD-WAN Validator (formerly vBond). This component is very important because it provides initial authentication for participation in the fabric and acts as the glue that discovers and brings together all other components. Multiple SD-WAN Validator instances can be deployed to achieve high availability. Since a WAN Edge router can point to only a single SD-WAN Validator, it is recommended to configure WAN Edge routers to use a DNS name that has a single A record pointing to the IP addresses of all SD-WAN Validators. When the WAN Edge router tries to resolve the DNS record for the SD-WAN Validator, the DNS server provides multiple IP addresses for the hostname, and the WAN Edge router tries to connect to each of them sequentially until a successful control connection is made.

When a WAN Edge router first joins the overlay, the only thing it knows about the SD-WAN network is the IP address or DNS name of the SD-WAN Validator. It receives this information via one of these methods:

• PNP/ZTP

• Bootstrap configuration

• Manual configuration

The WAN Edge router attempts to build a temporary connection to the SD-WAN Validator over each transport. Once the control plane connectivity is up to SD-WAN Controller and SD-WAN Manager, the connection to the SD-WAN Validator is torn down. When the WAN Edge router connects to the SD-WAN Validator, they both go through an authentication process in which each component authenticates the other and, if successful, a Datagram Transport Layer Security (DTLS) tunnel is established. The SD-WAN Validator then distributes the connectivity information for the SD-WAN Controller and SD-WAN Manager to the WAN Edge router. You can see why the SD-WAN Validator is referred to as the glue of the network: It tells all the components about each other. (This process is discussed in more detail in Chapters 3 and 4.)

One remaining functionality that the SD-WAN Validator provides is NAT traversal. By default, the SD-WAN Validator operates as a STUN server (RFC 5389). A WAN Edge router operates as a STUN client. What this means is that the SD-WAN Validator can detect when WAN Edge routers are behind a NAT device such as a firewall. When a WAN Edge router goes to establish its DTLS tunnel, the interface IP address it knows about is written into the outer IP header and noted within a payload of the message. When SD-WAN Validator receives this information, it compares the two values. If they are different, it can be inferred that NAT is in the transit path of the WAN Edge router (since the outer IP header was changed to a NAT IP address and no longer matches the IP address noted in the payload of the packet). The SD-WAN Validator communicates this back to the WAN Edge router, and the WAN Edge router can communicate this information to the rest of the overlay components—ultimately allowing data plane connectivity to be established through a NAT device. There are, however, some scenarios where this won’t work, such as with symmetric NAT (as discussed in more detail in Chapters 3 and 4). Figure 2-11 explains how STUN is used to detect when a WAN Edge router or another SD-WAN Control Component is subject to NAT.

When deploying an SD-WAN Validator, one special consideration is that it must be reachable directly from all transports with enabled control connectivity. This implies that SD-WAN Validator needs a public IP address (or a private IP address with 1:1 static NAT) when Internet transports are used in SD-WAN fabric.

Other SD-WAN Control Components (including SD-WAN Managers and SD-WAN Controllers) can use private IP addresses as long as they have connectivity to SD-WAN Validator since they use the same NAT discovery method (STUN) as the WAN Edge routers.

Multi-tenancy Options

Cisco Catalyst SD-WAN supports multiple modes of segmentation in the control, data, management, and orchestration planes, as shown in Figure 2-12. One mode is dedicated tenancy. In this mode, each tenant has dedicated components, and the data plane is segmented as well. The second option is VPN tenancy. This mode segments only the data plane of the VPN topology and allows you to define read-only users who can view and monitor their VPN within SD-WAN Manager. VPN tenancy still shares the same SD-WAN components, however. The third option is multi-tenancy. With Cisco Catalyst SD-WAN multi-tenancy, a service provider can manage multiple customers, called tenants, from SD-WAN Manager. The tenants share the same set of underlying SD-WAN Control Components: SD-WAN Manager, SD-WAN Validators, and SD-WAN Controllers. The tenant data is logically isolated on these shared SD-WAN Control Components. WAN Edge devices are typically tenant specific (that is, not shared), but service providers managing a multi-tenant SD-WAN deployment may deploy a multi-tenant WAN Edge device to serve as a shared gateway for traffic belonging to multiple tenants.

Deployment Options

Cisco Catalyst SD-WAN supports multiple deployment options for SD-WAN Control Components:

• Cisco cloud hosted: This is the recommended and the most common deployment option, where Cisco builds, operates, and monitors all the SD-WAN Control Components introduced in this chapter. This greatly simplifies the deployment, allowing the network administrator to focus on the configuration and policy administration of the Cisco Catalyst SD-WAN fabric. Customers can manage their deployments through the Cisco Catalyst SD-WAN portal (), a cloud-infrastructure automation tool tailored for Cisco Catalyst SD-WAN. Using this portal, they can submit fabric provision requests, indicating the preferred cloud provider (AWS or Azure) and regions for hosting SD-WAN Control Components and data. The SD-WAN portal also offers additional functions, such as controller monitoring and fabric maintenance.

• Managed service provider (MSP) or partner hosted: SD-WAN Control Components are hosted in a private or public (AWS or Azure) cloud of an MSP or partner. The provider is responsible for provisioning of the SD-WAN Control Components and backups/disaster recovery.

• On premises: This option is suitable when business requirements dictate hosting SD-WAN Control Components in a traditional data center. With this approach, customers assume full responsibility for deploying, managing, and monitoring the SD-WAN Control Components. While it offers full control, customers must also manage the operations and maintenance of servers hosting these components. Another challenge is resource scaling, which is not as easy as with cloud-hosted solutions. On-premises deployment is particularly important for companies that are subject to strict regulations, such as those in the government, financial, healthcare, and utilities sectors.

• Customer cloud hosted: In this mix of previous options, SD-WAN Control Components are deployed in a public cloud (AWS or Azure), but customers are fully responsible for their deployment, management, and monitoring. Compared to on-premises hosting, customer cloud deployments have a low initial setup cost, as there is no need to purchase additional data center infrastructure. This option brings in traditional cloud benefits: ease of provisioning, stability, security, and scaling.

Summary

This chapter introduces the components that make up Cisco Catalyst SD-WAN. It discusses the data plane, wherein user traffic is routed and forwarded across the WAN. The data plane is similar to routers that would be deployed in a traditional WAN; in Cisco Catalyst SD-WAN, they are referred to as WAN Edge routers.

This chapter also introduces SD-WAN Manager, which is part of the management plane, where all Day 0, Day 1, and Day N functions are performed, including WAN Edge configuration, routing and control policies, troubleshooting, and monitoring.

You have seen that SD-WAN Controller, the brain of the Cisco Catalyst SD-WAN fabric, is responsible for calculating and deploying all control and data policies as well as handling the distribution of encryption keys for data plane connectivity.

You have also seen that SD-WAN Validator makes up the orchestration plane and is responsible for authenticating components on the fabric in addition to distributing control and management plane information to the WAN Edge routers. SD-WAN Validator is the component that aids in discovery of the fabric for all other components (such as when devices are behind NAT).

Finally, this chapter discusses deployment options. The most common deployment method is Cisco cloud hosted, but there are three other options to consider: on-premises, public cloud, and customer cloud hosted. By supporting all four deployment options, Cisco Catalyst SD-WAN can support all business requirements.

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 2-1 lists these key topics and the page number on which each is found.

Table 2-1 Key Topics

Key Topic Element	Description	Page
Figure 2-1	Cisco Catalyst SD-WAN distributed architecture	15
Section	Data plane	16
Section	Cisco Catalyst SD-WAN supported platforms	19
Section	Management plane	22
Section	Control plane	24
Section	Orchestration plane	27

Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

control plane

data plane

management plane

orchestration plane

Overlay Management Protocol (OMP)

SD-WAN Controller

SD-WAN Manager

SD-WAN Validator

WAN Edge

Chapter Review Questions

1. What are the three Cisco Catalyst SD-WAN Control Components? (Choose three.)

1. SD-WAN Controller

2. SD-WAN Validator

3. WAN Edge

4. SD-WAN Manager

5. SD-WAN Orchestrator

2. How does the Cisco Catalyst SD-WAN architecture differ from traditional WAN technologies? (Choose three.)

1. Single pane of glass

2. Increased scale with centralized control plane

3. Reduced uptime in branch locations

4. Topology dependence

5. Distributed architecture

3. What are the three functions of SD-WAN Manager in Cisco Catalyst SD-WAN?

1. Troubleshooting

2. Configuration

3. Redistribution

4. Loop prevention

5. Monitoring

4. True or false: WAN Edge routers provide data plane encryption via IPsec.

1. True

2. False

5. What traditional networking concept does SD-WAN Controller closely relate to?

1. OSPF designated router

2. DHCP helper

3. BGP route reflector

4. PIM designated router

6. What functions does SD-WAN Validator provide in the SD-WAN environment? (Choose two.)

1. Authentication and authorization of the SD-WAN components

2. NAT detection and traversal

3. Pushing configuration to WAN Edge routers

4. Software upgrades

7. True or false: Cisco Catalyst SD-WAN supports multi-tenancy.

1. True

2. False

8. Which routing protocols are not supported on the service side of Cisco Catalyst SD-WAN? (Choose two.)

1. EIGRP

2. OSPF

3. RIPv1

4. OMP

5. BGP

9. What attributes are measured with BFD? (Choose three.)

1. Delay

2. Loss

3. Jitter

4. Out-of-order packets

10. True or false: Cisco Catalyst SD-WAN is able to provide segmentation and different topologies per VPN.

1. True

2. False

11. Which is not a valid option for the deployment of SD-WAN Control Components?

1. Cisco cloud hosted

2. Customer on premises

3. Partner cloud hosted

4. Cisco on premises

References

RFC 4023, “Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE),” , March 2005.

RFC 5389, “Session Traversal Utilities for NAT (STUN),” , October 2008.

“Cisco Catalyst SD-WAN,” .

“SD-WAN Platforms,” .