Cisco Secure Agile Exchange Solution verview Cisco ublic ... · Cisco Secure Agile Exchange ... The combination of software and hardware is then ... given that both the consumers

© 2017 Cisco and/or its affiliates. All rights reserved.1

Cisco Secure Agile ExchangeEnabling enterprises to quickly and securely interconnect users to applications by virtualizing the network edge and extending it to colocation centers, the crossroads of Internet traffic.

© 2017 Cisco and/or its affiliates. All rights reserved.

Cisco Secure Agile ExchangeSolution OverviewCisco Public


Solution OverviewDigitization is placing unprecedented demands on IT to increase the speed of services and products delivered to customers, partners, and employees, all while maintaining a high level of security. The interconnections between users and applications are evolving to complex digital business architectures, so the network needs to be both fast and flexible to meet the expanding changes and demand.

• Users are dispersing into various physical locations (away from fixed campuses or headquarters) with varying devices, including Internet of Things (IoT) endpoints. The growing number of users is creating strains on the already saturated and expensive bandwidth. Dispersed users are creating security and performance challenges.

• Applications can reside in multiple locations, including the private data center; in the cloud in the form of infrastructure as a service (IaaS) with providers like AWS, Azure, and Google Cloud Platform; or as software as a service (SaaS) with providers such as ServiceNow and Salesforce.com. Regardless of an organization’s cloud strategy, most will have applications across all three of these of these locations.

• Flexibility in connections is increasing, with not only traditional leased-line or Multiprotocol Label Switching (MPLS) connections but also IP Security (IPsec) VPN or SSL/TLS becoming popular. Enterprises have an opportunity to save costs on dedicated circuits, but also need to rethink their network architecture in order to accommodate the different connections and determine how these dynamic connections meet application performance and security service-level agreements (SLAs).

Cisco® Secure Agile Exchange (SAE) enables enterprises to quickly and securely interconnect users to applications by virtualizing the network edge (DMZ) and extending it to colocation centers, the crossroads of Internet traffic. It allows users – employees, customers, and partners – to reach the desired application, whether it resides in the data center, the public cloud, or a SaaS cloud, while ensuring the best application experience. SAE can dynamically respond to user, application, and business policy changes by deploying network services in minutes, in either colocation centers or private data centers.

The foundational components of SAE are the following:

• High-performance network functions virtualization (NFV) platform: Cisco Cloud Services Platform (CSP) 2100

• Network services: Cisco virtual network functions (VNFs) such as Cisco Cloud Services Router CSR 1000V, Cisco Adaptive Security Virtual Appliance (ASAv), Cisco Firepower™ NGFW Virtual (NGFWv), and Cisco Virtual Wide Area Application Services (vWAAS), as well as third-party services

• Switching fabric: Cisco Nexus® 9000 Series• Customer services: Advisory and implementation services (optional):

Cisco Managed Services

The benefits of SAE include the following:

• Performance: Enterprises can optimize application performance by strategically placing SAE in colocation centers that are closest to the SaaS and public IaaS cloud providers.

• Agility: By virtualizing network services, enterprises can simplify their operations. Scaling up and down and adding new services can now be done remotely. The CSP 2100 negates the need to order, cable, rack, and stack dedicated hardware appliances when capacity needs to be increased or changes are required.

• Security: Centralization of communication patterns between employees, customers, partners, and applications allows for better and more consistent implementation of security policies. SAE allows users to be grouped and policies to be orchestrated automatically.

• Cost savings: By having a central location to connect to various clouds (including private clouds), enterprises can optimize the costs of circuits to connect their users to applications. Circuit costs for a colocation facility are significantly lower than in a private data center. Also, a DMZ built on NFV reduces both CapEx and OpEx.

SAE enables hybrid cloud, reduces circuit costs, offers carrier and cloud independence, enforces consistent security, simplifies moves/adds/changes, optimizes traffic flows, and reduces infrastructure. It is an open orchestrated NFV platform that doesn’t require the operational complexity of OpenStack or software switching overlays yet delivers the benefits of virtualization at scale. SAE lives up to its name by securely connecting enterprise application consumers and providers using x86-based hardware when possible and purpose-built hardware when necessary. The combination of software and hardware is then orchestrated to offer consumable network connectivity with Group-Based Policy (GBP) constructs (Figure 1).


http://www.cisco.com/go/csp


Figure 1. Secure Agile Exchange

MicrosoftO�ce 365 Google

Salesforce Cisco WebEx

SaaS

PrivateData Center

Public Cloud

Customers

Employees

Partners

Colocation Centers

CiscoSecure Agile

Exchange

BackgroundLike people, enterprises are becoming more and more connected. Traditionally, the DMZ was for e-commerce and employee Internet egress. Then partner connections moved onto the Internet too. As enterprises consume cloud in the form of public SaaS and public IaaS, we are piling more and more secure connectivity into the DMZ. The enterprise DMZ has not been well structured, and as a result organizations have done their best to build an environment to support diverse use cases with diverse connection types that have diverse trust levels using diverse products that are implemented with very custom security policies. Consequently, the DMZ is now complex, fragile, slow, error prone, time consuming, and ripe for attention. In response to the increasing complexity of the DMZ, Cisco is now offering SAE as a solution to help enterprises organize, virtualize, orchestrate, and automate their various interconnections.

One of the fastest-growing forms of external connectivity is the public cloud. Enterprises vary quite a bit in their adoption of and plans to adopt public cloud. Most have started with public SaaS, but the adoption of public IaaS is in its infancy.

The enterprise cloud adoption approach generally falls into three categories:

Private First• Most applications hosted in your private data center

• Some use of public SaaS

• Limited use of public IaaS for development and testing

Cloud FirstYour decision order for a new application is public SaaS first, public IaaS hosted second, private data center packaged third, and private data center from scratch fourth.

Cloud All InCloud first for new applications, plus you are investing resources in refactoring, lifting, and shifting existing applications to migrate them from the private data center to public SaaS and IaaS.

In some cases, a large enterprise may choose an approach for the entire company, and all the lines of business then follow the same strategy. In most cases, however, the decision is made at the business unit level, so a single large enterprise may have all three approaches at the same time in different business units. If an enterprise is not private data center first, we refer to it as a hybrid cloud enterprise. The hybrid cloud enterprise will have applications running in the private data center, the public IaaS, and the public SaaS cloud in varying quantities. Given these three environments, the enterprise network needs to adjust based on where the applications and data are hosted.

SAE reduces circuit costs, lowers CapEx by virtualizing network functions, and reduces OpEx through structured orchestration using GBP sourced from a common policy repository. If you are not aggressively adopting a hybrid cloud strategy, SAE would be implemented as a replacement DMZ in your private data center. If you are aggressively moving business applications to the public cloud, SAE would be implemented in a colocation facility or carrier-neutral facility (CNF).



Business InteractionsTraditionally, the enterprise applications and data resided in data centers and were accessed by PC clients from either enterprise-owned locations or over remote-access VPNs or, on occasion, virtual desktop/application connections. Increasingly, applications are moving to public clouds, mostly in the form of public SaaS but also as public IaaS. For public IaaS, the presentation tiers of applications are the early movers, while the business logic and databases lag behind, remaining in the private data centers. Very often, the enterprise data follows the application into the cloud, usually but not always resulting in distributed data. Even in the cloud, a centralized approach may be taken by hosting data in one cloud (Amazon S3, Box, Dropbox, etc.) for consumption by other clouds. Figure 2 represents the context-based interactions that commonly occur in the enterprise today. Essentially, users on devices in various places cross networks to access applications that present data. The context of an interaction depends on the trust level of all of these components. For the sake of consistency, this document refers to users and devices as consumers and to applications with data as providers. First, we’ll explore what the interior enterprise network should look like, given that both the consumers and providers are becoming more distributed, less owned (because users are bringing their own devices [BYOD]), and less controlled. Second, we’ll consider how to enable network policies that simplify consumer-to-provider interactions by organizing connections for orchestration with structured access controls.

Figure 2. Enterprise Consumer-to-Provider Context-Based Enterprise Interactions

Consumer

User

Employee

Partner

Vendor

Customer Thing Anywhere SSL/TLSPublic

IAAS/SAASHosting

Client stored

Mobile Home IPSec VPN DedicatedHosting

IAAS/SaaSintegrated

store

PC Branch MPLS Partner DataCenter

IAAS/SaaSdedicatedstorage

Campus Leased Line Private DataCenter

PrivateNAS/SAN,

DB

VDI orApplication

Server

Device Access ApplicationLocation

DataLocation

UserLocation

Hig

her

Trus

tLo

wer

Tru

st

Access Provider

Cen

tral

ized

Dis

trib

uted

Network TopologiesThe enterprise WAN was built to support employees in branches on managed and owned devices crossing private lines to access applications and data in private data centers. As a result, all consumer connections from employees, partners, and customers terminated in the enterprise data center. It made sense, and we optimized the networks for this specific use case. As SaaS offerings grew and business use of the Internet grew, the costly private WAN filled up with Internet-bound traffic. In response, Cisco introduced Cisco Intelligent WAN (IWAN) for Internet offload and/or direct Internet access (DIA) to avoid backhauling the Internet-bound traffic. However, DIA doesn’t entirely solve the problem of accessing distributed SaaS applications. What about mobile and VPN employees, partners, and customers? The current enterprise network has not evolved to support distributed consumers (employees, partners, customers) interacting with distributed applications and data that potentially reside in many clouds. The changes in consumers and providers dramatically affect how we design secure networks that deliver a good experience.



Private-First Enterprise NetworkThe private-first customer network topology will likely not change, even though the transport may use Internet or DIA for SaaS. The consuming employees, things, vendors, partners, and customers traverse networks that will continue to logically terminate in the private data center, even if they use Internet transport. Untrusted and semi-trusted consumers and providers traverse in-depth security and monitoring across the DMZ, which incorporates connections to cloud, often over the Internet (Figure 3).

Figure 3. Private Data Center-Centric Network

Employee

~80%Apps

~10%Apps

~10% SAAS

Internet

PublicIAAS

Consumers

Providers

Things Vendor Partner Customer

DM

ZPrivateDC

Cloud All-In Enterprise NetworkA small number of enterprises have declared an all-in approach to cloud, meaning that they will not only put new applications in the public cloud but also spend substantial resources on refactoring, lifting, and shifting applications to the public cloud. Often these enterprises want to get out of the data center business entirely, leaving a CapEx

consumption model for an OpEx one. At some point, the intention is for there to be no enterprise data center or for its existence to be minimal for very old client/server and mainframe applications. These enterprises or business units will spend time and money to accelerate the move to cloud, reducing the timeframe from an average application lifespan of about 20 years to as little as 5 years. Sometimes the business units of these enterprises have aspirations of moving the employee private WAN network terminations to IaaS cloud providers. In essence, all the consumer networks would terminate in the cloud, potentially including Internet-bound traffic, which would go through cloud-based content filtering located near or in the IaaS cloud. These enterprises also need to consider where and how they terminate business-to-business (B2B) and business-to-consumer (B2C) connections, especially if they are multicloud (Figure 4).

Figure 4. Cloud-Centric Network

Employee

~67%Apps

~33% SAAS

Internet

Consumers

Providers


DM

Z

PublicIAAS



Hybrid Cloud EnterpriseCloud-first enterprises will likely use public cloud for new applications when they can, but will fall back to private when they must due to application availability, regulatory (data sovereignty) requirements, compliance, etc. Whether an enterprise declares that it will be cloud first or cloud all in, it will be hybrid cloud during the journey, which may last 5 years if accelerated or 20 years or more if existing applications are left to retire in their normal lifespan. In either case, the enterprise will have applications distributed across the private data center, the public SaaS cloud, and the public IaaS cloud, often accessed through a private connection if used en masse. Both cloud all-in and cloud-first customers will fall into this hybrid cloud category for the foreseeable future. To optimize traffic patterns for experience, secure interactions, reduce circuit costs, and provide flexibility, it makes sense for hybrid cloud enterprises to build out SAE in a colocation facility or CNF. If you are private first, SAE can be placed within your existing private data center (Figure 5).

Figure 5. Hybrid Cloud-Centric Network

Employee

~33%Apps

~33%Apps

~33% SAAS

Internet

PublicIAAS

Consumers

Providers


PrivateDC

NeutralFacility

DMZ

Service ChainsIn a typical enterprise, a fairly common set of services is applied in the various consumer and provider zones. Service nodes have been used to implement security and experience functions in the path of traffic since the beginning of networking. Generally, the implementation of the network services has not been very structured. In SAE, structure is applied to the sets of services applied to consumer and provider access chains for branch and campus connections, partner connections, or virtual private cloud connections. Within a single SAE, application consumers and providers meet at an orchestrated cross-connect built on intelligent high-speed switching with the Cisco Nexus 9000 Series Switches and virtualized network services hosted on x86 compute using the CSP 2100, patterned and orchestrated for service catalog-based operations.

OrchestrationAutomation originates with business policy that is collected through a workflow-based portal. The automated workflow may be retained in a service catalog and reused through an abbreviated workflow. Orchestration is the act of translating the automated workflow into coordinated configuration to offer a service. Configuration parameters are extracted from the information collected in the workflow and translated into configuration to create a consumable service. A consumable service is described through a service model. The service model is translated into a device-specific configuration through a device model called a Network Element Driver (NED). In order to create a consumable service, the service is deconstructed into layers across many devices that create the service when implemented completely. If the service cannot be implemented for any reason, then nothing is changed or what is changed is removed.

VirtualizationVirtualization is foundational to orchestration and automation. In networking, VLANs were instrumental in reducing the number of switches required to provide the desired network segmentation. A single switch could be securely shared through reprogramming. The same holds true for VNFs, which can be created, read, updated, and deleted (CRUD) through programmatic interfaces (command-line interface [CLI], Rest API, GUI, NETCONF/YANG). The CSP 2100 is the NFV platform used in SAE.



What Is the CSP 2100?The Cisco Cloud Services Platform (CSP) 2100 is a turnkey, open, x86 Linux Kernel-based virtual machine (KVM) software and hardware platform for data center NFV. The platform enables network, security, and load balancer teams to quickly deploy any Cisco or third-party network virtual service through a simple, built-in native web UI, CLI, REST API, and/or NETCONF/YANG using Cisco’s Network Services Orchestrator (NSO) or any other third-party northbound management and orchestration system. Any or all management interfaces can be used. The CSP 2100 is delivered as an appliance in 1-rack-unit (1RU) and 2RU form factors (Figure 6).

Figure 6. CSP 2100 High-Level Architecture

CSP 2100 SW, ConfD, Linux KVM, OVS, PCle Passthrough, SR-IOV

CSR XRv9000 ASAv Third

partyThirdparty

KVMbased

services

NSO

NFS

CLIGUI

RESTNetConf

API

Cisco UCS 1RU/2RU Modular Platforms, 1 and 10G SFP+ NICs

Partner Extranet Automation and Orchestration Partner connectivity is constructed by layering service models on top of each other until the service is assembled. The policy and parameters consumed by the orchestrator may be acquired by SQL from a database in which they were populated by a portal, by a REST API request to the Internet Protocol Address Management (IPAM) system, and/or from an internal repository. To lay down a new partner service, the orchestrator first provisions the VLANs from an internal pool to the switching layer via a NED. Second, the orchestrator directs the hosting platform to provision the VNFs with several virtual network interface cards (vNICs) (untrusted, trusted, management, etc.) attached via single-root I/O

virtualization (SR-IOV) to physical NICs (PNICs) and hence the switch VLANs (Figure 7).

Figure 7. SAE Extranet Architecture

Event Monitor

Standardized Re-usableLayered Service Models

Access Control

VPN Con�guration

VF L2/3 Network

VM To Network

L2 Network

Workflow

PolicyServiceCatalogPolicy

ParameterDB

• Providers/Apps - IP:Mask:Port - Name• Provider Groups• Consumers - IP:Mask:Port - Name• Consumer Groups• Partners - Partner X - Partner Y• Partner Groups• Consumables• Connection Type

IPAM

NED NED

CSR

ASRNexus 9000

CSR 2100SR-IOV

ASAv

NED NED NED

NSOConfd

Confd

CDB

SecurityThe partner extranet is often one of the most dynamic security zones in SAE because a whitelist security policy is applied while application consumers and providers are constantly changing. The policy and parameter database is populated through the portal with details on the provided applications (IP address, port) grouped/tagged by the consumer types that are intended to have access. Partner consumers are similarly grouped/tagged by consumer type. For example, a personnel data tag may be applied to internal applications that house data on employees and should be exposed to payroll, healthcare, retirement account, etc. partners. Rather than managing access lists to accomplish this, we associate IP addresses and ports to partners and applications and then group them so that access list controls are automatically applied when the groups housed in the database change. When a new personnel application is deployed, it triggers an event that may be confirmed by the infrastructure team. Once confirmed, the application is tagged and populated in the database along with the relevant IP address and port. As a result, the appropriate security controls are then automatically deployed to the appropriate partners without having to manually configure each partner connection.


http://www.cisco.com/go/nso

http://www.cisco.com/go/nso


Similarly, retiring or deleting an application triggers an event that, if confirmed by the infrastructure group, results in the access list controls being removed from the specific group of partners.

This GBP-driven approach, using a portal and database of consumers and providers, may be extended to all of the SAE zones. Access list management is minimized through grouping and policy to offer a whitelist security-based model with auditability. The granularity of the GBP can be managed at the zone level. Zones can be subdivided into smaller and smaller groups based on appropriately tagging the consumers and providers. For example, within the partner extranet zone, partners can be grouped into a category of law firms, which can then be further segmented by mergers and acquisitions, patent, environmental, labor, real estate, etc. There may be some provided applications that are exposed to all law firm partners but others that are exposed to only a specific group of law firm partners. The groupings may also be applied to login groups from the partners if a common directory is used. Ultimately, access list management would be a thing of the past, since the classifiers associated with consumers and providers would reside in a policy database that was translated into infrastructure configuration through the orchestrator.

Over time, each zone is organized and automated using the same consumer and provider group-based approach, such that when a new application is provided in a cloud zone such as AWS, the system can automatically detect the event and prompt the network security infrastructure teams of the new application, perhaps represented by an elastic load balancer IP address and port. The infrastructure administrator would then accept or deny that application. If accepted, the appropriate provider access list controls would be applied to the AWS provider zone. Then the infrastructure administrator would be asked what consumer zones the provided application should be exposed to. From the database, the granularity could be all employees (or a group-tagged subset), a group of partners, and potentially other required application components that reside in the private data center.

How Is SAE Being Deployed?Most designs are using SR-IOV connectivity for near-line-rate performance, along with a data center fabric using a spine and leaf architecture provided by Cisco Nexus 9000 Series Switches (Figure 8).

Figure 8. Sample High-Availability SR-IOV Connectivity Design

Cisco Nexus 9000 Series Spine Switches

VNF VNF VNF

MGMT Switch MGMT SwitchCisco Nexus 9000

Series Leaf Switches

10G

SR-

IOV

Inte

rfac

e

10G

SR-

IOV

Inte

rfac

e

CSP 2100CSP 2100

VNF VNFVNF

SR-IOV PNICSR-IOV PNIC SR-IOV PNIC SR-IOV PNIC

Phased Implementation PlanSAE offers a path to adopt public IaaS with an aggregation layer to reduce circuits costs, virtualization to reduce infrastructure costs, and policy-based orchestration to reduce operational costs. Recognizing that all the value would be hard to consume in one step, the following phased plan lays out an approach that allows value to be consumed incrementally over time with the final destination in mind.

In the first phase, physical network appliances that are currently x86 based are simply replaced by virtual network appliances attached to the physical networking infrastructure via mechanisms such as SR-IOV or PCIe pass-through for high performance. To the network, these virtual appliances look just like physical appliances, so the same operational model is retained without introducing the complexity of software networking in a purely transit infrastructure. In the second phase, lifecycle management is enhanced beyond a keep-alive approach that restarts a failed virtual service to the ability to dynamically scale out or in and replace failed compute nodes. In the third phase, we automate zones, recognizing that some zones may not be worth automating. Automation is targeted at those zones that have frequent and complex moves, adds, and changes (MACs). We covered the extranet zones and application hosting zones as zones where MACs will occur frequently.


http://www.cisco.com/c/en/us/products/switches/nexus-9000-series-switches/index.html


Even though MACs of applications and partners occur frequently, the basic connectivity and service chains in these zones will not change that often. As a result, the automation focus is on the application-specific policies that change often. Once the consumers and providers are grouped and put into a database, the intrazone policies may be automated through the event-triggered policy portal. Ultimately, when a growing number of enterprises get their consumer and provider groups automated, further optimization will be possible through an interdomain/intercompany cloud service. However, that level of optimization will be achievable only after a majority of the companies in an industry or in general are able to expose consumer and provider groups through databases or directories (Figure 9).

Figure 9. SAE Phased Approach

Horizon 1

VirtualizeNetwork

Appliances

Virtual ApplianceLifecycle

Management

AutomateConsumer and

Provider Services

AutomateInterzoneSecurity

Sec

ure

Agi

le E

xcha

nge

As

A S

ervi

ceAutomate acrosszones

Automate services within a zone

Orchestrate virtual service con guration based on events/wizards

NFV/application lifecycle management, a�nity/anti-a�nity, automated chaining, RBAC,storage clustering

NFV hosting appliance, virtualized hardware acceleration, box clustering, shared storage/repository

OrchestrateComponents

Horizon 2 Horizon 3 H4

SummaryThroughout this solution overview, we have shared benefits that result from having an automated, virtualized, and centralized point of policy for distributed consumers and providers. The first step is to start virtualizing your legacy physical network appliances. The benefits of virtualized network services are immense and are foundational to future levels of automation and efficiency.

• Security and experience:

- Whitelist security model (optional)

- Group-Based Policy (GBP) via consumer provider database

- Enhanced telemetry and analytics

- Ability to choose security services independent of public IaaS, PaaS, or SaaS cloud availability

- Optimized traffic engineering, path optimization, acceleration, etc.

• Lower-cost, more flexible infrastructure:

- Fewer circuits via distributed provider aggregation layer

- Carrier and cloud neutral

- Dynamic and flexible circuit consumption from colocation facility and CNF (WAN, Internet, cloud/partner connections)

- Lower infrastructure cost and space by virtualizing physical appliances

- Consumption of only what’s needed by virtually scaling out rather than up

- Lights-out data center with ability to buy once, wire once, use many

• Automation and operations:

- Simple operations with no Linux or OpenStack skills required

- Ability to use telemetry and analytics to effect infrastructure change

- Reduced cost and improved agility through automation of virtual service lifecycles

- Security driven by GBP to reduce access list management and improve security posture

- Accelerated ability to incrementally adopt new technology starting with specific consumers or providers


© 2017 Cisco and/or its affiliates. All rights reserved. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) C22-738619-00 02/17

Service and SupportCisco offers a wide range of services to help accelerate your success in deploying and optimizing the Secure Agile Exchange (SAE). The innovative Cisco Services offerings are delivered through a unique combination of people, processes, tools, and partners focused on helping you increase operational efficiency and improve your IT infrastructure. Cisco Advanced Services use an architecture-led approach to help you align your data center infrastructure with your business goals and achieve long-term value. Cisco Smart Net Total Care™ Service helps you resolve mission-critical problems with direct access at any time to Cisco network experts and award-winning resources. Spanning the entire network lifecycle, Cisco Services help increase investment protection, optimize network operations, support migration operations, and strengthen your IT expertise. For more information, please visit http://www.cisco.com/go/services.

Cisco Capital Financing to Help You Achieve Your ObjectivesCisco Capital® financing can help you acquire the technology you need to achieve your objectives and stay competitive. We can help you reduce capital expenditures (CapEx), accelerate your growth, and optimize your investment dollars and return on investment (ROI). Cisco Capital financing gives you flexibility in acquiring hardware, software, services, and complementary third-party equipment. And there’s just one predictable payment. Cisco Capital financing is available in more than 100 countries. Learn more.

For More InformationFor additional information about Secure Agile Exchange and the CSP 2100, visit http://www.cisco.com/go/csp.


http://www.cisco.com/go/services

http://www.cisco.com/web/ciscocapital/index.html

http://www.cisco.com/go/csp

Documents

Cisco Secure Agile Exchange Solution verview Cisco ublic ... · Cisco Secure Agile Exchange ... The combination of software and hardware is then ... given that both the consumers