Cisco offers multiple SD-WAN options, and there are two main SD-WAN solutions and WAAS:
1. SD-WAN vEdge (aka, Viptela)
2. Meraki
3. WAAS
Because of these various options, you need to understand their respective strengths, business requirements, and total ownership cost.
At a high level, the Cisco SD-WAN vEdge solution offers a more granular approach to networking, meaning it is better suited to large complex Enterprise requirements, such as deep packet inspection, support for advanced routing, and sophisticated orchestration. This allows for greater scale and expandability.
Meraki is ideal for reasonably standard requirements to meet most branch office needs and easily configure wireless.
The typical questions that arise begin with a discussion on how many links your business needs to support for load balancing or redundancy. At the most basic level, Meraki supports dual WAN circuits vs. SD-WAN vEdge, supporting additional requirements.
In addition to these two major SD-WAN solutions, WAAS offers WAN optimization, acceleration of TCP-based applications, and Cisco's Wide Area File Services (WAFS) in a single appliance or blade.
It is Cisco's attempt to keep WAN optimization residing firmly in the router, eliminating the need to deploy acceleration appliances throughout the infrastructure.
Please find additional resources at the Cisco SD-WAN website.
https://www.cisco.com/c/en/us/solutions/enterprise-networks/sd-wan/index.html
- SD-WAN vEdge (aka, Viptela)
The Cisco SD-WAN solution is comprised of separate orchestration, management, control, and data planes.
- The orchestration plane assists in the automatic onboarding of the SD-WAN routers into the SD-WAN overlay.
- The management plane is responsible for central configuration and monitoring.
- The control plane builds and maintains the network topology and makes decisions on where traffic flows.
- The data plane is responsible for forwarding packets based on decisions from the control plane.
<Overview of Cisco SD-WAN solution planes> |
▶ Controller Deployment Options
In any SD-WAN deployment, the controllers are deployed and configured first, followed by the main hub or data center sites, and lastly, the remote sites. As each site is deployed, the control plane is established first, automatically followed by the data plane. It is recommended that hub sites are used to route between SD-WAN and non-SD-WAN sites as the sites are being migrated to SD-WAN.
1. Cisco Cloud-Hosted Deployment (recommended)
This is the recommended model and controllers can be deployed in AWS or Azure. Single or multiple zones are available for the deployment. Most customers opt for Cisco cloud-hosted controllers due to ease of deployment and flexibility in scaling. Cisco takes care of provisioning the controllers with certificates and meeting requirements for scale and redundancy. Cisco is responsible for backups/snapshots and disaster recovery. The customer is given access to vManage to create configuration templates and control and data policies for their devices.
2. Cloud-hosted Controller Deployment
This is private cloud-hosted or can be public cloud-hosted and deployed in AWS or Azure. The MSP or partner is typically responsible for provisioning the controllers and responsible for backups and disaster recovery.
In the cloud-hosted environment, the controllers sit behind a virtual gateway. Each controller is addressed with a private IP address, and the virtual gateway applies 1-to-1 NAT by translating each private controller address into a separate publicly routable IP address for reachability across the Internet.
3. On-Premise Controller Deployment
In this type of controller deployment, controllers are deployed on-premise in a data center or private cloud.
The customer is typically responsible for provisioning the controllers and responsible for backups and disaster recovery. Some customers, such as financial institutions or government-based entities may choose to run on-premise deployments mainly due to security and compliance reasons.
For on-premise deployments, there are multiple ways to arrange the controllers using NAT, Public IPs, and/or Private IPs.
▶ WAN Edge Deployment Options
WAN Edge routers are deployed at the remote sites, campuses, and data centers and are responsible for routing data traffic to and from the sites across the SD-WAN overlay network.
Connection Choices
All that is needed to establish the underlay is IP connectivity from the WAN Edge router to the transport service provider, who is responsible for propagating the tunnel subnet route information to the remote SD-WAN sites. The connection to the transport can be made in multiple ways although it is recommended to be positioned as close to the transport as possible. The following are common connection choices:
<MPLS and Internet WAN Edge connections> |
(A) Replace a CE
For MPLS, a WAN Edge router can completely replace a Customer Edge (CE) router so there is direct connectivity from the WAN Edge router to the Provider Edge (PE) router in the MPLS transport. For the Internet transport, a WAN Edge router is connected directly to the Internet transport with no firewall present. This connection type is commonly seen in branch sites.
(B) WAN Edge router places behind a CE router or a firewall
For MPLS, a WAN Edge router can be placed behind a CE router which connects to the MPLS transport. This is used when the CE router must remain in place.
For the Internet transport, the WAN Edge router can be placed behind a firewall if it is required by the company security policy. This connection type is commonly seen in data center sites.
For the Internet transport, the WAN Edge router can be placed behind a firewall if it is required by the company security policy. This connection type is commonly seen in data center sites.
(C) WAN Edge router connects to the LAN switch
For both MPLS and Internet transports, a WAN Edge router can be connected directly to the LAN switch for transport connectivity when a CE or Firewall is required but no direct connection is available to the CE or Firewall for the SD-WAN router.
*Reference URLs:
Cisco SD-WAN Design Guide (Download PDF)
Cisco SD-WAN Migration Guide (Download PDF)
Cisco SD-WAN: WAN Edge Onboarding (Download PDF)
SDWAN solution: Meraki Vs Cisco Viptela
Cisco SD WAN Viptela vs Meraki?
Routed mode on a Cisco Meraki MX is best used when the security appliance will be connecting directly to your internet demarcation point. When this is the case, the MX will have a public IP address that is issued by the internet service provider. The MX will also be the device handling the routing for clients to the internet, and any other networks configured for the device to communicate to. This mode is optimal for networking environments that require a security appliance with Layer 3 networking capabilities.
Passthrough mode on a Cisco Meraki MX configures the appliance as a Layer 2 bridge for the network. The MX in this mode will not perform any routing or any network translations for clients on the network. Passthrough/Concentrator Mode is best used when there is an existing Layer 3 device upstream handling network routing functions. The MX in this instance would still act as a security appliance, but with less functionality for Layer 3 networking.
The recommended use case for the MX security appliance in passthrough mode is when it is acting as a VPN Concentrator for the Cisco Meraki Auto VPN feature. Passthrough/VPN Concentrator mode ensures easy integration into an existing network that may already have layer 3 functionality and edge security in place. With this mode, a Cisco Meraki MX security appliance can be integrated into the existing topology and allow for seamless site to site communication with minimal configuration needed.
*Reference URLs:
Cisco SD-WAN Design Guide (Download PDF)
Cisco SD-WAN Migration Guide (Download PDF)
Cisco SD-WAN: WAN Edge Onboarding (Download PDF)
SDWAN solution: Meraki Vs Cisco Viptela
Cisco SD WAN Viptela vs Meraki?
- Meraki SD-WAN
1. Routed (NAT) Mode
Routed mode on a Cisco Meraki MX is best used when the security appliance will be connecting directly to your internet demarcation point. When this is the case, the MX will have a public IP address that is issued by the internet service provider. The MX will also be the device handling the routing for clients to the internet, and any other networks configured for the device to communicate to. This mode is optimal for networking environments that require a security appliance with Layer 3 networking capabilities.
2. Passthrough/VPN Concentrator Mode
Passthrough mode on a Cisco Meraki MX configures the appliance as a Layer 2 bridge for the network. The MX in this mode will not perform any routing or any network translations for clients on the network. Passthrough/Concentrator Mode is best used when there is an existing Layer 3 device upstream handling network routing functions. The MX in this instance would still act as a security appliance, but with less functionality for Layer 3 networking.
The recommended use case for the MX security appliance in passthrough mode is when it is acting as a VPN Concentrator for the Cisco Meraki Auto VPN feature. Passthrough/VPN Concentrator mode ensures easy integration into an existing network that may already have layer 3 functionality and edge security in place. With this mode, a Cisco Meraki MX security appliance can be integrated into the existing topology and allow for seamless site to site communication with minimal configuration needed.
<Meraki Passthrough/VPN Mode> |
*Reference URLs:
General MX Best Practices (Merkai)
Cisco MX SD-WAN Connectivity Models (willette.works)
- WAAS
Cisco Wide Area Application Services (WAAS) is technology developed by Cisco Systems that optimizes the performance of any TCP-based application operating in a wide area network (WAN) environment while preserving and strengthening branch security. WAAS combines WAN optimization, acceleration of TCP-based applications, and Cisco's Wide Area File Services (WAFS) in a single appliance or blade.
It is Cisco's attempt to keep WAN optimization residing firmly in the router, eliminating the need to deploy acceleration appliances throughout the infrastructure.
The WAAS system consists of a set of devices called Wide Area application Engines (WAEs) that work together to optimize TCP traffic over your network.
▶ Inline/In-Path Mode
The WAE physically and transparently intercepts traffic between the clients and the router. To use this mode, you must use a Cisco WAAS device with the Cisco WAE Inline Network Adapter, Cisco Interface Module, or Cisco AppNav Controller Interface Module.
*NOTE: Inline mode and WCCP redirection are exclusive. You cannot configure inline mode if the WAE is configured for WCCP operation. Inline mode is the default mode when a Cisco WAE Inline Network Adapter is installed in a WAE device, but you must configure inline mode explicitly on a device with a Cisco Interface Module.
▶ WCCP (Web Cache Communication Procotol)
Redirects all packets matching policy, not flow aware, load independent flow distribution.
Used for transparent interception of application traffic and Common Internet File System (SMB) traffic. Used in branch offices and data centers to transparently redirect traffic to the Cisco WAAS devices. The traffic is transparently intercepted and redirected to the local WAE or ANC by a WCCP-enabled router or a Layer 3 switch.
You must configure WCCP on the router and WAE in the branch office and the router and WAE in the data center.
*NOTE: WCCP works only with IPv4 networks.
▶ PBR (Policy-Based Routing)
Policy-based routing (PBR), introduced in the Cisco IOS Software Release 11.0, allows you to implement policies that selectively cause packets to take specific paths in the network.
PBR also provides a method to mark packets so that certain kinds of traffic receive differentiated, preferential service when used in combination with queuing techniques enabled through the Cisco IOS software.
Used in branch offices used for wide area application optimization. The branch office router is configured to use PBR to transparently intercept and route both client and server traffic to the WAE that resides in the same branch office.
In data centers, used for data center application optimization. The data center router or Layer 3 switch can be configured to use PBR to transparently intercept and route client and server traffic to WAEs within the data center. PBR, however, does not support load balancing across multiple WAEs, such as WCCP does. PBR does not support load balancing when you use a hardware load balancer, such as the Cisco CSM or Cisco ACE.
▶ AppNav Controller
For WAEs that are part of an AppNav deployment and are configured as Cisco WAAS nodes in an AppNav Cluster, you must configure them to use the appnav-controller interception method. This configuration allows WAEs to receive and optimize traffic that is intercepted and distributed by the AppNav Controllers.
▶ ACE or CSM
Cisco Application Control Engine (ACE) or Catalyst 6500 series Content Switching Module (CSM) installed in the data center for data center application optimization. The ACE or CSM allows for both traffic interception and load balancing across multiple WAEs within the data center.
▶ ITD (Intelligent Traffic Director)
About Intelligent Traffic Director (Network Direction)
Intelligent Traffic Director (ITD) is a Cisco proprietary technology. It is capable of load balancing and traffic steering in the data centre. The Nexus N5K, N6K, N7K, and N9K switches offer ITD support. ITD needs the Enhanced Layer 2 or Network Services license.
*Reference URLs:
Cisco SD-WAN Getting Started Guide
Configuring Traffic Interception
Planning Your Cisco WAAS Network
Cisco SD-WAN WAAS Deployment and Migration Guide (May 2020, Version 1, PDF)
No comments:
Post a Comment