Chapter 4. Cisco Digital Network Architecture
In May 2016 Cisco introduced its Cisco Digital Network Architecture (Cisco DNA). Just like the architecture frameworks described in Chapter 3, “Enterprise Architecture,” it is an architecture framework that describes how network infrastructures (not only campus) should be designed and implemented. As with the other frameworks, Cisco DNA in itself is not a product but a collection of design principles, abstract building blocks, and guidelines that, if implemented correctly, will assist (almost) any enterprise or organization in implementing an efficient network infrastructure.
This chapter describes in more detail what Cisco DNA exactly entails. It is important to understand that, just like any other architecture or design within IT, Cisco DNA is not a product on its own but a collection of rules and specifications that can be implemented with specific tools and solutions.
This chapter covers the following topics:
Requirements upon which Cisco DNA is built
Guiding design principles of Cisco DNA
Design concept of Cisco DNA
Derived design principles
Overview of Cisco’s solution in conjunction with Cisco DNA
Cisco DNA in relation to enterprise architecture
Requirements
Any design or architecture should be based on a defined set of requirements that match and solve a problem. Cisco DNA is no exception and defines requirements common for the problems today’s enterprise networks and corresponding enterprises face. These requirements are primarily focused on solving the issues and drivers described in Chapter 2, “Why Change Current Networks? A Need for Change.”
One of the key drivers for digitalization is faster innovation and development of new services. As a result, a new network architecture must meet the following requirements:
Faster innovation
Flexibility
Context
Intelligent feedback mechanism
Integration and faster deployment
Reducing complexity and cost
Simplicity
Increased efficiency
Compliancy and technology
Security
External compliancy rules and regulations
High availability
Cloud-enablement
The following sections describe these requirements in greater detail.
Faster Innovation
One of the key drivers for digitalization is faster innovation and development of new services. As a result a new network architecture must meet the requirements described in the following sections.
Flexibility
The diversity of devices connecting to the enterprise network is rapidly growing. It is a requirement that the enterprise network must be used to facilitate this wide number of endpoints, regardless of how that device needs to be connected. Each set of devices has its own connection and security parameters. This requires flexibility in the connection methods available in the infrastructure.
Besides a diversity of devices, the number and diversity of applications used in the enterprise are changing as well. Studies show that applications have an increased velocity in terms of features and requirements; for example, an application’s behavior changes might be more dynamic and use different datasets from the enterprise. Therefore, the network architecture also needs to be flexible in such a way that it supports these applications, which can run anytime and anywhere.
Context
The campus network is the foundation of the enterprise architecture. In essence, the campus network is the principal element within the enterprise that connects devices, its users, and applications to the datacenters, Internet, and/or cloud-based applications to provide and consume data. Without the campus network, the enterprise comes to a standstill. In traditional networks it was sufficient to view statistics based on the IP connectivity and flows that an application was using. Applications were recognized on specific flows and port usage.
With the dynamic behavior, the growing number of devices used by an employee, and an increase in encrypted application flows, there is a need for more context. The network needs to be able to recognize applications and users regardless of whether encryption is used. Based on the recognition, the network needs to be able to adjust policies and prioritize applications if required.
Intelligent Feedback Mechanism
Traditionally campus networks were measured against availability. As both the integration with business processes and the demand for quantifying the network performance increase, the traditional poll-based mechanisms (Simple Network Management Protocol [SNMP]) for monitoring the campus’s network state are not meeting that requirement. The traditional monitoring environments (often requiring manual configuration) based on SNMP provide trends on generic availability and capacity. They lack the granularity to define key performance indicators (KPI) or metrics based on applications or processes.
With the tighter integration into business processes with trends such as IoT, physical security over IP, applications as a service (cloud), and wireless/mobility, it is important that the right metrics can be defined and monitored on to provide the required KPIs to the right department within the enterprise as part of a service level agreement.
Cisco DNA must have the necessary analytics to provide this granularity and metrics to support the enterprise.
Integration and Faster Deployment
Rapid application development and deployment has been a growing trend in applications used in the enterprise. The release cycle of applications, existing and new, is increasing (potentially even up to once a month); each change can result in different requirements on the network. With every release of a new application there is a need to consume the enterprise network as a transport service. The network architecture needs to be able to keep up with this release cycle of applications and provide the necessary constructs for facilitating transport services, either individually or grouped with other applications, to the department that consumes or releases the application.
This implies that changes need to be deployed in the network much faster and that the network needs to facilitate a mechanism for application developers to request transport services (semi)automatically.
Reducing Complexity and Cost
Traditionally the increase of diversity in systems and applications also increases the complexity of the network system and its operations, with an increase in cost and loss of efficiency as consequences. The requirements of simplicity and increased efficiency are set within Cisco DNA to counter this effect, as described in the following sections.
Simplicity
Traditionally, networks were designed to facilitate a specific function—for example, a network for office automation, a network for guests, a logistics network in the warehouse, a production network in the plant, and so on. Over time, these networks needed communication between them as well and were interlinked, introducing even more complexity. Operation of these types of networks increases in complexity and results in longer delays to execute a change or troubleshoot a network.
To prevent history from repeating, the Cisco Digital Network Architecture must assume that a diversity of devices and applications will run on the network, where interconnection is possible, based on policies that need to be implemented in the network. Therefore the network must be designed for simplicity where policies, based on software, determine how and in what way specific access is permitted.
The network needs to be set up with a deterministic, flexible, and predictable set of services upon which specific (complex) policies can be implemented via software and predetermined behavior so that complexity in the network infrastructure itself is not increased.
Increased Efficiency
The operation of a business relies on an excellent performing network. However, there will always be an incident or problem that affects the network and thus the business. The tighter integration between the two results in an increased impact on the operation of the business in case of an incident in the network. There have been many instances where issues in IT disrupted network services. For example, in the past within Cisco a misconfigured Active Directory caused an outage to the network access control with loss of service as a consequence.1
1 This information was shared via several CiscoLive breakout sessions regarding ISE best practices.
Because incidents will happen, Cisco DNA must be designed with increased efficiency in solving such incidents in the most optimum way. The increased efficiency not only provides the benefit of faster recovery from an incident but also reduces the overall operational costs of operating the network.
Compliancy and Technology
Cisco DNA is part of a larger whole, and its design is also based on a more direct interaction with business applications and processes. The interconnectivity with the cloud and a multitude of external managed devices such as IoT sensors facilitate both technology innovation as well as the requirement for a tighter demand for compliancy. The requirements associated with compliance and technology are security, external compliancy rules and regulations, and high availability, as described in the following sections.
Security
Network security is evolving at an even more rapid pace than the dynamic application environment or the endpoint proliferation. Network security has to keep up with the constant threat of users with malicious intent and where malicious software gets more intelligent and professional by the day. From security intelligence centers, such as Talos2, it is clear that malicious users have started to act as regular enterprises with normal business hours, software targets, quality assurance, software warranties, malware as a service, and other similar activities like normal businesses.
2 Talos is the security intelligence organization from Cisco Systems that provides continuous updates on the threat landscape in the field. More information can be found on https://www.talosintelligence.com/.
It is therefore important that security policies be set up in line with other requirements described in this chapter, such as simplicity and increased efficiency.
External Compliancy Rules and Regulations
IT is maturing at an ever-increasing pace. Part of this maturity is that data (and meaningful data results in information) is becoming more important for any enterprise. Data has for some businesses even become the new currency and is also critical to the success of the digital transformation of the business.
The collection and handling of more data inside the enterprise also requires the enterprise to be compliant with different external rules and regulations, such as the EU General Data Protection Regulation (GDPR),3 PCI, HIPAA, or other specific market regulations.
3 General Data Protection Regulation, European Union (2016/679) directive that specifically states how businesses need to manage privacy-sensitive data, such as personal information. Not being compliant can result in heavy fines for the business.
Compliance with these rules is becoming increasingly important for enterprises to be successful and to prevent potential fines or loss of business due to lack of compliance, which can result in negative media attention.
Cisco DNA needs to be able to comply with external compliancy rules and regulations, enabling the auditability of the network operations and therefore increasing the maturity of the network architecture. Chapter 12, “Enabling the Digital Business,” provides more details on the organization aspects for a digital network architecture and maturity.
High Availability
The enterprise network connects every device in the business. Without the network, almost all businesses run into a standstill. Therefore, the digital network architecture needs to be designed with high availability in mind. The network needs to be resilient and fault-tolerant to prevent single points of failure in the network that can bring an entire business to a standstill.
Cloud-Enablement
The cloud (IT elements as a service) has become a key element of most ICT strategies within enterprises. These strategies can vary from “cloud-only, unless” to “no cloud for corporate data” and include a variety of alterations such as operating and designing internal cloud-like datacenters and a full multicloud strategy. In conclusion, the cloud is a standard component of the IT in the business. As a consequence, not only does the specific cloud need to be transparently connected to the enterprise network, but also the employees should not know or see the difference between a cloud application and an internal application.
Therefore, the enterprise architecture itself needs to be cloud-enabled as well, allowing applications to run in both the cloud and inside the enterprise environment. This means that the network operations for policy, analytics, and change management need to be applied with equal simplicity between cloud-enabled applications and enterprise applications.
Furthermore, Cisco DNA must be able to take full advantage of cloud potential (permitting security policy). This can be, for example, optimizing business processes using open and available data, out-tasking specific processes to the cloud based on a larger software scale, or driving faster innovation by allowing faster adoption of new features and functions.
Cisco DNA Design Concept
To meet and be able to implement the earlier set of requirements, Cisco has translated these requirements into a vision named Digital Network Architecture. Figure 4-1 displays the conceptual overview for the Cisco Digital Network Architecture.
Figure 4-1 Conceptual Overview of the Cisco Digital Network Architecture
Figure 4-1 is, for purpose of explanation, slightly different from the figure used within Cisco’s white paper about Cisco DNA.4 Cisco DNA consists of five different functions that collectively meet the requirements. These five different functions result in a number of guiding design principles and derived design principles. These principles are explained in more detail later in this chapter. First each of the five distinct functions of Cisco DNA is explained in the following sections.
4 The Cisco Digital Network Architecture Vision—An Overview, published by Cisco Systems November 2017.
Cloud Service Management
Although the title of this function might be a bit misleading, cloud service management is in essence the umbrella function of the network architecture toward the business. The cloud service management function translates the application policies into several policies, such as identity, access, network, and application definitions. The cloud service management is responsible for pushing these policies into the different underlying functions and validating via the analytics that the state of the network is as designed and set forth via the policies.
Cisco uses the term cloud service management for this function for two distinct requirements:
That the platform itself fully integrates with different cloud models, such as private clouds, virtual clouds, or public clouds. This means that the platform must be able to run on any of these clouds.
That the cloud device management platform must also be capable of orchestrating policies and models across a multitude of cloud platforms as well to provide an end-to-end implementation of the policy.
Figure 4-1 displays two directions of information. One is to receive business and application policies from applications or business processes. This capability is presented via a user interface as well as open standard application programmer interfaces (APIs) so that applications can embed the required functions inside the applications. The second arrow provides, also via user interface and APIs, the necessary information toward applications and other business processes about the operational state of the network, its connected devices, and applications being serviced.
Automation
Within Cisco DNA, the automation function fulfills the responsibility of translating network policies received from the cloud services management function into concrete network configurations intended for the appropriate network devices inside the infrastructure function.
The automation function uses APIs to present its own functions toward the cloud service management function as well as leverages APIs and preferably a stateful transaction mechanism to push the configurations in a controlled manner to the network devices.
The section, “Network Automation Tools,” in Chapter 6, “Tools for Intent,” describes the concept of automation in more detail with network-related examples.
Identity
The identity function defines and is responsible for the identity and access policies within Cisco DNA. Both policies are based on the available policies and resources from the cloud services management function. The identity policy determines who is allowed to access the network infrastructure, and the access policy is used to define which resources (applications and other resources) the user or device is entitled to.
Both policies work in close cooperation; the identity policy is used by the infrastructure to determine which user is connecting to the network. The identity function in return provides the proper mandated access control to the infrastructure function, so that the proper resources can be configured for the connected device.
The identity function is also responsible for facilitating changes in the access control if, for example, malicious activity is found on the network and the device needs to be isolated from the network (or needs to be investigated further).
This function relies heavily on the usage of open and accepted standards, such as the IEEE 802.1X standard (in combination with RADIUS) to provide both functions toward the network devices inside the infrastructure function.
Analytics
Analytics is a key concept function within Cisco DNA. It provides the necessary functions to provide feedback to the monitoring and orchestration tool (inside the cloud services management function) about the operational state of the network, the connected endpoints, its users, and how applications are performing over the network (regardless of whether they run inside the cloud or not).
The analytics function uses APIs to obtain the necessary information from the infrastructure function. These APIs are based on open standards and open mechanisms so that all devices providing network infrastructure functions can provide the necessary information.
Infrastructure
The infrastructure function comprises all network infrastructure–related devices that perform network functions, such as wired access, wireless access, router, WAN, enforcing security policies, and so on. In essence every network device—whether a switch, router, access point, wireless LAN controller, firewall or other security device, physical or virtual—is part of the infrastructure function.
In essence this function is the execution part of Cisco DNA; all network policies, provisioned via automation, are translated into actual network configuration and network operation. Information about the state of the network, the way the network is behaving, and which users attempt to connect are in turn sent to the analytics function.
The receiving of policies or sending analytics of network data in return is preferably executed via open standards and/or APIs. This enables the diversity of network devices to be managed in a single function and in a single manner. Using a single function results in a single view across the complete enterprise network, regardless of where applications and users reside.
Security
Although security is drawn as a vertical column in the image, security itself is not a separate function but must be integrated in every function and implementation of Cisco DNA. It is therefore more a common design principle than a function. The security design principle is covered later in this chapter in the section “Common Design Principles.”
Design Principles
Cisco DNA is founded upon four distinct design principles:
Virtualize network functions
Design for automation
Pervasive analytics
Policy driven and software defined
These design principles govern and support a modern network architecture design for the coming decade. Together, these principles and implicit Cisco DNA design fundamental functionality collaborate to build a modular network concept that can accommodate the radical and rapid changes described in Chapter 2. The following sections describe the four Cisco DNA design principles in more detail.
Virtualize Network Functions (VNF)
Virtualization is common within IT and has been for quite some time now. The introduction of server virtualization consolidated significant server compute power and was one of the enablements for the cloud (as different virtual application functions could be shared on a single server provided by a managed provider). Virtualization within IT means that software (which defines a server or service) runs on top of hardware using an abstraction layer, so that not only multiple services can run on the same hardware, but it is also possible to run different services on that same hardware. In summary, virtualization creates the possibility of running different services on the same hardware instead of using dedicated hardware. It also provides the flexibility that over time different services can be implemented during the lifecycle of the physical server. Besides server virtualization, it is also possible to virtualize applications (known as containers or microservices). It is common for new application development to use application virtualization instead of using monolithic application services.
With Cisco DNA, the virtualization concept is also taken into the network infrastructure. It has been common for network infrastructures to use fit-for-purpose hardware and design the rest of the network around it. Routers are used for running routing protocols and interconnecting several functional routing domains, switches (either campus or datacenter) are used to connect network endpoints to the network, utilizing VLANs to logically separate them (if needed), and firewalls (preferably dedicated appliances) are used for securing those networks.
One of the drawbacks of virtualization is that the network functions run on generic purpose hardware, which can result in a decrease in performance as the number of network functions increase. It is therefore important to only set up VNF in network infrastructure devices that are hardware-optimized for these functions in the network.
Use Case: Virtualize Network Functions
Traditionally SharedService Group had the policy to “pull” all traffic from branches to HQ where the central breakout to the Internet was controlled with the necessary security policies. This policy was also applicable to the different branches located worldwide. Although it was accepted by its employees, the employees did have a preference for accessing the local translated web services, such as Google.
At a certain moment the wireless guest services provided at HQ were also to be deployed at the different branch locations. As the design for this new service was being validated, it became clear that it was not desired to have the wireless guest services brought back into the HQ for a central guest Internet connection for a number of reasons. Besides security risks, the risk of requiring extra WAN capacity and providing a less than adequate service at branch locations where English was not the native language were reasons to decide that wireless guest services must use a local Internet connection.
This decision provided the need to procure and implement new hardware at the branch offices so that the central security policies could still be applied. This resulted in a much higher than anticipated investment; therefore, the wireless guest service at branch locations was put on hold until network equipment was to be replaced during a lifecycle management process.
The example of SharedService displays one of the key benefits to Virtualized Network Functions (VNF). The service was requested by the business, but the required investment did not weigh up to the cost of the new service, and the new service was put on hold. With VNF in the branch offices, it would have been possible to deploy virtual firewalls with the same policies and use a VLAN with a router provided by the local Internet Service Provider to implement this new service. With the increased adoption rate of cloud-enabled sensors and applications in the enterprise, the use of VNF allows for deploying new network functions with a much lower investment cost.
An added benefit of VNF is that new services can be deployed much faster. The network devices are already available, and it is only a matter of software to be deployed. This speed increase supports the need for faster service delivery and will drive innovation.
The first design principle of Cisco DNA is that all network functions must be virtualized in order to achieve flexibility in the deployment of network functions.
Design for Automation
The FreeBSD 10.x and 11.x Frequently Asked Questions5 contains the following question (joke):
5 http://ftp.freebsd.org/pub/FreeBSD/doc/faq/book.pdf
“Q: How many FreeBSD hackers does it take to change a lightbulb?”
A: One thousand, one hundred and sixty-nine:
Twenty-three to complain to -CURRENT about the lights being out;
Four to claim that it is a configuration problem, and that such matters really belong on -questions;
Three to submit PRs about it, one of which is misfiled under doc and consists only of “it’s dark”;
One to commit an untested lightbulb which breaks buildworld, then back it out 5 minutes later;
Eight to flame the PR originators for not including patches in their PRs;
Five to complain about buildworld being broken;
Thirty-one to answer that it works for them, and they must have updated at a bad time;
One to post a patch for a new lightbulb to -hackers;
One to complain that he had patches for this three years ago, but when he sent them to -CURRENT they were just ignored, and he has had bad experiences with the PR system; besides, the proposed new lightbulb is non-reflexive;
Thirty-seven to scream that lightbulbs do not belong in the base system, that committers have no right to do things like this without consulting the Community, and WHAT IS -CORE DOING ABOUT IT!?
Two hundred to complain about the color of the bicycle shed;
Three to point out that the patch breaks style(9);
Seventeen to complain that the proposed new lightbulb is under GPL;
Five hundred and eighty-six to engage in a flame war about the comparative advantages of the GPL, the BSD license, the MIT license, the NPL, and the personal hygiene of unnamed FSF founders;
Seven to move various portions of the thread to -chat and -advocacy;
One to commit the suggested lightbulb, even though it shines dimmer than the old one;
Two to back it out with a furious flame of a commit message, arguing that FreeBSD is better off in the dark than with a dim lightbulb;
Forty-six to argue vociferously about the backing out of the dim lightbulb and demanding a statement from -core;
Eleven to request a smaller lightbulb so it will fit their Tamagotchi if we ever decide to port FreeBSD to that platform;
Seventy-three to complain about the SNR on -hackers and -chat and unsubscribe in protest;
Thirteen to post “unsubscribe”, “How do I unsubscribe?”, or “Please remove me from the list”, followed by the usual footer;
One to commit a working lightbulb while everybody is too busy flaming everybody else to notice;
Thirty-one to point out that the new lightbulb would shine 0.364% brighter if compiled with TenDRA (although it will have to be reshaped into a cube), and that FreeBSD should therefore switch to TenDRA instead of GCC;
One to complain that the new lightbulb lacks fairings;
Nine (including the PR originators) to ask “what is MFC?”;
Fifty-seven to complain about the lights being out two weeks after the bulb has been changed.
Nik Clayton <[email protected]> adds:
I was laughing quite hard at this.
And then I thought, “Hang on, shouldn’t there be ‘1 to document it.’ in that list somewhere?”
And then I was enlightened :-)”
Although the concept of the joke is applicable to many areas such as technology or large organizations, there’s unfortunately a double truth to that answer for operating network infrastructures. Very often many people must be involved for a change based on the processes, validation, alignment with end users, change management, and so on.
It is also, unfortunately, very common that these infrastructures, from small to large, are managed using a per-device approach (using either CLI or on-box management tools). So upgrading IOS on switches, creating or deleting a VLAN, or changing a DHCP helper are all executed by a network engineer typing the required commands onto the box and validating whether the change was successful. This adds an extra layer of complexity, higher risk of error, and extra time requirements to execute a relatively simple change.
Automation allows network operation teams to execute changes automatically in a controlled method instead of executing changes manually per device. The automation tool will execute the mandated change in a very punctual method, repeating the change the same way for each device it is applied to. This reduces the risk of human error greatly, although a mistake in the change can have drastic consequences. Therefore, it is key to test the change before running it through an automation tool.
Use Case: Automation at FinTech Ltd.
FinTech Ltd. has been using network access control for quite a while, changing over time from Cisco Access Control Server (ACS) to Cisco Identity Services Engine (ISE). The same ISE deployment has also been used to introduce central authentication and authorization of the network infrastructure devices as well.
As part of their latest ISE upgrades, the appliances had to be replaced as well as performing a clean install was recommended due to some major internal changes within ISE.
During the migration, a change procedure was documented and crafted. During the preparation of that change procedure it became clear that the RADIUS configuration was not consistent across the sixty-odd access switches; different radius server group names or defaults were used.
As a result, the change procedure itself became more complicated due to these design changes. The lead engineer decided to include a standardized configuration component for the changed RADIUS configuration (using one configuration block for network access control and one for network device management).
The change was further prepared by creating a dedicated application that would execute the necessary changes. This application had the required configuration changes in text (and thus templating the configuration) and used an export of the old ISE environment to know which devices to connect to. A log provided the necessary output to validate whether the changes were executed successfully.
During the change window, the created application was run several times to roll out the necessary configuration changes in small atomic steps. The change itself was faster and more secure, as the tool was executing the changes in a consistent way, leaving the engineer validating if no error occurred. The change was successful as there were no failures or incidents related to network access control on the first day after the change.
This example displays the power of automation. When a campus network is designed for automation, an operation change such as authenticating against a different ISE server can be deployed using templates or other tools instead of copy-pasting changes from notepad into the CLI of sixty-odd devices. The change is in turn executed more efficiently and with no chance of having inconsistencies across the network.
The second design principle of the Cisco Digital Network Architecture mandates that the network infrastructure must be designed with automation in mind.
Pervasive Analytics
There are a few differences between a traditional network and Cisco DNA. One of the primary factors that differentiates both is that Cisco DNA is based on policies (automatically) being pushed to the infrastructure. As these policies can be dynamic and software driven, a feedback mechanism is required to validate the correct state and operation of that infrastructure. This feedback mechanism can be found in the analytics function of Cisco DNA.
Analytics itself can consist of simply checking whether the routing tables and the routing neighbors are set and checking the generic trend on bandwidth utilization and errors found on an interface. This kind of monitoring is traditionally executed via a poll mechanism using SNMP. This traditional method of polling requires some manual configuration per device, is intensive on the CPU of the network device, and is also not capable of providing granular information about the performance of applications or whether a DHCP server is not responding. In summary, the traditional method of only polling the network is not enough for Cisco DNA.
Instead of using polling mechanisms, a more modern approach to obtaining the state and operation of the network is required. Instead of having to poll each device, the infrastructure should provide the analytics function within Cisco DNA the necessary information. Just like how weather sensors provide data to meteorological models, a similar approach is an integral part of Cisco DNA. The infrastructure devices should provide telemetry data (not only including the traditionally available data like interface statistics, but also including client-related data) to the analytics function.
This model-driven telemetry feature allows the analytics function within Cisco DNA to gather more detailed data and perform the proper tasks to determine if the network is operating as expected and therefore provide the proper feedback to cloud service management.
Another requirement for Cisco DNA is to increase efficiency of the network while the diversity and the number of endpoints is increasing. The number of network devices will increase, and the existing network operations team needs to manage and operate the network using different methods. Traditionally the network team would respond to IT-related incidents reported by end users. Most incidents are focused (or blamed) on the network, and it is up to the network team to “prove” that the network is not at fault. The model-driven telemetry already provides a benefit for this task. However, instead of responding to incidents, the intelligence of the network needs to be used to change the network team from responsive to proactive.
In essence, instead of waiting for an incident to happen, Cisco DNA uses programmable network sensors to proactively measure and test the network in a predictive manner. These sensors can be existing network devices, virtual services on these devices, or dedicated test hardware strategically placed in the network.
These sensors will perform the configured tests frequently. The results of these tests are then provided to the analytics function of Cisco DNA so that alerts can be provided to the network team (or other teams) for a possible failure. Using sensors, more intelligence is placed in the network to proactively test several network functions and applications. This provides, in a proactive manner, more information if a client is not receiving an IP address on a site, a DHCP server might be down, or other connectivity-related issues exist. Using network sensors, the network operations team is supported in transforming from reactive to proactive responses.
The data that becomes available from the network infrastructure within Cisco DNA can be used in combination with the evolution of machine intelligence to provide suggested fixes to common problems within the network itself. Machine intelligence is a trend that allows systems within enterprises to use the available (structured) data to provide recommendations on different topics, such as the ordering process, or to determine the cost of an insurance policy. The same principle is to be applied within Cisco DNA. Machine intelligence can use the received telemetry data, information from the identity function, and results from sensors to find relationships to incidents or problems before they might even occur. Based on that “intelligence,” recommended actions can be provided to the network operations team, further promoting proactive behavior. The network is intelligently supporting the network operating team to optimize the operation of the network.
The third design principle of Cisco DNA is that pervasive analytics are used in Cisco DNA to fully harness the power of the latent data inside the network to validate the correct state of the network as well as to detect incidents in the network more quickly by using the intelligence of the network.
Policy Driven and Software Defined
A keyword that has been used repeatedly in the previous paragraphs is policy. Traditionally the network was configured based on the requirements being translated into a number of configuration lines. There was no abstraction layer as to why a certain set of configuration commands had to be used in a specific way other than there was either a template or another switch with similar functionality available. And this is applicable to many areas of the campus network, including switches, wireless networks, routers, and the WAN. The main disadvantage of this methodology is that it does not provide an easy way to validate whether the configuration is working as expected or to be able to reuse the same configuration. In essence, there is a lack of policy.
Policies provide an abstraction mechanism that can hide the details of a configuration or implementation by using a generic specification of the requested service while being as specific as possible. Although this sounds contradictory, an example might help.
Business application X consists of the client applications installed on tablets communicating with web servers via HTTPS. The web servers in turn communicate with an application server that consumes the required data from a single MySQL database server.
This application description is specific in which communication the application requires, but it does not state which specific IP addresses are used. It does not describe where the database server resides and what IP address those web servers have or that the clients are using. This is a perfect example of a policy description that can be stored/recorded in Cisco DNA.
When this application is implemented, specific implementation IP addresses can be specified and the proper access list rules can be created based on the network topology and implementation. The power of this policy is that it can be reused for other implementations of that same application. Or, if the application is moved to the cloud, only the IP addresses for the web servers need to be changed, and the policy can be reimplemented.
Cisco DNA harnesses the full power of operating based on policies. In the preceding example, if that change needs to be executed, Cisco DNA “knows” that the earlier access list rules need to be changed in the campus network, allowing the clients to communicate to the cloud on those ports.
Policies provide the capacity and power to present complex technical implementations in a more generic form, allowing both the required transparency for visibility in an everdiversifying network as well as the ability to perform required changes in a consistent manner.
Inherent to a policy-driven methodology is the concept of software defined. If a policy is defined by the operations team, the software should translate that policy into a consistent change of specific configurations on the different network devices in the infrastructure. This approach allows the software to keep track of which policy resulted in which change so that when a policy is removed, the necessary specific configuration can be removed from the devices as well.
By using a software-defined approach, it is also possible within Cisco DNA to provide a per-user policy into the network once that user or device is connected to the network. The software-defined approach translates the allowed applications policy to configuration elements specific to that user. This allows for more visibility and control in the diversity of applications used in the enterprise.
The fourth design principle is that Cisco DNA is a policy-driven architecture and uses a software-defined approach to implement and monitor those policies. All communication between the different functions is based on a software-defined approach.
The book Cross-Domain Segmentation with Intent-Based Networking by Mark Hazell, Brian Shlisky, Errol Roberts, and David Jansen provides different examples of how a policydriven and software-defined approach can be applied in end-to-end use cases across the enterprise.
Common Design Principles
The different functions within Cisco DNA and its four design principles rely on a number of common principles. Besides regular common network design principles such as mean time between two failures, fault isolation, and so on, there are four common design principles that make Cisco DNA unique compared to regular (campus) network infrastructures:
Cisco DNA-ready infrastructure
Open standards
Use of API
Security everywhere
These four common design principles lay the foundation for every solution based on Cisco DNA. The following sections provide an explanation of these design principles.
Cisco DNA-Ready Infrastructure
In the past, network devices were selected based on their primary network functions. (For example, a switch was selected if the primary function was switching, a router for routing purposes such as a WAN, and so on.) The primary cause for this was that the chip (ASIC) that performed the network function in hardware was built for that purpose. In other words, a switch has an ASIC and physical interfaces used primarily used for switching purposes. The ASIC was preprogrammed for that function, and running new technology or network features in hardware was not possible.
Difference Between Switchport and Routed Port
The Ethernet interfaces on a Cisco device are a switchport or a routed port. With the command no switchport on a switch, it is possible to make a switchport behave like a routed port. All Layer 2 configurations, such as Spanning Tree, are removed from the interface, and for most switches an internal VLAN (in the extended range) is assigned to that interface, allowing only that interface to have an IP address and respond to ARP requests. As a consequence, that VLAN becomes unavailable for Layer 2 functions. This information can be read in the IOS Command Reference guide under the “Extended-Range VLAN Guidelines” section. Another way that a switchport is different from a routed port is that it is not possible to configure subinterfaces on a physical switched interface.
Similarly, routed ports do not support Layer 2 protocols unless they are explicitly configured for a Bridge Virtual Interface, which is partially run in hardware and software.
In designing a network based on models and building blocks, it is important to know which type of interface is available as it can have limits on design and function.
With the introduction of the Catalyst 3650/3850 series, Cisco also introduced a new type of ASIC, the programmable ASIC, also known as the Unified Access Data Plane (UADP) ASIC. The second version of this ASIC was introduced in the Cisco Catalyst 90006 series. This ASIC is unique in the sense that it does not know how to handle an Ethernet frame or an IP packet when the switches are booted. The ASIC is literally programmed with the required features when the switch is starting up. This programmable ASIC provides many benefits and has already proven powerful. For example, at the introduction of the Catalyst 3650/3850 switches the technology VXLAN did not exist, and yet with new releases of operating system code, these switches now support this technology. You could even state that if a new network protocol would be designed and adopted, for example IPv11, this ASIC would be able to handle it in hardware.
6 Cisco has published a book on the capacity of the Catalyst 9000 series at http://cs.co/cat9k-ebook.
The programmability of ASICs is discussed in a Cisco TechWise TV episode7 with Principal Engineer Peter Jones and Distinguished System Engineer Dave Zacks, who both have personally been involved in the development of this ASIC.
7 https://www.cisco.com/c/m/en_us/training-events/events-webinars/webinars/techwise-tv/214-programmable-asics.html
Besides the programmable ASIC, the operating system for the more recent Cisco routers (ISR 4000 series, ISR 1100 series) and switches (Catalyst 3650/3850 series and Catalyst 9000 series) run on the same operating system, called Cisco IOS-XE. Cisco IOS-XE is based on Linux and allows the hardware to run other services besides the IOS-daemon that performs the network functions. In essence, running Cisco IOS-XE allows you to run other virtual machines (although limited) on the device, provided that the device has sufficient CPU and memory, like the Catalyst 9000 series has.
Another benefit of running network devices with the same operating system is that features traditionally only available in routers are now becoming available in switches, such as MPLS and routing protocols such as LISP. In summary, technology features are converging and becoming available on other platforms.
The programmability of the ASIC and convergence of features benefit the network devices used in Cisco DNA. These devices become capable of performing new services, technologies, or features as they become available and required in the Cisco DNA without replacing the network device.
Open Standards
Cisco network devices are most often configured via a command-line interface. The engineer, or in some environments the tool, enters the configuration command for command into the device. Besides the chance of locking the tool or the engineer out (by changing an IP address or IP route), the commands are also executed atomically, that is, each single command becomes effective immediately. Transactional changes (committing a set of commands in a single action) are limited to NX-OS (Datacenter) and IOS-XR (Service Provider). Cisco DNA is based on translating policies into pieces of configuration (for example, building blocks) that can be applied and removed from the basic network infrastructure to support the diverse clients and applications on the digital network. To maintain network integrity it is required to execute these changes (applying and removing policies) in a transactional manner; for example, each policy change should be a single transaction on the network device instead of a sequence of commands executed per device.
Cisco DNA is based on a modern, adaptive approach to the network as a whole, where policies are applied and removed to infrastructure devices. This methodology is required to facilitate network-enabled applications requesting transport over the network via automated processes. This means that application developers (building enterprise applications) must understand how a network operates without the in-depth technical knowledge of commands a network designer or network engineer has. This is accomplished via a model that abstracts the network from specific configuration commands. As Cisco DNA is part of a larger connected environment and this model is intended for third-party developers, the model must be based on open accepted standards.
In conclusion, Cisco DNA prefers the deployment of configurations to be executed in a transactional method to maintain integrity, and a model that abstracts the network from the actual commands is required. Therefore, Cisco DNA requires the usage of internationally accepted open models and standards in its design and implementations. This can be accomplished using NETCONF/YANG models.
Use of API
Cisco DNA consists of five functions (cloud service management, automation, identity, analytics, and infrastructure). These functions represent in a sense their own specific responsibilities and tasks. They also have relationships with other functions, usually as a consumer, provider, or both. For example, the automation function provides methods to the cloud service management function to allow the network to be changed based on policies. Based on the specific change, the automation function translates (or transforms) the policy into distinct, predetermined, and tested configuration changes. These changes are subsequently applied to the network devices inside the infrastructure function.
These methods between two Cisco DNA functions are commonly performed by software without human intervention. It is therefore important that these methods between functions need to be described in such a formal manner that different tools can provide one or more of the Cisco DNA functions. This formal method of describing and enabling functionality between systems is commonly referred to as Application Program Interface (API).
APIs provide software engineers with sufficient documentation and functionality so that software engineers can use the functionality inside their own code without writing that functionality themselves.
Within Cisco these formal methods can exist between two different solutions each performing a Cisco DNA function; therefore, these API calls are to be executed via server-to-server communications. To facilitate a digital network architecture based on a policy-driven, software-defined, and automated approach, the communication between Cisco DNA functions is to be executed via APIs. These open and exposed APIs are also applicable in the communication to and from the cloud service management function.
This common design principle allows external parties, such as enterprise application developers or other software engineers, to programmatically (using a software-defined approach) request the operational state of the network as well as to provide the possibility to request transport services for their application.
RESTful Application Programmer Interface
Within the history of software development, several methodologies and principles have been used in the past to allow server-to-server or client-to-server communication. Concepts varied from Remote Procedure Calls, Remote Method Invocations, Service Oriented Architectures, and Enterprise Messaging Queueing Systems to full Enterprise System Buses. The most recent and widely adopted concept for API-based communication over a network (also known as Web 2.0 services) is called RESTful API. REST is the acronym for Representational State Transfer and has been available since 2000.
The RESTful API is based on the HTTP protocol and uses so-called Create, Read, Update, and Delete (CRUD) methods in combination with URLs. The data being transferred between systems is text encapsulated in specific file formats, such as Hypertext Markup Language (HTML), eXtensible Markup Language (XML), or JavaScript Object Notification (JSON). XML is common, while JSON is gaining more popularity due to its easier-to-read-and-construct syntax.
An example of a REST API call would be a weather app asking the weather for a specific location at a web service. A special GET request would be sent to a weather service, where the response would be the weather forecast in a structured format. That response is parsed by the app and shown to the user.
This example showcases that an app is executing a system-to-system response to a service and receives the response back, which in turn is presented to the end user. More information and examples of APIs are provided in Chapter 10, “Phase Four: Enable Intent.”
An increasing number of Cisco products provide an API interface and primarily use a REST-full API for that. The DevNet8 website from Cisco provides more details and code examples of APIs.
Security Everywhere
Network security is evolving at an ever-increasing pace. This increase is a direct result of the professionalism that malicious actors apply on their software and approach. In general the malicious actors have near-unlimited funding and time to try to gain access to the data they want. This includes (successful) attempts to compromise software or other elements in the supply chain of the enterprise to achieve their goal.
In classic enterprises security was commonly implemented by a defense-in-depth approach, with several active security perimeters in the network, providing a layered approach where the most sensitive data was hidden behind several of these security layers.
However, a negative side effect of the increase in cloud usage, diversity of devices, and other issues is that the possible attack surface available to malicious users increases. Figure 4-2 provides a schematic overview of an enterprise network and shows where different attack points can be used by malicious users. There are many more possible attack vectors compared to the past, where the Internet perimeter was the primary attack surface.
Figure 4-2 A Conceptual Overview of Potential Threat (Image courtesy of Cisco Live Techtorial on Offensive Cybersecurity)
To be able to keep up with the pace as well as keep the enterprise manageable and respond to security risks rapidly, there must be a unified security approach to the network infrastructure. This unified security approach must be able to fulfill a minimum set of requirements. These requirements are aimed to improve security across the enterprise network:
Visibility and detection: The network must be able to provide the necessary visibility for devices (and end users) and their communication on the campus network. By having a unified visibility, it is easier to detect if malicious activity is seen within the enterprise.
Single consistent security access policy: With the network being more dynamic, security access policies need to be consistent and created in such a way that the access is defined and determined in a holistic approach, regardless of which device (switch, next generation firewall, or wireless LAN controller) it is applied to. This consistent security access policy increases the visibility and provides an increase in network security.
Unified segmentation policy: With the diversity of types of devices and related access policies, it is necessary to have a unified segmentation policy applied to the (campus) network. A unified segmentation policy improves the visibility and ensures that it is impossible to view the information within flows if not allowed. In other words, using a unified segmentation policy ensures that, for example, IoT traffic is not matched with enterprise traffic so that compromised IoT devices cannot listen to that enterprise traffic.
Easy and rapid containment: The nPetya outbreak in June 2017 resulted in more than 5,000 infections per minute inside an affected enterprise. The cause of this high infection rate was the ability of the malware to move laterally through the network. This real-world example shows that it is key for a modern digital network architecture to enable rapid threat containment. In other words, if malicious activity is seen, the device needs to be isolated from the network as soon as possible to prevent further damage.
In conclusion, network security and visibility must be an integral part of Cisco DNA to maintain the required security policies in the dynamic use of the campus network. Security needs to be everywhere inside a Digital Network Architecture.
Overview of Cisco Solutions
Cisco DNA is in principle a functional architecture design for the enterprise network and fits inside the technology architecture of an enterprise. Cisco’s product portfolio provides solutions that can implement the different functions of Cisco DNA. Figure 4-3 provides an overview of the different products and solutions applicable to campus networks with which a Cisco DNA can be implemented.
Figure 4-3 Overview of Cisco Products and Solutions Matching DNA Criteria
Figure 4-3 provides a direction in which products and solutions can be used to implement Cisco DNA. As the technology inside products, solutions, and integrations evolves, specific limitations can be applicable for certain devices. At the time of writing, the following limitations are known and should be taken into account:
The Cisco WLAN Controllers 2504 and 5508 do support AireOS 8.5 code releases; Software Defined Access (SDA) Wireless is supported, but model-driven telemetry (Analytics) is not supported on these devices.
The Catalyst 3650/3850 is Cisco DNA ready infrastructure but has limitations in number of capacity and sizing in relationship to SDA.
Certain compact 3560C and industrial switches do support SDA with limitations specified in the release notes.
Prime Infrastructure and APIC-EM are available solutions for today and have not seen an end-of-life announcement. However, Cisco DNA Center is the successor to these tools, and it is expected that Prime Infrastructure and APIC-EM will get an end-of-life once Cisco DNA Center has a similar set of features. This should, however, not restrict any organization from starting the transformation to Intent-Based Networking.
Every organization and network is unique. The details in deployment and situation determine which tool fits the purpose best.
The table in Figure 4-3 can be used in the beginning stages to transform existing networks into a Digital Network Architecture, which is described in more detail in Part 2, “Transforming to an Intent-Based Network.”
Summary
From the perspective of the TOGAF® standard, the Cisco Digital Network Architecture (Cisco DNA) is part of the technical architecture describing the requirements, principles, and functions of the network infrastructure for the enterprise. Cisco DNA is based on requirements that represent the challenges and drivers described in Chapter 2. These requirements can be summarized as follows:
Faster innovation through:
Increased flexibility
Providing more context to allow granular metrics and services
Intelligent feedback mechanism
Faster deployment through tighter integration
Reducing complexity and cost via:
Simplicity in design
Software-driven operations based on policies and automation
Increased efficiency of operation
Tighter integration with compliancy and technology:
Security
High availability
Visibility for external compliancy rules and regulations
Cloud-enablement by default
Based on these requirements, Cisco DNA is composed of five distinct functions, which can be summarized as
Cloud service management, to provide business-enabled services
Automation, to quickly deploy changes in configuration to network infrastructure devices
Identity, which is used to determine who is accessing the network and what access policy is to be applied
Analytics, to validate whether the network infrastructure is operating correctly and providing the correct services
Infrastructure, the actual network infrastructure devices
Cisco DNA also provides a number of design principles and common design principles used to meet the requirements and support a successful implementation of the requirements. These design principles and common design principles are summarized as
Virtualize network functions
Design for automation
Pervasive analytics
Policy driven and software defined
Cisco DNA-ready infrastructure
Open standards
Use of APIs
Security everywhere
Cisco DNA provides, on a functional level, an extensive architectural approach to the design of a network infrastructure that is prepared to meet all requirements and the foreseen challenges for a campus network.