Chapter 4

Introducing the Cisco Digital Network Architecture

Chapter 1, “Why Transform Your Business Digitally?,” and Chapter 2, “The Business Value of Cisco DNA,” provided the motivation to evolve the enterprise network architecture. They outlined why digitalization is transforming the business and how many enterprises are pursuing such a transformation. This chapter provides an initial introduction to Cisco Digital Network Architecture (Cisco DNA) in support of these digitalized business processes.

This chapter explains the following:

The sections that follow lay the foundation for the Cisco Digital Network Architecture for the remainder of the book, starting off with the requirements that arise for the network as business operations and processes are digitalized. The principles driving the network architecture are also introduced in this chapter. These provide a guideline on what Cisco DNA aims to deliver—an architectural compass. The chapter then introduces the high-level components of Cisco DNA, which include the following:

The chapter concludes with a short section on the business outcomes that are supported by Cisco DNA.

Requirements for Cisco DNA

Over the last few years, the demands on network functionality have evolved significantly. Wireless is the dominant access method in enterprise networks, enabling the proliferation of endpoint types. According to the Cisco Visual Networking Index1, non-PC devices will account for 71 percent of traffic generated by 2020, of which 30 percent is expected to come from smartphones.

1 Cisco Systems. “Cisco Visual Networking Index: Forecast and Methodology, 2016–2021.” Updated Sept. 15, 2017. https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/complete-white-paper-c11-481360.html.

Today, many employees can bring their own devices into the workspace, which requires the necessary functionality to authenticate, control, and audit these devices, as well as to shield corporate data from unwanted access. Multimedia communication has also increased dramatically, with video being the standard communication, whether for direct communication or for meetings.

What is more, many businesses are taking advantage of digitalization to transform their processes or disrupt an existing market. Think about the business models of Uber or Airbnb—based on interactive web applications that are easy to use, quick, and efficient. Entire market segments are being disrupted by digitalization!

Digitalized business processes require rapid service deployments to meet the ever-increasing demands and expectations of your customers, partners, and employees. Digitalization allows you to identify market opportunities and offer business services to your customers, and to capitalize on these opportunities by using rapid, agile application development. Cloud computing allows you to deploy such new services without requiring you to stand up your own compute infrastructure. This saves costs and makes application deployments more flexible. You can use cloud computing to collect rapid feedback from customers at a large scale (i.e., electronic surveys and business analytics) and to engage in shortened improvement cycles for the digitalized services to adapt business services according to such feedback. Application delivery is also accelerated by using existing software stacks based on open and agile principles and by drawing additional data from a multitude of information sources.

These digitalized business trends have led to a significant increase in not only overall IP traffic volumes but also network complexity. For example, in a digitalized world you need to manage an increasing number of end devices—especially a rising number of Internet of Things (IoT) devices like refrigerators, sensors, meters, etc. You need to reduce the time to enable new digitalized applications on the network to avoid being disrupted, ensure application service-level agreements (SLA) are met, and provide increasingly granular reports on the performance of networked applications, users, and devices. And to top it all, you need to guarantee security of the network and the integrity of the data to be accessed.

As a result of these digitalized business trends, the requirements for the enterprise network architecture have shifted significantly in the following four categories:

The remainder of this section explores these requirements in more detail.

Requirements to Reduce Complexity and Costs

As business processes are digitalized, the cost and complexity of the network and the applications are often becoming primary concerns for many enterprise operators. To keep both in check, simplicity and automation are critical requirements for the network.

The simplification of network operations and the deployment of new network transport services have become major requirements to offset the increased complexity caused by the increase in the number of devices, the proliferation of applications, and their increasingly dynamic usage. Simplicity extends throughout the network services lifecycle, from day 0 design and installation of the infrastructure components to day 1 service enablement and day 2 management and operations. Requirements for an evolved enterprise network include the following:

As the complexity of network operations increases with a growing number of end devices (e.g., from adding more and more IoT devices) and end users, so do operational expenses. As illustrated in Figure 4-1, operational expenses (OPEX) account for two thirds of all networking expenditures. Automation is a primary requirement to limit or even reduce the network OPEX. The requirement for network automation is to support the trends toward programmability, open application programming interfaces (API), standards-based protocols, and simplified network operations. Imagine if network services and operations were fully automated, deployable within minutes regardless of geography, and capable of providing instant feedback to the operator or users to reflect the state of the service, the network, or the application?

The horizontal axis represents the networking expenditures and the vertical axis represents the percentage of expenses. The graph infers the following data: CAPEX, 33 percent; and OPEX, 67 percent.
Figure 4-1 CAPEX and OPEX in Digitalized Business Environments

Requirement to Increase Operational Flexibility

In a digitalized business environment, the network must support fast innovation cycles. This requirement is especially critical in a digitalized world where market disruptions can happen overnight! The demand for Cisco DNA to support innovation includes the following:

Flexibility

The number and types of endpoints seeking transport services from the enterprise network are expected to continue to grow. A fundamental requirement for an evolved enterprise network architecture, therefore, is to accommodate a wide variety of different endpoints, regardless of how they wish to connect. The same network and security services must be available to wired, wireless, mobile, and IoT hosts alike. Flexibility is also required from the network to support a variety of network and business applications that are increasingly dynamic in nature and no longer tied to a geographic location. As a result, the network must support network services and applications that can run anytime, anywhere.

The requirement for flexibility must be accompanied by speed of deployment. The previously discussed requirement for automation not only aims to reduce operational costs, but also aims to increase the speed of deployment of new functions. The requirement for speed of deployment goes hand in hand with the requirement for the network to be flexible. Both are important to foster business innovation and to ensure that the network supports a dynamic business environment.

Intelligent Feedback Mechanism

Significant improvements in network state feedback mechanisms have also become a main requirement. Instant feedback is already a characteristic of many business processes—think about all the applications on smartphones that report on service requests, from the location of your taxi request, to the status of an online purchase, to information about current traffic conditions. Such interactions also set the bar for network operations!

Traditional mechanisms like Simple Network Management Protocol (SNMP) and screen scraping are reaching limitations in Cisco Digital Network Architecture. SNMP is inefficient from a protocol perspective—it is based on polling rather than being event driven, which adds to the load of the underlying devices. SNMP thus lacks the required scalability and speed for a digitalized network. Operations based on the command-line interface (CLI) and screen scraping, on the other hand, are highly manual and prone to errors. Even seemingly minuscule changes in a vendor’s screen output risk breaking custom scripts and wreaking operational havoc. These limitations raise the requirement for more state-of-the-art feedback mechanisms, such as Yet Another Next Generation (YANG) or event-based streaming telemetry. These mechanisms already have made successful advances in data center (DC) architectures.

The network must provide the correct metrics to support business-critical and transport policy decisions. Such data needs to support active troubleshooting, facilitate trending and health monitoring of network elements and applications, and be easily extendable. Analytics capabilities for the enterprise network are required to be at the user, application, or device granularity and, of course, support a myriad of device types that are expected in a network built to also accommodate the Internet of Things.

Application, User, and Device Awareness

In a digitalized world, applications are added in a matter of hours or days, especially if they are hosted in the cloud. The network therefore needs to keep pace with rapid application development cycles and offer the flexibility to introduce transport services for new applications in minimal time. Similarly, new users or devices (especially in a world of “things”) can seek access to network services instantaneously.

As your enterprise network becomes more and more an integral part of every aspect of your business processes, it needs to become fully aware of the applications, users, and even devices to properly treat the traffic (e.g., prioritize traffic flows or apply the desired transport policies). The network must be able to identify users, applications, devices, and groups or combinations thereof. Awareness at this level of granularity even applies if encryption is enabled.

Security and Compliance Requirements

The digitalization of business operations also triggers important requirements for security, regulatory compliance, and availability. Malicious attacks on enterprise networks are evolving rapidly. In its Q3 2016 State of the Internet – Security Report, Akamai reports a 138 percent year-on-year increase in total distributed denial-of-service (DDoS) attacks over 100 Gbps in 2016.2 Traditional approaches based on static signatures are not fulfilling the security requirements of today’s businesses.

2 https://content.akamai.com/PG7470-Q3-2016-SOTI-Security-Report.html?utm_source=GoogleSearch&gclid=CM7zsunN7NACFYSFswodxxwERw

Security must keep pace with the dynamic application environment and the endpoint proliferation. The ability to segment traffic and users from each other is a challenge for any enterprise network architecture. The network should offer a single segmentation strategy that can be applied to different user groups and applications and be part of the operators’ policy framework. The segmentation capabilities of the network should be complementary to the previously mentioned requirements of simplicity, application awareness, and endpoint flexibility. Segmentation, however, has to be augmented by tools that can baseline normal behavior, detect anomalous network states, and react to security breaches in real time while still complying with the security requirements of regulators.

A related requirement here is to also ensure high availability of the network itself. Some of the previously mentioned security breaches aim to deactivate the network in part or whole (e.g., a DDoS attack on DNS). Ensuring the availability of your network services thus continues to be a baseline requirement. Traditional high-availability mechanisms are expected to improve to offer better predictability and determinism. Any failure of a transport service must be graceful, with configurable orders of operations to prioritize applications according to their business priority. Again, the demands for simplicity, application awareness, and endpoint flexibility need to be supported by high availability.

Cloud-Enablement Requirement

The enterprise network needs to have the option to be fully integrated with the cloud to support rapid application development, prototyping, and hosting of digitalized applications. Cloud infrastructures must integrate seamlessly with the rest of the network from both an operations perspective and a transport perspective. Many enterprise network operators no longer wish to distinguish between applications hosted in their own data centers and applications hosted in the cloud. Network operations, analytics, and policy should apply with equal simplicity to either enterprise-hosted or cloud-hosted applications. Digitalized enterprise networks are able to take full advantage of the power of the cloud to speed the delivery of innovation and incremental services augmentation. Further, they are able to use cloud-based analytical analysis of crowd-sourced information (telemetry, utilization statistics, etc.) to facilitate rapid enhancement development and service augmentation.

Architectural Principles

All successful network architectures are based on sound principles that guide their logic and structure. For example, in the early 2000s, Cisco created the Architecture for Voice, Video, and Integrated Data (AVVID) to offer an enterprise-wide, open, and standards-based architecture. More recently, the Cisco SAFE architecture provides a framework supported by Cisco Validated Designs (CVD) for end-to-end security across places in the network (PIN).3

3 Cisco SAFE Reference Guide, https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/SAFE_RG/SAFE_rg/chap1.html.

Structured network architectures thus provide a compass to reach the “north star.” A structured target architecture allows a planned evolution of the existing network architecture toward the north star, possibly in several controlled enhancement steps. The architectural principles in Cisco DNA are as follows:

Openness

Cisco DNA–based infrastructure is open by design. Openness in this context is defined as enabling customers and partners to guide and influence the operation of the network through the following:

Extensibility

Extensibility is another principle guiding Cisco DNA. It ensures that you can evolve a Cisco DNA network as technology progresses, or as your business requirements demand. The extensibility of Cisco DNA implies that Cisco as a vendor, an enterprise’s business partners, or even you as a network operator can add functionality to the network. Such additions may be at the network control layer, for example, by developing applications that can be integrated with the network controllers. Alternatively, the extensibility may be at the infrastructure layer, via network elements that can be augmented in their functionality through a simple software upgrade, instead of mandating a forklift upgrade of hardware network elements just to support a new protocol header! The principal of extensibility guiding Cisco DNA also means that third-party software (even virtualized network functions) can become part of the architecture. In this case, extensibility is also tied to the principle of openness, previously introduced.

Programmability

Programmability is at the heart of Cisco DNA. It allows the network to be fully automated across all of its components, ready for machine-to-machine interactions. Gone are the days of skilled experts having to know all the hardware and software details about a particular network element, driving functionality into the network by logging into devices and configuring these using intricate CLI commands. Such practices have become major cost factors for network operators, being error-prone and slow. Allowing for disparate network elements adds complexity to the network.

Network automation is essential not only to reduce OPEX but also to increase the speed at which new network, business, or security services are introduced. Imagine a network where a new transport segment can be deployed for guest access at the click of a GUI button, triggering not only the instantiation of the required network segment, but also the associated access policies, firewall functions, or other functions you may wish to associate with this user group in your network. Programmability enables this capability to deploy within minutes, rather than weeks or months as is traditionally the case. Furthermore, compared to a more manually intensive deployment method, programmability, especially via a centralized Cisco DNA controller, is typically more accurate, less error-prone, and more tightly aligned to best practices for network deployment, operation, and use.

Chapter 14, “Cisco DNA Automation,” introduces the components of the Cisco DNA controllers and orchestrators as key elements to facilitate this automation. Triggered by the orchestration applications, new digital services are deployed by the controller onto the relevant network elements at the right time. The controller offers a network abstraction layer to arbitrate the specifics of various network elements in this automation and toward the orchestration and analytics engines. Consistent, machine-based interfaces are being developed as an integral part of Cisco DNA to enhance automation techniques. These interfaces will also be used by Cisco DNA controllers to provide scale beyond what is available today. Speed and agility are critical requirements for service rollout and network operations, and a controller-based system helps to facilitate this. Network functions can also be instantiated by the controller.

Policy-based Networking

Policy-based networking is an important principle that is facilitated by the programmability just described. You have likely used policies in your network many times, configuring access control lists (ACL) to determine who can gain access to the network, to help classify traffic flows into the right quality of service (QoS) classes, or even to assist in Layer 4 firewall rules. But have these policies always been aligned with your business objectives, especially as they evolve over time? And are existing policy mechanisms scalable, easy to use and troubleshoot? There are plenty of anecdotes about ever-growing ACLs—operators are reluctant to remove entries at the risk of breaking existing behavior. And what is more, such policies are tightly coupled with the underlying segmentation/VLAN structure, and thus tied to the network topology.

In Cisco DNA, a key principle is to ensure that the business goals align with the services delivered by the network—services that are tied to users, applications, and devices, not topology. In other words, the network and the business are always fully coordinated to support the business objectives.

The Cisco DNA controller is vital to drive the policies associated with digitalized services consistently throughout the network infrastructure. It translates the business intent for the digital services into actionable and verifiable network policies at the user, application, or device level. Such business intent of a digital service may result in multiple network policies that need to be instantiated and monitored to deliver a service. The Cisco DNA controller, therefore, implements policy in any part of the network that a service instance reaches, such as the cloud or the campus, WAN, or data center domains, for all variants of policies, such as those governing access, transport, or path optimization.

Security

Security is another fundamental principle behind Cisco DNA. In a world of digitalized business processes and interactions between employees, customers, and partners, the communication channels need to be absolutely secure. Any security breaches in such an environment can challenge the very existence of your business.

In Cisco DNA, security functionality and components are pervasive throughout the infrastructure. As the architecture components are described in detail in later chapters, you will find that every building block considers the security implications of the functionality it provides for the architecture and includes the following:

Software Driven

The principle of Cisco DNA being software driven is important to complement the extensibility, programmability, and openness of the architecture. New functionality in software can be developed in a fraction of time as compared to hardware—with new agile development methodologies often in months, weeks, or even days. An architecture that is software driven can thus react much quicker to changing business requirements. In Cisco DNA, this allows the alignment of the network and the business goals to always be in lockstep.

The majority of Cisco DNA functions are driven by software. Functions to forward and manipulate the IP traffic flows can be provided in a virtual form factor, allowing for a flexible separation of the packet-processing software from the underlying hardware, if desired. Control of the network elements has traditionally been a software-driven process, but is now being elevated in importance by enhancing this control plane with a centralized controller function that can run anywhere in your network (e.g., in your data center, in a virtual private cloud [VPC]). Because such a centralized control point of the network elements is responsible for the entire network infrastructure, additional intelligent algorithms can be developed to optimize the operation of the network. Such algorithms may even replace complex protocol interactions between the network elements and therefore contribute to the simplification of network operations. For example, a traffic-engineered path for a particular endpoint group can be algorithmically determined by software based on the full view of the network state. This can augment or replace protocol interactions to exchange state between network elements and the execution of a distributed traffic engineering algorithm.

Software also plays an increasing role in collecting telemetry data from the network, processing it, and presenting it to network operators or business applications in the right format at the right time. Software-driven functionality and network telemetry become particularly impactful with programmable application-specific integrated circuits (ASIC, specialized and sophisticated chipsets) when these are designed to scale and accelerate software-driven operations.

Cloud Integrated

Ensuring that Cisco DNA is fully cloud integrated is the last of the guiding design principles. Cloud computing in today’s world already plays a fundamental role in changing the economics of networking. Using a cloud provider to host applications avoids capital costs to build up data center infrastructure and operational costs to run it. Using the cloud for management allows for a more ubiquitous access to the network for you as an operator. And finally, the cloud can also be used as a source of information by leveraging or connecting to applications that are outside your businesses operational responsibility—publicly available data such as traffic patterns, weather forecasts, population statistics, timetables, etc. can often be used to augment digitalized business processes.

In Cisco DNA different cloud models are fully integrated, including private clouds, virtual private clouds, hybrid clouds, and public cloud environments. This integration is designed both at the transport layer and the control layer of the network. At the transport layer, the various cloud environments can be fused into the enterprise network seamlessly by use of tunneling techniques. For example, a virtual IPsec gateway can be instantiated in a VPC and connected to the enterprise-operated fabric by means of an IPsec tunnel. Configuring the virtual router with similar policies and functions as the enterprise-operated branch environments then makes the VPC behave like other branches that are part of the network infrastructure. At the control layer, management and orchestration tools can be used to operate the network. Analytics and telemetry engines accessing and storing information in the cloud are also part of the cloud enablement aspect of Cisco DNA. By making the cloud an integral part of the enterprise network, Cisco DNA is addressing the requirement for cloud enablement to drive rapid application prototyping, fast application deployment, and continuous feedback loops to speed digitalized business processes.

Conflicting Principles?

The principles already discussed are guiding the architectural decisions behind Cisco DNA. They are the “compass” to evaluate architectural design alternatives. In some cases, these principles may seem to counter each other. For example, the desire for “openness” may imply full support of third-party hardware components in the architecture in the extreme case. This may lead to a significant increase in the systems integration effort, and thus impact speed and flexibility. The Cisco DNA architecture balances such conflicts based on feedback from operators and network architects, with an overarching goal to provide a cohesive, flexible, and powerful solution.

Overview of the Cisco DNA Components

Now that the higher-level architectural principles behind Cisco Digital Network Architecture are clear, this section provides an overview of the main architectural components: the Cisco DNA infrastructure, automation, analytics, and cloud integration. This section not only provides a high-level overview of these components, but also offers clear definitions of the main terms for any concepts that are used in the remainder of the book. Chapter 5, “The Cisco Digital Network Architecture Blueprint,” elaborates on these building blocks and their functionality to described the architectural blueprint behind Cisco DNA.

The main tenets of Cisco DNA are shown in Figure 4-2, which illustrates how the principles of openness, extensibility, programmability, software driven, policy-based networking, security, and cloud integration (all discussed in the previous section) drive the overall architecture. Figure 4-2 also shows that the main components of Cisco DNA—infrastructure, automation, analytics platform, and cloud integration—collaborate as a system to deliver the requirements (outlined in the earlier section “Requirements for Cisco DNA”) of reducing complexity and costs, increasing the operational flexibility, and enhancing security and compliance.

An illustration shows an overview of the main architectural components of Cisco DNA.
Figure 4-2 Cisco DNA Concepts and Main Components

Infrastructure

The infrastructure component in Cisco DNA represents all those functions that participate in carrying network traffic between users, devices, and applications. This building block corresponds to the traditional data plane and control plane functions needed to transport traffic across the network to connect users, applications, and devices with each other. Cisco DNA still relies on the proven distributed forwarding techniques that are successfully deployed in every network today! However, in a Cisco DNA infrastructure, these techniques also include significant enhancements that help to directly address and provide simplicity, security, and the shift toward policy-based networking.

The infrastructure component is made up of both hardware and virtualized network elements. Hardware-based network elements are enhanced in functionality to accommodate the Cisco DNA principles of software driven, programmability, and security. Network elements in Cisco DNA leverage programmable ASICs to this end. For example, transport protocol developments or packet formats such as the recent rise of the virtual extensible local area network (VxLAN) may not require the re-spin of ASICs, triggering a forklift upgrade of the installed base when you wish to introduce this technology into the network. While ASICs are continuing to improve in speed and functionality, the hardware-based network elements can also be uplifted by a software upgrade in Cisco DNA, extending the lifecycle of the installed base. Hardware-based network elements in Cisco DNA also allow high-bandwidth communication at speeds up to 100 Gbps and beyond.

VNFs are added to the functional components of the Cisco DNA infrastructure. They are integral to address the Cisco DNA principles of openness, software driven, programmability, and security. VNFs can perform infrastructure forwarding functions. For example, the Cisco Cloud Services Router (CSR) 1000V Series offers the same functionality as a hardware-based IOS XE router (the Cisco ISR 4000 Series or the Cisco ASR 1000 Series routers), but in a software-virtualized form factor. This provides both operational and functional consistency between the physical and virtual network infrastructures—significantly enhancing simplicity and operational consistency. Alternatively, Layer 4–Layer 7 functions such as firewalls, DPI, IPS/IDS, etc. can also be accommodated in Cisco DNA in a virtual form factor if and where desired. Such functions can even be provided by yourself or third-party vendors—for example, troubleshooting, monitoring tools, or even network functions from other vendors that have been certified in your organization.

The inclusion of VNFs as infrastructure components directly addresses the requirement of deploying functionality in the network with speed and agility, and keeps the network aligned with the business objectives.

Note that in Cisco DNA, applications can also be hosted within the infrastructure. In some situations, you may wish to deploy your own application workloads as a network operator (for instance, traffic generators, troubleshooting or monitoring tools, or even print servers or other business support functions). Such application workload could run efficiently in a container so as not to require an additional layer of operating system (which is the case in a virtual machine–based deployment). Cisco DNA fully recognizes the need to offer this level of flexibility.

Cisco DNA Infrastructure Domains

Traditionally, the enterprise infrastructure is composed of a campus, data center, and WAN/branch domains that connect users and devices to applications, along with their respective control functions. In Cisco DNA, while still helpful from a conceptual architecture perspective, the demarcations of these domains are less strict. But the concept of “domains” can be more flexible in Cisco DNA and be extended to “controller domains.” The traditional separation of a network into campus, WAN/branch, and data center was partly motivated by different requirements, technologies, and organizational structures that characterized the domains. For example, the WAN domain traditionally had to contend with a variety of WAN technologies (serial, frame relay, ATM, etc.), secure connectivity to the Internet, provide access to mobile or nomadic users, and handle bandwidth-limited links to connect sites that are geographically dispersed. The campus’s focus was on providing access ports to users and devices, and aggregating as many of these as possible efficiently—while dealing increasingly with user and device mobility, an increasing proliferation of device types, and bandwidth demands. Similarly, the DC architectures of the past were driven by connecting vast amounts of servers hosting applications to the network. In Cisco DNA however, a domain can also be created for all network elements in Campus and WAN, under the governance of a single controller instance.

Because these different network domains serve distinctly different needs, these domains are also present within a Cisco DNA network infrastructure. The pertinent domains in Cisco DNA are likely to remain the campus, the data center, the cloud, and the WAN (which includes WAN aggregation and branches), as illustrated in Figure 4-3. In the campus, multiple endpoints connect to the network using either wired or wireless access. The campus may also provide connectivity to the data center or WAN domains, helping endpoints to reach applications residing in the data center or to reach hosts located in branches, respectively. The WAN domain typically consists of many branches that are aggregated across an enterprise-managed or service provider–managed WAN into multiple WAN aggregation sites. The WAN aggregation sites connect into the campus domain. The data center domain provides the infrastructure to connect servers hosting enterprise applications to the network in the most efficient and flexible manner possible.

A figure showing the DNA infrastructure and domains.
Figure 4-3 Cisco DNA Infrastructure and Domains

The forwarding infrastructure in Cisco DNA may be accompanied by additional functions that deserve calling out separately. For example, some control plane functions such as LISP Map-Servers/Map-Resolvers (MS/MR) may run in virtual machines (VM) to assist in determining the forwarding path. Other examples of such auxiliary functions are DNS servers or DHCP servers. Because these are often essential for the successful operation of the Cisco DNA infrastructure, they are called out separately in Figure 4-3.

Extending the Concept of Network Fabrics in Cisco DNA

The transport infrastructure in Cisco DNA is provided by the concept of an enterprise IP fabric. The Cisco DNA fabric refers to the infrastructure components in Cisco DNA, which include the following:

The Cisco DNA fabric has the following characteristics:

The data plane in the fabric is predominantly hardware based to offer high-speed transport at scale. Assuring low-latency packet transport, integrated security services, and/or QoS at high speeds typically requires sophisticated ASICs to be deployed in the network elements, such as Cisco Unified Access Data Plane or Cisco QuantumFlow Processor (discussed in more detail in Chapter 7, “Hardware Innovations”). Providing security in the fabric through encryption or imposition of security group tags is an important requirement driving the need for hardware support in Cisco DNA network elements. Furthermore, these ASICs are fully programmable in the Cisco DNA fabric, allowing for new software-based capabilities to be introduced into the network through a simple software upgrade. Finally, the requirement for a high volume of telemetry data to be collected and delivered to the analytics engine is also a reason for the use of high-speed ASICs in the fabric.

Virtualization

Virtualization plays another key role in the Cisco DNA infrastructure because it is a crucial mechanism to deploy services fast and with minimal dependencies on the underlying hardware infrastructure. The virtualization architecture that is part of Cisco DNA can be broken down into two main components:

The logical separation of traffic by means of VLANs or virtual routing and forwarding (VRF) is already a standard tool in enterprise network architectures. The network elements comprising the enterprise fabric are fully capable of logical separation of traffic at both Layer 2 and Layer 3. These concepts carry forward to Cisco DNA, but gain even more importance to ensure that services are associated with the right segmentation policies within the network. Recall that a service connects endpoints or endpoint groups; therefore, the service may be not only application aware but also user (identity) aware. The logical segmentation of groups of users and applications, then, is an essential component of the enterprise fabrics overlay architecture, augmenting (rather than replacing) the traditional concepts of VLANs and VRF.

Network function virtualization (NFV) is part of the architecture that can enable network functions to run anywhere in the network infrastructure based on the availability of x86-based compute resources. The virtualization of network functions that manipulate the IP traffic flows according to the policies is essential in Cisco DNA to provide a completely virtualized environment. Transport virtualization is extended in Cisco DNA by allowing these network functions to run in virtual machines or containers (for instance, LXC or Docker) on any available x86-based compute resources on the operator’s policies. Network elements increasingly offer x86-based compute resources for this purpose, also allowing them to host specialized applications in a Cisco DNA network deployment. In cases where these resources are insufficient, dedicated x86-based servers may be co-located throughout the Cisco DNA infrastructure, as illustrated in Figure 4-4. The operating systems of the network elements in Cisco DNA are enhanced to support this virtualization, providing the ability to spin up or tear down network functions within minutes, to monitor their status, and to redeploy, restart, or even support their move from one location or server to the next.

An illustration depicts transport and network function virtualization.
Figure 4-4 Transport and Network Function Virtualization in Cisco DNA

In this way, NFV allows for novel architectural approaches where the functions applicable to a service flow can be distributed in the infrastructure based on optimal placement policies. The functions no longer are tied to physical network elements, nor are they required to be executed in a single process on a network element.

The concept of chaining a service flow through multiple virtualized network functions based on policy is thus also supported by the Cisco DNA architecture. Virtualization allows for networking functions to be provisioned at a more granular level—even at the user, application, or device granularity, if desired—and to place those most optimally in the network: hosted within a network element, hosted in distributed x86-based resources, or centralized in the data center or the cloud. Service chaining helps to ensure that the right sequence of executing these functions is maintained while forcing a traffic flow through a path that “hits” each of the required functions. Traditionally architected using routing and VLANs, this paradigm is now enhanced using Service Function Chaining (SFC) based on a network services header (NSH). SFC not only decouples the chaining from the underlying topology constructs. It also allows for metadata to be passed between chained functions, such as the application type that a packet belongs to. For example, a flow may be passed through a DPI function identifying its application, and the application type can then be communicated to downstream functions that may leverage this information in processing the packet.

Note that virtualization in Cisco DNA is seamless between the different fabric domains. A virtualized network function such as DPI or a firewall may be deployed in a VM on a host connected to the campus, or it may be deployed in a VPC. The seamless extension of the enterprise fabric architecture into the cloud by means of encrypted tunnels carries forward to VNFs and gives the operator the flexibility to decide where to best instantiate a network function. Such flexibility is lacking in today’s traditional enterprise network operations due to management complexity.

Policy

The drive toward policy is arguably one of the most important directional shifts that Cisco DNA brings to enterprise networking. In many traditional networks, network operations is not in lockstep with the business requirements. In an agile software application world, developing a new application might take only a few days—and yet onboarding the application onto the network may take months. Such discrepancies are the motivation for a shift toward policy and Cisco DNA services. The goal is to fully align the business objectives with network operations—at any point in time.

Policy is inherently tied to a Cisco DNA service, which is defined as any service that is offered to users, devices, and applications, consisting of transport in association with policies. The transport services define how traffic is forwarded through the network, with support of network functions. The policies define how traffic is treated by the network.

Policies in Cisco DNA are attributes of the service the network delivers to users, applications, or devices. Policy categories in Cisco DNA include the following:

Note that the definition of policy in Cisco DNA is a lot more comprehensive, extending beyond simple security policies such as access control or ACLs. It encompasses all the characteristics of a service that is delivered to the users of the network to connect these or their devices to the applications: security policies, traffic handling policies, or reporting policies.

The focus on policy in Cisco DNA extends across all the building blocks of the architecture, not restricted to the infrastructure component alone. The role of the infrastructure component in delivering policy is to instantiate and enforce policy. Existing policy constructs such as ACLs are examples of relevant functions that carry forward from traditional networking. But these are also extended to include any mechanism or function that is required to implement the policy. For example, a virtualized firewall or a WAN optimization appliance becomes an instrument in Cisco DNA of policy—each are deployed to deliver on the policy aspects of a Cisco DNA service, and this association always couples the function to the services that rely on it.

For example, an extranet partner service in Cisco DNA specifies that selected partners (by policy) can access all those applications in your enterprise that are designated for partners, along with traffic treatment functionality such as “no security,” “always log transactions,” or that the extranet partners always have to go through a strict firewall function to enter your enterprise’s network.

Automation

As shown earlier in Figure 4-2, automation is another main component of Cisco DNA. Automation helps deliver all the design principles previously identified, in particular the support for programmability, openness, and extensibility.

Automation is defined as the ability to externally manipulate network elements within a domain. It is a base capability provided via a controller in Cisco DNA.

This definition highlights the ability of a Cisco DNA-based network to be fully programmable—i.e., fully able to be manipulated by external elements such as a controller, using open APIs. The automation building block is broken down into two further subcomponents: controller and orchestrator. These are explored in detail next.

Controllers

The enterprise IP fabric in Cisco DNA is governed by a controller that oversees the configurations and operations of its network elements. As such, the controller has a domain-wide view of the state and the operations of the associated network elements. The Cisco DNA controller is responsible for the configuration of the network fabrics—the underlay communication and overlay services architectures. It configures the user- or application-visible network services (for example, applying a service policy to a particular IP flow, or applying one or more Layer 4–7 service functions to a user–application communication pattern). Most importantly, the controller is the element in the architecture to instantiate policy.

The controller is a mandatory component in Cisco DNA that defines and co-ordinates the instantiation of Cisco DNA services for a single domain. The principal function of a controller is to offer a layer where the network is viewed as a system and where network decisions can be made centrally, in particular to align the business intent. It configures the network elements using a set of well-defined south-bound interfaces, thus abstracting the network infrastructure and automating policy. The controller may also interact directly with applications via north-bound APIs, for example, Cisco Unified Communications Manager (CUCM). The controller may also communicate directly with the analytics engine to automate recommended data-driven actions.

As noted, a focus on policy and intent is one of the key architectural shifts supported by Cisco DNA. Recall that each service offered by Cisco DNA implements a business intent and is instantiated by a transport path with the associated policies.

The role of the controller to deliver policy-based services is to enable the actuation of policy. The underlying model in Cisco DNA is that policy can be expressed in the abstract with a terminology or syntax to align the network easily with the business intent (e.g., connecting a user group to a business-relevant application group with a high level of security). The Cisco DNA controller then possesses the intelligence to “translate” an abstract expression of policy into actual device configurations. This is performed in the controller with the assistance of a policy engine and associated application(s). The abstracted policy expressions are associated with concrete policies for the network elements that are under the controller’s span of governance. The controller then instantiates the policy into the network elements (i.e., pushes the right device configurations). The network elements then execute the actual policies (i.e., they enforce the policies).

The benefits of the Cisco DNA controller’s policy functionality can be illustrated by example of application-aware services. The network operator may specify in the policy application that a particular service applies only on a per-application basis. The controller must then translate this service policy into access policies to be applied at the policy enforcement points (PEP)—explicit points in the network where the policies are instantiated through device configuration. The PEPs ensure that the right applications are filtered out as users, applications, or devices access the network.

Such a filter may be based on standard DPI techniques, such as Cisco Application Visibility and Control (AVC). Alternatively, advanced mechanisms such as DNS as Authoritative Source (DNS-AS) can be deployed to create such filters. DNS-AS helps classify applications with the help of the DNS server, where the application type can be specified as part of the DNS record and returned to the requestor in the DNS response. The controller may also need to deploy policies between domains or within a particular fabric domain to effect the right treatment for the service, such as mapping the service to a QoS transport class. The domain-wide view of the controller, therefore, helps to instantiate the right policies in the right places of the network, and ultimately delivers on policy-based service delivery. Figure 4-5 depicts the main functionality of the controller: taking intent as an input from the orchestrator (more details following on this), computing the right policies and service constructs, and pushing those into the Cisco DNA fabric and NFV components using APIs.

An illustration depicts the functionality of the DNA Controllers (Network Abstraction and Policy Determination).
Figure 4-5 Cisco DNA Controllers (Network Abstraction and Policy Determination)

Programmability is a critical supporting aspect of the Cisco DNA controller. Configuration of the underlay network, the overlay architecture, or even specific services is handled by a south-bound interface between the controller and the network elements and functions. This south-bound interface may rely on the CLI, or other standards-based mechanisms such as NETCONF interfaces, YANG data models, Representational State Transfer (REST), or REST Configuration Protocol (RESTCONF).

Supporting standards-based southbound interfaces contributes to the openness of Cisco DNA and also allows third-party vendors to participate in the network infrastructure, while supporting CLI lends to the ability for a controller to more readily be introduced into a brownfield environment in which not all of the network gear may yet support more advanced machine-to-machine protocols such as NETCONF/YANG. Toward the orchestration layer, the controller provides a level of network abstraction by exposing northbound APIs, which again may be standards based. The controller can enable a simplified operation of the domain fabric, and supports rapid and elastic provisioning of network services. The programmability aspect of the Cisco DNA controller is vital to delivering on the automation, as well as fast and flexible configuration, of Cisco DNA.

Orchestrators

The orchestrator in Cisco DNA plays the critical role of allowing the network operator to specify Cisco DNA services that cross multiple domains. Take for example the likely case of a service connecting applications in a data center to users and devices that are distributed throughout a global WAN with many campuses and branch locations. The different domains may be governed in this case by multiple controllers for administrative or scalability reasons. For example, one controller may be handling the data center (DC) environment, and another controller may be responsible for the campus and WAN. Such flexibility ensures that Cisco DNA can align with your organizational structures, and also allow for technology domain-specific controller functions to be leveraged. In the data center, the controller may focus on high availability and bandwidth, whereas in the campus the controller may focus on increased functionality to handle both wired and wireless clients consistently and with strong authentication. In such multidomain cases, a functional instance to coordinate services across domains and controllers is needed. This is the principle function delivered by the orchestrator.

The orchestrator is defined as an optional component that, if present, defines and coordinates the instantiation of the Cisco DNA services across different domains.

The orchestrator thus enhances the concept of network abstraction offered by the controller, abstracting from the details of network elements or virtualized network functions and providing the focus on the services. You as an operator can focus on the specification of the service details from the user, application, or device point of view, without having to know all the details of individual network elements or virtualized network functions. The orchestrator then interfaces to the controllers using standard APIs to instantiate the specified services at the right time in the right network element in the right sequence of operations.

Stipulating network services and their associated characteristics can be done in Cisco DNA in multiple ways. You can create standard templates for services using a GUI. Alternatively, a service can be characterized using a graphical tool. For example, the Cisco DNA branch orchestration application allows the customized specification of enterprise branch profiles. A network extension service (adding a new branch to extend the network reach) can be defined graphically, empowering you as the operator to not only list the functions required in a particular branch, but also influence their order and associated policies for the service. For example, a canvas-based templating approach allows you to drag an icon representing an x86-based host onto a work area, then graphically add the required virtualized network functions, interconnect them, and specify any parameters that may have to be provided for a particular instance of the template.

Model-based approaches to service declarations are also part of the orchestration architecture in Cisco DNA for those operators who seek further abstraction. Figure 4-6 shows the relationships between the Cisco DNA orchestrator and the controller(s).

An illustration depicts the relationship between the DNA orchestrator and the controllers.
Figure 4-6 Cisco DNA Orchestration (DNA Service Definition Across Domains)

Analytics Platform

The third main component of Cisco DNA is the analytics platform (refer to Figure 4-2). Imagine a network where the operational state is continuously available, provided from throughout the network, and presented in a simple and graphical manner, without having to write custom scripts that screen-scrape outputs from multiple devices with different software versions deriving operational state with home-grown applications. The analytics engine is another element that significantly enhances the overall functionality of the enterprise network and supports the Cisco DNA principles of openness, policy based, security, and software based.

Analytics is defined as the process of correlating data and extracting meaning so as to identify anomalies, derive insights, and enable data-driven decisions.

The analytics platform is essential to provide feedback mechanisms—collecting data on an ongoing basis to offer continuous and relevant information about the operational state of the network. Such states can be harvested to optimize the network and security services (delivered to end users and applications). Alternatively, the states and data can be fed back to digitalized business applications, supporting the dynamic environment that these applications require, and fostering the cycle of continuous application development and improvement.

Analytics support is based on the following subcomponents:

Data Collection

The Cisco DNA network elements are enhanced to collect data about all aspects of the network, including the state of the network elements and the traffic flows pertaining to the services offered by the network. This data collection is not just restricted to the transport network elements (routers, switches, access points, etc.). It also extends to supporting network functions such as AAA servers and virtualized or physical Layer 4–Layer 7 functions. Network elements and virtual network functions in Cisco DNA are inherently designed to collect a vast amount of data. As an example, the network elements and functions provide statistics on user groups, in addition to the standard fields on source and destination IP addresses and ports; protocol types, bytes, or packets sent; or TCP flags. Furthermore, firewalls such as the Cisco Adaptive Security Appliance (ASA), authentication servers such as the Cisco Identity Services Engine (ISE), and URL filtering functions collect data at similar granularity. The continuous collection of such data always includes timestamps, allowing time-series analysis of all events. Data collection in Cisco DNA even extends to end-user and device information. Any telemetry data collected from the network or supporting network functions can be correlated with end-user or device identities to provide comprehensive reporting.

Data Reporting

The data reporting mechanisms (telemetry) in Cisco DNA allow for the collected data to be reported to a collector. Telemetry in Cisco DNA is defined as the export of instrumentation data to an analytics engine for further analysis.

This reporting mechanism leverages existing, well-established mechanisms such as SNMP, AAA, or Flexible NetFlow, but also extends now to REST or NETCONF. The telemetry in Cisco DNA supports an any-to-any model: data can be exported from any network element or function using multiple telemetry mechanisms, and to multiple collectors. Figure 4-7 shows a high-level representation of the Cisco DNA analytics components.

An illustration depicts high-level representation of the DNA analytics components.
Figure 4-7 Cisco DNA Analytics (Telemetry, Data collection, Analysis, and Reporting)
Cisco DNA Analysis

Cisco DNA analytics engines normalize, analyze, and correlate the data that is collected and reported via telemetry. Data can be in different formats and thus may need to be normalized to the right timestamps and data formats to be automatically interpreted. Analysis of the data can come in multiple forms, and typically needs to consider the consumer of the data. An application developer wishing to leverage information about the network may be interested in a different data set than the data set a network operator responsible for hardware would be interested in. Consequently, multiple analytics engines may potentially co-exist to analyze the right data for the right consumer. In some cases data can even be correlated from different sources to draw meaningful inferences. For example, any public information on weather could be pulled into an analytics engine to enhance the capabilities for Cisco DNA services.

The analytics capabilities of Cisco DNA are illustrated in Figure 4-8 by example of Lancope’s StealthWatch. In this solution the network acts as a security sensor and provides network anomaly-detection services to the operator. Data from various sources is correlated to make inferences about the security aspects of the network. The analytics engines within Cisco DNA offer the capability to not only analyze the events over time but also filter the relevant data collected from the network to the correct granularity or by correlating traffic flows (i.e., directionally). By looking at the events and data over time—both user specific and application specific—intelligent insights into the state of the network and the applications can be made. An example is detecting application or user behavior patterns that may be “out of profile” and which should be flagged for further analysis and/or upon which action should be taken (e.g., restrict, quarantine, or block) within the network infrastructure.

An illustration represented in three layers depicts Analytics Example Based on Lancope StealthWatch.
Figure 4-8 Analytics Example Based on Lancope StealthWatch

Such analytics capabilities can also be deployed in a virtualized form factor within Cisco DNA and, as such, be distributed in the infrastructure when and where appropriate, and where the required compute resources are available (for example, within a switch or router).

Feedback and Control

The insights gained by an analytics engine can be used to drive events and actions. Network or security services can be optimized based on the analytics results, for example, by instantiating new policies for particular applications or users, or by modifying existing policies. In Figure 4-8, the network functions work in unison with the identity engine, firewalls, and the Lancope StealthWatch Analytics engine to deliver continuous adjustments to the security policy.

The feedback and control in the analytics platform primarily target the implementation of a continuous feedback loop. Analytics results can be fed back to the controller to take action, for example, to optimize the operation of the network or the Cisco DNA services. The analytics engine is thus vital in Cisco DNA to deliver service assurance. Assurance is defined as the coordination of automation with analytics to verify that the business intent has been delivered. If it has not, then assurance can automate the necessary changes to remediate.

Analytics and assurance thus deliver a continuous feedback cycle in Cisco DNA: network elements collect data on an ongoing basis. This data is reported via multiple mechanisms to one or more collectors, picked up by one or more analytics engines, and then reported back to the controller for further action. The controller can chose to present the results to the operator, or even trigger an automated optimization function to optimize the network configuration.

The Cisco DNA telemetry and analytics infrastructure does not just optimize available network services and operations. Analytics can also be exposed to the digitalized applications to enhance their operations or behavior. Information about user behavior on the network, such as their communication or location patterns, can enhance the applications riding on the network themselves, thus powering ever-improving and valuable client experiences.

The upcoming section “Connecting the Building Blocks: APIs” elaborates on the feedback loop from the controller into the orchestrator. Data collected by the network elements and pushed back into the controller can thus be analyzed and presented to the controller in a concise and condensed form, focusing on the relevant data sets required to optimize or refine the service operations.

The Role of the Cloud in Cisco DNA

Cloud computing has been perhaps the most disruptive trend in networking in recent years. Many enterprise applications are already running in a cloud environment to benefit from several advantages of the cloud. For starters, enterprise-operated data center infrastructure has often been underutilized, in some cases even running at below 20 percent capacity. Outsourcing data center operations to a cloud provider allows your organization to save both capital and operational costs to run servers and switches, as the cloud provider may be able to run its infrastructure with a higher degree of efficiency in terms of capacity usage than the organization itself could, thus lowering costs. The cloud provider offers network infrastructure as a service, for example in IaaS, PaaS, or SaaS models. The cloud provider can leverage techniques like virtualization to increase the utilization levels of the infrastructure, possibly even sharing the same physical infrastructure among multiple enterprises.

Secondly, the cloud model enables enterprises to be a lot more flexible. If you require additional capacity to run existing applications, or if you want to introduce a new application to customers, partners, or employees, a cloud-hosting model can significantly reduce the time to deployment. In these cases, you no longer need to engage in a lengthy product evaluation process, take the desired order through lengthy internal approval processes, then wait for delivery, and spend your own resources installing and deploying. The cloud provider pre-provisions capacity that can be sold to enterprises virtually on-demand.

In short, the cloud market is already an important tool for you as a network architect. But there is further room for improvement that Cisco DNA aims to address—making the cloud a fully integrated, principal building block of the architecture!

Cloud integration is the concept in Cisco DNA to fully incorporate the functionality offered by the cloud into the network architecture. How is this achieved in Cisco DNA? The different roles that the cloud can play in the architecture can be categorized into “cloud for applications,” “cloud for management and orchestration,” and “cloud for analytics.” Let’s explore these in more detail.

Cloud for Applications

Cloud for applications refers to the components in Cisco DNA to host applications in the cloud. In a public cloud model such as Microsoft Office 365, Cisco DNA provides secure connectivity (e.g., HTTPS) along with appropriate traffic handling and controls for such applications. In a private or hybrid cloud model, Cisco DNA provides virtualized network functions (e.g., the Cisco CSR 1000V with IPsec tunneling), allowing the VPC to become part of the network infrastructure.

The cloud is a fully integrated domain in Cisco DNA, particularly in a VPC model. When enterprise applications are hosted by a VPC provider, transport and network functions to connect the rest of the Cisco DNA network to the VPC are part of Cisco DNA operations. For example, a virtual router in the VPC provides connectivity to the WAN/DC/campus Cisco DNA domains. This virtual router can be configured such that the VPC behaves just like another branch. Additional virtualized network functions such as firewalls, IPS/IDS, or Cisco Wide Area Application Services (WAAS) can also be hosted in the VPC to support the transport of traffic to and from the enterprise applications. These auxiliary functions are configured to fully interoperate with the rest of the Cisco DNA network.

The cloud is now an important platform for innovation. Many an application has been developed based on resources in the cloud. Application developers no longer have to spend time and resources to maintain their own application development environments. These can simply be rented from a cloud provider. Gone are the days of having to upgrade basic system components. DevOps models allow for such development environments to be fully portable, such that the resulting applications run both in a cloud and in a self-hosted environment. In this way, cloud computing can become a vital factor to increase the speed of innovation for your enterprise.

The cloud is fully participating in and contributing to the principle of security in Cisco DNA. Applications hosted in the cloud can benefit from the security services offered by the cloud providers. The Cisco DNA network can be extended by an infrastructure-as-a-service model, where applications are hosted on dedicated and secured infrastructure by the cloud provider. Alternatively, the enterprise applications can be hosted in a software-as-a-service (SaaS) or platform-as-a-service (PaaS) model, supported by data encryption and security services of the cloud provider. In a VPC model, the integration of the cloud into the rest of the Cisco DNA network can also be fully secured. For example, the transport connection into the cloud can be either a private, dedicated circuit or encrypted. And additional security functions such as firewalls or intrusion prevention and detection functions can be deployed to augment the security of the network.

Cloud for Automation and Management

Cloud for automation refers to the automation components of Cisco DNA running in the cloud. Both the Cisco DNA controllers and the Cisco DNA orchestrators may be hosted in the cloud to benefit from its advantages—ubiquitous reachability from anywhere, scalable compute resources, etc.

The cloud is integrated not only from a transport perspective but, more importantly, from an automation and management perspective. The Cisco DNA orchestration component has full visibility into the available cloud hosting domains for applications. It can thus ensure that the Cisco DNA services can be instantiated into the cloud under the same pane of glass. Imagine seamlessly moving your enterprise applications to and from the cloud under the same orchestration umbrella! Moreover, the enterprise policies focusing on security, transport handling, and reporting that you have defined between user groups, device groups, and application groups can extend seamlessly into the cloud!

Cloud for Analytics

Cloud for analytics refers to the analytics platform of Cisco DNA running in the cloud. Note that such applications can support the data plane or the control plane (e.g., the platform to collect and process analytics data).

Using the cloud for analytics is a special case that deserves to be called out. In some sense, analytics in Cisco DNA can be viewed as “just another control application in my network.” However, the sheer amount of data that is collected and the computational cycles required to perform the normalization, analytics, and correlations make cloud environments particularly attractive for this important Cisco DNA building block. The ability for the cloud to collect data from various sources—even those outside the Cisco DNA domain—may be beneficial for the correlation. Imagine how certain external events such as the weather can influence network usage patterns. A snow storm can entice employees to work from home and thus stress the VPN platform and Internet access infrastructure more. Figure 4-9 illustrates the relationship of private and public cloud hosting functions to the rest of the Cisco Digital Network Architecture building blocks.

An illustration depicts the role of the cloud in DNA-Location Independence of DNA Functions.
Figure 4-9 Role of the Cloud in Cisco DNA—Location Independence of Cisco DNA Functions

Note that the full integration of the cloud into Cisco DNA for applications, automation, and analytics also allows for multiple cloud providers to become part of your enterprise Cisco DNA network. The cloud thus also extends the architectural flexibility that is required and provided by Cisco DNA. Applications can be hosted by multiple cloud providers, in multiple models—public or virtual private/hybrid cloud integration. Carrier-neutral facilities (CNF) or cloud interconnection fabrics (cloud “exchanges”) can provide an efficient platform to integrate multiple cloud providers seamlessly into Cisco DNA.

Connecting the Building Blocks: APIs

Now that the main components of the Cisco DNA architecture have been introduced, it’s time to glue them all together. This “glue” in Cisco DNA is the open APIs. APIs enable better consistency and speed of development for machine-to-machine communications and, as such, form the necessary basis for automation. Each of the building blocks is programmable via the Cisco DNA APIs, and so all the components work together to deliver a coherent and integrated network architecture.

In conformance with the principles previously outlined, the APIs are open and standards based. API definitions—their names, input parameters, and outputs—are published. This provides full transparency of the functionality that can be driven by a building block, and also opens up the architecture for extensions. Recall that such programmability is essential to deliver speed and flexibility, underlining the importance of the APIs.

Furthermore, in many cases the interactions between the components are standards based. Technologies such as REST, NETCONF/YANG, and SNMP are examples of standards-based protocols that enable the APIs.

Figure 4-10 illustrates the importance of these APIs as a glue between Cisco DNA components. Moreover, it also shows the Cisco DNA closed-loop automation, because the APIs enable intelligence obtained through analytics and telemetry to be fed back into the Cisco DNA controller to optimize the network operations.

An illustration depicts the role of APIs in DNA.
Figure 4-10 Gluing the Components Together—the Role of APIs in Cisco DNA

Outcomes

Motivated by the requirements and the guiding principles, the building blocks that were introduced integrate into a coherent architecture: Cisco Digital Network Architecture. The key goals of such an architecture are to support real business outcomes such as:

The support for those business outcomes is achieved in Cisco DNA through the following:

The building block approach of Cisco DNA, with clear functional responsibilities for each component and well-specified interfaces, makes the architecture easy to understand. This is essential to drive simplification into the network. Cisco DNA is designed to fully align with the business objectives—especially with the focus on policy—to ensure that the network delivers the services required to support your digitalized business processes in the most efficient and easy-to-use manner. No superfluous functions exist in the network that complicate its operations. All interactions are designed to support machine-to-machine communications that are fully automated, and that can be audited for service assurance.

The inclusion of the analytics platform as a key component is particularly helpful in Cisco DNA to deliver valuable insights into the network. You as an operator are aware of the state of the network at any point in time, enabling you to determine whether any provisioning steps you have initiated are successfully implemented, or whether unexpected failures or instabilities are emerging. Those insights ultimately improve the experience that Cisco DNA delivers, and allow you to focus on innovation to further your business, rather than spending valuable time “just keeping the network running.”

A key outcome of the Cisco DNA approach is to raise compliance and security to new levels. The pervasive inclusion of security functions in every component and every API protects the network and the services that it delivers to your business. And the analytics capabilities of Cisco DNA again ensure that the integrity of the infrastructure is documented on an ongoing basis, and that any breaches are fully logged. Complying with regulatory requirements is thus also simplified, and again allows you to focus on what is important to you—your business—rather than manually performing sophisticated compliance audits or worrying about security leaks.

The bottom line is that Cisco DNA is designed to drive real business outcomes for you! The total cost of ownership of your enterprise network can be substantially reduced. A Cisco DNA network is simpler to operate through automation, offers full visibility at any point in time through service and network assurance, and can furthermore reduce both operational and capital expenditures through cloud integration.

Summary

This chapter provided initial insight into the architectural building blocks of Cisco DNA. It began by focusing on the requirements that arise from the digitalization of business processes. The digitalized business environments present new and enhanced requirements for the enterprise network, such as an increased focus on simplicity, automation, flexibility, intelligent feedback mechanisms, application, user, and device awareness, security and compliance, high availability, and the movement toward policy as a foundational component in networking. These requirements are taken into account in Cisco DNA by building the architecture on a set of sound principles that provide the architectural compass:

At a high level, Cisco DNA is then based on six main building blocks. The Cisco DNA infrastructure with supporting network functions provides connectivity between endpoints and allows traffic to be manipulated. This infrastructure is fully programmable and leverages both physical and virtualized network functions. The Cisco DNA controller provides an abstraction of the infrastructure to facilitate simplicity and also ensures that the right policies are determined and instantiated based on the business intent. The Cisco DNA orchestrator is the building block in the architecture where the business intent is defined at an abstract level, aligning the network to the business processes and operations. Complementing these components is an analytics building block to continuously collect data from the network, analyze it, and serve it up to network operators for network assurance, or even expose APIs for application developers to leverage network intelligence thus collected.

The outcomes of this architecture are to deliver on the requirements introduced here: a network that provides simplicity and assurance, that provides insights and experiences, and that meets the security and compliance requirements in a digitalized world.

Chapter 5 expands on each of these components. It examines the details of the infrastructure to intensify your understanding about relationships between components and functions, and thus deepen the architectural model behind Cisco DNA.

Further Reading

Akamai. “Q3 2016 State of the Internet–Security Report.” Available for download at https://content.akamai.com/PG7470-Q3-2016-SOTI-Security-Report.html?utm_source=GoogleSearch&gclid=CM7zsunN7NACFYSFswodxxwERw.

Cisco Systems. Cisco AVVID Network Infrastructure Overview. 2002. https://www.cisco.com/web/offer/CAT4500/toolkit/comin_ov.pdf.

Cisco Systems. Cisco Enterprise Network Functions Virtualization. 2017. https://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/enterprise-network-functions-virtualization-nfv/white-paper-c11-736783.pdf.

Cisco Systems. Cisco SAFE Reference Guide. Updated Oct. 31, 2013. https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/SAFE_RG/SAFE_rg/chap1.html.

Cisco Systems. “Cisco Visual Networking Index: Forecast and Methodology, 2016–2021.” Updated Sept. 15, 2017. https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/complete-white-paper-c11-481360.html.

Cisco Systems. The Cisco Digital Network Architecture Vision–An Overview. 2016. https://www.cisco.com/c/dam/global/ru_kz/solutions/enterprise-networks/digital-network-architecture/pdf/white-paper-c11-736842.pdf.