Cisco DNA Center is the network management and command center for Cisco Digital Network Architecture. According to Cisco, the DNA Center is a technology upon which the future of networks, Intent Based Network (IBN), will be based. This technology provides a centralized place to manage device configurations.
Cisco DNA Center Device Management
Cisco DNA Center gives network managers more control over networks device management and notification handling. According to Cisco, the DNA Center is a technology upon which the future of networks, Intent Based Network (IBN), will be based. This technology provides a centralized place to manage device configurations.
Cisco DNA Center can be accessed by using the Cisco DNA Center web-based GUI interface (web interface) or by using the REST APIs.
Using the web interface will need some more configurations on Cisco DNA Center as well as the firewall for proper access. Our main focus will be REST API but the web interface for the devices will also be discussed. But first, let us look at the structuring of management information.
YANG and Model Driven Programmability
Models allow us to specify the structure based on which data is sent across the network. They ensure that the configuration information is received in a consistent and standardized way.
This is the language that enables networking devices to know how to structure the data they will be transmitting. For example, in order to get an interface’s information, the interface-name, the interface-status, and the interface-address will always be required. This can be specified in a YANG model so that whenever a device information is required, these required pieces of information are always present. The YANG models are normally written by vendors, and there is no need to write these models from scratch. Many modern Cisco devices come with pre-installed YANG models that define how they will structure the data when communicating with the DNA Center.
Cisco DNA Center REST API
Authentication
The Cisco DNA Center features can be accessed via a REST API.
During the setup of Cisco DNA Center, users are created in the system that can access the Cisco DNA Center (DNAC) controller. When accessing Cisco DNA Center, valid user credentials are required for login (username and password). These username and password will be provided as basic authentication and will be enough to generate the user access token for the device.
This can be done through a Python script (not tested in the exam) as seen below:
import requests
from requests.auth import HTTPBasicAuth
CONTROLLER_ADDRESS = “sandboxdnac.cisco.com”
CONTROLLER_USERNAME = “devnetuser”
CONTROLLER_PASSWORD = “Cisco123!”
response = requests.post(“https:// {}/dna/system/api/v1/auth/token”. format (CONTROLLER_ADDRESS), auth=HTTPBasicAuth (username=CONTROLLER_USERNAME,
password=CONTROLLER_PASSWORD))
response_dict = response.json()
token = response_dict[‘Token']
print(token)
This script should print the access token on execution. For generation of a token again in the future, the above script should be placed in a Python function as illustrated below:
import requests
from requests.auth import HTTPBasicAuth
CONTROLLER_ADDRESS = “sandboxdnac.cisco.com”
CONTROLLER_USERNAME = “devnetuser”
CONTROLLER_PASSWORD = “Cisco123!”
def generate_dnac_token(address, username, password):
url = “https://{}/dna/system/api/v1/auth/token”.format(address)
response = requests.post(url, auth=HTTPBasicAuth(username=username, password=password))
response_dict = response.json()
token = response_dict[‘Token']
return token
token = generate_dnac_token(CONTROLLER_ADDRESS, CONTROLLER_USERNAME, CONTROLLER_PASSWORD)
print(token)
This will produce the same result as the previous code snippet.
Make a POST request with the given URL. Replace {{username}} with your username, specify your password, and on the URL, replace {{DNA-address}} with the address of your DNAC controller.
It should be noted that the authentication used here is the basic authentication, which only requires a username and a password to generate the key. The token generated in the response body will be used in the subsequent requests to get information about the network and make any configuration changes.
List devices
Let’s dig a bit deeper. To get a list of all networking devices under the DNAC controller, authentication is required before starting.
import requests
CONTROLLER_ADDRESS = “sandboxdnac.cisco.com”
CONTROLLER_USERNAME = “devnetuser”
CONTROLLER_PASSWORD = “Cisco123!”
token = generate_dnac_token(CONTROLLER_ADDRESS, CONTROLLER_USERNAME, CONTROLLER_PASSWORD)
def get_devices(address, token):
url = “https://{}/api/v1/network-device”.format(address)
headers = {‘x-auth-token': token}
res = requests.get(url, headers=headers)
devices = res.json()[‘response']
return devices
for device in get_devices(CONTROLLER_ADDRESS, token):
print(device)
print(“—————————————–“)
For authentication, the token that was generated in the code snippet above is entered. In the headers, x-auth-token field is used, and its value is set as the token that was generated in the above step of authentication.
Then a GET request is sent to https://{{dnac-address}}/api/v1/network-device where {{dna-address}} is the DNAC controller’s address with the header.
NOTE: Remember to replace the CONTROLLER_ADDRESS, CONTROLLER_USERNAME and CONTROLLER_PASSWORD with the address, username, and password of the DNAC controller you are using.
For my case, I will set CONTROLLER_ADDRESS=”sandboxdnac.cisco.com”,
CONTROLLER_USERNAME=”devnetuser”, and CONTROLLER_PASSWORD=”Cisco123!”.
If the script above runs successfully, the output should be something like below:
{‘lineCardCount': ‘9', ‘series': ‘Cisco ASR 1000 Series Aggregation Services Routers', ‘collectionInterval': ‘Global Default', ‘collectionStatus': ‘Managed', ‘roleSource': ‘AUTO', ‘softwareType': ‘IOS-XE', ‘lastUpdated': ‘2020-03-11 13:35:46', ‘managementIpAddress': ‘10.10.22.253', ‘platformId': ‘ASR1001-X', ‘memorySize': ‘3819298032', ‘errorDescription': None, ‘location': None, ‘bootDateTime': ‘2019-11-08 00:14:32', ‘softwareVersion': ‘16.3.2', ‘interfaceCount': '12', ‘tunnelUdpPort': None, ‘id': ‘1cfd383a-7265-47fb-96b3-f069191a0ed5', ‘apManagerInterfaceIp': ”, ‘associatedWlcIp': ”, ‘role': ‘BORDER ROUTER', ‘inventoryStatusDetail': ‘<status><general code=”SUCCESS”/></status>', ‘snmpContact': ”, ‘errorCode': None, ‘family': ‘Routers', ‘lineCardId': ‘d9ee06c9-1d0c-4032-919a-9896b0119567, 999f98b1-19bc-4146-a70c-a465ba449831, 1d21ac54-2aee-4e64-8076-fa7638f11a2e, cbcacc67-5020-4e80-b742-870d81f1b764, b84abe3a-6b3a-4f8f-a6b8-fcce654fe753, 4ebb74b8-2850-4ebd-b288-60b4d1500eb3, c46992ff-fed6-4c3c-8765-a253130090f4, 159a794d-fa02-442e-ac22-25496395934b, 0d54d112-96b3-47b3-8d35-03aa8abd7e0c', ‘instanceUuid': ‘1cfd383a-7265-47fb-96b3-f069191a0ed5', ‘type': ‘Cisco ASR 1001-X Router', ‘reachabilityStatus': ‘Reachable', ‘instanceTenantId': ‘5dc444d31485c5004c0fb20b', ‘hostname': ‘asr1001-x.abc.inc', ‘tagCount': ‘0', ‘upTime': '35 days, 2:16:57.11′, ‘reachabilityFailureReason': ”, ‘waasDeviceMode': None, ‘MACAddress': '00:c8:8b:80:bb:00′, ‘serialNumber': ‘FXS1932Q1SE', ‘locationName': None, ‘snmpLocation': ”, ‘lastUpdateTime': 1583933746136}
—————————————–
{‘lineCardCount': ‘2', ‘series': ‘Cisco Catalyst 9300 Series Switches', ‘collectionInterval': ‘Global Default', ‘collectionStatus': ‘Managed', ‘roleSource': ‘AUTO', ‘softwareType': ‘IOS-XE', ‘lastUpdated': ‘2020-03-11 13:40:04', ‘managementIpAddress': ‘10.10.22.66', ‘platformId': ‘C9300-24UX', ‘memorySize': ‘1425966824', ‘errorDescription': None, ‘location': None, ‘bootDateTime': ‘2019-11-08 00:43:17', ‘softwareVersion': ‘16.6.4a', ‘interfaceCount': '41', ‘tunnelUdpPort': None, ‘id': ‘21335daf-f5a1-4e97-970f-ce4eaec339f6', ‘apManagerInterfaceIp': ”, ‘associatedWlcIp': ”, ‘role': ‘ACCESS', ‘inventoryStatusDetail': ‘<status><general code=”SUCCESS”/></status>', ‘snmpContact': ”, ‘errorCode': None, ‘family': ‘Switches and Hubs', ‘lineCardId': ‘0f6e996d-afb5-42b0-97b7-3ef432351f88, 231651f1-cfb0-4c44-a347-4d41253c550c', ‘instanceUuid': ‘21335daf-f5a1-4e97-970f-ce4eaec339f6', ‘type': ‘Cisco Catalyst 9300 Switch', ‘reachabilityStatus': ‘Reachable', ‘instanceTenantId': ‘5dc444d31485c5004c0fb20b', ‘hostname': ‘cat_9k_1.abc.inc', ‘tagCount': ‘0', ‘upTime': ‘124 days, 12:53:57.09', ‘reachabilityFailureReason': ”, ‘waasDeviceMode': None, ‘MACAddress': ‘f8:7b:20:67:62:80', ‘serialNumber': ‘FCW2136L0AK', ‘locationName': None, ‘snmpLocation': ”, ‘lastUpdateTime': 1583934004046}
—————————————–
Each device’s details are separated by a dotted line, shown at the end of above code. This will appear a couple of times depending on how many devices are being controlled by the DNAC controller. The resulting response will be a list of all the networking devices being used under the DNAC controller.
Listing events in the network
To get a list of all the events that have occurred in a network, same procedure will be followed as mentioned above. We will use the URL:
https://{{dnac-address}}/dna/intent/api/v1/events
The response should be a JSON with a list of all events, their types, details of the events, severity, subscription types, and much more. This will inform us about the series of actions that have been going on in the network.
Signing up for network event notifications
Listing network events is useful for viewing network activities and troubleshooting any issues but what if an instant notification is required when an event occurs?
To do this, a URL that is accessible online needs to be set up.
Assuming our publicly accessible URL is https://some-url/, we can set it up to constantly receive notifications using the Intent API. To subscribe to a specific event, the x-auth-token will be used in the header, like it was used previously for authentication. In our request body, the following items will be specified:
- Name of the webhook
- Description of the webhook
- Endpoints you want to subscribe to events
- Events you want to be subscribed to
An example of the event that can be subscribed to is an interface going down. In the description of the webhook, the name, URL, method, connector, and the type of URL must be specified.
Whenever a subscribed event occurs, a JSON message will be sent to https://some-url using the method that was specified while subscribing to the event. We can then program to set up the URL, in our case flask, to specify what should happen when the message is received from Cisco DNA Controller.
Visit the Cisco Developer network for more details on how the Cisco DNA Center Intent API can be used to subscribe to events and how it can be used dynamically.
Cisco DNA Center Web Interface
The web interface can also be used to do exactly what has been done previously in Python. A basic introduction is discussed but the web-interface GUI is quite self-explanatory
Upon visiting the DNAC controller address on a web browser, a login page will ask for a username and password as depicted in below figure:
FIG 26.1 – Cisco DNA Center login page
You will enter the username and password which was used in the previous API section. The generated token will not be stored this time because the web application will do it automatically, and then you will successfully log into the system.
The basic details will be visible as mentioned in below figure:
FIG 26.2 – Cisco DNA Center homepage
Different features of Cisco DNA Center such as monitoring and management of devices, Integrated Service Engine, policies, procedures can be accessed using the dashboard.
REST APIs
To optimize the client application, you should be aware of some of the many advanced features that Representation State Transfer (REST) Application Programming Interface (APIs) can provide. REST API has completely reshaped the user interaction with the most applications because of its robust architecture.
What is an API?
An Application Programming Interface (API) is a window to system resources.
Consider an example of using a drive-through. A person places an order, and the order is processed, packed, and given back to the person. Does the person bother about the details of what happened in the kitchen before the food was received? Not really, because there is only a window, all that is required to get the food. The person does not need to enter the kitchen and do the cooking and packaging himself.
The window that is open for a user to give order, is known as a resource in APIs. A resource is available for a user; he only needs to request something and expect a response. This is how APIs operate.
FIG 26.3 – Picture of a drive-through (Image source: nairobiwire.com)
Most of the time, systems are built to hold specific pieces of data, and the systems work on these pieces of data to ensure user demands are met. The data is usually completely secured from applications residing outside the hosting server.
In the modern world, however, the applications do not operate alone. Different applications and systems are constantly communicating with each other, exchanging state information, data, and so much more. As I like to say, ‘no application is an island.’
FIG 26.4 – APIs integrating everything together (Image source: draw.io)
Let’s look at smart refrigerators as an example. Some of them are capable of informing a user via his mobile phone when the milk is finished in the refrigerator. What happens there? The fridge is a system on its own, and it can detect the absence of milk in the refrigerator. The mobile phone runs an application which is also a system on its own. When the fridge detects that the milk is finished, it sends a notification to the mobile phone. In this way, two systems completely independent of each other can communicate.
They are able to communicate through an API, which transmits specific pieces of data from the refrigerator. This API allows complete synchronization of both sender and receiver.
Also, the refrigerator only transmitted a certain attribute of milk while keeping all other attributes hidden, thus preventing any compromise of system details. This is the beauty of APIs; they allow the users to specify exactly what needs to be transmitted to external applications while securing all other attributes.
From an SDN standpoint, there is a controller which has the complete information of the network. Let us assume that this controller is our server and the information it contains includes a list of networking devices, users that are allowed to log into the networking devices, details of the networking devices (e.g. interfaces), and protocols being run within the network etc.
At some point, this data may be needed from the controller to optimize the network for business needs. APIs will be extremely helpful in this case because they will provide resources both for analysis and general notifications, for example, in case of a malfunction or heavy traffic.
FIG 26.5 – Controller communication with an API
In this section, along with discussing APIs, we will also try to develop a “mobile application”. The application will be used to set configurations for networking devices and retrieve data from these devices.
The following are common uses of APIs in modern technology:
- Authentication – APIs are used for authentication, for example, login via Facebook uses a Facebook API.
- Channel of communication – APIs are used as a channel of communication between low power devices (e.g. mobile applications) and high-power devices (e.g. servers) because low power devices are normally unable to perform heavy processing such as Artificial Intelligence.
- Front-end and back-end separation – APIs allow separation of the front-end and the back-end during web development. The people working on the actual system hide the complexity of the system and only have an API that exposes specific details about the system. The developers only consider the design and interaction with the API.
The following are some uses of APIs specific to computer networks:
- Getting and editing running configurations within networking devices
- Giving details about traffic, for example, when the limit has reached a certain point
- Sending notifications of specific actions on interfaces in networking devices, for example, when an interface goes down or comes back up.
- Sending header information for incoming packets through the OpenFlow Protocol.
What is REST API?
REST is short for Representational State Transfer. REST is an architectural style for distributed hypermedia systems as described in https://restfulapi.net. Simply put, REST is an easily comprehensible technique used for communication between various systems.
Let’s clear something up before we have a deeper look at REST. It is an architecture (not a protocol) that resides on HTTP/HTTPS protocols in the application layer. There are protocols that allow communication between various web entities.
The architecture looks something like this:
FIG 26.6 – API architecture
REST has been used extensively for reasons including:
- Simplicity – REST APIs are easy to understand and do not have strict pre-requisites to start off. They are very simple as compared to SOAP and are quite eye catching. The data format REST uses for transmission and how REST displays the data will be discussed later.
- Ease of use –REST uses HTTP/HTTPS. For most developers, HTTP/HTTPS is a lot easier to understand and use because it utilizes traditional methods/verbs that developers have been using for a long time.
- Speed – REST is less resource intensive on the network because of the weight of the data it carries. This is beneficial for both application developers and network engineers.
One point that should be noted is that REST APIs are completely stateless. This means that the data from an earlier request is completely unknown to a new request, and each new request holds its data on its own. So, if a user want to retain a state between requests, user tokens would have to be used. Tokens are beyond the scope of the CCNA syllabus.
FIG 26.7 – REST API requests and responses with authentication
REST APIs operate on a client-server architecture. In a client-server architecture, there are two parties (that are not peers) communicating with each other; one has the resources (server) that the client requires. In this architecture, the server always enables access to its resources and specifies its available resources. The client will initiate a request on learning the resources through an API. This request is sent for a specific resource and is always initiated by the client. After the server has received the request, it will search the system and, based on what the client has requested, will give an appropriate response.
As mentioned above, after the client has received the response from the server, the information received from the request will be lost after the second request, unless the client has a technique to hold this data from one request to another.
There are specific rules that must be followed for an application to be considered as RESTful:
- Uniform Interface – For information transfer between systems, there should be standards between these systems. This allows appropriate resource requesting and response so that each system can comprehend the other. For interfaces to be considered RESTful, these things must be uniform: resources (URIs), Hypermedia Engine of application state, self-descriptive messages e.g. standard MIME types, and manipulation of resources through these representations e.g. using GET, POST etc. methods.
- Client-Server – RESTful interfaces mainly involve getting services from one host to another; the host providing the services is the server and the one requesting for the services is the client. There should be a separation of concern and the client should not be concerned with the complexity of the server.
- Stateless – Systems communicate through a series of requests and responses between the systems. For a communication interface between the systems to be considered RESTful, it should not be stateful. This means that from one request to another, the data should not be held.
- Cacheable – Caching is used in system development for improvement of performance. When something is regularly accessed, it is cached thus making it easier and faster to access. The client should be able to reuse data from a previous request if possible. The server should specify when the data being sent is cacheable.
- Layered System – Each component should not have knowledge of the behavior of other components in the system. If a user is raising a query of an aspect in the system that will in turn query a database, the user should not know that the database is being queried. He should only have the knowledge of the contact he is making.
- Code on Demand (optional) – This is used when clients need to get the code to perform a specific action on their part. For example, in REST API chatbots, buttons can be used as a part of messages. These buttons are UI elements, and they will send a code. In such case, when the client needs to get the code and implement it, the code will get exposed. Because this is not always the case, therefore, this feature is optional.
Our Application
We need to start developing our “mobile application” but first, we need to have a system that is working. Let us take the following system:
FIG 26.8 – Network system
This is a system that runs inside a network controller. The controller will serve as a REST API server. This controller communicates with the networking devices and runs commands based on the information it receives from these devices.
It is also assumed that there are specified users who can access the data inside the controller and their information is stored in USERS section. The controller has a list of NETWORKING DEVICES and their details, such as interfaces that are up and the states of various protocols inside these networking devices. The networking device details execute the CONTROLLER LOGIC. This controller logic includes items such as routing algorithms, switching algorithms, load balancing, and other things related to networking devices. NETWORK ANALYSIS can also be included to analyze and optimize the network according to business needs.
Let us have an overview of how the API from the controller, which is a REST server, will be communicating with the client, the mobile application.
FIG 26.9 – Overview of our application API
So, our networking system is now running on the controller. The controller has to expose two elements on the API, user authentication and networking device resources.
In our case, a user accessing the mobile application should be able to get information of all the networking devices present in the network. This list will be retrieved using the network devices API resource running on the network controller, which is also our API server. As shown in Figure 26.9, the controller elements should only be accessed by specific authorized users. This is the reason why a user authentication resource is utilized. The users will be required to enter their e-mail and password on the mobile phone before they can access the network details.
Create Read Update Delete (CRUD)
Systems are created for data storage. This is true for any system ranging from networking applications to health systems or any other type. Any interaction with these applications revolves around the data that they can hold.
The actions performed on the data are abbreviated as CRUD, short for Create, Read, Update, and Delete. These are the actions that can be performed on the data from an application.
CREATE
The application should have an option to add new pieces of data. In our case, the data could be networking devices, networking users etc.
READ
The stored data should be retrievable from the application. In our case, the application should be capable enough to get complete information of already-present networking devices. The information includes Interface States, IP addresses of different systems etc.
UPDATE
The provision to edit data should also be present in the application. The networking application, in our case, should be capable to edit the IP addresses of the networking devices known to the application.
DELETE
The application should be able to get rid of the stored data. If there is a networking application and a networking device is removed from the network, then the application should delete this device from the its database.
The above-mentioned CRUD activities are performed by the application itself, and the application should have the complete internal information about these activities. The external applications accessing our application’s resources through an API should not have direct access to these activities or functionalities. HTTP verbs allow external applications to perform CRUD actions without having direct access to the application’s data.
Our Application
Let us review how CRUD can be utilized in our application.
FIG 26.10 – CRUD for our application
HTTP Verbs/Methods
FIG 26.11 – HTTP verbs or methods
When a resource is accessed, a verb is specified so that the server whose resources are accessed knows which action is expected from the request. HTTP verbs, also known as HTTP methods, must be sent along with each HTTP request. If the HTTP verb is not specified, the GET verb is used by default.
Some common HTTP verbs/methods are mentioned below:
GET
This is similar to the READ activity in CRUD. If data is read from our system, then there is a chance that it gets exposed through an API resource that uses the GET method.
For instance, in a networking-based application, READ gives details about the networking devices. When an API resource, e.g. https://our_uri/devices, is accessed using the GET method, it lists all the networking devices present in our system.
This is the way Cisco based controllers access all the devices that are under the controller.
POST
Like CREATE in CRUD, this method is used to create new elements in a system. For example, it can be used to add a new networking device in a system.
PUT
Like UPDATE in CRUD, this method is used to edit elements of an application by replacing the existing information in the application’s database. When an entire networking device is replaced, PUT will be used to change the details of previous networking device in the application.
DELETE
As the name suggests, this method is used to delete elements in a system using an API resource. If we want to erase a specific node, DELETE will be used to send a request to the APU resource involved with individual devices.
PATCH
Like PUT method, PATCH is used to edit data in a similar manner to the function of UPDATE in CRUD. It can only be used to update the data and is incapable of replacing the element in the system. For example, in our networking application, PUT was used when a networking device was completely replaced. PATCH only modifies specific details of the element. For instance, if IP address modification is required of a node in the network, unlike PUT, PATCH will be the appropriate method because it will allow to edit only specific attributes of the node.
