White Paper Automating Enterprise Networks with Cisco DNA Center 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 30
Contents Introduction... 3 DNA Center automation principles... 4 DNA Center building blocks... 5 Automating the enterprise network infrastructure... 8 Standardizing the enterprise network architecture... 9 Standardizing device configurations with network profiles... 10 Onboarding and deploying network elements with DNA Center... 11 Automating network deployments and lifecycle management... 13 Automating fabric deployments for Cisco Software-Defined Access... 15 Automating DNA services based on policies... 17 DNA Center access policies and virtual network segmentation... 18 DNA Center access control policies... 20 DNA Center application and traffic copy policies... 22 DNA Center Platform... 26 For more information... 30 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 30
Introduction The enterprise networking landscape has changed dramatically in recent years. Enterprises are presently relying on digitized processes powered by thousands of networked devices to drive their business operations. As a result, the number of managed endpoints has increased substantially. Endpoints have also become more diverse in kind, ranging from small networked sensors, scanners, handheld devices, notebooks, laptops, and smartphones to powerful platforms running enterprise applications. These trends have stretched many IT and networking departments, which are often challenged to manage and maintain such a fast-evolving and diverse network environment, sometimes with fewer and fewer operators. As a result, the networking industry has seen an increased demand for network automation solutions to allow the network to continue to grow, reduce the time to onboard new devices and services, and minimize configuration errors while ensuring that corporate and regulatory standards are in compliance, and that security is not compromised. This white paper provides an overview of the automation capabilities of Cisco DNA Center. DNA Center allows the operation of enterprise networks as a system, covering wireless and wired access, campus networks, and routing technologies. DNA Center also realizes Intent-Based Networking (IBN) in the enterprise. Network operators can express the intended behavior of the network based on policies. The expressed intent is activated in the network infrastructure based on automated provisioning workflows. Telemetry data is continuously collected to assure that the expressed intent is adhered to while maintaining network security, providing a continuous verification loop (Figure 1). Figure 1. The Cisco intent-based networking architecture 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 30
The DNA Center automation capabilities explored in this white paper focus on the activation and policy translation functions of IBN. The concepts of workflows and DNA Center applications are introduced to automate standard and nonstandard network changes, with a particular focus on the design and provisioning workflows. The white paper also examines how DNA Center helps to translate intent into network policies. An overview of the DNA Center Platform architecture is also provided. This white paper is intended for CTOs and network architects seeking to gain an introduction to the automation capabilities of DNA Center. Network operators embarking on the journey toward IBN may also benefit from this paper. For interested readers, the reference section provides additional details that explore many of the concepts outlined herein in depth. DNA Center automation principles Cisco DNA Center automation is built around the principles of network element lifecycle management and policybased automation, while supporting integrated IT process automation. Lifecycle management of network elements is supported in DNA Center with workflows and automation applications. Network architects can start with the design workflow to standardize the topologies and functionality to be deployed in their enterprise wired and wireless campuses or branch environments. Cisco DNA Center models the enterprise network as a hierarchical set of sites, each of which can be associated with one or more buildings containing multiple floors. Standardized deployment templates can be stored in a library to be applied at provisioning time. Lifecycle management also accommodates a provisioning workflow, in which network elements and services can be automatically deployed. As network elements are powered up, they may call in to Cisco DNA Center to be provisioned according to the template associated with the site or building during the design workflow. Changes made to the templates after the initial deployment can similarly be automated to help ensure continuous alignment of the network configuration with the standardized deployment templates. The principle of policy-based automation is realized in Cisco DNA Center using the policy workflow. Operators can author policies that govern the relationship between endpoint groups or applications using the DNA Center user interface. Similarly, the application policy functionality regulates the treatment that application flows receive in the network. Network architects can express the intended importance of applications in abstracted categories (such as default, business relevant, or irrelevant ), triggering the appropriate automation to configure the network elements throughout the enterprise network domain. Cisco DNA Center achieves the principle of IT process automation by enabling tight integration of its workflows and automation applications with the wider enterprise IT process ecosystem. The DNA Center workflows themselves support IT processes by defining a well-structured sequence of operations that can be automated, logged, and audited. Integrations of external tools such as IP address management or service management functions are examples of DNA Center supporting IT processes that are often performed by different teams. The tight linkage to the Cisco Identity Services Engine for access policy governance is another example of linking DNA Center into enterprise IT toolchains. Figure 2 summarizes the main functions of the DNA Center workflows. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 30
Figure 2. DNA Center workflows for design, policy, provisioning, and assurance DNA Center building blocks Cisco DNA Center offers a platform for automating and assuring the operation of an enterprise network. The platform is built based on automation and assurance processes with an elastic infrastructure. The design, policy, and provisioning workflows used to automate the enterprise network operations are all realized based on microservices, in which respective software functions are implemented in multiple containers communicating with each other, rather than amalgamating all workflow and automation functions into a single software binary. For example, the inventory application collects and establishes an inventory of all network elements that are governed by DNA Center. The topology application provides a graphical view of the network topology, representing the network hierarchy that consists of sites, buildings, and floors, with routers, switches, wireless access points, and other physical and virtual network elements. The three main workflows supported by Cisco DNA Center for automation are Design Policy Provision 1 1 Cisco DNA Center also offers an assurance workflow that is not within the scope of this automation white paper. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 30
These workflows can be viewed as a set of related automation microservices to cover the design, the policy authoring, and the provisioning (and update) phase of the network lifecycle. Supporting the top-level workflows is a set of automation tools. These allow DNA Center operators to perform specific, networkwide tasks in support of the automation workflows. The current set of automation applications includes Network Discovery: Automates the discovery of existing network elements to populate into the inventory Inventory Management: Manages the set of physical and virtual network elements that are governed by DNA Center Topology: Visualizes the physical topology of enterprise routers, switches, access points, and other physical and virtual network elements Network Plug and Play: Supports the automated configuration of network elements Image Repository: Manages software images for the various network elements License Manager: Administers and visualizes software license usage in the enterprise network Command Runner: Provides a utility to diagnose one or more network elements based on a Command-Line Interface (CLI) Template Editor: Enables the creation and authoring of CLI templates associated with network elements in a design profile Figure 3 shows the Cisco DNA Center landing page, displaying the workflows and tools. Figure 3. Cisco DNA Center landing screen depicting the workflow tabs and automation and assurance tools 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 30
Cisco DNA Center offers networkwide operations to drive consistency and standardization into the enterprise network. Automation operations are not limited to individual network elements. The enterprise network can also be viewed as a system consisting of routers, switches, access points, and other network elements that are connected to each other. In addition to offering atomic operations (such as managing the software images of the set of Cisco Catalyst 9000 switches, for example), DNA Center captures the relationships between network elements. Examples of this include the ability to view the network topology or to design the architecture of a site, rather than automating the constituent network element configurations. DNA Center supports network-level automation in addition to device-level automation. At the heart of DNA Center automation is a powerful automation and orchestration engine. Abstracted expressions of intent for infrastructure operations or policy are modeled within DNA Center using the YANG modeling language. The workflow engine then takes abstracted, networkwide models and derives device configurations through a set of model transformations to break the networkwide abstracted model into device-specific models and ultimately device configurations. The resulting configurations are instantiated into the network elements with a controlled orchestration using RESTful interfaces. The automation engine regulates the sequence with which devices are configured, and provides rollback capabilities in case of a configuration failure. DNA Center supports multiple configuration mechanisms, including CLI or NETCONF, depending on the current capabilities of the possibly diverse routers, switches, access points, and wireless LAN controllers in the enterprise network. The base infrastructure in the Cisco DNA Center system architecture provides the capabilities to run automation microservices in containers. Automation functions are implemented in smaller functional groups that communicate with each other and run in software containers with their own namespaces, rather than in a single software image. These containers can expand or contract based on the load that a microservice experiences (supported by the appropriate load balancing). The base infrastructure also offers common functions for automation microservices, such as databases and an associated management system for state storage, and a stream-processing information bus for the sharing of vast amounts of data between DNA Center microservices. The base platform also provides the necessary authentication and security functions for DNA Center to be operated by multiple teams, often with different privilege levels. Figure 4 illustrates the high-level system architecture of Cisco DNA Center. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 30
Figure 4. Cisco DNA Center high-level software architecture Automating the enterprise network infrastructure At a high level, DNA Center automation can be categorized into Network infrastructure automation Cisco DNA service automation Network infrastructure automation concentrates on bringing up, connecting, and maintaining the routers, switches, access points, and other network elements that make up the enterprise network. It includes tasks such as provisioning a network element, loading an initial configuration, updating device configurations as new services are introduced, maintaining software images, and managing licenses for the device. These automation tasks relate to the network infrastructure, as opposed to relating to the Cisco DNA services that connect endpoints to applications or to each other. Cisco DNA service automation focuses on the services that the DNA Center network delivers to endpoints and applications. Service automation instantiates policies that govern whether endpoints and applications are granted access to the network, what communication relationships they can establish with other endpoints or applications, and how the traffic flows between endpoints or applications are to be treated by the network infrastructure. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 30
A key aspect of automation is to increase the level of standardization in the network. Architectures with a wide variety of network elements (possibly from different vendors), software versions, device configurations, or site topologies are very hard to automate. Such variations in the network by definition typically require customized automation processes, thus diminishing the benefits of networkwide automation. Increasing the level of standardization in the network for example, by templating device configurations, reducing the catalog of allowed network elements, or minimizing the number of different software versions deployed increases the efficiency and benefit of network automation. Change requests in the network often come in varying levels of standardization. Repetitive network operations tasks are prime candidates for automation. Examples are standard network settings (IP addresses of Network Time Protocol [NTP], Dynamic Host Configuration Protocol [DHCP], and DNS servers), as well as many port/interface or VLAN settings. Such tasks may be automated with single actions or tools. Other network operations tasks are more intricate in nature, possibly requiring committee approval or proven to cause service disruptions. For example, performing a software upgrade on a critical infrastructure router or switch falls into this category. Automation can still be beneficial in those cases but may need to be designed around a workflow rather than individual tasks. Standardizing the enterprise network architecture Cisco DNA Center helps drive standardization for both single as well as workflow-based operations. The enterprise network architecture can be captured as a hierarchy consisting of connected sites, each comprising one or more buildings, possibly with multiple floors. Essential network settings such as device credentials, IP address pools, parameters for DHCP, DNS, NTP, Simple Network Management Protocol (SNMP), and other supporting network functions can also be captured networkwide or for each site to avoid misconfigurations. Other areas of standard settings supported are service provider Quality-of-Service (QoS) templates or wireless settings, which can be defined for the entire network or restricted to specific sites. Figure 5 shows an example of how standard settings can be automated with DNA Center. Figure 5. Standardizing base automation parameters in Cisco DNA Center 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 30
Standardizing device configurations with network profiles Network profiles allow an architect to specify well-defined deployment templates and architectures. For example, for nonfabric switching deployments, configuration templates can be associated with a profile. For wireless access points, both configuration templates and SSID parameters can be linked to a deployment profile. For virtualized branches based on the Cisco Enterprise Network Functions Virtualization (ENFV) solution, a full subworkflow can be executed in DNA Center. Cisco ENFV is based on x86 hosts running the Cisco Network Functions Virtualization Infrastructure Software (NFVIS) and operating virtualized network functions on top of a hypervisor environment. The network profile for ENFV enables the characterization of the x86 hosting platform, including the Cisco Enterprise Network Compute System (ENCS), Cisco UCS, or Cisco 4000 Series Integrated Services Routers (ISRs). The connectivity to the WAN can be determined by selecting the number of service providers connecting to the branch and the redundancy model of the branch. The initial screen of the virtual branch deployment is shown in Figure 6. Figure 6. Standardizing a NFV architecture template in the Routing and NFV workflow The virtual branch architecture can be further detailed with the number and type of Virtual Network Functions (VNFs) that are to be deployed as per the profile. Figure 7 shows the standard selections for different types of VNFs. For each type, a specific VNF product can be selected, such as the Cisco Integrated Services Virtual Router (ISRv) for a virtual router, the Cisco Adaptive Security Virtual Appliance (ASAv) for a virtual firewall, or a virtualized Wide Area Application Services (WAAS). Third-party VNFs can be characterized in these virtualized architecture templates. Non-networking VNFs can be added to the profile, such as Linux or Windows VMs. The physical resource requirements in terms of virtual CPU, virtual memory, and virtual storage are implied in the deployment profile that is associated with a VNF in this design step. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 30
Figure 7. Selecting NFV functions in the Cisco DNA Center Routing and NFV workflow The outcome of the DNA Center design workflow is a set of parameters for the network infrastructure elements (DNS, DHCP, and other supporting services), as well as deployment profiles for switches, wireless access points, and virtual or physical routers. These network profiles are associated with one or more sites in the network hierarchy, such that they can be applied if a device is onboarded into DNA Center. Onboarding and deploying network elements with DNA Center Network elements and enterprise network topology can be onboarded into Cisco DNA Center using multiple methods: Network discovery The network discovery tool enables the detection of existing network elements in an existing network. Devices can be searched for based on a given IP address range at Layer 3, or based on the Cisco Discovery Protocol or the Link Level Discovery Protocol (LLDP) at Layer 2. Detected devices are placed in the DNA Center inventory for subsequent network operations. Network plug and play Cisco DNA Center hosts a Plug-and-Play (PnP) server that assists in the onboarding of new devices. Any device that is network PnP capable can call in to this server to announce itself to DNA Center. Upon successful completion of the PnP process, the operator can choose to claim the network element into its inventory if the device is trusted in the network. Once added to the inventory, the device is ready for further DNA Center operations. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 30
Network elements can learn about the DNA Center PnP server address using various mechanisms. If the network element is staged, the PnP server address can be manually configured before shipment to a site. Alternatively, the PnP server address can be communicated as part of the device s DHCP process in DHCP option 43. The DHCP server can be configured to pass option 43 back to a DHCP request, containing the IP address of the DNA Center PnP server. Alternatively, if DHCP option 43 is not an option, DNS can assist in the determination of the appropriate DNA Center PnP server. The device can resolve the Fully Qualified Domain Name (FQDN) pnpserver.<domain.com>, which can be mapped in the DNS server against the DNA Center PnP server IP address. A cloud option from Cisco is also available, in which Cisco Software Central can be contacted to associated the network element with a DNA Center instance based on the Cisco.com credentials of the operator. LAN automation In a new campus environment, multiple switches can be added to Cisco DNA Center automatically, based on LAN automation. Upon selection of a seed device (typically the border router), the campus topology is automatically detected by the LAN automation process. LAN automation is based on PnP as a functional component. The seed device locally acts as a PnP server to provide the appropriate software images and device configurations to discovered network elements. Detected switches are configured with the appropriate IP addresses out of a given pool, as well as underlay routing based on Intermediate System-to- Intermediate System (IS-IS) to form a prescribed underlay campus transport network. Manual onboarding Network elements can also be added manually into the DNA Center inventory based on a graphical user interface. Individual devices can be added by providing the name or IP address along with necessary credentials. Multiple devices can be uploaded by providing the necessary information in a CSV file. Again, once a single or multiple devices appear in the inventory, Cisco DNA Center can be used for subsequent automation operations. Once a device has been authenticated into the network, it is added to the inventory. For the device s initial deployment to proceed in the DNA Center workflow, it must be associated with a site in the network hierarchy. This creates the required link to the desired network profile to be applied to the network element. DNA Center correlates the network profiles that have been associated with a site during the design workflow with the devices that have been associated with a site in the onboarding workflow. The desired network profile is determined, and corresponding configurations are automated into the network element. For example, for a newly onboarded Cisco ENFV system running NFVIS, DNA Center applies the desired network profile, including Instantiation of the VNFs defined in the profile Creation of the desired network connectivity to neighboring network elements and within the x86 host 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 30
Automating network deployments and lifecycle management Ongoing changes and modifications can be automated with Cisco DNA Center using the automation tools as well as the design and provisioning workflows. Alterations to the network design profiles for switching, wireless, and routing/nfv templates can be made using the same procedure outlined above. The profile modifications can be saved to the existing library for subsequent deployment. Similarly, the provisioning workflow can be leveraged to push modified network profiles to any associated sites. This allows network operators to determine the time a network change is deployed. The workflow prompts for the required deployment parameters, such as variables that may have been used in the template editor or any modifications to the VNF set associated with a virtualized branch design. The Inventory Management, Topology, License Manager, and Image Repository automation tools can also assist in the ongoing operations of the network. The current state of the devices under management is displayed using the Inventory Management tool. This allows operators to ensure that all devices are in a managed state (that is, are under control of Cisco DNA Center), as well as to monitor network element details such as assigned IP address for management, MAC address, uptime, configuration, and other details. Similarly, the topology tool allows operators to maintain a good understanding of the state of the physical connectivity between devices. The Image Repository tool in Cisco DNA Center offers ongoing software image lifecycle management. Software images for the various device types under management can be uploaded into DNA Center s image library. The tool provides the status for each uploaded software image, including security verification, software version number, the association with actual devices, and which role the software is being deployed for (core, distribution, access switching, border routing, etc.). Figure 8 illustrates the main user interface for the DNA Center Image Repository tool. Figure 8. DNA Center Image Repository tool 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 30
Importantly, the Image Repository tool offers various tasks for managing software images throughout the network. New images can be uploaded from Cisco.com, from a local network server, or from a local file. Images can be tagged as golden, indicating that the version is approved for deployment by a network engineer or architect. Software upgrades can be automated using the update device function, allowing for all or selected devices to be targeted for upgrades and reporting on the upgrade status. The automated deployment of a software image does not simply push a file onto the targeted network device. DNA Center performs sophisticated predeployment and postdeployment validation checks. For example, in predeployment validation, the Image Repository tool ensures that sufficient capacity is available on the device to receive the upgrade, and that the device is compatible with the intended software version. An example of a postdeployment check is the validation that the upgrade has been successful and that the device is operational again. The entire software image upgrade process can also be embedded into IT service management workflows, as shown in Figure 9. Figure 9. Functional elements of the Cisco DNA Center software image management process 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 30
Automating fabric deployments for Cisco Software-Defined Access The Cisco Software-Defined Access (SD-Access) solution can also be deployed automatically with the fabric provisioning workflow. Recall that the SD-Access solution provides intent-based networking for campus networks. Fabric edge switches are connected to fabric border nodes using a Virtual Extensible LAN (VXLAN) overlay to provide end-to-end user segmentation based on Group-Based Policy (GBP). Fabric edge switches connect wired or wireless endpoints to the SD-Access infrastructure using physical ports or fabric-enabled Access Points (APs), respectively. SD-Access fabric edges represent the policy enforcement points, governing which users and devices gain access to the network. Fabric border nodes provide connectivity to external Layer 3 domains in the enterprise network, including the WAN or the Internet. A Locator-ID Separation Protocol (LISP)-based control plane maps endpoint identifiers to device relationships, allowing for devices to seamlessly connect to the SD-Access fabric using either wired or wireless access with consistent policy. The decoupling of endpoint identification from the Layer 2 or Layer 3 transport topology allows powerful policies to be applied. The IP addresses assigned to hosts are no longer used for both device reachability and policy. Policies can be anchored against the VRF and Scalable Group Tag (SGT) information in the VXLAN header, while the IP addresses of the outer encapsulation ensure reachability from a transport perspective. Deployment of a Cisco SD-Access fabric entails the following steps: Provisioning of fabric edge nodes Provisioning of one or more fabric border nodes Provisioning of a fabric control bode Cisco DNA Center allows the automated provisioning of one or more fabric domains using the fabric provisioning workflow. The initial landing screen in DNA Center allows operators to define one or more SD-Access fabric domains, each defined with its own fabric control, fabric border, and fabric edge nodes. DNA Center can thus be used to control multiple sites with a single pane of glass, as illustrated in Figure 10. Figure 10. Fabric creation landing screen in Cisco DNA Center 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 30
Selection of a particular fabric domain brings up the topology of devices in the inventory. For an SD-Access fabric to be created, at least one fabric border node and one fabric control plane node can be selected graphically. One of the network elements in the topology can be graphically chosen and assigned to the role of fabric border node. The node properties permit the designation of the chosen network element as either internal or external borders. Internal fabric borders track routes that are known throughout the enterprise network domain. Internal borders export all internal IP pools to the connected domain using traditional routing protocols, and also import IP subnets known in the enterprise into the LISP control plane mapping system. External borders (or default borders) track routes that are unknown, such as prefixes located in the Internet. An external border in the SD-Access architecture acts as a gateway of last resort, exporting all internal IP address pools into traditional IP routing protocols. Unknown routes are not imported into the LISP mapping system. Details of the routing protocol, autonomous system, or process numbers are determined as part of the fabric border selection workflow. Similarly, one of the network elements in the topology can be graphically selected to perform the fabric control node functionality in SD-Access. A network element can even be chosen to act as a combined fabric border and fabric control node. Finally, one or more switches in the topology can be nominated graphically to be fabric edge nodes. Such nodes are responsible for identifying and authenticating endpoints, and registering the endpoint identifier with the fabric control plane node. Fabric edges in Cisco SD-Access also provide an anycast Layer 3 gateway for all connected devices. The same anycast Layer 3 gateway is provisioned throughout all fabric edge nodes, allowing for seamless mobility in case of a nomadic endpoint. Fabric edge nodes encapsulate incoming IP flows into the VXLAN overlay network with the appropriate segmentation information (virtual network) and SGT value. Figures 11 and 12 illustrate details of the Cisco SD-Access provisioning workflows. Figure 11. Cisco DNA Center fabric provisioning workflow 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 30
Figure 12. Selecting fabric edge, fabric border, and fabric controllers to build a Cisco SD-Access domain The Cisco DNA Center automation engine mechanically provisions the fabric border, fabric control, and fabric edge nodes with their respective device configurations. Fabric border nodes are configured with the appropriate routing configuration to connect to external (known or unknown) domains. Configuration to reach the fabric control plane node is also added as part of this workflow. For any virtual network, a VRF instance is created. Fabric control nodes are provisioned with the appropriate LISP configuration for the Map Server/Map Resolver (MS/MR) to run the LISP host-tracking database. For fabric edge nodes, VRFs and VLANs corresponding to the desired virtual networks are created by the SD-Access provisioning workflow. Policy Enforcement Point (PEP) configurations to authenticate endpoints are also pushed to the designated fabric edge devices. The creation of a Cisco SD-Access fabric with its constituent fabric border, fabric control, and fabric edge nodes is an operational prerequisite for the group-based SD-Access policy workflows described next. Automating DNA services based on policies DNA Center automates Cisco DNA services connecting endpoints notebooks, desktops, printers, IoT devices, etc. to each other or to applications based on policies. DNA Center supports multiple types of polices to regulate endpoints and their generated IP traffic: Access policies govern admission to the network. Endpoints are authenticated and permitted to connect to the network only if authorized. Upon successful authorization, endpoints can be segmented into virtual networks to separate traffic for security reasons. Access control policies govern communication patterns between endpoints and applications. Admitted endpoints can be segmented into virtual networks to prevent communication between certain user and endpoint groups for security purposes. Traffic flowing between two or more endpoints and between endpoints and applications can be permitted, denied, or otherwise regulated by such policies. Application and traffic policies govern how application traffic should be treated by the network infrastructure. Prioritizing certain applications over others or redirecting traffic are examples of such policies. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 30
Cisco DNA service automation is based on groups. Endpoints and users operating them can be grouped based on common criteria such as device types, location, function, or otherwise. Access and access control policies can be authored against groups defined in the Cisco Identity Services Engine (ISE), allowing for application groups to be learned from Cisco Application Centric Infrastructure (Cisco ACI ). Applications can be grouped within DNA Center into business-relevant, default, and irrelevant categories. Grouping of endpoints and applications facilitates the creation and scale of policies. Figure 13 depicts the initial user interface for the Cisco DNA Center policy workflows. The initial policy workflow landing screen provides a summary of the known endpoint and application groups (based on either SGTs or IP subnets) and the number of virtual network segments deployed in the network, as well as the number of deployed access control policies (for both fabric and nonfabric campus deployments). A summary statistic of the deployed traffic copy policies is also displayed on the initial DNA Center policy workflow landing screen. The Policy History list provides the DNA Center operator s recent activity in authoring or deploying policies, including metadata about the policy type, version, operator, description, scope, and timestamp. Figure 13. Cisco DNA Center Policy landing screen DNA Center access policies and virtual network segmentation Access policies in a Cisco DNA infrastructure are regulated exclusively by Cisco ISE, which acts as an Authentication, Authorization, and Accounting (AAA) server. Policies that determine which user or endpoint is admitted into the network can be expressed in the Cisco ISE user interface. Users and devices can furthermore be dynamically grouped together, each group being represented by an SGT. Group definitions can also be imported into Cisco ISE from the Cisco ACI controller that governs the data center. Application groups defined in Cisco ACI can be ingested into the list of available groups in Cisco ISE using REST API calls, and passed on to DNA Center. This allows for policies to be authored based not just on the user and endpoint groups defined in Cisco ISE, but also on application groups. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 30
Cisco ISE provides the capabilities to author access policies against such groups. In addition, the groups that are defined or imported into Cisco ISE can be passed to Cisco DNA Center for traffic segmentation based on virtual networks. Figure 14 illustrates how the imported groups can be associated with a virtual network in the Cisco SD- Access solution. The group definitions available in Cisco ISE are displayed for selection and graphical association with a virtual network segment. Endpoint and application groups associated with one virtual network by default cannot communicate with endpoint and application groups associated with another virtual network. Communication between virtual networks is restricted, providing complete isolation. Figure 14. Defining access control policies in Cisco DNA Center Once the desired access and virtual network segmentation policies are defined in Cisco ISE and Cisco DNA Center, respectively, they are automatically pushed to the network infrastructure elements. Optionally, as users and endpoints authenticate, Cisco ISE can use RADIUS to automatically deploy the appropriate SGT to be added to IP traffic. Cisco ISE also configures an access control list based on IP subnet or SGT (SGACL) to permit or deny endpoint traffic seeking to enter the network. The appropriate device configurations to reflect virtual networks defined in the policy authoring workflow are pushed by DNA Center to all fabric edge devices in an SD-Access campus network. For each virtual network, a VRF is created in all the SD-Access fabric edge and fabric border nodes. A virtual network is also associated with its own host IP address pool. This helps ensure seamless endpoint mobility: users and endpoints are associated with scalable groups by Cisco ISE, and DNA Center imports these groups and prepositions the correct virtual network assignments at every access switch. The user or endpoint is thus automatically placed in the desired virtual network segment regardless of where they connect into the network. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 30
DNA Center access control policies Communication of groups within a virtual network can further be controlled by Cisco DNA Center access control policies, which are based on contract templates. A contract defines the action to be taken against a particular port or protocol, as defined in the access contract user interface under the policy/contracts workflow. Once contracts are defined, they are applied to a source/destination tuple under the policy administration user interface. A contract can be applied to SGT-based application control policies, as well as to IP-based application control policies. Figure 15 illustrates the initial Cisco DNA Center Policy screen for specifying application contracts. The list of available contracts, a description, and the default and explicit actions, as well as possible protocol filters are summarized on the initial landing screen. Figure 16 shows further details on how an individual contract can be added to the contract template library, specifying the contract name and an implicit (default) action, as well as possibly port- or protocol-specific actions of the defined contract. Figure 15. Defining access contracts in Cisco DNA Center 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 30
Figure 16. Defining access contract templates in Cisco DNA Center Contracts are applied to a tuple of source/destination group (based on SGTs or IP) under the policy administration workflow, as shown in Figure 17. The initial Policy Administration landing screen lists the authored policies with their deployment status and description. New access control policies can be added to this list by selecting a source group and destination group, as well as the desired contract. Figure 18 shows the access control policy definition screen for SGT-based policies. Note that an access control policy is not by default bidirectional. Unless the option Enable Bi-directional is selected, an access control policy is defined for traffic flowing from the specified source to the specified destination only. Figure 17. Group-based access control policy status in Cisco DNA Center 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 30
Figure 18. Defining group-based access control policies in Cisco DNA Center Cisco DNA Center automates the deployment of access control policies into the Cisco DNA infrastructure network elements via Cisco ISE. DNA Center communicates the defined access control policies to Cisco ISE via REST API calls. The network elements are programmed by Cisco ISE using RADIUS calls with the appropriate device configurations that represent the policies. Cisco DNA Center thus offers a networkwide access control policy authoring environment, while Cisco ISE remains responsible for the instantiation of both access and access control policies into the network. DNA Center application and traffic copy policies The DNA Center application and traffic copy policies govern how application flows are treated within the Cisco DNA network. Application policies determine the quality-of-service treatments in the network. Traffic copy policies enable the DNA Center operator to selectively copy flows to a predefined destination for further inspection or processing. The application policy workflow in DNA Center uses Network-Based Application Recognition (NBAR) to classify over 1400 applications into application sets. Applications with similar traffic characteristics can be categorized into the same set to simplify the subsequent QoS treatment. Applications that are similar can be grouped into application sets. This grouping simplifies the workflow for end users. The 1400+ applications known to DNA Center can thus be handled by 30+ application sets. Users can create custom applications as well as application sets if a particular application in their network cannot be identified by the NBAR protocol pack. These application sets are predefined by Cisco DNA Center in the Application Sets user interface under Policy/Application, as shown in Figure 19, allowing also for custom application sets to be created. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 30
Figure 19. Defining application sets for application policies in Cisco DNA Center Further abstractions of the application treatment in Cisco DNA are provided under the application workflow. The list of known applications can be grouped into control, voice/video, and data traffic classes. The subcategories for these traffic classes are Control Operations administrative management Network control Signaling Voice/video Multimedia conferencing Multimedia streaming VoIP telephony Broadcast video Real-time interactive Data Bulk data Transactional data Application sets and traffic classes provide for a two-dimensional classification of the known application space: by application traffic class (control, voice/video, or data) and by higher-level application type. The QoS behavior to be applied in the Cisco DNA infrastructure is regulated by queuing profiles. For each of the traffic classes, the desired Differentiated Services Code Point (DSCP) value or bandwidth percentage allocation can be manipulated using a graphical slider. Default values based on the Cisco Validated Design are also available. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 30
The application sets, traffic classes, and queuing profiles provide valuable input to the application policy definition. This policy type permits the abstracted, intent-based definition of applications into business-relevant, default, and business-irrelevant classes based on IETF Request for Comment (RFC) standards. Business relevant: These applications directly support business objectives. Applications should be classified, marked, and treated marked according to industry best practice recommendations. (RFC 4594) Default: These applications may or may not support business objectives (e.g., HTTP/HTTPS/SSL). Applications of this type should be treated with a default forwarding service. (RFC 2474) Business irrelevant: These applications do not support business objectives and are typically consumeroriented. Applications of this type should be treated with a less than best effort service. (RFC 3662) Figure 20 illustrates the details of the application policy authoring user interface. The association between application classes and policy category is displayed graphically. Each application policy is associated with one or more sites, pointing to one of the queuing profiles to be applied. Custom application policies can be created by moving individual applications or entire application sets between the business-relevant, default, and businessirrelevant classifications, and by associating them with a different set of sites or queueing profile. Figure 20. Authoring application policies in Cisco DNA Center Cisco DNA Center deploys the specified application policies into the network underlay using the DNA Center automation engine. The intent-based application policies defined in the abstract are translated into device-specific QoS configurations, taking the network topology, device types, and software versions into account. The derived configurations are then programmed into the network elements using device API calls, based on CLI, REST, or NETCONF/YANG where applicable. Traffic copy policies are another example of policy treatment, allowing the operator to selectively copy traffic flows for further processing or inspection. A Cisco DNA traffic policy takes a target flow between a source and destination and copies its packets to one of the predefined copy destinations. The steps to create a traffic copy policy in Cisco DNA Center are: 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 30
1. Define a copy destination. 2. Define a copy contract (possibly filtering an application). 3. Define a source/destination group flow to copy. These steps are similar to the access control policy workflow. The DNA Center operator can provide details of one or more copy destination devices by selecting one of the known devices in the inventory and selecting a port. The traffic contract definition then allows a specific traffic copy destination to be associated with a traffic contract under a given name. Finally, the traffic contract can be applied to a source/destination group pair, as shown in Figure 21. The source and destination SGT-based groups can be graphically selected, and a traffic contract applied with a name and a textual description. Figure 21. Applying traffic contracts to access control policies in Cisco DNA Center As with other types of policies in Cisco DNA Center, the resulting traffic copy policy is transformed into device-level configurations and mechanically instantiated into the relevant network elements. The DNA Center workflow engine in this case considers the list of network elements as well as the specific traffic copy destination. Cisco Encapsulated Remote Switched Port Analyzer (ERSPAN) is configured with a filter to copy packets of the desired source-destination flows toward the traffic copy destination. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 30
DNA Center Platform Cisco DNA Center offers integrations for network operations into broader IT process and workflow management along multiple fronts: Ecosystem integrations: DNA Center can directly integrate with other IT systems. Examples include IT Service Management (ITSM) systems to support business and operational efficiencies and IP Address Management (IPAM) systems. Integrations with reporting systems also fall into this category. Domain integrations: Integrations with other domains in the enterprise (WAN, data center), allowing network operators to exchange information with security, WAN, and data center network elements. API integrations: DNA Center provides APIs to control and drive functionality offered by DNA Center from northbound applications, Third-party device integrations: DNA Center offers a Software Development Kit (SDK) for device extensions in support of third-party network devices. The integration capabilities of DNA Center Platform allow operators to create value beyond the network infrastructure, empowering enterprises and partners to collaborate in a dynamic ecosystem. Business workflows can be automated, no longer requiring human interpretation and middleware to ensure that the business objectives are activated in the network. First, consider ITSM integration of the DNA Center Platform. This creates valuable links to incident management, change management, and problem management systems. The workflows of ITSM tools (such as approval and preapproval chains) are associated with DNA Center workflows programmatically. Change management and maintenance windows defined in the enterprise s IT processes can also be linked to the DNA Center workflows. Cisco DNA Center offers both information push and information pull capabilities for such integrations. Events and notifications for change management, issues, network events, and other problem data can be exposed using the push mechanisms with additional network context. DNA Center can also pull information and data into its environment, for example, approvals, schedules, and exceptions to complement its internal workflows. Integration with IPAM is offered to allow for networkwide management of IP address pools. Pools assigned to sites and devices can thus be synchronized with the IPAM tools. The available IP pools, free pools, pool depletion, or remaining pool size can be pulled into DNA Center to be incorporated in the provisioning workflows for network elements and SD-Access. Second, Cisco DNA Center extensions allow for complementary network domains to be interconnected. Currently, Software-Defined WAN (SD-WAN) or data center environments are typically controlled as separate domains, forcing network operators to separate the provisioning and assurance workflow per domain. The DNA Center integrations with Cisco ACI in the data center or with SD-WAN for the WAN provide a more seamless workflow experience. On the data center side, application groups defined in Cisco ACI can be imported into a DNA Center operated domain, allowing for policies to be authored against user and device groups as well as application groups. A DNA Center policy can, for example, restrict traffic from a user group defined in Cisco ISE to an application group defined in Cisco ACI throughout an SD-Access campus access network. Similarly, the DNA Center design workflow for virtual branches allows for a template to include an SD-WAN virtual router, the vedge Cloud VNF, in the design. During the provisioning of such a virtualized branch, the vedge Cloud VNF is instantiated and registered with the Cisco SD-WAN vmanage orchestrator for further configurations and policies to be applied. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 30
The DNA Center cross-domain integration also integrates Cisco Meraki environments. This linkage exposes Meraki devices into the DNA Center inventory, providing visibility into Meraki domains for both network elements and endpoints while incorporating common topologies into managed environments as well. Third, Cisco DNA Center APIs are exposed to facilitate the integration of its functions with external applications to a developer community. Operations such as adding devices to the network inventory, retrieving details about a site, network element, or endpoint, or managing software images can be controlled using such APIs. Support for operational tools such as the template programmer, command runner, path trace, or network discovery is also available. The APIs are easily consumable from within the DNA Center environment as well as from the outside. Figure 22 shows an example of the API catalog that is provided, listing the available APIs and the method (GET, PUT, POST, DELETE), as well as a short description. Further details can be exposed by clicking the name of the API, including the external URL to call, the runtime parameters, the return codes, and the model schema. A Try It button even permits a developer to experiment with a particular API to better understand its behavior (Figure 23). Figure 22. DNA Center Platform APIs landing screen 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 30
Figure 23. Cisco DNA Center API documentation, highlighting the Try It button Fourth, the SDK for DNA Center Platform provides extensibility to the supported network elements. Third-party switches and routers can be added to the list of supported Cisco devices to be managed by DNA Center. The SDK is based on Eclipse, running on Ubuntu, Microsoft Windows, or Apple Mac OS X operating systems. Help functions, step-by-step cheat sheets, and a DNA Center package creation wizard offer the necessary support to quickly develop a project. Eclipse also helps with managing the connection of the SDK environment to a DNA Center instance. The DNA Center SDK capabilities support visibility and configuration for third-party network elements. Using the SDK, these can be discovered, added to the inventory, displayed in the topology, and even polled using SNMP. SDK capabilities permit configurations to be pushed based on the third-party device s operating system, and for show commands to be applied. 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 30
Figure 24 displays the Eclipse-based Cisco DNA Center SDK. Figure 24. Cisco DNA Center SDK to integrate third-party devices Extensive support for the Cisco DNA Center Platform is given in DevNet, the Cisco developer community, at https://developer.cisco.com/docs/dna-center/, including getting started information, examples, references, and further resources. Summary Cisco DNA Center automation extends the capabilities offered by device programmability to the network level. Rather than operating on a device-by-device basis, network automation aims to treat the network as a coherent system in itself. Operations are applied to the network to achieve a desired behavior, rather than pushing configurations to individual devices. This subtle but important distinction forms the basis for intent-based networking, in which network operators are encouraged to describe the intended behavior of the network, rather than configuring devices one by one. Intent-based networking focuses on what the network should do for users, devices, and applications, rather than how the individual elements are configured. DNA Center supports automation applications for standard processes such as creating an inventory of network elements, depicting the network topology, or performing software image management and license management tasks. In addition, it supports sophisticated workflows to operate all stages of a Cisco DNA network, starting at the design phase and continuing through the provisioning phase all the way to the day-n operations and ongoing lifecycle management phase. The DNA Center design workflows are particularly important for driving standards into a Cisco DNA network. Seemingly mundane settings such as IP addresses of common network functions (DNS, DHCP, SYSLOG, and NTP servers, for example) can be standardized and their reachability automated. The design workflow also accommodates the creation of standard site and device templates that are stored in a library to be applied in the provisioning phase of the network. The DNA Center provisioning workflow supports network plug-and-play, allowing IT staff to ship network elements to their sites and automatically provision them. Once a device calls home to the DNA Center plug-and-play server 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 29 of 30