Cisco Digital Network Architecture Vision for Virtualization

Transcription

1 Cisco Digital Network Architecture Vision for Virtualization Cisco Digital Network Architecture Vision for Virtualization 2016 Cisco and/or its affiliates. All rights reserved.

2 As enterprise business processes are increasingly digitized, new demands on the enterprise network architecture arise. Cisco s Digital Network Architecture (DNA) is built to facilitate fast and flexible network services that support digitalized business processes. DNA centers around a network infrastructure that is not only fully programmable and open to third party innovation, but can also fully and seamlessly integrate the cloud as an infrastructure component. The DNA controller facilitates simple, automated, and programmatic deployment of network services. It brings the notion of user and application aware policies into the foreground of network operations. With DNA, the network can provide continuous feedback to simplify and optimize network operations and to support digitalized applications to become inherently network aware. This document provides additional details about the virtualization building block of the Digital Network Architecture. The document presents the technical details underpinning the transport virtualization for service segmentation. It also describes the network function virtualization building blocks in detail, including the choice of operating system to simplify virtualization and the orchestration and controller functions. Index Terms Digitalize Services, Cloud, Virtualization, Controllers, Policy, Application-aware networking, Simplicity, Orchestration, Automation, Openness I. Overview As enterprise business processes are increasingly digitized, new demands on the enterprise network architecture arise. Cisco Digital Network Architecture provides a framework for enabling fast and flexible network services that support digitalized business processes. This architecture provides a network infrastructure that is fully programmable and open to third-party innovation and that also fully and transparently integrates the cloud as an infrastructure component. The DNA controller facilitates simple, automated, and programmatic deployment of network services and brings the concept of userand application-aware policies into the foreground of network operations. In Digital Network Architecture, the network provides continuous feedback to simplify and optimize network operations and to help make digitalized applications become inherently network aware. Figure 1 shows the main architectural concepts of the architecture. An overview of is given in [1]. This document provides technical details about how virtualization is implemented in DNA. Virtualization can be categorized into transport virtualization (network segmentation) and network function virtualization. The technical details for both are described here. The document first discusses network function virtualization (NFV), introducing the possible deployment models and the building block components. The next section presents the principles of transport virtualization (segmentation), providing architectural details to segment both the data plane and the control plane. The document concludes with a discussion of the outlook for the evolution of virtualization techniques in Digital Network Architecture Cisco and/or its affiliates. All rights reserved. 2

3 Figure 1. Main Concepts of Cisco Digital Network Architecture Cloud Enabled Network Enabled Applications Collaboration Mobility IoT Security Open APIs Developers Environment Automation Abstraction & Policy Control from Core to Edge Open Standards-Based Analytics Structured Data, Contextual Insights Programmability & Virtualization Physical & Virtual Infrastructure App Hosting Segmentation IOS ASIC This paper is written for CXOs, network architects, and network engineers wanting to understand the technical details underpinning the virtualization aspects of Digital Network Architecture. Engineering-minded decision makers seeking to understand how the architecture supports the business benefits of Cisco DNA may also benefit from this paper. II. Network Function Virtualization Architecture In Digital Network Architecture, network function virtualization, or NFV, allows the flexible placement of Layer 4 through 7 (L4-L7) functions anywhere in the architecture, assuming that the required x86 computing resources are available. These x86 resources can be provided in various form factors to meet the needs of the different domains in the network and to support a variety of use cases. In a data center, existing x86 servers can also host virtual network functions (VNFs) alongside digitalized applications. In the WAN, branch routers such as the Cisco 4000 Series Integrated Services Routers (ISRs) have x86 cores available for this purpose and can be extended with an x86 compute blade: the Cisco UCS E-Series Servers. Network elements are also planned with additional x86 resources (generic compute, memory, storage resources) to accommodate the virtualization of network functions and application hosting. Digital Network Architecture supports two types of operating systems for virtualization: the enhanced Cisco IOS XE network operating system and Cisco NFV Infrastructure Software (NFVIS). Figure 2 shows several deployment options. Use cases in which only a few VNFs are required can be deployed using enhanced Cisco IOS XE in existing network routers or switches. Cisco IOS XE is based on Linux, and this deployment variant feature to allow the VNFs to run in a virtual machine next to the router s Cisco IOS XE software processes. For deployments that require additional x86 resources, a Cisco UCS E-Series blade can be inserted in the chassis of a 4000 Series ISR. In this case, NFVIS supports the virtualization of network functions, as discussed later in this document. Another deployment scenario relies on x86 servers that are co-located with a physical router or switch. In this case, the router or switch is responsible for the IP transport function, whereas the L4-L7 network functions are running in VNFs on the x86 server. This deployment model even allows other router systems (such as the Cisco ISR Generation 2 [ISR G2] routers and the Cisco ASR 1000 Series Aggregations Services Routers) to participate in a virtualized architecture. In a fully virtualized deployment, even the routing function is virtualized. NFVIS controls the hardware elements of an x86-based server, with the associated flexibility to configure as many CPU, memory, and storage resources as required. Figure 2 Enterprise NFV Deployment Models Full NfV L4-7 NfV Router-integrated NFV Router-based NFV VM 1 VM n VM 1 VM n VM 1 VM n NFVIS Licensing PnP Client Monitor LCM Web UI Security NFVIS Licensing Monitor PnP Client Web UI Linux LCM Security NFVIS Licensing Monitor PnP Client Web UI Linux LCM Security IOS XE Container VM 1 VM n Linux eios XE eios XE eios XE 2016 Cisco and/or its affiliates. All rights reserved. 3

4 A. Enterprise NFV: NFVIS Operating System As illustrated in Figure 2, several deployment models are based on NFVIS in the virtualization architecture. NFVIS extends a standard Linux OS distribution by packaging additional functions to simplify the deployment and operation of VNFs. NFVIS delivers the following components and functions: Linux: This common standard OS drives the underlying hardware platforms (Cisco Unified Computing System [Cisco UCS] servers, Cisco UCS E-Series Servers, x-86 enhanced network elements, etc.). Virtualization support: The hypervisor for virtualization is based on the Linux Kernel-based Virtual Machine (KVM) and includes Quick Emulator (QEMU), the libvirt tool, and other associated processes. Virtual switching: Open vswitch (OVS) is supported to enable multiple VNFs to share physical interface resources and to allow traffic to be passed within the x86 host between VNFs. Virtual machine lifecycle management: Management support is provided to deploy VNFs dynamically and to control their liveliness. Plug-and-play (PnP) capability: The PnP client automates the deployment of any host that uses NFVIS. The PnP client can communicate with a PnP server running in the DNA controller and be loaded with the correct host configuration. ConfD: This client enables various open APIs for the controller and orchestration systems. Representational state transfer (REST), commandline interface (CLI), and NETCONF YANG capabilities are supported. Webserver: The webserver enables connectivity to NFVIS through HTTP/HTTPS, which is used particularly to support local management tools. Device management: Tools packaged in NFVIS, including a resource manage, support device management. Statistics collection: Tools such as syslogd, snmpd, and collectd assist in statistics collection and reporting. Service chaining: This function enables service chaining based on the network services header (NSH). Note that NFVIS does not have an integrated virtual router. Virtual routing in an NFVIS system either is provided in a VNF such as in a virtual ISR (ISRv) or is offered by a traditional hardware-based router such as the ISR or ASR 1000 Series. With the packaging described here, NFVIS takes advantage of the popularity of the standard Linux distribution with a KVM hypervisor, but it significantly expands the capabilities to facilitate deployment and operations of VNFs. This approach allows operators to concentrate on delivering digitalized services, rather than on integrating and testing various software components. A particular benefit of NFVIS is the packaging and systems integration of all the required functions and processes for NFV. Figure 3 shows NFVIS in the context of the Digital Network Architecture enterprise virtualization solution. As discussed earlier, NFVIS is the common operating system for NFV running on various hardware platforms. The overall enterprise NFV solution also provides the actual VNFs and the control layer: that is, integration with the enterprise controller and the orchestration system. The various VNFs are not integral parts of NFVIS, but they can be instantiated on demand to offer their respective functions. Both Cisco and third-party VNFs are supported. Examples of such VNFs are the ISRv for virtual routing, the IP Security (IPsec) gateway, and other advanced features offered in Cisco IOS XE. Other examples include the Cisco Adaptive Security Virtual Appliance (ASAv [2] firewall), the Cisco Firepower solution for intrusion prevention systems (IPSs) and intrusion detection systems (IDSs), Cisco Virtual Wide Area Application Services (vwaas) for WAN optimization, etc. Similar VNFs from other vendors can also be instantiated as part of the enterprise NFV solution in Digital Network Architecture, again demonstrating the openness of the architecture. Note also that ordinary digitalized applications can be hosted on a host powered by NFVIS. The DNA controller, as shown in Figure 3, is responsible for the deployment and integration of NFVIS hosts in DNA. Here, the PnP client-server interaction is critical to automate the onboarding process. The controller also manages the configuration of both NFVIS and the VNFs and extracts the telemetry data that may be required for network analytics. Standards-based interfaces such as REST and NETCONF/YANG are used in the communication between the controller layer and an NFVIS host; hence, the ConfD client is included as part of the NFVIS package Cisco and/or its affiliates. All rights reserved. 4

5 Figure 3. Enterprise NFV Using NFVIS: Building Blocks ISRv ISR4K + UCS-E Enterprise Orchestration Enterprise Controller ASAv vwaas vfirepower VNF n App 1 App 2 App n NFVIS UCS The DNA orchestration layer also handles both physical and virtual services. If digitalized services are implemented using virtualization, the architecture is responsible for instantiating the VNFs at the right time in the right location to provide connectivity to these newly instantiated VNFs. It is also responsible for instantiating or modifying existing policy enforcement points (PEPs) to help ensure that the service makes use of these newly instantiated VNFs. Consider the example of a virtualized branchlocation environment in DNA. In a fully virtualized branch environment, an x86-host is located in the enterprise branch to accommodate all functions in a virtual form factor. Figure 4 shows details of a possible configuration, using a Cisco UCS C-Series Rack Server host with multiple physical LAN and WAN interfaces running NFVIS. Several VNFs are instantiated in this example: an ISRv for WAN connectivity (configured for the Cisco Intelligent WAN [IWAN] solution), a vwaas to offer WAN optimization, and a Cisco Firepower appliance for the IPS and IDS functions. Additional VNFs provide Cisco network analysis module (NAM), wireless support (Cisco Wireless LAN Controller [WLC]), virtualized storage, and host application (Microsoft Windows) functions. The VNFs are connected to the NFVIS virtual switch to link them to either the physical interfaces or to each other. In the example, the ISRv is chained to the vwaas and IPS by forcing the traffic through bridge BR1 and then bridge BR0. The other services are directly reachable from the LAN interfaces through BR0. Figure 4 System Architecture for a Virtualized Branch Location in Cisco Digital Network Architecture ISRv IWAN WAAS IPS(t) NAM WLC Win vstorage NFVIS Hypervisor (KVM) Tap7 Tap6 Tap5 Tap4 Tap3 Tap2 Tap1 Tap0 vswitch BR1 BR0 WAN NIC WAN NIC LAN NIC GE5 GE4 GE0 GE1 GE2 GE3 (t) = transparent, Lines connect to SIDE of the text box Non-transparent VNFs: connectors drawn at the BOTTOM of the text box Cisco and/or its affiliates. All rights reserved. 5

6 Figure 5 shows the workflow to arrive at the forwarding state for branch virtualization. In the initial state, the branch does not have routing or L4-L7 functions deployed or configured. Only the end devices, access switches, and WAN links are present (the latter are not connected). As the first step, a branch profile is configured in the orchestration system, specifying the types of network functions that should be deployed in the branch. Actual device configurations are also associated with each function in the profile. To complete the orchestration setup, the profile is associated with a particular branch instance: for example, by correlating the serial number of an x86 host to be deployed with the geographic location of the branch site. This profile and instance setup is communicated to the DNA controller. Upon successful deployment and power-up of the x86 host (such as a Cisco UCS C-Series Server or a Cisco 4000 Series ISR with a Cisco UCS E-Series blade) at the branch, a PnP process is triggered. Upon bootup, the NFVIS system contacts the DNA controller to request its configuration. Because the controller has received the branch profile and associated device configurations from the initial setup process, it is aware of this branch site and can successfully complete the launch of the NFVIS system in the branch by pushing its device configuration. Assuming that the PnP process is completed successfully, the controller notes the site availability in its inventory for subsequent monitoring and management operations. The controller also notifies the orchestrator about the successful instantiation of the hosts, which triggers the next step in the workflow. At this point, the NFVIS host is operational, but without any VNFs deployed. Before actually instantiating the VNFs for the branch according to the profile, a resource check is performed. The orchestrator requests instantaneous resources from the branch through the controller. Assuming again that sufficient resources are available to instantiate the profile, the orchestrator then triggers the creation and configuration of the virtual switching infrastructure required on the NFVIS host using the controller. Next, requests are initiated to deploy actual instances according to the profile. In this step, the ISRv, vwaas, IPS and IDS, vnam, WLC, Windows, and additional VNFs or applications would successively be deployed and connected to the respective virtual bridges in the OVS. As these VNFs are deployed, the associated device configurations are also pushed to the VNFs according to the profile specified in the orchestrator. The device configurations for the VNFs activate the forwarding path on which the packets flow. Note that all interactions between the DNA orchestrator, the DNA controller, NFVIS, and the VNFs are based on the standard APIs that are part of the solution. Figure 5 Workflow to Launch a Virtual Branch Instance in Cisco Digital Network Architecture NFVIS-Host DNA Controller DNA Orchestrator Operator Configures Branch Profiles Operator defines device Configurations & imports into orchestrator Profile applied to Branch instance Register NFVIS configuration for S/No with Controller PnP Agent contacts Controller with S/No of NFVIS NFVIS-Host & config in inventory Device shipped to Branch ACK NFVIS-host Configuration pushed to host Invoke REST API to get NFVIS Platform details (based on IP address) NFVIS returns host resource details Invoke REST API to create OVS Notification of NFVIS instantiation Request resources status of NFVIS instance (mem, CPU..) Resource profile passed to orchestrator Create OVS bridges Create OVS Bridges(s) ACK OVS Bridge creation ACK Invoke REST API to deploy VNF & pass config Deploy VNFs & pass Day 0/1 config VNFs Deployed ACK ACK 2016 Cisco and/or its affiliates. All rights reserved. 6

7 B. Enterprise NFV: Enhanced Cisco IOS XE Operating System Virtualization of network functions by using NVFs is also supported in the enhanced Cisco IOS XE operating system. Cisco IOS XE was designed specifically to run on Linux. In contrast to the traditional Cisco IOS Software that powers routers and switches, Cisco IOS XE supports full modularity. The software infrastructure is composed of the following elements: Cisco IOS Software control plane Fast-forwarding packet processing data plane Middleware software processes to optimize the interprocess communication between the control plane and the data plane KVM hypervisor to enable virtual network functions or application hosting Consider a more detailed comparison between the traditional Cisco IOS Software architecture and the enhanced Cisco IOS XE architecture. In the former, Cisco IOS Software runs the control plane for the network (routing protocols), drives the hardware (interrupts, memory management, and CPU scheduling), and processes packets in the data plane. All functions are run within a single Cisco IOS Software process. In contrast, with enhanced Cisco IOS XE, the controlplane software is separated from the data plane and the underlying systems management. Cisco IOS XE is a modular operating system in which the hardware management functions are performed by the underlying Linux OS. The Cisco IOS XE control plane is responsible only for running the network control functions, providing consistency and backward compatibility with the traditional Cisco IOS Software system. Because of this Linux-based software architecture in Cisco IOS XE, a KVM hypervisor can be configured directly on the underlying Linux system. This approach allows the underlying hardware resources to be shared not only among the native Cisco IOS XE processes, but also by VNFs that run on top of such a hypervisor. Figure 6 illustrates the Cisco IOS XE architecture at a high level. In particular, it shows the KVM hypervisor environment for running VNFs and hosting applications. This architecture is particularly useful for operators who want to retain their Cisco IOS Software network functions. Any routing or switching functions available in Cisco IOS XE natively will be run by the fast-forwarding packet processing control plane, benefiting from the optimized forwarding path and the multitude of data plane features that can be configured in combination. However, L4-L7 networking functions such as WAAS, advanced firewalls, and IPS and IDS can now also be instantiated in a virtual machine. This feature enables operators to choose best-in-class functions and offers a smooth migration path to virtualization. Cisco IOS XE is complemented by the DNA controller which provides the link to software-defined networking (SDN) based management tools. Particularly noteworthy again is the open API in Cisco IOS XE, which allows the controller to configure and influence the operations of a Cisco IOS XE system programmatically. In addition to CLI calls, Cisco IOS XE supports REST and NETCONF YANG. The main characteristics of Cisco IOS XE are: Software modularity based on Linux Network function virtualization Application hosting Model-based APIs SDN-based management Fog and edge computing Figure 6 Enhanced Cisco IOS XE Enterprise NFV: Building Blocks IOSd Control Plane Cisco Apps (WAAS, Snort) LINUX OS KVM/LXC Customer and 3 rd Party Applications Virtual Ethernet Platform-Specific Data Plane AppNav 2016 Cisco and/or its affiliates. All rights reserved. 7

8 III. Transport Virtualization (Segmentation) Architecture Network segmentation is the capability to split a physical network into multiple logical partitions to separate the traffic from different groups of users and devices. The need for network segmentation in the enterprise is not new, but it is becoming more important as a result of the following recent trends: Internet of Things (IoT) and bring your own IoT (BYOI) Mobility in the next-generation workspace Cloud-enabled services and applications For example, with IoT a lot of traditionally non-ip things (such as healthcare instruments and heating, ventilation, and air conditioning [HVAC] and lighting apparatus) are becoming IP enabled and connected to the network. The enterprise infrastructure needs network partitioning to keep these various systems and their administrative and security policies completely separated. Guest access and user and device mobility are other simple but important use cases in which role-based access to internal resources needs to be guaranteed independent of where endpoints connect. Other common use cases for network segmentation are focused on security: Security for multitenant dwellings: For example, airports with multiple airlines, public-sector buildings with multiple agencies, and enterprise buildings in which departmental separation is required (engineering, sales, human resources, etc.) Regulation compliance: Health Insurance Portability and Accountability Act (HIPPAA) requirements in healthcare, Payment Card Industry (PCI) requirements in retail sales, Sarbanes-Oxley requirements in finance, and many others Security for mergers and acquisitions: For example, the need to keep policies differentiated while dealing with overlapping IP addresses Cloud computing security: Security needs in a multitenant private or public cloud environment To meet new customer requirements and provide a solution to address these important industry trends, network segmentation and virtualization is built into DNA to create logical separation of services at Layer 2 and Layer 3. A. Network Segmentation Architecture The Cisco segmentation architecture is based on three main components: network access control, network service edge, and network path isolation (Figure 7) Figure 7. Segmentation Access Control Network Path Isolation Service Edge MPLS EVN VRF lite Functions Policy Based Access Device Authentication and Authorization Classification and VLAN, SGT, ACL enforcement Map VRFs to VLANs in Access and Service Edge VRF segmentation and transport Traffic Isolation Shared or dedicated Services Inter VRFs routing Isolated App environment 2016 Cisco and/or its affiliates. All rights reserved. 8

9 1) Network Access Control The access control function assigns an identity to the users and things that connect to the network so they can be successfully assigned to a corresponding group. A group is used as a pointer to a set of permissions to allow differentiated access for clients and devices. In the context of network segmentation, the identity also provides the linkage to path isolation and virtualization techniques so that permission is enforced throughout the network and not only at the access network device. Access control consists of three main functions: Authentication: Authentication governs who (devices and users) can access the network. Authentication can be performed dynamically through IEEE 802.1x, Web Authentication (Web-Auth), or network-based classification using network sensors. Alternatively, authentication can be performed statically. Authorization: Authorization defines the policies associated with the authenticated endpoint. Policy enforcement: Policy enforcement associates a parameter to identify the endpoint in the rest of the network. This parameter can be a VLAN, a Virtual Routing and Forwarding (VRF) instance, an access control list (ACL), or a security group tag (SGT). It also enforces the policy in DNA by means of the policy enforcement point. Cisco Identity Service Engine (ISE) is the central platform for policy definition and management. It gathers advanced contextual data about who and what is accessing the network and then defines rolebased access policies. 2) Network Service Edge The service edge is the place (central or distributed) at which an enterprise deploys shared resources (Dynamic Host Configuration Protocol [DHCP], Domain Name Service [DNS], Internet access, etc.) or protected resources (for example, human resources databases). By default, the different logical networks (virtual private networks [VPNs]) built on top of the physical infrastructure are completely isolated from each other, so a mechanism to break this behavior is needed to allow shared resources. The technical solutions to implement shared services across virtualized networks include prefix leaking between routing tables using Border Gateway Protocol (BGP) and Cisco Easy Virtual Network (EVN) route replication and the use of a multiple-context firewall. Providing a separate firewall for each VPN allows the application and management of security policies for each virtual network independently, and it is hence the recommended deployment model. Analysis and discussion of the various deployment modes for protecting access to shared services is beyond the scope of this document. Details can be found in [3]. 3) Network Path Isolation Network path isolation (or network virtualization) refers to the creation of multiple logical network partitions overlaid on top of a common physical network infrastructure. Each partition is logically isolated from the others and must appear to the end device or user as a fully dedicated network, and it must provide all forwarding, security, and services expected from a physical network. Virtualization of the transport layer must address virtualization at both the device level and the interconnection level: Device forwarding virtualization: The creation of VLANs for switches and VRF instances for routers are both examples of techniques to create multiple separated control plane and data plane instances on top of the same physical device. Data-path virtualization: Data-path virtualization is the virtualization of the interconnection between devices. This connection can be a single-hop or a multiple-hop interconnection. For example, an Ethernet link between two switches provides a single-hop interconnection that can be virtualized by using IEEE 802.1Q VLAN tags. When an IP cloud separates two virtualized devices, a multiple-hop interconnection is required to provide end-to-end logical isolation and is usually implemented through tunneling. Cisco has multiple solutions for implementing Network Path Virtualization. They can be classified in two main categories: policy based and control-plane based. Policy-based Path Segmentation Policy-based path segmentation restricts the forwarding of traffic to specific destinations based on a defined policy and independent of the information provided by the forwarding control plane. A classic example of policy-based segmentation is the use of VLANs and related ACLs assigned to a switch port or to a service set identifier (SSID) for wireless users. Groups of devices or users are assigned to VLANs and ACLs by static configuration or as a result of the authentication using IEEE 802.1X or other technologies (Figure 8). Although common for use cases such as guest access, this Layer 2 virtualization solution has scalability limitations: every time a VLAN is added, a series of parameters needs to configured on the network devices (subnet, DHCP pool, routing, etc.) Cisco and/or its affiliates. All rights reserved. 9

10 Figure 8. Segmentation ACL Aggregation Layer VLAN Addressing DHCP Scope Redundancy Routing Static ACL Access Layer Quarantine Voice Data Suppliers Guest Also, the logical isolation provided by VLANs ceases to exist at the boundary between Layer 2 and Layer 3 domains (the distribution-layer devices). To extend the propagation beyond the access device, a VRF instance needs to be defined and mapped to the VLAN. Specific to wireless users, peer-to-peer blocking allows simple segmentation to control traffic between users connected to the same SSID by either dropping the traffic or forwarding it to the core network 1. Peerto-peer blocking is used primarily for the guest WLAN and is configured at the SSID level. For Wi-Fi access, customers have been using Control and Provisioning of Wireless Access Points (CAPWAP) protocol to tunnel wireless traffic from access points to a centralized WLC on top of an IP cloud and to provide the desired segmentation. SSIDs broadcast over the air interface are mapped at the WLC to different VLANs as traffic enters the wired network. To add virtualization at Layer 3, the VLAN can be also mapped to a separate VRF instance on the first-hop layer device as shown in Figure 9. The Cisco WLC does not support overlapping IP addresses at this point. VRF-based segmentation is still supported to help ensure logical separation of the different traffic flows. Figure 9. CAPWAP Tunnels VLAN Blue VLAN Red IP Network VRF Blue VRF Red CAPWAP tunnel 1 The forwarding option is available only for traffic switched centrally at the WLC Cisco and/or its affiliates. All rights reserved. 10

11 Figure 10. Cisco TrustSec Solution Single-Hop SXP Speaker SXP Listener SXP Enabled Switch/WLC Non-TrustSec Domain SGT Capable HW In summary, policy-based technologies do not rely on a control plane to transport the virtualization information and, to provide any-to-any segmentation, they use hop-by-hop propagation. This approach can result in more deployment and management complexity and limited scalability. The Cisco TrustSec solution overcomes the above limitations of solutions based on VLANs and ACLs and brings role-based access control (RBAC) to the network: that is, to all devices in the network and not just the access device. The Cisco TrustSec solution does not require changes in VLANs and subnets and works with the existing design (Figure 10). Cisco TrustSec security is based on three functions: Classification: An SGT can be assigned dynamically as the result of Identity Services Engine authorization. Alternatively, it can be assigned through static methods to map the SGT to a VLAN, subnet, or IP address. Propagation: SGT information can be propagated either inline (hop by hop) or through the SGT Exchange Protocol (SXP). Enforcement: The network device enforces the policy through SGT-ACLs dynamically downloaded from the Identity Services Engine. The Cisco TrustSec tag is inserted at Layer 2 in the Ethernet frame in the Cisco TrustSec metadata (CMD) field. For inline propagation, every node in the network needs to be able to interpret the tag and act on it. If the customer deployment does not require any-toany segmentation, Cisco TrustSec can be used with the SXP protocol, which allows the propagation of SGT information across a network that is not enabled for Cisco TrustSec security. Control-Plane-Based Segmentation Control plane-based techniques achieve path isolation by restricting the propagation of routing information to only subnets that belong to a VPN. To achieve control plane virtualization, a Layer 3 device must use the VRF technology, which allows virtualization of the forwarding plane. Path virtualization technologies can be classified based on the way that virtualization information is transported across the underlying network infrastructure: Multihop path isolation: The virtualized devices are not directly connected, and the virtualization information is carried across a network that is not virtualization aware by the use of a Layer 3 tunneling technology. VRF-lite with Generic Routing Encapsulation (GRE) and Multiprotocol Label Switching (MPLS) VPN are examples of multihop solutions. Single-hop path isolation: The VRF information is carried hop by hop, and all the devices in the path need to be VRF aware. VRF-lite and EVN are technologies in this category. 1) Multihop Path Isolation Techniques VRF-lite with GRE is the simplest multihop technology. A GRE tunnel is built between the routers that are part of the same virtual network, and the VRF instances are mapped to the GRE header. The implication is that GRE peering sessions need to be established among all the routers that are part of the virtual network, and if a router is added in a new site, all the existing routers need to be reconfigured. So the solution does not scale very well. Also, GRE tunneling is implemented in hardware only in higher-end switches such as Cisco Catalyst 6500 Series Switches and Cisco Nexus 7000 Series Switches, and not in lower-end switches that can be found at the edge. For these reasons, this technology has not been widely adopted by customers and is recommended only if it is deployed in a hub-and-spoke topology typical of guest access scenarios Cisco and/or its affiliates. All rights reserved. 11

12 In an MPLS VPN design, the exchange of VPN routes is achieved by using an additional control-plane element called Multiprotocol BGP (MP-BGP), which is an extension of the existing BGP-4 protocol. The MPLS core is made up of provider edge (PE) and provider (P) routers. At the PE level, MP-BGP is used to exchange VRF routes (Figure 11). MPLS VPN uses two sets of labels. The outer label represents the PE destination and is used by the PE routers to forward the packet through the network. The inner MPLS label is the VPN label and carries the VRF information. Only the destination PE will interpret this VPN label and forward the original packet to the associated VRF instance. Figure 11. VRF-Based Segmentation PE DATA 4 Byte IGP Label 4 Byte VPN Label P Original Packet As with GRE tunnel overlay architecture, MPLS VPN architecture based on BGP requires a fullmesh neighbor relationship to be established. The added configuration and management complexity of such full-mesh designs can be mitigated by the deployment of BGP route reflectors (RR) to relay the BGP information to other PEs in the network. In case of an MPLS core, Virtual Private LAN Services (VPLS) can also be used to provide a Layer 2 pseudowire service across the core network. VPLS mitigates the Spanning Tree Protocol problems that arise from PE the extension of VLANs across multiple switches. However, VPLS also requires full-mesh control-plane communication and can limit MAC address scalability. In summary, multihop segmentation techniques have the advantage that they touch and virtualize only the devices at the edge of the network; the rest of the network ignores the VPN information. MPLS VPN solutions scale well and support any-to-any connectivity, relying on an underlay MPLS network based on BGP. This approach can require staff to learn new techniques and hence can increase deployment time and costs. Single-Hop and Hop-by-Hop Path Isolation Techniques An example of a single-hop (or hop-by-hop) isolation technique is VRF-lite. In this case, each and every network device is virtualized as are all the devices physical interconnections. From a data-plane perspective, VLAN tags can be used to provide logical isolation on each point-to-point link that interconnects the Layer 3 virtualized network devices. VRF-lite does not rely on the MP-BGP or MPLS label to carry the network segmentation information. Instead, it requires hop-by-hop path isolation. Separate interfaces or subinterfaces must be provisioned for each virtual network on core-facing interfaces on an end-toend virtualized path. Figure 12 shows VLAN-based segmentation with VRF-lite. The use of multiple VRF instances is suitable for networks with a limited number of VRF instances and hops in a virtual network path. As the number of virtual networks grows, new interfaces and subinterfaces and related IP addresses and routing will need to be added, increasing planning and provisioning overhead. To address this complexity, Cisco introduced Easy Virtual Network, or EVN. Figure 12. VLAN-Based Segmentation with VRF-lite R1 R q 802.1q 802.1q 2016 Cisco and/or its affiliates. All rights reserved. 12

13 Figure 13. VLAN-Based Segmentation with Cisco EVN Edges Interfaces Trunk Interface Edges Interfaces 802.1q vnet tag 802.1q R1 R2 With EVN, path isolation can be achieved by using a unique tag for each virtual network. This tag, the virtual network (VNET) tag, is operator assigned. An EVN device on the virtual path uses the tags to separate traffic among the different virtual networks. This approach eliminates the need to depend on physical and logical interfaces to provide traffic separation. As illustrated in Figure 13, only a single trunk interface is required to connect a pair of EVN devices. Also, instead of having to add a new field to carry the VNET tag in a packet, the VLAN ID field in IEEE 802.1Q is repurposed to carry the VNET tag. In summary, VRF-lite and EVN are IP-based solutions that reuse familiar technologies such as IEEE 802.1Q and Interior Gateway Protocol (IGP) routing protocols to provide virtualization. This approach can provide straightforward migration from existing campus architecture and less need for staff learning (for example, because complexities arising from BGP are eliminated). Also, VRF-lite is supported on all the major Cisco Catalyst switches starting with the Cisco Catalyst 3000 Series. With EVN, Cisco enabled easy implementation with the use of EVN tags and features such as route replication that allow greater scalability (up to 32 VRF instances is the current recommendation). Evolution of the Virtualization Technologies The previous sections of this document focus on the virtualization techniques available for deployment in enterprise network architectures today. Additional virtualization solutions first developed for data center architectures are now also starting to be applied in other network domains. For transport virtualization, protocols such as Cisco Locator/ID Separation Protocol (LISP) and Virtual Extensible LAN (VXLAN) are evolving to meet most of the requirements for an optimal segmentation solution: Easy to deploy: The more complex a solution is to deploy, the greater the operating expenses (OpEx). Security-group-based policy: Traffic between devices can be isolated. Scalable: Any-to-any connectivity is provided with no configuration burden. Address family independent: IPv4 and IPv6 are both supported. Incrementally deployable: Incremental deployment helps provide a migration path from the current customer architecture. Mobility aware: Easy mobility for wired and wireless hosts is provided. LISP and VXLAN in combination promise to overcome the scalability limitations of the policy-based technologies described earlier in this document: in particular, the operational challenges imposed by hop-by-hop segmentation. Because it is based on an IP packet format for transport, VXLAN allows virtualization information to be carried in the IP header. Only network elements at the edge require virtualization awareness, and any intermediary network elements operate in IP-forwarding mode only. An IP-based transport such as VXLAN helps organizations migrate to virtualization by eliminating the need for major equipment upgrades and allowing gradual introduction of the new technologies. A LISP control plane can also benefit transport virtualization by facilitating a scalable mechanism to distribute segmentation information. Identity information for endpoints can also be decoupled from the actual location information by the use of the aforementioned techniques with VXLAN and LISP, breaking the bond between endpoint location and identity that is inherent when the IP address is used for both location and identity. Network-based solution: No host change is required Cisco and/or its affiliates. All rights reserved. 13

14 An upcoming evolving NFV technology is based on the concept of service-function chaining (SFC) using the network services header, or NSH. SFC allows the deployment of network functions independent of location. Traffic flows are classified at the network edge, and a header describing the services required for the flow is pushed onto each packet. The (virtualized) network services are then reached by the SFC architecture through overlay tunnels governed by a controller. For example, a flow can be subjected to immediate deep packet inspection (DPI) based classification as the user-network interface (UNI) is traversed. It can then require processing by a firewall instance in a regional office followed by processing by a web filter that is cloud based. SFC enables these services to be applied at the network edge by imposing the respective header for such a chain and by automating the transport path between the services. Another benefit of NSH-based service chaining is the inclusion of metadata in the packet header. The NSH fields added to a flow not only signify the service sequence. They can also carry metadata pertinent to a packet between services, such as the application type or additional segmentation information. Appendix A: Glossary API: Application programming interfaces help enable network elements or functions to be controlled by outside applications. Typically, an API is a set of functions that can be called into a software program with specified parameters and formats to provide input data or receive output from the function. APIs can enable openness and flexibility in Cisco Digital Network Architecture by allowing third-party vendors to contribute to network operations and to accelerate deployment of new services. Cloud: The cloud is the computing, storage, and networking infrastructure offered by the aggregate set of cloud providers as services to run enterprise applications. The cloud is made up of all the data centers used by cloud providers to host applications. The advantage of cloud computing is that these services can be acquired instantaneously upon demand, so that enterprises do not need to invest in data center infrastructure (saving both capital expenditures [CapEx] and operating expenses [OpEx]). The cloud provider services the resources to help ensure that capacity meets demand and that cloud services are offered with redundancy and security. Cloud computing offers a different consumption model (subscription pricing) for computing. Controller: A controller is a network component that manipulates the network elements in Digital Network Architecture according to the policies (to instantiate the services). The controller maintains the full holistic current state of the network: that is, it keeps an abstracted network state. The controller interfaces with the orchestration and policy layers through a northbound interface. Controllers instantiate configuration entries in the network to create transport paths or to implement the services that are offered to the endpoints using a southbound interface. In Digital Network Architecture, a single controller can span multiple domains (cloud, WAN, campus, and data center). Alternatively, multiple controllers can collaborate, each fulfilling a domainspecific role. The functions that controllers run can even be divided among multiple subcontrollers, each specializing in a particular control task, such as monitoring and manipulating the QoS state of the network. Devices: Devices are physical systems capable of running applications and sending or receiving network traffic. Digitalization: Digitalization is the process of bringing digital technologies into all aspects of an enterprise s business and offering digitalized services to the business s consumers. Digitalization also refers to the act of converting business processes into digital formats and take advantage of automated algorithms and processes to optimize and simplify either internal operations or interactions with consumers. DPI: Deep packet inspection is a technique to determine the type of the application carried in an IP flow by inspecting the payload, often over multiple packets, and making inferences based on the payload. This approach contrasts with application characterization based on TCP port numbers or payload type fields, which are often insufficient to adequately characterize an application. Endpoint: Endpoints are consumers of network services defined at the application level. They can run on traditional hosts such as PCs, notebooks, and IP phones, and also increasingly on IP-enabled devices that drive digitalized business processes: robots, point-of-sale (POS) displays, scanners, inventory tracking devices, vehicles, and more. Applications running on servers in a data center are considered consumers of network services and are therefore endpoints in the architecture Cisco and/or its affiliates. All rights reserved. 14

15 Endpoint group (EPG): And EPG is a categorization of multiple endpoints into one logical entity receiving a service from the network. An EPG could bundle all endpoints from a particular end device, for example. Alternatively, an EPG could bundle all endpoints from a particular end user, with the endpoints on multiple physical devices. The term endpoint is used loosely in this document to mean both individual endpoints and endpoint groups. Fabric: A fabric is a collection of network elements that offers communication paths between its outbound-facing ports, providing any-to-any connectivity through the use of overlay tunnels. A fabric is governed by a controller to simplify operation. A service can be instantiated by applying the right policy enforcement to characterize the service instances, and by using the any-to-any connectivity offered by the fabric to reach the service s remote ends. Intent: Intent is the association of a business process with a service. The purpose, or intent, of a service delivered by the network is to implement the business processes relevant to the enterprise. Services, therefore, implement the business intent of the enterprise, and a policy specifies how the service is implemented and enforced by the network. Internet of Things (IoT): The IoT is the extension of the Internet to reach not only traditional computing resources such as PCs, notebooks, and servers, but also any device. This definition implies that IoT devices must become networked: that is, they must be extended to include computing resources on which a networking software stack can run. The definition also typically implies that IoT-enabled devices can run digitalized business applications to benefit from Internet connectivity. Examples of IoT devices include refrigerators, cameras, vehicles, parking meters, production robots, elevators, RFIDequipped hardware, and sensors. The advantage of networked objects equipped with software stacks is that these devices can be controlled remotely, so they help digitalize business processes and services. Intrusion prevention system (IPS) and intrusion detection system (IDS): IPSs and IDSs are sets of network functions that continuously monitor the network. The systems look for behavioral anomalies and malicious activities and take appropriate actions (such as blocking or reporting) when such activities are detected. These systems often rely on baseline behavior characterization (signatures), against which the anomalies are defined. Statistical methods may also be employed. Open networking: Open networking allows the operation of the network architecture to be influenced by third-party software or hardware vendors. It relies on standards-based and published APIs to facilitate such integration. Open networking empowers the community of developers outside Cisco to contribute to network operations and capabilities. Open networking increases the speed of innovation and introduces more flexibility into the network. Orchestrator: This orchestrator allows controlled specification of services in the network and instantiation or ongoing modification of those services. The orchestrator in Digital Network Architecture focuses on service definition from the network consumer s point of view, thus abstracting any low-level details about how, and sometimes where, those services are to be configured. The orchestrator determines the service intent and communicates this to the controller. The controller then manipulates the network elements to provide the transport between the relevant policy enforcement points, to instantiate the policies (transport, security, etc.), and to help ensure that services are monitored on an ongoing basis. Overlay network: The overlay network is based on network tunneling that sits on top of an underlay network. Tunneling techniques are used to decouple a network service from the underlying transport infrastructure. The state of the service is retained only at the edge of the network. For all network elements that make up the underlay network, the tunneled service traffic appears simply as the encapsulated tunnel traffic. Overlay networks are characterized by: Segregation of traffic between users Support for different address spaces Support for dynamic device or virtual machine placement (independent of the underlay topology and addressing) Support for large-scale deployments A network is fully virtualized if virtual network functions, such as routers or firewalls, are connected to each other using VLANs or VRF instances Cisco and/or its affiliates. All rights reserved. 15