Cisco Platforms and Development (8)

 

Why Should I Take this Module?

As is frequently the case with NetAcad courses, the final module is where you get to put all that you’ve learned to the test. And DevNet Associate Fundamentals is no different.

If you want to know about all of Cisco's developer and automation offerings, there is a lot of information to sort through. This section pulls it all together in big categories, such as collaboration, compute including data centers, networking including data models, and security. Even if you are familiar with a product family, we hope you learn new tips or hints while reading through and trying some of these platforms first-hand.

Introduction to Cisco Platforms

Understanding the Cisco API Platform

Cisco has a long history as a networking gear company and hardware supplier. Those offerings are now available as automation opportunities. The Cisco portfolio spans customer service centers, phone management, mobile and wireless networking, the Internet of Things (IoT), and even security, as Cisco continues to improve data center and cloud-based solutions. In this module, we'll look at some of these platforms and how they can be used.

Exploring the categories of Cisco technology

To help with sorting through all of the Cisco developer offerings, DevNet creates Dev Centers for each technology group, and those Dev Centers are a convenient way of grouping technologies together. On the landing pages that represent those Dev Centers, you can find all the related resources for that technology, such as links to relevant documentation, Sandboxes, and Learning Labs. Below is a list of the Cisco Dev Centers:

• Cloud
• Collaboration
• Data center
• Internet of Things(IoT) and edge computing
• Networking
• Security
• Wireless and mobile
• Application developers

Cloud

Cisco works on solutions with major cloud providers such as AWS and Google Cloud, as well as offering a container management program running on Cisco hardware. Cisco provides many models for cloud deployments, including public, private, or hybrid. Cisco also has container management solutions based on Docker and Kubernetes.

Cisco knows that most companies do not use a single cloud-based deployment or storage or networking solution but instead, use combinations of hosting, including cloud and on-premises, as well as using solutions from various partners. With that in mind, DevNet provides a Cloud Dev Center with links to the APIs, tools, and explanations of container networking and hybrid connectivity.

Collaboration

Modern collaboration tools connect the world and Cisco has many capabilities in the collaboration category. The Webex product line has both device and cloud-based API access for video teleconferencing, enterprise-level instant messaging, and meeting scheduling and management. Use cases include integrated customer care through Finesse, as well as call control for customer service centers using Cisco Unified Communications Manager (CUCM). Additional use cases include voice messaging and presence statuses, chatbots for customer support or notifications when monitoring systems, calling, and messaging.

Cisco Unified Communications Manager (CUCM) provides API access to data management, call management, and voicemail integration. Developers can create custom web applications for voice and video calls, or interact with a Cisco desk phone. Use cases, integration points, and many more developer tools for collaboration solutions, can be found in the Cisco DevNet Collaboration Dev Center.

Data Center

The data center provides networking, compute power, storage solutions, and access for powerful solutions for operations, business networks, and applications. Cisco provides multiple data center platforms, including Nexus and Cisco Unified Computing System (UCS). Data center use cases address both the NX-OS and IOS XE operating systems.

With programmable infrastructure, developers and engineers are integrating network deployment with monitoring and policy management to deploy their workloads programmatically. Many components of a data center may be accessed programmatically to manage everything from a single server with a standalone network, to complex multi-layered architectures with thousands of devices in orchestration. We call this Application Centric Infrastructure or ACI.

Cisco provides platforms that integrate with automation, orchestration, and configuration management tooling while also offering monitoring, detection, alerts, and telemetry data. This wide range of Cisco platforms and infrastructure form the basis for solutions that scale to large service provider platforms.

You can use Python SDKs for data center automation solutions for ACI, Nexus platform, and Cisco Unified Computing System (UCS). The Python Automation Test Systems (pyATS) may also be used as a basis for reusable tests, represented by linked objects. pyATS tests range from simple connectivity tests all the way to profiling and verifying the target network with automated tests. DevNet provides the Data Center Dev Center that serves as a starting point for compute and networking APIs, day 0 provisioning use cases, testing and automating with Python, and links to management tools and technologies.

Internet of Things (IoT) and Edge Computing

Sometimes you need networks with built-in capabilities for lots of sensors and data on the IoT. These sensors may even be needed in harsh or remote environments. Cisco provides different types of tools for IoT, including rugged industrial-strength networking gear, IoT gateways, low-power solutions, and embedded networking for highly secure IoT data delivery as needed. All are configurable with Cisco access points and routers.

With Cisco IOx, you can host applications on Cisco hardware, including container-based deployments. IOx applications integrated with Kinetic can publish data using a message protocol, MQTT, acting as a Kinetic data connector.

Edge computing refers to providing computing capability as close to the actual data as possible. There are many reasons to have an application deployed at the edge, such as to avoid high levels of data transfer for performance or security purposes. Or, maybe there are a large number of sensors with a high level of streaming data. With Cisco edge computing support, you can build, deploy, monitor applications on network devices.

These use cases are explained in greater detail and references to resources in the IoT Dev Center.

Networking

Cisco doesn't just provide network device hardware such as switches, wireless endpoints, routers. The operating system software for these devices is purpose-built for specific needs. Cisco IOS is used for network infrastructure, with different specialty versions. Cisco IOS XR focuses on service provider use cases. Cisco IOS XE separates the data plane and control plane for network creation and maintenance. Cisco NX-OS works across both physical and virtual data center deployments.

Nearly all of the major product lines from Cisco have APIs and programmability built-in. As a result, it is now possible to write shared code to manage varied network devices, even if the devices are from different vendors. For example, Meraki offers monitoring, configuration, and data access such as floor plans, plus security and teleworker appliances, with APIs available to build custom solutions built on the Meraki platform. And Cisco DNA Center enables automation for network-wide changes, plus monitoring with events and notifications, and integration points for third-party tools, all through APIs.

DevOps engineers now have powerful tools to quickly get visibility into the status of the network and to reduce time to solution and repair. The Networking Dev Center is a place to learn about methods and approaches for enhancing network fault-finding and correction.

Security

In today's threat landscape, there can be an overwhelming firehose of security and threat information. It is critical to triage this information by elevating key threats and relegating other items for later analysis. This can not be accomplished by a single security professional working alone. Fortunately, there are security organizations working on a much more massive scale. The Open Web Applications Security Project (OWASP) provides an updated knowledge base to help security professionals take on the challenges related to securing web sites and web applications. Similarly, the Talos project has an intelligence team that provides data about threats.

Cisco provides products that investigate threats and malware, and can quarantine endpoints as needed. These products provide programmatic access and policy-based responses to quarantine and mitigate threats.

The Security Dev Center provides information on Cisco security products that work together in multiple scenarios to keep your network and applications safe.

Wireless and mobile

Events or organizations with a lot of people mean a lot of mobile devices, along with requirements for a robust wireless network. Cisco wireless networks can be customized so that developers can create unique experiences, or better performance in their mobile apps. Location analytics offer real-time visibility into the users and devices on your networks. Take a look at the Mobility Dev Center for SDKs, technical resources, and use cases for mobile needs.

Wireless, including Wi-Fi6 access, provides capabilities for low-power IoT devices, high-density deployments, and meeting the demands of real-time applications such as Augmented Reality (AR) and Virtual Reality (VR). The Wireless Dev Center offers tools for wireless network troubleshooting and RF analysis in the field.

Application developers

All of these areas require application development. Developers might choose to embed video calls in custom web applications, provide location services and analytics on wireless and mobile networks, or create conversational chatbots for support, automation, or alerting.

Applications may need prioritized traffic capabilities, such as indicating which networks have video or real-time data needs. For example, location services might be added to an application that is serving end-users on mobile networks, such as in a retail store, where the business wants to send coupons to customers while they are shopping.

With Cisco Webex and collaboration use cases, developers might create meeting rooms customized for business needs using available devices and sensors. You can meet your application deployment needs, such as edge computing or continuous integration pipelines using Cisco offerings like IOx or Cisco Container Platform. All of these use cases are brought together in the Application Developer Center.

Cisco SDKs

What is an SDK?

SDK stands for Software Development Kit. Typically an SDK contains a set of software development tools integrated for developing applications for a specific device or system.

From an end user's point of view, an SDK is quite different from an API. Most SDKs are a package, integrated with libraries, documents, code examples, etc. Most SDKs require installation. In comparison, an API is essentially a documented set of URIs. Developers require only a reference guide and a resource address to get started.

For example, if you want to develop a mapping application for an iPhone, you need to download and install the iOS SDK. In contrast, to try the Google Map API, you need only an API reference and require initial authentication credentials.

An SDK can provide simpler authentication methods as well as enabling token refreshes as part of the package. SDKs often help with pagination or rate limiting constraints on responses for a particular API. Also, it can be easier to read examples in a programming language you are already familiar with, so code examples in an SDK can be helpful.

Cisco SDKs

Cisco provides a wide range of SDKs on different Cisco platforms. This list is not an exhaustive list:

• Webex Teams Android SDK - Use the Webex Teams Android SDK to customize your app and to access powerful Webex Teams collaboration features without making your users leave the mobile app. See Webex Teams Android SDK.
• Jabber Web SDK - This SDK is used for developing web applications on Cisco Unified Communications, including voice and video, IM and Presence, voice messaging, and conferencing. See Jabber Web SDK.
• Jabber Guest SDK for Web - The Cisco Jabber Guest SDK for Web is primarily a call widget that is embedded in an iframe within another web page. See Jabber Guest SDK for Web.
• Jabber Guest SDK for iOS - The Jabber Guest SDK for iOS coordinates and simplifies the implementation, use, and quality of two-way video calls from within an application. See Cisco Jabber Guest for iOS.
• Jabber Guest SDK for Android - With the Jabber Guest Android SDK, you can enable your application to instantiate a two-way video call via the internet. The call is between the user's device and a video endpoint registered with a CUCM inside an enterprise firewall. The SDK handles all aspects of establishing and maintaining the two-way video call within your application. See Cisco Jabber Guest for Android.
• Cisco DNA Center Multivendor SDK - For partners and customers who have a mix of Cisco and non-Cisco devices in their network, this SDK builds support directly in Cisco DNA Center. See Cisco DNA Center Multivendor SDK.
• UCS Python SDK - The Cisco UCS Python SDK is a Python module used to automate all aspects of Cisco UCS management, including server, network, storage, and hypervisor management. See Official Documentation for the UCS Python SDK.
• Cisco APIC Python SDK (Cobra SDK) - The Cobra SDK is a native Python language binding for the APIC REST API to interact with the APIC controller. The installation of Cobra requires installing two .egg files: acicobra.egg and acimodel.egg. See Installing the Cisco APIC Python SDK.
• Cisco IMC Python SDK - Cisco IMC Python SDK is a Python module supporting the automation of all Cisco IMC management servers (C-Series and E-Series). See Instructions for installing IMC Python SDK and Official Documentation for the IMC Python SDK.
• Cisco Instant Connect SDK - Cisco Instant Connect has an Android, Windows, and Apple iOS Software Development Kit, providing tools for partners to embed Push-To-Talk in mobile or desktop applications. See Cisco Instant Connect SDK Downloads and Introducing Cisco Instant Connect.
• Webex Teams Python SDK example - You can work with the Webex Teams APIs using a familiar language, in this case Python, with the webexteamssdk . This SDK is available on GitHub. This SDK handles pagination for you automatically, simplifies authentication, provides built-in error reporting, and manages file attachments. Here is a simple Python example to retrieve a user's account information:

from webexteamssdk import WebexTeamsAPI, ApiError
access_token = 'jY1...e10f'
api = WebexTeamsAPI(access_token=access_token)
try:
    me = api.people.me()
    print(me.emails)
except ApiError as e:
    print(e)

The output you'd see from this script is a line with the email address or addresses for the account related to the access_token. If something goes wrong, the try... except block returns a readable error.

A couple of notes about this webexteamssdk example:

• The SDK needs a Webex Teams access token to make API calls. You can either set it with a WEBEX_TEAMS_ACCESS_TOKEN environment variable, or by putting the access_token argument into the function call. This example uses an access_token variable and then passes it in as an argument.
• The SDK provides error reporting with the ApiError exception. Notice that ApiError imported in the first line.

The SDK gives you access to precise parts of the return body, such as me.emails . In the example above it returns only the emails data from the response JSON.

Understanding Network Programmability and Device Models

What is Model-Driven Programmability?

Programmability is the capability of a device to accept instructions to control or alter behavior. For network devices, this frequently means being configured and managed using software protocols. Unlike human-oriented interfaces such as CLI and GUIs, programmable interfaces are explicitly designed to be consumed by machines.

Model-driven programmability inherits the power of models, matching a device's abilities and services to standardized models. This makes it easier to configure network devices and overcome drawbacks posed by traditional network device management techniques.

What is a data model?

In general, a data model is a structured method to describe any object, whether it's a person, a car, a building, or some other object. For example, the personal data on a passport or driver's license can describe a person in an individual way, so those are both "data models".

In networking, "data models" are a programmatic and standards-based way of writing configurations for any network device. It can replace manual configuration, implementing YANG as the de-facto data modeling language.

In the current networking world, one set of data models is based on YANG and uses the YANG modeling language. YANG version 1 [RFC6020] or YANG version 1.1 [RFC7950] are used to specify the configuration and operational state that a device supports.

The YANG based Model-Driven Programmability Stack looks like this:

The figure shows six rows: apps, a p i's, protocol, encoding, transport, and models. In the apps row are three textboxes each labeled app. The a p i's row text: model driven a p is yang development kit (y d k). Protocol textboxes: net conf, rest conf, g r p c. Encoding textboxes: x m l, j s o n, g p b. Transport textboxes: s s h and h t t p. Models text: yang models (native, open).

Model-Driven Programmability Stack

Model-driven programmability benefits

Traditionally CLIs or SDK library functions are used to configure network devices. CLIs and scripts are almost always device-specific; they can only be used in the same type of devices that use the same CLIs from the same vendor. Moreover, those functions may not exist for all configuration commands, and where they do exist, it may be difficult to program a complex configuration.

However, model-driven programming provides a standard way to describe the desired configuration of the network devices.

Of course, the target device itself has to support the model-driven configuration. For YANG based models, it needs to support YANG and understand higher-level protocols based on YANG, such as NETCONF and RESTCONF.

Model-based configurations still must be delivered to the network device. Model delivery might be encapsulated in an API, or handled in an SDK wrapper.

In summary, model-driven programmability:

• Provides configuration language that is human-readable
• Is Model-based, structured, and computer-friendly
• Includes support for multiple model types, including native, OpenConfig, and IETF
• Uses specification that is decoupled from transport, protocol end encoding
• Uses model-driven APIs for abstraction and simplification
• Leverages open-source and enjoys wide support

In order to understand model-driven programmability, we need to understand its key components:

• YANG
• NETCONF
• RESTCONF

YANG is a modeling language. NETCONF and RESTCONF are protocols used for data model programmable interfaces.

What is YANG?

YANG, an acronym for Yet Another Next Generation, as defined in RFC7519, is "a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications."

YANG in the Model-Driven Programmability Stack

A YANG module defines hierarchies of data that can be used for NETCONF-based operations, including configuration, state data, RPCs, and notifications. This allows a complete description of all data sent between a NETCONF client and server. YANG can also be used with protocols other than NETCONF.

Although YANG can describe any data model, it was originally designed for networking data models.

In the real world there are two types of YANG models, open and native.

• Open YANG Models: Developed by vendors and standards bodies, such as IETF, ITU, OpenConfig, etc.. They are designed to be independent of the underlying platform and normalize the per-vendor configuration of network devices.
• Native Models: Developed by vendors, such as Cisco. They relate and are designed to integrate features or configuration only relevant to that platform.

Why we need YANG for device modeling?

YANG provides a standard while still allowing for further description. We need a standard way to model network device configuration. YANG allows different network device vendors to describe their device type, configuration, and state to map to the device operation in programmatic way.

The terms used in YANG are defined in RFC6020 section 3. Here are some commonly used terms to understand before you dive into YANG:

• anyxml: A data node that can contain an unknown chunk of XML data.
• augment: Adds new schema nodes to a previously defined schema node.
• container: An interior data node that exists in, at most, one instance in the data tree. A container has no value, but rather a set of child nodes.
• data model: A data model describes how data is represented and accessed.
• data node: A node in the schema tree that can be instantiated in a data tree. One of container, leaf, leaf-list, list, and anyxml.
• data tree: The instantiated tree of configuration and state data on a device.
• derived type: A type that is derived from a built-in type (such as uint32), or another derived type.
• grouping: A reusable set of schema nodes. Grouping may be used locally in the module, in modules that include it, and by other modules that import from it. The grouping statement is not a data definition statement and, as such, does not define any nodes in the schema tree.
• identifier: Used to identify different kinds of YANG items by name.
• leaf: A data node that exists in at most one instance in the data tree. A leaf has a value but no child nodes.
• leaf-list: Like the leaf node but defines a set of uniquely identifiable nodes rather than a single node. Each node has a value but no child nodes.
• list: An interior data node that may exist in multiple instances in the data tree. A list has no value, but rather a set of child nodes.
• module: A YANG module defines a hierarchy of nodes that can be used for NETCONF-based operations. With its definitions and the definitions it imports or includes from elsewhere, a module is self-contained and “compilable”.
• RPC: A Remote Procedure Call, as used within the NETCONF protocol.
• state data: The additional data on a system that is not configuration data, such as read-only status information and collected statistics [RFC4741].

YANG defines four types of nodes for data modeling. The detail is described in RFC6020 section 4.2.2 or RFC 7950 section 4.2.2.

• Leaf Nodes
• Leaf-List Nodes
• Container Nodes
• List Nodes

A YANG module contains a sequence of statements. Each statement starts with a keyword, followed by zero or one argument, followed either by a semicolon (";") or a block of sub-statements enclosed within braces ("{ }").

statement = keyword [argument] (";" / "{" *statement "}")

There are four major statements in a YANG module:

• Container: A grouping of other statements (has no "Value").
• List: Multiple records containing at least one Leaf "Key" and an arbitrary hierarchy of other statements
• Leaf: Single key/value pair.
• Leaf-list: Multiple key/values pair of the same type.

YANG Module Constructs

Modules usually root from one or more containers, and the schema tree extends to another level of data structures. A branch ends with leaves and/or leaf-lists.

YANG Module Structure

YANG in action

Now let's take a look at an example of a YANG file in real life, ietf-interfaces.yang. This YANG open module contains a collection of YANG definitions for managing network interfaces.

When you know the terminology and structure of YANG, it is not hard to understand the content of a YANG file, which has very detailed comments and descriptions. But those descriptions also make the file very long. Fortunately, there are tools to extract the content in a more readable and concise way, and the pyang tool is one of them.

You can install pyang using the pip command in a virtual environment.

As you can see below, using the pyang tool can convert a YANG file to an easy-to-follow tree structure.

1. Create a file named ietf-interfaces.yang using a text editor locally.
2. Copy an example YANG file from GitHub. For example, you can go to https://github.com/YangModels/yang/blob/master/standard/ietf/RFC/ietf-interfaces%402018-02-20.yang for an open model, or https://github.com/YangModels/yang/blob/master/vendor/cisco/xr/602/ietf-interfaces.yang for a vendor-specific native model.
3. Click the Raw button and copy the text from the page into the local ietf-interfaces.yang file in a text editor.
4. Save the ietf-interfaces.yang file locally where you have installed pyang.
5. In the directory where you have stored the YANG file, run the pyang -f tree ietf-interfaces.yang command to generate a tree-formatted list of ietf-interface resources.

Pyang output example

module: ietf-interfaces
   +--rw interfaces
   |  +--rw interface* [name]
   |     +--rw name                        string
   |     +--rw description?                string
   |     +--rw type                        identityref
   |     +--rw enabled?                    boolean
   |     +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   +--ro interfaces-state
      +--ro interface* [name]
         +--ro name               string
         +--ro type               identityref
         +--ro admin-status       enumeration {if-mib}?
         +--ro oper-status        enumeration
         +--ro last-change?       yang:date-and-time
         +--ro if-index           int32 {if-mib}?
         +--ro phys-address?      yang:phys-address
         +--ro higher-layer-if*   interface-state-ref
         +--ro lower-layer-if*    interface-state-ref
         +--ro speed?             yang:gauge64
         +--ro statistics
            +--ro discontinuity-time    yang:date-and-time
            +--ro in-octets?            yang:counter64
            +--ro in-unicast-pkts?      yang:counter64
            +--ro in-broadcast-pkts?    yang:counter64
            +--ro in-multicast-pkts?    yang:counter64
            +--ro in-discards?          yang:counter32
            +--ro in-errors?            yang:counter32
            +--ro in-unknown-protos?    yang:counter32
            +--ro out-octets?           yang:counter64
            +--ro out-unicast-pkts?     yang:counter64
            +--ro out-broadcast-pkts?   yang:counter64
            +--ro out-multicast-pkts?   yang:counter64
            +--ro out-discards?         yang:counter32
            +--ro out-errors?           yang:counter32

Since YANG was first used with NETCONF, take a closer look at NETCONF and see how the two relate.

What is NETCONF?

Network Configuration (NETCONF) is a protocol defined by the IETF RFC7519. It is designed to install, manipulate, and delete the configuration of network devices. It is the primary protocol used with YANG data models today. Its operations are realized on top of Remote Procedure Call (RPC) exchanged via a secure transport protocol such as SSH.

NETCONF in the Model-Driven Programmability Stack

The NETCONF protocol uses XML-based data encoding for both the configuration data and the protocol messages.

The NETCONF protocol provides a small set of operations to manage device configurations and retrieve device state information. The base protocol provides operations to retrieve, configure, copy, and delete configuration data stores.

NETCONF Protocol Operations

The NETCONF protocol provides a set of operations to manage device configurations and retrieve device state information. The base protocol includes the following protocol operations:

Operation	Description
get	retrieve running configuration and device state information.
get-config	retrieve all or part of a specified configuration.
edit-config	edit a device configuration.
copy-config	create or replace an entire configuration datastore with another complete configuration datastore.
delete-config	delete a configuration in a data store.
lock	lock the entire configuration datastore system of a device.
unlock	release a configuration lock, previously obtained with the lock operation.
close-session	request graceful termination of a NETCONF session.
kill-session	force termination of a NETCONF session.

NETCONF versus SNMP

NETCONF and SNMP protocols are both defined to remotely configure devices.

Feature comparison

SNMP:

• Uses pull model when retrieving data from device which does not scale up well for high-density platforms
• Does not have a discovery process for finding Management Information Base (MIBs) supported by a device
• Does not support the concept of transactions
• Lacks backup-and-restore of element configuration
• Limited industry support for configuration MIBs

NETCONF was designed to enable:

• Multiple configuration data stores (candidate, running, startup)
• Device-level and network-wide transactions
• Configuration testing and validation
• Distinction between configuration and operational data
• Selective data retrieval with filtering
• Streaming and playback of event notifications
• Extensible remote procedure calls
• Built-in capability exchange

The NETCONF RFC has three distinct data stores that are the target of configuration reads and writes. These are:

• running (mandatory)
• candidate (optional)
• startup (optional)

NETCONF versus SNMP capabilities

Use Case	NETCONF	SNMP
Get collection of status fields	Yes	Yes
Set collection of configuration fields	Yes	Yes
Set configuration fields in transaction	Yes	No
Transactions across multiple network elements	Yes	No
Send event notifications	Yes	Yes
Secure protocol	Yes	Yes
Test configuration before final commit	Yes	No

Note: You will learn how to use NETCONF in the lab, Use NETCONF to Access an IOS XE Device.

What is RESTCONF?

The RESTCONF RFC 8040 defines a protocol and mechanism for REST-like access to configuration information and control. Similar to NETCONF, it uses the datastore models and command verbs defined in the Network Configuration Protocol (NETCONF), encapsulated in HTTP messages. As with NETCONF, the YANG language is used to define the command structure syntax, as the semantics of the configuration datastore configuration, state, and events.

RESTCONF in the Model-Driven Programmability Stack

RESTCONF uses structured data (XML or JSON) and YANG to provide REST-like APIs, enabling programmatic access to devices. HTTP commands GET, POST, PUT, PATCH, and DELETE are directed to a RESTCONF API to access data resources represented by YANG data models. These basic edit operations allow the running configuration to be viewed and altered by a RESTCONF client.

RESTCONF is not intended to replace NETCONF, but rather to provide an HTTP interface that follows the REST principles and is compatible with the NETCONF datastore model. A network device may serve both NETCONF and RESTCONF concurrently, or may provide only one or the other.

RESTCONF vs. NETCONF

Overall, NETCONF is more comprehensive, flexible, and complex than RESTCONF. RESTCONF is easier to learn and use for engineers with previous REST API experience. The following are differences between NETCONF and RESTCONF:

• NETCONF supports running and candidate data stores, while RESTCONF supports only a running datastore as any edits of candidate data store are immediately committed.
• RESTCONF does not support obtaining or releasing a data store lock. If a datastore has an active lock, the RESTCONF edit operation will fail.
• A RESTCONF edit is a transaction limited to a single RESTCONF call.
• RESTCONF does not support transactions across multiple devices.
• Validation is implicit in every RESTCONF editing operation, which either succeeds or fails.

NETCONF operations and RESTCONF methods mapping

Description	NETCONF	RESTCONF
Create a data resource	<edit-config>, </edit-config>	POST
Retrieve data and metadata	<get-config>, <get> , </get-config>	GET
Create or replace a data resource	<edit-config> (nc:operation="create/replace")	PUT
Delete a data resource	<edit-config> (nc:operation="delete")	DELETE

Each device RESTCONF server is accessed via API methods. Where can you find the RESTCONF API? The answer is that individual device APIs are rarely published. Instead the method URLs are determined dynamically.

The RESTCONF RFC 8040 states that RESTCONF base URI syntax is /restconf/<resource-type>/<yang-module:resource>. <resource-type> and <yang-module:resource> are variables and the values are obtained using specific YANG model files.

The basic format of a RESTCONF URL is https://<hostURL>/restconf<resource><container><leaf><options> where any portion after restconf could be omitted.

An initial GET request with just the restconf portion should return a response with the resources available at that server. For example, a GET constructed as follows:

GET /restconf HTTP/1.1
Host: example.com
Accept: application/yang-data+json

Would return something similar to:

HTTP/1.1 200 OK
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
    {   
        "ietf-restconf:restconf" : {
            "data" : {},
            "operations" : {},
            "yang-library-version" : "2016-06-21"
        }
    }   

This response tells us that data, and operations are RESTCONF resource-types supported by this device.

Note: You will learn how to use RESTCONF in the lab, Use RESTCONF to Access an IOS XE Device.

Lab – Explore YANG Models

In this lab, you will learn how to use the open source pyang tool to transform YANG data models from files using the YANG language, into a much easier to read format. Using the “tree” view transformation, you will identify the key elements of the ietf-interfaces YANG model.

You will complete these objectives:

• Part 1: Launch the DEVASC VM and CSR1000v VMs
• Part 2: Explore a YANG Model on GitHub
• Part 3: Explore a YANG Model Using pyang

Lab – Use NETCONF to Access an IOS XE Device

In this lab, you will use a NETCONF client, ncclient, which is a Python module for client-side scripting. You will use ncclient to verify NETCONF is configured, retrieve a device configuration, and modify a device configuration.

You will complete these objectives:

• Part 1: Build the Network and Verify Connectivity
• Part 2: Use a NETCONF Session to Gather Information
• Part 3: Use ncclient to Connect to NETCONF
• Part 4: Use ncclient to Retrieve the Configuration
• Part 5: Use ncclient to Configure a Device
• Part 6: Challenge: Modify the Program Used in This Lab

Lab – Use RESTCONF to Access an IOS XE Device

In the first half of this lab, you will use the Postman program to construct and send API requests to the RESTCONF service that is running on R1. In the second half of the lab, you will create Python scripts to perform the same tasks as your Postman program.

You will complete these objectives:

• Part 1: Build the Network and Verify Connectivity
• Part 2: Configure an IOS XE Device for RESTCONF Access
• Part 3: Open and Configure Postman
• Part 4: Use Postman to Send GET Requests
• Part 5: Use Postman to Send a PUT Request
• Part 6: Use a Python Script to Send GET Requests
• Part 7: Use a Python Script to Send a PUT Request

Cisco Network Management

Network Management Platforms

Cisco has a long history of inventing and supporting networking solutions, in both hardware and software. Since the beginning of computer networking, network configuration centered on a device-by-device, manual, and often complex set of tasks. This approach did not pose much of a problem with a few networking devices, but configuring and maintaining hundreds or even thousands of devices on a network becomes nearly impossible.

Moreover, as scale increases, changes implemented by humans have a higher chance of misconfigurations. The mistakes could be simple typos, applying a new change to the wrong device, or even completely missing a device. Manually performing repetitive tasks that demand a high degree of consistency introduces a risk for error. And the number of changes required increases as there are more demands from the business to deploy more applications at a faster rate.

You probably know that the solution lies in automation. Network programmability helps reduce Operational Expenses (OPEX), which represents a significant portion of overall network cost. Teams can speed up service delivery by automating tasks that are typically done by hand using a command-line interface (CLI).

Network automation plays a crucial part in simplifying day-to-day operations and maintenance. When you automate everyday network tasks and functions, and manage repetitive processes with code, you can reduce human errors and improve network service availability. Operations teams can respond and handle trouble tickets faster, and can even act proactively. Network automation also lowers costs by giving operations teams the ability to migrate mundane and repetitive tasks to automated processes.

Network automation is used for various common tasks in an organization:

• Device provisioning - Device provisioning is simply configuring network devices more efficiently, faster, and with fewer errors because human interaction with each network device is decreased.
• Device software management - Controlling the download and deployment of software updates is a relatively simple task, but it can be time-consuming and may fall prey to human error. Many automated tools have been created to address this issue, but they can lag behind customer requirements. A simple network programmability solution for device software management is beneficial in many environments.
• Compliance checks - Network automation methods allow the unique ability to quickly audit large groups of network devices for configuration errors and automatically make the appropriate corrections with built-in regression tests.
• Reporting - Automation decreases the manual effort that is needed to extract information and coordinate data from disparate information sources to create meaningful and human-readable reports.
• Troubleshooting - Network automation makes troubleshooting easier by making configuration analysis and real-time error checking fast and simple, even with many network devices.
• Data collection and telemetry - A common part of effectively maintaining a network is collecting data from network devices and telemetry on network behavior. Even the way data is collected is changing as now many devices can push data (and stream) off box, in real-time, in contrast to being polled in regular time intervals.

Take a look at the products that Cisco provides for all of these common tasks, especially those with an eye for automation.

Cisco IOS XE

IOS stands for "Internetwork Operating System." IOS was the original operating system for Cisco Systems routers and Cisco network switches. IOS XE is the next-generation programmable platform. With IOS XE, you have access to standards-based, consistent, programmable interfaces, standard data models for configuration, deployment, and rollback, as well as services integration with the network.

Benefits and purpose

IOS XE is based on Linux. Key network functions run as system daemons and system processes, which results in greater stability. Distributing functions into processes also allows for better workload balance, resulting in higher performance.

In IOS XE the control plane and the data plane are separated. The control plane "controls" the network, meaning it stores the routes, mapping, generally all the "signals" that are needed to run the router or switch. The data plane contains the actual client, user, or application data that needs to go along the network from one device to another.

The IOS XE system includes configuration management, provisioning, and diagnostic services. Tracing capabilities, also included, support quick resolution of network problems. With Model-driven programmability included, you can create and extend automated device management.

Model-driven programmability support in Cisco IOS XE

With YANG Data Models available for each Cisco device, you have access to configuration data, state information, and any data specific to the exact Cisco device model. Cisco device YANG models can be obtained from the Cisco Device YANG models repository.

IOS XE is used on most high-end Cisco platforms, including switches, routers, gateways. Not all programmability features are available on every platform. Consult the reference documentation for your device and release version. See Networking Software (IOS & NX-OS) and Programmability Configuration Guide.

NETCONF/YANG is supported as of IOS XE 16.3.1 software. In Cisco IOS XE Fuji 16.8.1 and later releases, operational data works on platforms running NETCONF and is enabled by default.

Enabling model-driven programmability

On some devices, Model-driven programmability services must first be enabled.

Enter configuration mode using the configure terminal command. (See configure terminal reference for details.)

Enable NETCONF on IOS XE

NETCONF connections should be authenticated using AAA credentials. Typically RADIUS, TACACS+, or local users defined with privilege level 15 access are allowed, but running from a particular privilege mode varies depending on the platform.

The CLI command to enable NETCONF is:

CSR1kv> enable
CSR1kv# configure terminal
CSR1kv(config)# netconf-yang

Troubleshooting

If you get an "Unknown command" response to the netconf-yang as shown below, double-check the device configuration.

CSR1kv(config)# netconf-yang
% Bad IP address or host name% Unknown command or computer name, or unable to find computer address

Cisco IOS XE supports two datastores: running and candidate. It also supports locking datastores, as well as configuration rollback.

Enable RESTCONF on IOS XE

RESTCONF connections should be authenticated using AAA credentials. RADIUS, TACACS+, or local users defined with privilege level 15 access are allowed.

RESTCONF runs over HTTPS. The following commands must be enabled to support RESTCONF over port 443:

CSR1kv(config)# ip http secure-server

The CLI command to enable RESTCONF is:

CSR1kv(config)# restconf

When enabled using the CLI, all supported operations may be governed through model interfaces, including optional settings for RESTCONF configuration and operational data settings.

Accessing YANG models

For a complete look at Cisco YANG models, browse or clone the GitHub repository at https://github.com/YangModels/yang. The vendor/cisco subdirectory contains models for Cisco platforms.

Cisco DNA Center

A Cisco DNA Center is a foundational controller and analytics platform for large and midsize organizations. It is at the heart of a Cisco intent-based network. It provides a single dashboard for network management, network automation, network assurance, monitoring, analytics, and security.

Cisco DNA Center provides both a web-based GUI dashboard and the RESTful Intent API used to programmatically access its services and functions.

It supports full 360-degree services and integration:

• North - The Intent API provides specific capabilities of the Cisco DNA Center platform.
• East - These are services for asynchronous Event Notification through WebHooks and email notification.
• Southbound - The Multivendor SDK is used to integrate non-Cisco devices into the Cisco DNA network.
• Westbound - Integration with Assurance and IT Service Management (ITSM) services, such as ServiceNow.

Here the focus is on using the Intent API, but you will also get a quick overview of services directly available through the GUI.

Cisco DNA Center dashboard (GUI)

The GUI organizes services and activities into Design, Policy, Provision, Assurance and Platform.

• Design - Design your network using intuitive workflows, starting with locations where your network devices will be deployed. Existing network designs created in Cisco Prime Infrastructure or Application Policy Infrastructure can be imported into Cisco DNA Center.
• Policy - Define and manage user and device profiles to facilitate highly secure access and network segmentation.
• Provision - Deployment, and Policy-based automation to deliver services to the network based on business priority and to simplify device deployment. Zero-touch device provisioning and software image management features reduce device installation or upgrade time.
• Assurance - Telemetry and notification for application performance and user connectivity events in real-time.
• Platform - Information and documentation for the DNA Center Intent API supporting the use of third-party applications and processes for data gathering and control via the API. This is the means to improve and automate IT operations, establish customized and automated workflow processes, and integrate network operations into third-party applications.

Role-based access control (RBAC)

The initial user, 'admin', is assigned the SUPER-ADMIN-ROLE allowing complete control of the DNA Center and access to all sections.

Administrators for each Cisco DNA Center may create additional 'role-based' users. The assigned role controls the level and type of access to sections of the GUI as well as API service rights.

As users are created, they are assigned a SUPER-ADMIN-ROLE, NETWORK-ADMIN-ROLE, or OBSERVER-ROLE. Users assigned a NETWORK-ADMIN-ROLE have general access and may create and manage devices. OBSERVER-ROLE assigned users have read-only access in both the GUI and API (GET only) and are restricted from some portions of the GUI interface.

Product hardware

The Cisco DNA Center appliance runs on dedicated Cisco Rack Servers in various scalable configurations. See Cisco DNA Center Data Sheet for the most recent information on hardware, environmental requirements, and scaling limits.

It is used to monitor, command and control Cisco routers, switches, wireless access points, Cisco Enterprise NFV Infrastructure Software (NFVIS) platforms, and integrated non-Cisco equipment. See Cisco DNA Center Supported Devices for compatibility information.

Cisco DNA Center Intent API

The Intent API provides the means to programmatically access the Cisco DNA Center services and functionality. This allows for automation and standardization of common management activities, as well as integration with third-party or enterprise applications. It is a RESTful API and uses HTTPS verbs (GET, POST, PUT, and DELETE) with JSON structures to discover and control the network.

Domains and subdomains

The Intent API is organized hierarchically into functional groups known as domains and subdomains.

Domain	Domain Purpose	Subdomains
Authentication	User authentication and session token generation	Authentication
Know Your Network	Discover and manage sites, topology, devices, users, and issues.	Sites Topology Devices Clients Users Issues
Site Management	Enterprise network provisioning, onboarding, and deployment, and software image management.	Site Design Network Settings Software Image Management Device Onboarding (PnP) Configuration Templates
Connectivity	Manage and configure SD-Access fabric wired and non-fabric wireless networks, including Enterprise SSIDs, wireless profiles, RF profiles, and access points.	SDA Non-Fabric Wireless
Operational Tasks	Command (CLI). Task, and Tag Management Network Discovery and Path Trace › Task Management Tag Management	Command Runner Network Discovery Path Trace File Task Tag
Policy	Applications, Application Sets, and Application Policy Management	Application Policy
Event Management	Configure and manage event-based notification to external handlers	Event Management

Cisco DNA Center – Intent API

Intent API documentation

The Intent API documentation is found in the DevNet Cisco DNA Center, under section "Cisco DNA Center - Intent API".

Cisco DNA Center API documentation on DevNet

Additional documentation and a built-in 'TryIt' capability is available in the product GUI, under Platform › Developer Toolkit to users assigned a 'NETWORK-ADMIN-ROLE' or 'SUPER-ADMIN-ROLE'.

Cisco DNA Center API documentation via Developer Toolkit

Method description, URI, and parameters

Both documentation sources list all available API methods and provide a description, request parameters, response structures, and the range of potential HTTP response codes.

(The DevNet documentation is organized by subdomain groups. The GUI Platform Developer Toolkit is organized by Domain: Subdomain.)

DevNet Intent API Subdomain

Clicking any of the subdomain names expands to display list of methods associated with that subdomain.

DevNet Intent API Site Methods

Click any of the individual methods to see documentation for that specific method. Each API will be named and described, with request parameters and structured shown and documented, and response structures and response codes documented.

The two documentation sets display this information slightly differently. In the DevNet method documentation, the method URI is given in an abbreviated format, showing only the URL suffix. In code, when actually issuing the API call, the URI must be prefixed with the specific DNA Center URL. The GUI Platform Developer Toolkit includes the specific expanded URL using the IP address of the DNA Center.

Documentation for the GET Site method is shown below, as seen from both DevNet and GUI Platform: Developer Toolkit.

DevNet Get Site Method Detail

GUI Platform Developer Toolkit Get Site Method Detail

All Intent API methods respond with a JSON-structured content payload. Each response structure is described in the documentation.

An HTTP response code indicates success or failure for the request.

Cisco DNA Center – Create (POST) - Update (PUT)

Intent API PUT and POST methods require a JSON request payload. These are documented in each method description.

Both POST and PUT requests are handled within the Cisco DNA Center asynchronously, which means that the request to add, create, or modify a resource is initiated with a correctly formed request, but not necessarily completed before responding. A request which has been successfully initiated, responds with a structure containing executionId, executionStatusUrl, and a status message.

Completion status is obtained using Task API methods to monitor execution completion. File API methods are used to obtain additional results following successful execution completion.

This part of the module works with 'read-only' GET methods only. POST, PUT, and DELETE methods that modify the target network are beyond the scope of this part of the course.

Documentation

Documentation for the Cisco DNA Center is organized into multiple separate guides. For more information consult the relevant published guides.

See Cisco DNA Center User Guides for the latest revisions of the following:

• Cisco DNA Center User Guide
• Cisco DNA Assurance User Guide
• Cisco DNA ITSM Integration Guide
• Cisco DNA Center Platform User Guide

See Cisco DNA Center Maintain and Operate Guides for the latest revision of the following:

• Cisco Digital Network Architecture Center Administrator Guide
• Cisco DNA Center High Availability Guide

See Cisco DNA Center Install and Upgrade Guides for the latest revision of the following:

• Cisco DNA Center Second Generation Appliance Installation Guide
• Cisco DNA Center First Generation Appliance Installation Guide
• Cisco DNA Center Upgrade Guide

Cisco ACI

The Cisco Application Centric Infrastructure (ACI) platform, run on Nexus 9000 hardware, is the Cisco solution for Software-Defined Networking (SDN). The centralized management system is the Application Policy Infrastructure Controller (APIC), a cluster of controllers. The APIC manages and provides for automation and management, policy programming, application deployment, and health monitoring for the fabric. With the APIC, you get unified operation of both physical and virtual, or software-based infrastructure. This platform helps network engineers and developers to manage networks programmatically.

Instead of opening up a subset of the network functionality through programmatic interfaces, the entire ACI infrastructure is opened up for programmatic access. This entirety is achieved by providing access to Cisco ACI object model. The ACI object model represents the complete configuration and run-time state of every software and hardware component in the entire infrastructure. The object model is made available through standard REST API interfaces, making it easy to access and manipulate the configuration and run-time state of the system. The API accepts and returns HTTP or HTTPS messages that contain JSON or XML documents. You can use any programming language to generate messages and JSON or XML documents that contain the API methods or Managed Object (MO) descriptions.

A common scenario for network automation is to manage the network with the same tools as you do other infrastructure. Combining the ACI data models with DevOps tools like Ansible, Chef, or Puppet, you can manage your infrastructure holistically with applications in mind. You can also build integrations with other management, security, policy, and monitoring tools.

Note: Rather than ACI mode, Nexus 9000 switches may be configured in NX-OS mode to access device-level APIs. In NX-OS mode you can manage switches as a Linux device.

ACI use cases

Common use cases include:

• Programmability as a single fabric, with access to read and write object models representing all attributes in the system.
• Desired state defined and enforced.
• Extension to AWS or Azure public clouds (via Multi-Site Orchestrator (MSO) and its API)

An example walkthrough could include providing a check of a particular tenant, continuously monitoring whether it changes, and if it changes, update the configuration back to the desired state.

Tools used with ACI

In addition to the standard REST interface, Cisco provides several open source tools or frameworks such as the ACI toolkit, Cobra (Python), ACIrb (Ruby), Puppet, and Ansible to automate and program the APIC. On top of REST API are also both a CLI and a GUI for day-to-day administration.

Note: The above tools are available for accessing the Multi-Site Orchestrator (MSO) for hybrid clouds as well. MSO's API is different from ACI's, the latter is used to access a private ACI fabric via its Application Policy Interface Controller (APIC).

Cobra (Cisco ACI) Python SDK

The Cobra SDK gives you access to all REST functions using native Python bindings. Objects in Cobra are one-to-one representations of the Management Information Tree (MIT). Cobra installation documentation can be found at h​ttp://cobra.readthedocs.org. The SDK offers Python methods to match the REST methods that the GUI uses, such as those shown in the API Inspector. It offers full functionality and is suited for complex queries, incorporating Layer 4-7 devices, initial fabric builds, and so on.

Cisco ACI toolkit

This toolkit is a set of Python libraries you can use for basic configuration of a subset of the object model. Available on GitHub at h​ttps://github.com/datacenter/acitoolkit. This set exposes a small subset of the Cisco APIC object model, unlike the full functions of the Cobra SDK.

APIC REST Python adapter (ARYA)

This tool converts XML/JSON objects to equivalent Python code. Often people use it with the API Inspector built into the product. Note that the tool does not validate targets or perform lookups. Documentation is available at h​ttps://developer.cisco.com/docs/aci/#!arya.

ACIrb

This tool provides a Ruby-based implementation of the Cisco APIC REST API. It enables direct manipulation of the MIT through the REST API using standard Ruby language patterns.

CLI

ACI also offers an NX-OS style CLI to configure and manage ACI in a traditional CLI way. Moquery is a CLI Object Model query tool, while Visore is Object Store Browser (GUI).

API Inspector

When you perform a task in the Cisco APIC GUI, the GUI creates and sends internal API messages to the operating system to execute the task. By using the API Inspector, which is a built-in tool of the Cisco APIC, you can view and copy these API messages. An administrator can replicate these messages to automate key operations, or you can use the messages as examples to develop external applications that will use the API.

APIC API Inspector

Cisco ACI – Ansible Modules

Ansible modules for ACI (and MSO)

Cisco and the wider community have collaborated on a broad suite of open source modules for Ansible, enabling configuration and management of ACI fabrics as code, alongside other Ansible-managed inventory. Modules have also been created to address multi-site and hybrid cloud resources via the Multi-Site Orchestrator (MSO) APIs. Ansible provides a complete index of modules with links to documentation.

The ACI/MSO modules permit the simple creation of playbook elements to perform inquiry, administration, and management tasks upon an ACI fabric. For example, the following task, drawn from Ansible documentation, idempotently ensures that a given tenant account exists (creating it, if not). It uses the aci_tenant module, which provides a range of tenant-management functionality.

- name: Ensure tenant customer-xyz exists
  aci_tenant:
    host: my-apic-1
    username: admin
    password: my-password
    tenant: customer-xyz
    description: Customer XYZ
    state: present

Cisco ACI REST API Example

With the REST API you have an interface into the MIT, allowing you to manipulate the object model state. The APIC CLI, GUI, and SDK use the same REST API interface so that whenever information is displayed, the data is read through the REST API, and when configuration changes are made, they are written through the REST API. Additional data available with the API includes statistics, faults, and audit events. With WebSockets, the API even provides a means of subscribing to push-based event notification. When a change occurs in the MIT, the API can send an event notification.

The APIC REST API supports standard methods such as POST, GET, and DELETE operations through HTTP. The POST and DELETE methods are idempotent, meaning an operation can be repeated without additional effects when called with the same input parameters. The GET method is nullipotent, meaning that performing it multiple times has the same effect as performing it zero (null or never) times. Basically, the GET call is a read-only operation.

The REST interface accepts payloads to and from the resources with either XML or JSON encoding. For XML, the encoding operation is simple: the element tag is the name of the package and class, and any properties of that object are specified as attributes of that element. You create child elements in XML to define nested containment in a model.

Any data on the MIT can be described as a self-contained structured text tree document, encoded in XML or JSON. With that information model, Cisco ACI fits in well for REST API design: URLs and URIs map directly to Distinguished Names (DNs) that identify objects on the tree, and the objects have parent-child relationships also identified using distinguished names and properties. This makes the REST API useful to read and modify data with a set of Create, Read, Update, Delete (CRUD) operations.

You access these objects for retrieval and manipulation of Cisco APIC object data, using standard HTTP commands and a well-defined REST URL.

Distinguished name (DN) - Identifies a specific target object, letting you map the name directly to URLs.

Relative name (RN) - Names the object apart from its siblings within the context of a parent object.

Object instances are referred to as Managed Objects (MOs). Every MO in the system can be identified by a unique DN. With the MO and its DN, you can refer to any object globally. In addition to a DN, you can refer to each object by its RN. The RN identifies an object relative to its parent object.

You can use either the RN or the DN to access an object, depending on the current location in the MIT. You can query the tree in several ways because it is hierarchical. Then combine hierarchy with the attribute system for further object identification. You can perform a query for an object through its DN, or on a class of objects such as a switch chassis, or on a tree-level to discover all related members of an object.

Cisco ACI URL Format

ACI URL Format

It's probably easier to understand with a few worked examples. Envision the URL format representation as follows:

• http:// | https://:: By default, only HTTPS is enabled.
• host: This component is the hostname or IP address of the APIC controller, for example, "SandboxAPIC".
• port: This component is the port number for communicating with the APIC controller if a nonstandard port configured.
• api: This literal string (api) specifies that the message is directed to the API.
• mo | class: This component specifies the target of the operation as a managed object or an object class.
• DN: This component is the DN of the targeted managed object, for example, topology/pod-1/node-201.
• className: This component is the name of the targeted class, concatenated from the package and the class in the context of the package, for example, dhcp:Client is dhcpClient. The className can be defined in the content of a DN, for example, topology/pod-1/node-1.
• json | xml: This component specifies the encoding format of the command or response body as JSON or XML.
• ?options: This component includes optional filters, selectors, or modifiers to a query. Multiple option statements are joined by an ampersand sign (&).

A URI provides access to a target resource. The first two sections of the request URI specify the protocol and access details of the APIC. The literal string api, indicates that the API is to be invoked. The next section of the URI path specifies whether the operation is for a Managed Object or a class.

Next in the path is either the fully qualified DN for object-based queries, or the package and class name for class-based queries. The final mandatory part of the request URI is the encoding format: either .xml or .json.

The REST API supports a wide range of flexible filters, useful for narrowing the scope of your search to allow information to be located more quickly. The filters themselves are appended as query URI options, starting with a question mark (?) and concatenated with an ampersand (&). Join multiple conditions when you want to form complex filters.

With the capability to address an individual object or a class of objects with the REST URL, the system provides complete programmatic access to the entire object tree and to the entire system.

One of the most common use cases for this API is for monitoring the Cisco ACI Fabric. Proactive monitoring is a very important piece of the network administrator's job, but is often neglected because putting out fires in the network usually takes priority. However, because the APIC makes it incredibly easy to gather statistics and perform analyses, it saves network administrators both time and frustration.

For example, if you want to learn about the details of all available fabric nodes (Cisco ACI leaf and spine switches) at host devasc-aci-1.cisco.com, including the state, IP address and so on, you could use the following Cisco ACI REST API call:

GET h​ttps://devasc-aci-1.cisco.com/api/node/class/fabricNode.json

Response code: 200
Response body:
{
    "totalCount": "6,"
    "imdata": [
        {
            "fabricNode": {
                "attributes": {
                    "adSt": "on,"
                    "address": "10.0.240.32,"
                    "annotation": ","
                    "apicType": "apic,"
                    "childAction": ","
                    "delayedHeartbeat": "no,"
                    "dn": "topology/pod-1/node-101,"
                    "extMngdBy": ","
                    "fabricSt": "active,"
                    "id": "101,"
                    "lastStateModTs": "2019-11-17T15:32:30.294+00:00,"
                    "lcOwn": "local,"
                    "modTs": "2019-11-17T15:32:53.511+00:00,"
                    "model": "N9K-C9396PX,"
                    "monPolDn": "uni/fabric/monfab-default,"
                    "name": "leaf-1,"
                    "nameAlias": ","
                    "nodeType": "unspecified,"
                    "role": "leaf,"
                    "serial": "TEP-1-101,"
                    "status": ","
                    "uid": "0,"
                    "vendor": "Cisco Systems, Inc,"
                    "version": ""
                }
            }
        },
        ...

Besides manual querying, you can gather information automatically and then apply policies, minimizing the opportunities for human error. As you can see in the figure below, when you start using automation when monitoring the ACI fabric, you can build various applications that can execute different tasks if there is a specific change in the network.

Proactive Monitoring of the ACI Fabric

Cisco ACI Cobra

As you have seen, the Cisco ACI platform has a robust REST API. However, using the raw API can be tedious and cumbersome. This is because you need to know and configure low-level details such as which HTTP verb is being used, the URI, headers, and encoding supported. Additionally, it would be important to code error handling in custom code using a native REST API.

To simplify application development with ACI, Cisco has developed Cobra, a robust Python library for the APIC REST API. Objects in the Cobra library (SDK) map 1:1 to the objects within the Cisco ACI MIT. If you are planning to dive deeper into Cobra, the best place to start is the official Cobra documentation. These documents review everything from installation to showing examples, and even include a Frequently Asked Questions section to jump-start individuals looking to test Cobra.

To access the APIC using Cobra, you must log in with valid user credentials. Cobra currently supports username/password-based authentication, in addition to certificate-based authentication. To make configuration changes, you must have administrator privileges in the domain in which you will be working. A successful login returns a reference to a directory object that you will use for further operations.

You can use the Cobra SDK to manipulate the MIT generally through this workflow:

• Identify the object to be manipulated.
• Build a request to read, change attributes, or add or remove children.
• Commit the changes made to the object.

On the left is the create session textbox that has a callout: session = LoginSession (apic, username, password), moDir = MoDirectory(session). The create session box has an arrow pointing to a login box that has the callout of moDir.login(). The login box has two arrows, each one pointing to the build configuration object box or the get object box. The get object box has a callout: tenant = moDir.lookupByDn('uni/tn-PEPSI'). The build configuration object has a callout: uniMo = moDir.lookupByDn('uni'), new_mo = Tenant(uniMo, name='PEPSI'). The build configuration object has an arrow pointing to the create config request box that has a callout: tenantCfg = ConfigRequest(), tenantCfg.addMo(new_mo). The create config request box has an arrow pointing to the commit config request box that has a callout: moDir.commit(tenantCfg)

Workflow of the Cobra SDK Objects

A common workflow for retrieving data using Cobra is as follows:

1. Create a Session Object.
2. Log in to Cisco APIC.
3. Perform Lookup by Class or DN.

A common workflow for configuring the Cisco ACI Fabric is as follows:

1. Create a Session Object.
2. Log in to Cisco APIC.
3. Create a Configuration Object.
4. Create a Configuration Request Object.
5. Add your Config Object to the Request.
6. Commit.

Summary

You now have some powerful tools to investigate and use with Cisco ACI. With an underlying REST API and standard data model plus hierarchy, you can manage and monitor a myriad of infrastructure, both virtual and hardware-based.

Cisco Meraki

Cisco Meraki is a suite of cloud-managed network solutions that enables a single source of management for infrastructure, locations, and devices.

Components include:

• Integration APIs
• A complete cloud-managed network infrastructure solution
• Wireless, switching, security, SD-WAN, Mobile Device Management (MDM), and smart cameras
• Integrated hardware, software, and cloud services

Meraki Cloud Platform

Meraki API Services

The Meraki enterprise cloud-managed networking infrastructure service has five different APIs for integration:

• Dashboard API - This a RESTful service for device provisioning, management, and monitoring.
• Webhook API – This is a real-time notification system for network alerts, covering events and network health.
• Location Streaming API – This is an HTTP POST method providing Wi-Fi and Bluetooth client location information (GPS, X/Y) based on Meraki Access Point (AP) map placement, and client signal strength.
• External Captive Portal (EXCAP) API - This enables an organization to build out custom engagement models at Wi-Fi access points.
• MV Sense API - This is a combination of REST APIs and realtime MQTT stream supporting oversight of a physical space.

Meraki Dashboard API

The Cisco Meraki Dashboard API is a RESTful API that uses HTTPS for transport and JSON for object serialization.

Note: These instructions are an example only. To complete these steps, you need to be a user with administrator access in a Meraki organization. The Meraki organization in this course has API access already and the API key is provided in the examples.

1. To provide access to the API for an organization, first enable the API for the organization under Organization › Settings.

1. Scroll down.

1. After enabling the API, go to the My Profile page to generate an API key. The API key is associated with a Meraki Dashboard administrator account. An API key can be generated, revoked, and regenerated for the user profile. The API key needs to be kept safe, as it provides authentication to all of the organizations that have the API enabled. If the API key is shared, it can be regenerated at any time. Regenerating the key revokes the prior API key.

Authorization

Every request must specify an API key via a request header. The API will return a 404 (rather than a 403) in response to a request with a missing or incorrect API key. This behavior prevents leaking even the existence of resources to unauthorized users.

X-Cisco-Meraki-API-Key: <secret key>

Meraki API call examples

API call to retrieve organization list

Below is a curl example that retrieves the list of organizations for the API key specified in X-Cisco-Meraki-API-Key. You can copy and run these in your terminal if you have curl installed.

curl --request GET -L \
  --url https://api.meraki.com/api/v0/organizations \
  --header 'X-Cisco-Meraki-API-Key: 8f90ecec4fca692f606092279f203c6020ca011c'

The result is similar to this, though more organizations may be listed in the JSON:

[
   {
      "id":"566327653141842188",
      "name":"DevNetAssoc",
      "url":"https://n6.meraki.com/o/dcGsWag/manage/organization/overview"
   }
]

Note that the request is redirected by the -L argument. An HTTP 302 (Found/Redirect) response is valid for any request, including those that may modify state such as DELETE, POST, and PUT. Client applications must be capable of following a redirect. The --url parameter contains the Meraki API that you are calling. The --header parameter holds the API Key that authorizes the API call. These examples follow the same pattern.

API call to retrieve organization metadata

The next call is a curl example to retrieve metadata about a specific organization, using the ID from the result above:

curl --request GET -L \
  --url https://api.meraki.com/api/v0/organizations/566327653141842188 \
  --header 'X-Cisco-Meraki-API-Key: 8f90ecec4fca692f606092279f203c6020ca011c'

The result is:

{
  "id": "566327653141842188",
  "name": "DevNetAssoc",
  "url": "https://n6.meraki.com/o/dcGsWag/manage/organization/overview"
}

API call to list networks

The following curl example shows how to list the networks in an organization.

curl --request GET -L \
  --url https://api.meraki.com/api/v0/organizations/566327653141842188/networks \
  --header 'X-Cisco-Meraki-API-Key: 8f90ecec4fca692f606092279f203c6020ca011c'

The result is similar is this JSON:

[
    {
        "id": "L_566327653141858435",
        "organizationId": "566327653141842188",
        "name": "DevNetAssoc1",
        "timeZone": "America/Los_Angeles",
        "tags": null,
        "productTypes": [
            "appliance",
            "switch",
            "wireless"
        ],
        "type": "combined",
        "disableMyMerakiCom": false,
        "disableRemoteStatusPage": true
    },
    {
        "id": "L_566327653141858436",
        "organizationId": "566327653141842188",
        "name": "DevNetAssoc2",
        "timeZone": "America/Los_Angeles",
        "tags": null,
        "productTypes": [
            "appliance",
            "switch",
            "wireless"
        ],
        "type": "combined",
        "disableMyMerakiCom": false,
        "disableRemoteStatusPage": true
    },
    {
        "id": "L_566327653141858437",
        "organizationId": "566327653141842188",
        "name": "DevNetAssoc3",
        "timeZone": "America/Los_Angeles",
        "tags": null,
        "productTypes": [
            "appliance",
            "switch",
            "wireless"
        ],
        "type": "combined",
        "disableMyMerakiCom": false,
        "disableRemoteStatusPage": true
    },
    {
        "id": "L_566327653141858438",
        "organizationId": "566327653141842188",
        "name": "DevNetAssoc4",
        "timeZone": "America/Los_Angeles",
        "tags": null,
        "productTypes": [
            "appliance",
            "switch",
            "wireless"
        ],
        "type": "combined",
        "disableMyMerakiCom": false,
        "disableRemoteStatusPage": true
    }
]

Meraki webhook alerts

Webhooks provide a POST to a particular URL when a defined criterion is met. With Meraki webhooks you can set up systems that subscribe to Meraki Cloud alerts. You configure which network alerts and events can automatically trigger the next action.

Alerts sent with Meraki webhooks vary in frequency depending on different factors. There may be computation time needed, or a delay required in order to aggregate multiple events before delivering the alert. You can also configure the timing threshold value, such as waiting for five minutes of downtime before sending a message.

You can calculate the delivery time by comparing the occurredAt and sentAt parameter values.

Read more details about Meraki webhooks, the Dashboard setup, and integration tools in the Meraki Webhooks documentation.

Cisco Meraki Location Scanning API

The Meraki cloud uses the physical location of access points (using the Map & Floorplan on the Dashboard) to estimate the location of a client. This should be considered a best-effort estimate, since the geo-location coordinates (latitude, longitude) and X,Y location data accuracy can vary based on a number of factors. These include AP placement, environmental conditions, and client device orientation. Experimentation can help improve the accuracy of results or determine a maximum acceptable uncertainty for data points.

Location analytics

The Location Scanning API can be used by retail stores with multiple locations, conference deployments where location information can be useful for attendees, or deployments where the business wants to know trends in user engagement. You can read about enabling the API for real-time device detection in the developer documentation.

Bluetooth Scanning API

Examples of Bluetooth Low Energy (BLE) devices include wireless headphones, wireless keyboards and mice, video game controllers, battery-powered beacons, Apple iBeacon hardware devices, fitness monitors, and remote sensors. Meraki Access Points (APs) can detect and locate these devices when they're nearby. This location data can be integrated with third-party applications.

To enable BLE device location, enable the BLE scanning radio on the access points. BLE Scanning is enabled in Wireless › Bluetooth Settings › Scanning.

Location and privacy

Due to the sensitive nature of location data with exact MAC addresses as part of that data, Meraki only stores a hashed version of the MAC address. It's implemented in such a way that no algorithm can recover the original MAC address of a client.

You can read details about identity protection when using Meraki and opt-in and opt-out mechanisms in the Meraki Location and Privacy documentation. Meraki's global opt-out is available at https://account.meraki.com/optout.

Meraki Smart Cameras can perform object detection, classification, and tracking directly on the edge of the network, placing the computing needs in the endpoint.

Through both REST and MQTT API endpoints, applications can request or subscribe to historical, current, or real-time data generated in the camera to use the camera for more than security. When you access the API endpoints in MV Sense, you gain access to machine learning/computer vision data for use in applications.

Camera API categories

A number of camera APIs are available for use:

• MV Sense - This includes REST and MQTT API endpoints, which provide historical and real-time people detection data and light readings. See MV Sense API Documentation.
• Live Link API - A REST API which returns a Dashboard link for a specified camera. If the link includes a timestamp, it provides data from that time. Get Network Camera Video Link API Documentation
• Snapshot API - A REST API that generates a snapshot of the specified camera’s field of view at a specific time and returns a link to that image. Generate Network Camera Snapshot API Documentation

REST vs MQTT APIs

Two different types of API endpoints are available in the MV Sense collection of API endpoints; REST-based and MQTT-based.

RESTful APIs offer an on-demand service. A connection will be made only when data is requested. Using the MV Sense REST APIs enable historical or near real-time people detection data from the camera.

MQTT-based protocols use a publish-subscribe connection between the client and server. In the case of MV Sense, the server is continuously pushing messages to the MV smart cameras so the device can respond instantly. Using the MV Sense MQTT APIs enable a real-time feed of people detection and their locations. Light-level readings can also be obtained.

MV API use cases

Here are a few example use cases for the camera APIs:

• Detect one or several people in the vicinity of a dangerous machine, and set off a nearby warning alarm.
• Detect several people standing in one location for an extended period of time and correlate with customer wait times.
• Provide better workplace lighting by integrating MV light readings into workplace smart lighting.

You have probably experienced a "splash page" when trying to access Wi-Fi at your favorite coffee shop or in a public library. This is known as a captive portal. It is what a user sees when they first associate with a Wi-Fi SSID and open a web browser to surf the internet while in range of the Meraki device. By configuring a captive portal, you can redirect all internet traffic to a particular URL.

With that URL, you can require users to take specific actions before their traffic is able to pass through to the internet. Maybe you want to ask a customer to take a variety of actions:

• Fill out a customer survey
• Choose and purchase a billing plan
• Watch a video advertisement
• Accept a set of terms and conditions

All these actions can be required before allowing the customer to access the internet.

Read more about splash pages in the Meraki Captive Portal Configuration Guide.

Cisco NX-OS Platform

Nexus Operating System (NX-OS) is a data center operating system for the Nexus switch.

Benefits and purpose

With the Nexus switches running the NX-OS, you can automatically provision Cisco switches in the data center and orchestrate changes much the same way you configure a Linux server.

Nexus switches are highly performant in data centers and integrate with a lot of systems. The Nexus switch family uses a Linux kernel. With this kernel, you can access a device's Bash environment and manage a switch with Linux-based commands. You can manage the device with existing management systems like Ansible or Puppet. NX-OS is interoperable with native IOS. NX-OS also provides a REST API service and model-driven programmatic access via RESTCONF, NETCONF, and OpenConfig.

Architecture

Cisco Open NX-OS leverages the native Linux networking stack, instead of a custom-built userspace stack (NetStack) that was used in prior versions of NX-OS. Virtual Routing and Forwarding actions (VRFs) are implemented using Linux network namespaces. Network namespaces provide the same isolation capabilities as VRFs.

Nexus switch interfaces, including physical, port-channel, vPC, VLAN, and other logical interfaces, are mapped to the kernel as standard Linux netdevs.

The REST API service is provided using an NGINX web server.

Environment and scale

The Nexus family of switches is used in data centers around the world. Nexus switches are used by service providers, servicing large numbers of consumers. They're performant and preferred by developers, DevOps professionals, and other users who want to provide self-service network infrastructure models.

The Cisco Nexus 9000 Series NX-OS Verified Scalability Guide document describes the Cisco NX-OS configuration limits for Cisco Nexus 9000 Series switches.

Capabilities

NX-OS fulfills several configuration use cases, such as interface configuration, VLAN configuration, VLAN management, and Open Shortest Path First (OSPF) configuration.

Linux environment and tooling

Standard Linux tools like ifconfig, ethtool, route, or tcpdump can be used to manage a Cisco Nexus switch with NX-OS. You can also use yum (Yellowdog Updater, Modified) as it is the default package and repository management tool for NX-OS and has RPM underneath. These same tools can be used for NX-OS process-patching, or installing external or custom-developed programs onto the switch.

Container support

NX-OS supports running Linux Containers (LXCs) directly on the platform. It provides access to a CentOS 7-based Guest Shell, which supports custom functionality directly on the device in a secure, isolated shell.

Telemetry

You can integrate different telemetry applications such as Ganglia, Splunk, or Nagios on the switch with NX-OS.

Open NX-OS programmatic interfaces

Open NX-OS is the set of software used to provide the APIs, data models, and programmatic access. This includes the NX-API REST service and model-driven programmability using YANG modeling. Both the NX-API CLI and NX-API REST API interfaces are served by an NGINX web server. The NX-API REST model borrows several concepts from Cisco ACI and makes them available for a non-ACI based standalone Nexus fabric environment.

Open NX-OS includes the native NX-OS data model in the software image itself. If you are only using Open NX-OS, you do not have to download additional models.

YANG, NETCONF, and RESTCONF

NX-OS has a comprehensive set of both native and open YANG models, supporting Nexus switch management. The list of supported models includes native, OpenConfig, and Internet Engineering Task Force (IETF) models. Cisco NX-OS supports YANG models through the interfaces of NETCONF, RESTCONF on Open NX-OS, you must enable the features and install the desired OpenConfig models to the network switch.

The Cisco NX-OS employs a NETCONF agent as a client-facing interface to provide secure transport for the client requests and server responses. The NETCONF is enabled on Cisco Nexus 3000, 5000, 6000, 7000, and 9000 series switches.

Enabling Model Driven Programmability features in NX-OS

Note: These instructions apply to Open NX-OS 9.2.1+. Previous versions of Open NX-OS require manual installation and activation of RPMs for the protocol agents. See the Programming Guides for your platform if you are using an earlier version.

Enable the following features on the switch using CLI or another method (such as NX-API). Enable the transport protocols that you want to leverage.

feature bash-shell
 feature netconf
 feature restconf

For more information on the YANG OpenConfig models for NX-OS, see NX YANG.

OpenConfig

OpenConfig, an alternative model, must be downloaded to the switch.

OpenConfig models supported by Open NX-OS can be downloaded from Cisco Artifactory Open NX-OS Agents. You will find Open NX-OS release specific folders containing RPM packages for individual models, as well as a single RPM with all OpenConfig models.

Download the desired models to your local workstation, and then copy them to the Open NX-OS switch where you want to install them.

nx-osv9000-1#copy scp://developer@10.10.20.20/home/developer/Downloads/mtx-openconfig-all-1.0.0.0-9.2.1.lib32_n9000.rpm bootflash: vrf management

Use the bash-shell feature on Open NX-OS to install the newly copied RPM files. Remember that the feature bash-shell must be enabled on your switch.

nx-osv9000-1(config)#run bash sudo su
 bash-4.2#
 bash-4.2# cd /bootflash/
 bash-4.2# yum install mtx-openconfig-all-1.0.0.0-9.2.1.lib32_n9000.rpm

Cisco NSO

The industry is rapidly moving towards a service-oriented approach to network management, where complex services are supported by multiple and diverse systems and processes. To manage services, operators transition from managing pieces of equipment towards actively managing the various aspects of services.

Configuring the services and the affected equipment are among the largest cost-drivers in provider networks. Still, the common configuration management practice involves pervasive manual work or ad-hoc scripting. Why do we still apply these sorts of techniques to the configuration management problem? Two primary reasons are the variations of services and the constant change of devices. These two underlying characteristics are, to some degree, blocking automated solutions, because it takes too long to update the solution to cope with daily changes.

Time-to-market requirements are critical for a new service to be deployed quickly; any delay in configuring tools impacts revenue.

In the past several years, Software-Defined Networking (SDN) has emerged as a solution. SDN provides a centralized, unified set of APIs to control both networks and services, automatically and in real time. The benefits include faster and more precise control of networks and services, leading to higher performance and lower costs.

Network Services Orchestrator (NSO) enables operators to adopt the service configuration solution dynamically, according to changes in the offered service portfolio. It delivers the SDN vision by providing a logically centralized interface to the multi-vendor network.

NSO has three components:

• Model-driven programmable interface (YANG models)
• Configuration database
• Device and service abstraction layers

Device and service abstraction layers

By using standard data models and modeling language to describe both services and devices, NSO can automate creation, deletion, and run-time modification of network services. NSO uses the standardized YANG modeling language to model and automate any type of device. The network you model can be a mix of traditional equipment and virtual devices, within Layers 1 through 7 of the OSI model.

The data model for a service correlates service definitions with network operations. An embedded algorithm determines the minimum network changes required for a service, and then executes them. For device data models, NSO recognizes and can work across the physical devices in a data center, including firewalls and other OSI model Layer 4 through Layer 7 devices. It also works with virtual resources, including Virtual Machines (VMs) and container-based networking models. The Cisco Elastic Services Controller (ESC) is part of the core platform and provides these capabilities. In addition, NSO can automate the launch, configuration, monitoring, and license management of Virtual Network Functions (VNFs).

Functional architecture

The NSO architecture is logically comprised of two layers: a Device Manager that simplifies device integration and manages device configuration scenarios, and a Service Manager that applies service changes to devices. The architecture diagram below shows the required building blocks for NSO to perform network service functions in these layers. Device Manager and Service Manager components serve different purposes but are tightly integrated into one transactional engine and database.

At the core of NSO is the Configuration Database (CDB), providing persistent datastore and which synchronizes with device and service configuration. It manages relationships between services and devices and can handle revisions of device interfaces. NSO addresses the mapping, working from a desired service configuration to the corresponding device configuration and through to a dedicated mapping layer.

The figure shows three main sections up top: network engineering, ops and provisioning, and service developers. A box labeled n s o has two blocks labeled service manager and device manager leading to a cylinder labeled C D B. To the right of the c d b is a box labeled package manager. Under this are two main boxes: device abstraction and E S C (V N F M). The device abstraction box has three textboxes with each one labeled N E D. The e s c box has two textboxes: V N F lifecycle manager and V N F service monitoring. A gray multi-domain networks textbox extends across the bottom

NSO Functional Architecture

The purpose of the Device Manager is to manage different devices using a YANG and NETCONF view. Whether the interface is SNMP or CLI, the Device Manager creates a transactional change sequence for the target devices. When the device supports YANG and NETCONF natively, the Device Manager process is automatic. Non-NETCONF devices are integrated into Device Manager using Network Element Drivers (NEDs).

The Service Manager lets you develop service-aware applications, such as switch port modification, MPLS, VPN, etc., to configure devices. Data models known as service models are created using YANG and are based on the requirements for the service. Mapping device-to-service can be completed in two ways. For simple cases, you specify configuration templates that transform service parameters to device configuration parameters. For complex cases, you need to program "Mapping Logic" for NSO to understand. The Service Manager handles the complete lifecycle (creating, modifying, and deleting) of service instances.

Custom code, applications, and specific NEDs are examples of packages that NSO loads. A package consists of code, YANG modules, custom UI widgets, etc. NSO loads these at startup. Packages can be added and upgraded at run-time.

Device Manager

The Device Manager lies at the heart of NSO. The Device Manager maintains a list of all managed devices. NSO keeps the master copy of the configuration for each managed device. Whenever a configuration change is done to the list of device configuration master copies, the job of the Device Manager is to partition this "network configuration change" into the corresponding changes for the actual managed devices. Depending on the device type, different protocols are spoken southbound. If the device is or has:

• NETCONF-capable - Device Manager produces explicit NETCONF edit-configuration RPC operations for each participating device and then inside the same transaction that runs in NSO, executes all the individual, device-specific NETCONF operations.
• An SNMP device - Device Manager translates the change of the NCS DOM tree into the corresponding SNMP SET PDUs.
• A CLI - such as Cisco IOS or IOS XR routers (or supporting the same command structure). A CLI NED is used to produce the correct sequence of CLI commands.

Otherwise, for devices that do not fall into those categories, Java code in a Generic NED gets invoked with the proposed changes. The job for that NED code is to translate between the diff on the NCS DOM tree to the corresponding operations on the device.

The Device Manager supports the following overall capabilities:

• Provision a new device by copy-and-edit, either from another configuration of another device or from a template configuration.
• Deploy configuration changes to multiple devices in a fail-safe way using distributed transactions.
• Validate the integrity of configurations before deploying to the network.
• Apply configuration changes to named device groups.
• Apply templates (with variables) to named device groups.
• Roll back changes, if needed.
• Audit configurations, check if device configuration state is synchronized with the NSO CDB view.
• Synchronize the CDB and the configurations on devices.
• Connect devices to NSO using NEDs.

Service Manager

The NSO Service Manager can be used to represent the network services, such as L2 and L3 VPNs, BGP Peers, or Access Control Lists. The network services can be represented in a vendor-agnostic way, and then NSO users can manipulate the services and let NSO calculate and apply the device changes. The objective of the Service Manager is to maintain the complete life-cycle for a network service.

A service in NSO consists of the following:

• A YANG service model - This defines the attributes of the service. For example, a Layer 2 VPN Network Service might be defined with virtual circuit ID, service identifiers, and interface names. NSO will use the YANG service model to render corresponding CLI and Web UI.
• Device configuration map - When the service is created, corresponding changes must be made to the devices. NSO supports ways to define this either with templates or with Java.

The Service Manager provides the following:

• Creating, modifying, deleting services. (FASTMAP works behind the scenes here.)
• Dry-run service life-cycle operations and report before making modifications. A dry-run report will predict changes to the devices.
• Check-sync all services or specific service. Check if the actual device configuration corresponds with the service view. This can be used to check if the device configuration has been changed out of band, or if the resulting device configuration is in violation of permitted service configurations.
• Maintaining device dependencies. Every service instance in NSO knows the corresponding device configuration. Device configurations that are the result of service provisioning can be mapped to the service instances that created the configuration.
• Service self-test. With a self-test action in NSO, you can trigger diagnostic tests of the service.

Configuration Database (CDB)

NSO uses an internal Configuration Database (CDB) to store its own configuration, the configuration of all services, as well as a copy of the configuration of all managed devices. The CDB is persistent, and all transactions are journaled to disk. CDB runs RAM-resident with the entire configuration maintained in memory, resulting in high-performance transactions. However, in tradeoff, run-time memory requirements increase with increased configuration data.

The NSO CDB provides:

• A model on how to handle configuration data in network devices, including an update mechanism upon subscription.
• An internal API for locating network element configurations.
• Automatic support for upgrade and downgrade of configuration data.

The consumers of the database services include the CLI, the web UI, and the NETCONF sessions. CDB client applications need to be able to read configuration data from the database and react when configurations are updated.

Note: The CDB journaling requires file system providing sufficient minimal performance and primitives must include file synchronization and truncation. NFS and other network file systems are unsuitable and unsupported for use with CDB in production deployment.

YANG models

NSO is model-driven with service-models expressed in YANG. Device models are also defined in YANG even though the native format may be MIBs or CLI commands. NSO is itself defined in YANG. A data model describes how data is represented and accessed. In YANG, data models are represented by definition hierarchies called schema trees. Instances of schema trees are called data trees and are encoded in XML. In NSO, there are three primary YANG sources:

• NSO data-model - This defines the built-in functions of NSO.
• Data models from devices such as native YANG modules from NETCONF devices, generated YANG modules from SNMP MIBs, or reverse engineered YANG modules from a CLI device. These YANG modules then specify the functions of the devices that are integrated to NSO.
• YANG service models - When developing service applications, a developer specifies the service model, such as a BGP peer, firewall setting, or MPLS VPN, in YANG.

These models are first compiled into NSO, which then renders all northbound APIs, User Interfaces (Web UI, CLI), and database schemas.

Service model design

A Service in NSO consists of the following:

• A YANG service model - This defines the attributes of the service. For example, an L2 VPN service might be defined with virtual circuit ID, service identifiers, and interface names. A matching CLI and Web UI are then rendered to match. Note: While most of the validation can be expressed in YANG, in some cases, the configuration data validation will require external code, such as when performing look-ups in databases. This step is developed using MAAPI.
  
• A device configuration mapping - When the service is created, corresponding changes must be made to the devices. These are defined using either service templates or programmatically using Java.
  • Service templates may be used to map services to device configurations.
  • Programmatic mapping may be required for more complex mapping. It involves mapping a service operation to available device operations. (The code must handle operations such as when an access link is added to a VPN, and how this is reflected on Customer Edge and Provider Edge routers.)

The core technology of NSO is the capability to read and write configuration to and from the devices. NSO stores the service instances and the device configurations in the Configuration Database (CDB). In contrast to "offline" inventory systems, NSO focuses on transactional integrity between the database and the network, resulting in a real-time database that is always in synchronization with the network. Therefore, NSO can quickly compare a new desired device configuration and to the current configuration. NSO can then automatically render the underlying device commands that will be required to change to the new desired configuration.

The transformation from service models to device models can be complex, especially when dealing with actual configuration details. The FASTMAP algorithm, used by NSO, greatly simplifies this task. Typically, an engineer defines a higher-level service model representing actual device configurations. FASTMAP enables automatic management of any kind of change or deletion. All change scenarios are inferred from a single definition of the service. The mapping from the service create to the corresponding device configuration is defined in a high-level API or through a template. The programmer has to only define the service create method. If a user changes or deletes an existing service later on, NSO calculates the changes.

NSO service mapping is illustrated below.

The figure shows three main sections up top: network engineering, ops and provisioning, and service developers. A box labeled n s o has two blocks labeled service manager and device manager leading to a cylinder labeled C D B. To the right of the c d b is a box labeled package manager. Under this are two main boxes: device abstraction and E S C (V N F M). The device abstraction box has three textboxes with each one labeled N E D. The e s c box has two textboxes: V N F lifecycle manager and V N F service monitoring. A gray multi-domain networks textbox extends across the bottom

NSO Service Mapping

Cisco NSO Services

An NSO service is a function provided by network devices. Creating, modifying, or deleting the service manipulates the actual configuration of the end devices. However, an NSO service does not actually include manual steps. Instead, service transactions performed complete logical operations meeting ACID (Atomic, Consistent DB, Isolated, and Durable) transaction properties. That is, the transaction must either complete as a unit, or not execute at all, and the database must be maintained in a consistent state.

A service model defines the required inputs in order to deploy the service in the network. NSO collapses the service logic problem to a YANG-to-YANG model transformation. If the mapping is straightforward, this can be expressed as a device template. If it is more complex, it can be expressed in a programmatic way using Java or Python. Only 'service creation' needs to be defined. The FASTMAP engine automatically manages all other service life-cycle changes such as modify, add, and delete.

Given a service model, the mapping logic reads the service model instance and updates the corresponding device tree. Mapping logic can be interface-agnostic and unaware of interface specifics such as if it is handled through CLI, NETCONF, or SNMP. The mapping logic also does not include error handling for southbound interface errors which is managed automatically by the transaction manager.

Northbound interfaces

Northbound interfaces allow integration of NSO with applications and portals. NSO has a set of northbound interfaces, including human interfaces like web UI and a CLI; programmable interfaces including RESTCONF, NETCONF, and language bindings including Java, Python, and Erlang. The list below outlines the available Northbound interfaces:

• CLI - The Command Line Interface is one of the flagships of NSO. It is a CLI with features such as tab completion, command history, and model awareness. This is a network-wide CLI that provides transactions across multiple devices and full support for the service models. This enables network automation by scripting towards the network and the network services in a unified CLI rather than scripting towards the devices and native CLIs.
• RESTCONF API - The RESTCONF API is a standardized REST interface as defined in RFC 8040 and provides a number of improvements over the proprietary and legacy REST interface, including the support for auto-generating Swagger/OpenAPI documents from YANG.
• NETCONF - This gives other OSS applications a NETCONF interface to the devices and services managed by NSO.
• Java - The Java interface is used to build applications and clients for NSO. The Java interface is model-aware; programmers can work with classes from the service and device data models. This eases the programming learning curve and assures program correctness at compile time.
• JavaScript - The JavaScript interface is used to build custom Web interfaces. The interface is AJAX-based so that true asynchronous clients can be created.
• SNMP - NSO can present operational data over SNMP to upper layer management systems. This can be useful for handling alarms and gathering performance data. There is also a dedicated SNMP Alarm MIB for the NSO Alarm Manager.
• Web UI - In the same sense as the CLI, the Web UI is generated dynamically from the models. The NSO Web UI can be highly customized.
• MAAPI - MAAPI comes in several flavors. It is the general Management Agent API. MAAPI is available as command line utilities: C-API, Java API, and a Python API.
• REST API - The REST interface provides a complete model via HTTP primitives. Exchanged data may be XML and JSON. Note: The legacy REST API has been deprecated since NSO 5.1 and is scheduled to be removed in NSO 5.3.

Command line interface (CLI)

The NSO CLI provides a unified CLI towards the complete network. It comes in two flavors: Juniper-style and Cisco XR-style. NSO CLI is a single interface for network devices and network services. Note that this is different than a "cut-through" CLI that reaches the devices directly.

As with many CLIs, there are operational and configuration modes. Depending on the mode, a show command will use different data sets. In configuration mode, it displays network configuration data from the NSO CDB configuration store. In operational mode, it will use live values from the devices and plus operational data stored in CDB. The CLI starts in operational mode. Different prompts are used for different modes helping to distinguish, when used interactively.

The CLI is automatically rendered using the data models described by the YANG files. There are four distinct types of YANG models: the built-in NSO YANG models for the device manager, the service manager models, YANG models imported from the managed devices, and service models. Regardless of model type, the NSO CLI seamlessly handles all models as a whole to produce auto-generated CLI. Auto-generated CLI supports:

• Unified CLI across network, devices, and network services
• Command line history and command line editor
• Tab completion for content of the configuration database
• Monitoring and inspecting log files
• Inspecting the system configuration and system state
• Copying and comparing configuration between different parts of the CLI, such as between two interfaces or two devices
• Configuring common setting across a range of devices

Web user interface

The NSO Web UI is also automatically rendered from the YANG data models. It mirrors the data model for NSO itself, as well as the data models for the managed devices and services. As soon as the models are updated, or new devices or services are added, the UI is also updated.

The Web UI is a YANG model browser with additional device and service functionality. The interface is built with pure client-side JavaScript. The Web UI is a mix of custom-built widgets and auto-rendering of the underlying device and service models. All major web browsers are supported, and no plugins are required. The Web UI is available on port 8080 on the NSO server. The port number is configured in ncs.conf.

Managing services (southbound)

NSO requires a YANG model, device address, management port, and authentication credentials for each device to be managed. YANG models are imported using the NSO YANG compiler.

A name identifies each managed device. Most commonly, this is the DNS name or IP address of the device but can be any text string value. Each managed device has a mandatory IP/port pair that, together with the authgroup leaf, provide information as how to connect and authenticate over SSH/NETCONF or TELNET. The device-type determines the communication method or protocol used to communicate with the device. Those are detailed under Southbound interfaces, below.

Southbound interfaces

Southbound interfaces allow the configuration and management of network elements. Available Southbound interfaces:

• NETCONF - (default) NSO automatically discovers and uses devices supporting NETCONF.
• SNMP - NSO can be configured to use device SNMP if provided with MIBs and additional declarative information.
• CLI - A corresponding CLI NED is required. Devices supporting the Cisco CLI engine are supported.
• IOS, IOS XR - A corresponding NED is required and must be loaded.
• Other/generic - A corresponding NED, YANG models, and Java code, is required.

Adding devices

A new device can be added into NSO using any of the following methods:

• Discovery
• Manually
• Cloning
• Templates

Example CLI sequence to manually add a device:

ncs(config)# devices device ce9 address 127.0.0.1 port 10031
ncs(config-device-ce9)# device-type cli ned-id cisco-ios
ncs(config-device-ce9)# authgroup default
ncs(config-device-ce9)# commit

NSO provides the ability to synchronize device configuration between the device and NSO. In the normal case, the configuration on the device and the copy of the configuration inside NSO should be identical. You can force direction so that either NSO or the device has precedence.

NSO device sync-from example:

ncs(config)# devices sync-from
sync-result {
device ce0
result true
}
sync-result {
device ce1
result true
}

Configuring devices

You can also configure several devices inside the same network transaction. First, initiate ncs (config) mode.

Multi-device simultaneous configuration example:

$ ncs_cli -C -u admin
ncs# config

Continue in ncs (config) mode:

ncs(config)# devices device pe1 config cisco-ios-xr:snmp-server community public RO
ncs(config-config)# top
ncs(config)# devices device ce0 config ios:snmp-server community public RO
ncs(config-config)# devices device pe2 config junos:configuration snmp community public view RO
ncs(config-community-public)# top
ncs(config)# show configuration
devices device ce0
config
ios:snmp-server community public RO
!
!
devices device pe1
config
cisco-ios-xr:snmp-server community public RO
!
!
devices device pe2
config
! first
junos:configuration snmp community public
view RO
!
!
!

Cisco SD-WAN

Cisco Software-Defined - Wide Area Networking (SD-WAN) supports third-party API integration, allowing for simplicity, customization, and automation in day-to-day operations. Cisco SD-WAN includes the common protocols used for all enterprise SD-WAN deployments, such as Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), Virtual Router Redundancy Protocol (VRRP), and Internet Protocol version 6 (IPv6).

Through a dashboard called vManage, Cisco SD-WAN provides:

• Transport independence - Guaranteeing zero network downtime, Cisco SD-WAN automates application flexibility over multiple connections, such as the internet, MPLS, and wireless 4G LTE.
• Network services - Deliver rich networking and security services with clicks on the dashboard. WAN optimization, cloud security, firewalls, IPS, and URL filtering can be deployed wherever needed across the SD-WAN fabric from a single location.
• Endpoint flexibility - Cisco SD-WAN can simplify connectivity across branches, campuses, data centers, or cloud environments, extending the SD-WAN fabric wherever you need it to go.

The figure has 6 textboxes going across the top: overlay routing, security and encryption, business logic, on demand v p n's network visibility, and network c l i. A horizontal bar with the words v manage network management system (n m s) is under the top boxes. In the top left is the icon for the v Bond orchestrator and in the center are v smart controllers. Dashed lines goes from these top icons to a section in the middle that has dashed lines around a rectangle that contains four clouds labeled metro e, internet, m p l s, and l t e. To the side and bottom of the rectangle are the words v Edge routers. Three dashed lines with checkmarks within circles at the end go from the rectangle to 4 icons: data center, campus, branches, and remote sites

SD-WAN Overview

Key features of Cisco SD-WAN

• Cloud-first architecture
• Embedded security
• Predictable application experience

Cisco SD-WAN components

• vManage Network Management System (NMS) - Centralized network management system, so that you can configure overlay networks from a dashboard.
• vSmart Controller - Controls the flow of data traffic by working with the vBond orchestrator to authenticate SD-WAN devices as they join the network. It also orchestrates connectivity among the vEdge routers.
• vBond Orchestrator - Orchestrates connectivity between vEdge routers and vSmart controllers. If any vEdge router or vSmart controller is behind a NAT, the vBond orchestrator also serves as an initial NAT-traversal orchestrator.
• vEdge Routers - Provisioned at the perimeter of a site (such as remote offices, branches, campuses, data centers), and delivered as hardware, software, cloud or virtualized components, vEdge Routers secure virtual overlay network over a mix of WAN transports.

vManage management plane

The vManage NMS is a centralized network management system. The vManage NMS dashboard provides a visual window into the network, and it allows you to configure and manage SD-WAN network devices. The vManage NMS software runs on a server in the network. This server is typically situated in a centralized location, such as a data center. It is possible for the vManage NMS software to run on the same physical server as vSmart controller software.

vSmart control plane

The vSmart control plane maintains a centralized route table that stores the route information, called OMP routes. It learns the route information from the vEdge routers and from any other vSmart controllers in the SD-WAN overlay network. Based on the configured policy, the vSmart controller shares this route information with the SD-WAN network devices in the network so that they can communicate with each other.

vBond orchestration plane

The vBond orchestrator coordinates the initial start-up of vSmart controllers and vEdge routers, and it facilities connectivity between vSmart controllers and vEdge routers. During the start-up processes, the vBond orchestrator authenticates and validates the devices wishing to join the overlay network. This automatic orchestration process prevents errors from manual starts.

vEdge data plane

The vEdge router, whether a hardware or software device, is responsible for the data traffic sent across the network. When you place a vEdge router into an existing network, it appears as a standard router. Envision a vEdge router and an existing router that are connected by a standard Ethernet interface. These two routers appear to each other to be Layer 3 endpoints, and if routing is needed between the two devices, OSPF or BGP can be enabled over the interface. Standard router functions, such as VLAN tagging, QoS, ACLs, and route policies, are also available on this interface.

Cisco SD-WAN APIs

The Cisco SD-WAN software provides a REST API, which is a programmatic interface for controlling, configuring, and monitoring the devices in an overlay network. You access the REST API through the vManage web server.

You can access the API documentation in the vManage REST APIs Command Reference.

The Cisco SD-WAN REST API calls expose the functionality of the software and hardware features and of the normal operations you perform to maintain SD-WAN devices and the overlay network itself. In REST API terminology, each of these features or operations is called a resource. A resource is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it.

Resources are grouped into collections. Each collection contains a single type of resource, and so is homogeneous. In the REST API, the collection of resources is present at the top level of the API. The SD-WAN REST API resources are grouped into the following collections:

• Administration
• Certificate Management
• Configuration
• Device Inventory
• Monitoring
• Real-Time Monitoring
• Troubleshooting Tools

Exploring the API with vManage API Explorer

You can explore the API documentation and even try it out by logging into the apidocs resource on your vManage platform as: https://<vmanage_host>:<vmanage_port>/apidocs

Try it: https://devasc-sdwan-1.cisco.com/apidocs/

Log in using username devnetuser and password RE!_Yw519_27.

After you are logged in, you will see a list of API functional groups.

SD-WAN vManage APIs

Click any API group name, and the display will expand to a list of APIs within that functional group. Shown below are the various API calls available under the Device Inventory category. Note that it supplies the required method (GET, PUT, POST, DELETE) as well as the required endpoint URL for each API call.

Device Inventory APIs

Selecting GET /system/device/{deviceCategory} will show detailed information on how to use the API to get a list of devices for that category.

Lists the Device Inventory Details using GET Method

The important areas to note about this view are:

• Response Content Type - In this case, the response will be in JSON format, so you need to be prepared to parse JSON.
• Parameters - These are the parameters you can pass into the API call to filter the returned data.
• Response Messages - The list of HTTP codes that can be returned.
• Try it out! - This is the activation button at the bottom of the page.

Set the deviceCategory parameter to vedges and the model parameter to vedge-cloud, then click Try it out!. Clicking this button executes the API call and passes in the parameters to filter the results to only vEdge Cloud models in the device inventory.

Note: Authentication is not required when using "Try it out!" from vManage, because you are already logged in to the vManage UI and have appropriate privileges.

GET Device API Example

Areas to note about this view:

• Request URL - This is the URL used to issue the request. The host name displayed in this URL is the IP address of this vManage host.
• Response Body - In this case, note the host-name, system-ip, and version.
• Response Code - In this case, we received 200, which means Success.

Cisco Compute Management

Cisco Compute Solutions

The Cisco Unified Computing System (UCS), along with its software and SaaS adjuncts, was introduced in 2009 to provide a complete physical and logical plant for compute, networking, and storage in the modern datacenter.

Here, you will examine UCS more closely, then inter-related management tools and services: UCS-Manager, UCS-Director, and the SaaS global infrastructure management system, Intersight.

An overview of UCS

Cisco UCS is engineered to improve flexibility and manageability for conventional infrastructure:

• Resolve problems that prevent, hinder, or make unaffordable the provisioning of optimal compute/storage/network configurations for diverse and dynamic applications.
• Reduce hardware limitations on the efficiency of virtualization, cloud computing, PaaS, container orchestration, and other frameworks that abstract compute, storage, and network resources.
• Enable end-users to provision arbitrary configurations of virtualized infrastructure that map efficiently to underlying physical infrastructure capabilities, capacity, and configuration.
• Enable management of physical infrastructure using the same type of software-centric, "infrastructure as code" disciplines that DevOps is applying, higher in the stack, to accelerate and scale operations.

UCS is "hyperconverged" infrastructure. In very abstract terms, UCS virtualizes physical infrastructure and makes it uniformly software-definable:

• The underlying physical plant provides modular compute and flexible storage capability that connects using an any-to-any switch fabric, making it easy to add capacity.
• Above this, novel firmware and embedded management software abstract the physical layer, making what are conventionally hard-coded characteristics (such as server UUIDs, MAC addresses, disk-drive layouts, and BIOS settings) configurable at boot times, under control of management software. This eliminates the need to manually implement complex hardware configurations and enables a uniform, software-driven, hands-off infrastructure management experience.
• Atop the hyperconverged infrastructure, UCS system management software and services enable web, CLI, API, and tool-based automated management (for example, using Ansible) of up to tens of thousands of physical servers, as well as the ability to manage a host of non-Cisco infrastructure products.

Cisco UCS Manager

The Cisco Unified Computing System (UCS) is a data center server computer product line composed of computing hardware, switching fabric, embedded management software, and virtualization support.

Cisco's definition for Unified Computing is "Unified Computing unifies network virtualization, storage virtualization, and server virtualization into one, within open industry standard technologies and with the network as the platform."

The products provide scalability by integrating many components of a data center. This lets users manage them as a single unit through UCS Manager, UCS Central, and the Cisco Integrated Management Controller. The different management products directly relate to the number of servers being managed:

• Cisco Integrated Management Controller (CIMC) can manage a single physical server.
• Cisco UCS Manager (UCSM) can manage up to 160 physical servers.
• Cisco UCS Central (UCSC) can manage up to 10,000 physical servers.

Cisco UCS Manager Server Overview

Cisco UCS Manager Graphical Interface

A Cisco UCS system or domain can consist of up to two Cisco UCS fabric interconnects and a minimum of one Cisco chassis with one blade or rack-mounted server. Up to 40 chassis with a mixture of blade types and rack-mounted servers can be connected and controlled by a single Cisco UCS Manager.

Cisco UCS Manager runs on the primary fabric interconnect and is assigned a virtual IP address (VIP), with failover capability to the subordinate fabric interconnect. In the event of a failover, the virtual IP address will connect to the subordinate fabric interconnect, making it the new primary fabric interconnect.

The Cisco UCS Manager management requests from the GUI or CLI are encoded in XML. All XML requests to Cisco UCS are asynchronous and terminate on the active Cisco UCS Manager. Cisco UCS Manager mediates all communication within the system; no direct user access to the Cisco UCS components is required.

Cisco UCS Manager is aware of the current configuration and performs automated device discovery whenever a new resource is installed. After a resource is detected, Cisco UCS Manager adds it and its characteristics to the system inventory. Whichever type of management is chosen, the management software is manipulating the same type of structure to manage the server settings. This is the Management Information Model (MIM).

Applying abstraction to servers

Cisco UCS started as a concept to abstract hardware identifiers and properties from physical computing devices, as well as component configurations and settings.

Cisco UCS Management software provides an abstraction layer between server component interfaces and the administrator. This abstraction layer gives the administrator a uniform experience and application methodology for managing server components. The abstraction layer is presented as a web-based GUI, an SSH CLI, and API.

A single server usually has some or all of the following characteristics:

• Many physical disk drives in multiple layouts, supporting a variety of redundancies, security protocols and standards
• Several logical configurations related to boot disk, network access, management interfaces, protocols and standards
• Many hours required to plan, configure and deploy to a data center

Server identifiers and properties are typically "burned-in" or configurable during the server boot phase with a break key sequence. "Burned-in" identifiers, like the server’s Universally Unique IDentifier (UUID) and Media Access Control (MAC) addresses are usually assigned to the server motherboard and network adapters at manufacturing. Component configurations and settings, such as disk-drive layout and boot drive assignment, are configurable during the server boot process by using a key sequence to “break-in” to the boot process. The point in the process where an administrator can “break-in” is usually right before the server would need to recognize a specific resource or configuration, and solidify that component or configuration so that subsequent processes can rely upon its state.

Users generally think of servers as the point where an operating system is running. Often, the first thing a user wants to know is what version of OS the server is running. This will indicate whether it is a hypervisor system capable of running multiple virtual machines each with its own guest operating system, or a bare metal server running a single instance of a Linux or Windows operating system. The power of UCS is what happens before the operating system is loaded.

Typically, each component of a server has an individual management interface. The method of accessing the component interface and performing that configuration varies from component to component. For example, a key break during server startup might give access to BIOS settings or disk configuration, while a USB drive with adapter software may need to be inserted into the server to setup network and storage interfaces.

Cisco UCS Manager was the first server management methodology to provide complete control over server component configuration with a single structure called a Service Profile. By moving all the server configuration into a Service Profile, UCS Manager enables the administrators to define server identity, addresses, configuration, and settings without actually having a physical server. Cisco-designed hardware enables the overwriting or reassignment of identifiers and addresses, even ones that were "burned-in". In addition, UCS Manager provides address pools and policy definitions that can be consumed by Service Profiles. UCS Manager also provides templates for Service Profiles and templates for network and storage adapters.

Cisco UCS Service Profiles

Cisco UCS Manager uses Service Profiles to assign identity to a server when a Service Profile is associated with a server. UCS Manager can have hundreds of instances of Service Profiles, each with unique addresses and identifiers while also using common policies to manage BIOS settings, boot order, and disk layout.

Each UCS server can only have a single Service Profile association at a time, but Service Profiles can be disassociated from one server and associated to another, thereby applying to the new server the identity that had been applied to the previous server.

The figure shows 3 main boxes. At the top are switches with the words fabric interconnects on the left and management, network, storage on the right. The two switches connect to each other as well as connections to the rack mounted c - series switches in the second box. In the bottom box are the chassis and blades b - series devices

Service Profile Application to Physical Servers

Cisco UCS Manager Servers

Cisco UCS Manager is an advancement in server management and deployment for several reasons:

• Embedded management - UCS does not require a separate management server because it has an embedded management processor that has global visibility on all the elements that constitute a UCS. This guarantees coordinated control and provides integrated management and diagnostics.
• Unified Fabric - UCS is the first server completely designed around the concept of Unified Fabric. Different applications have different I/O requirements, and without Unified Fabric, it is difficult to move applications from one server to another while also preserving the appropriate I/O requirement. Unified Fabric covers LAN, SAN, and the management network.
• Converged Management - Cisco UCS Manager manages servers themselves and the way the servers connect to the rest of the data center, using policies for uplink port-channeling, network failover, port management, virtual LAN and SAN connections, and more.

Cisco UCS Manager servers

Cisco UCS Manager servers are either blades that reside in chassis (B-Series Servers) or rack-mounted (C-Series servers). Both are connected to a redundant pair of switches are called UCS Fabric Interconnects (FIs). The FIs provide redundant network and storage paths, redundant management, and a single point of management control for an administrator. When FIs are connected to each other, they are automatically in a primary-subordinate relationship where the primary handles all of the management and data.

When the servers in a UCS system are configured to take advantage of all the redundant capabilities, there should not be a single point of failure. UCS servers can have redundancy, management, networking, storage, power, and cooling.

UCS Manager also keeps track of events, alerts, errors, and statistics. It is able to report these items using various industry-standard management protocols like SNMP and Syslog.

Capabilities, benefits, and use cases

Cisco UCS is deployed in a wide range of industries and provides high performance computing and virtual desktop services to machine learning and artificial intelligence. UCS servers are available in multiple models to target specific workloads but can be configured to accommodate any workload, from bare-metal OS installation to running hundreds of virtual machines.

Cisco UCS Manager supports the entire Cisco UCS server portfolio. It enables server, fabric, and storage provisioning, as well as device discovery, inventory, configuration, diagnostics, monitoring, fault detection, auditing, and statistics collection. You can extend the benefits of Cisco UCS Manager globally across an enterprise to thousands of servers in multiple domains with Cisco UCS Central.

Cisco UCS Manager treats infrastructure as code. It extends the functionality of existing management tools through a broad, mature partner ecosystem. IT organizations can transition to DevOps by evolving existing staff, skills, tools, and processes and making them more efficient.

An open API facilitates integration of Cisco UCS Manager with a wide variety of monitoring, analysis, configuration, deployment, and orchestration tools from other independent software vendors. The API also facilitates customer development through the Cisco UCS PowerTool for PowerShell and a Python SDK.

Cisco UCS Manager includes the following features:

• Supports Cisco UCS B-Series Blade and C-Series Rack Servers, the C3260 storage server, Cisco UCS Mini, and the Cisco HyperFlex
• Programmatically controls server, network, and storage resources, with a unified, policy-driven management, so they can be efficiently managed at scale through software
• Works with HTML 5, Java, or CLI graphical user interfaces
• Can automatically detect, inventory, manage, and provision system components that are added or changed
• Facilitates integration with third-party systems management tools
• Builds on existing skills and supports collaboration across disciplines through role-based administration

Benefits

Based on an analysis of more than 160 case studies, customers on average achieved the following benefits:

• 83 percent decrease in provisioning time
• 75 percent reduction in project implementation time
• 66 percent lower ongoing administrative and management costs

Cisco UCS Unified API

The Cisco UCS Unified API is called unified because the same API methodology is used for the CIMC, Cisco UCS Manager, and Cisco UCS Central. The information that follows pertains mostly to the Cisco UCS Manager XML API, however the concepts apply to CIMC and Cisco UCS Central.

Cisco UCS Management Information Model

All the physical and logical components that comprise Cisco UCS are represented in a hierarchical management information model (MIM), also referred to as the MIT. The MIT is a tree structure with nodes. Each node in the tree represents a managed object (MO) or group of objects that contains the nodes' administrative state and their operational state.

The hierarchical structure starts at the top (sys) and contains parent and child nodes. Each node in this tree is a managed object and each object in Cisco UCS has a unique distinguished name (DN) that describes the object and its place in the tree. Managed objects are abstractions of the Cisco UCS resources, such as fabric interconnects, chassis, blades, and rack-mounted servers.

Configuration policies are the majority of the policies in the system and describe the configurations of different Cisco UCS components. Policies determine how the system behaves under specific circumstances. Certain managed objects are not created by users, but are automatically created by the Cisco UCS, for example, power supply objects and fan objects. Invoking the UCS XML API is reading and writing objects to the MIM.

The information model is centrally stored and managed by the Data Management Engine (DME), a process running on the fabric interconnects. When a user initiates an administrative change to a Cisco UCS component (for example, associating a service profile to a server), the DME first applies that change to the information model, and then applies the change to the actual managed endpoint. This approach is called a model-driven framework.

The following branch diagram starts at sys from the topRoot of the Cisco UCS MIT. The diagram shows a hierarchy that consists of five populated chassis with eight blades in each chassis. All the blades shown have one or more adapters. For simplicity, only chassis number five is expanded in the graphic below.

Cisco UCS MIT Hierarchical Structure

Cisco UCS Managed Objects

Cisco UCS Managed Objects are XML representations of a physical and logical entities in the UCS system. A boot policy object named default with a single child object that indicates booting from virtual media looks as follows:

<lsbootPolicy
  bootMode="legacy"
  childAction="deleteNonPresent"
  descr="Default Boot Policy"
  dn="org-root/boot-policy-default"
  enforceVnicName="no"
  intId="85315"
  name="default"
  policyLevel="0"
  policyOwner="local"
  propAcl="0"
  purpose="operational"
  rebootOnUpdate="no">
    <lsbootVirtualMedia
      access="read-write"
      childAction="deleteNonPresent"
      lunId="unspecified"
      mappingName=""
      order="4"
      propAcl="0"
      rn="read-write-vm"
      type="virtual-media"/>
</lsbootPolicy>

The class name is the XML element, in this case, lsbootPolicy for the boot policy object, followed by a number of attributes and potentially containing children objects as shown here by the lsbootVirtualMedia object. The lsbootVirtualMedia object belongs to the class lsbootVirtualMedia.

A UCS managed object can have many attributes and can contain many children, the children objects can also contain many children, and so on.

Object naming

You can identify a specific object by its Distinguished Name or by its Relative Name.

The Distinguished Name (DN) enables you to unambiguously identify a target object. All UCS managed objects have a unique DN; no other object in the entire UCS management domain can have the same DN.

The DN has the following format consisting of a series of RNs:

dn = {rn}/{rn}/{rn}/{rn}...

In the following example, the DN provides a fully qualified path for adaptor-1 from the top of the object tree to the object. The DN specifies the exact managed object on which the API call is operating.

<dn="sys/chassis-5/blade-2/adaptor-1"/>

The Relative Name (RN) identifies an object within the context of its parent object. The DN is composed of a sequence of RNs. For example, this DN:

<dn="sys/chassis-5/blade-2/adaptor-1/host-eth-2"/>

is composed of the following RNs:

• topSystem: rn="sys"
• equipmentChassis: rn="chassis-5"
• computeBlade: rn ="blade-2"
• adaptorUnit: rn="adaptor-1"
• adaptorHostEthIf: rn="host-eth-2"

Object classes

All managed objects belong to a class indicating the type of UCS resource the object represents. For example, computeBlade is the class that all UCS blades belong to, and fabricVlan is the class for all VLAN objects.

UCS XML API

The Cisco UCS Manager XML API, like other APIs, provides methods to authenticate, query, and configure.

Authentication methods

Authentication methods authenticate and maintain an API session with UCS Manager:

• aaaLogin - Initial method for logging in and retrieving an authentication cookie.
• aaaRefresh - Refreshes the current authentication cookie.
• aaaLogout - Exits the current session and deactivates the authentication cookie.

Operations are performed using the HTTP post method over TCP. Cisco UCS supports both HTTP and HTTPS requests and HTTP and HTTPS can be configured to use different port numbers, but TCP/443 (or TCP/80 for non-secure connections) is used by default. The HTTP POST body contains the XML configuration.

Query methods

Query methods obtain information on the current configuration state of an object. The following are query examples:

• configResolveDn - Retrieves objects by DN.
• configResolveDns - Retrieves objects by a set of DNs.
• configResolveClass - Retrieves objects of a given class.
• configResolveClasses - Retrieves objects of multiple classes.
• configFindDnsByClassId - Retrieves the DNs of a specified class.
• configResolveChildren - Retrieves the child objects of an object.
• configResolveParent - Retrieves the parent object of an object.
• configScope—Performs – Performs class queries on a DN in the MIT.

Query filters

The API also provides a set of query filters. These filters can be passed as part of a query and are used to identify the desired result set.

Simple filters

There are two simple filters, the true filter and false filter:

• True - Objects with the Boolean condition of true.
• False - Objects with the Boolean condition of false.

Property filters

The property filters use the values of an object's properties as the criteria for inclusion in a result set. To create most property filters, classId and propertyId of the target object or property is required, along with a value for comparison.

• Equality - Objects with the identified property of "equal" to the provided property value.
• Not equal - Objects with the identified property of "not equal" to the provided property value.
• Greater than - Objects with the identified property of "greater than" the provided property value.
• Greater than or equal - Objects with the identified property of "is greater than or equal" to the provided property value.
• Less than - Objects with the identified property of "less than" the provided property value.
• Less than or equal - Objects with the identified property of "less than or equal" to the provided property value.
• Wildcard - Objects where the identified property includes a wildcard. Supported wildcards include "%" or "*" (any sequence of characters), "?" or "-" (any single character).

Composite filters

The composite filters are composed of two or more component filters. They enable greater flexibility in creating result sets. For example, a composite filter could restrict the result set to only those objects that were accepted by at least one of the contained filters.

• AND - Result set must pass the filtering criteria of each component filter. For example, to obtain all compute blades with totalMemory greater than 64 megabytes and operability of operable, the filter is composed of one "greater than" filter and one "equality" filter.
• OR - Result set must pass the filtering criteria of at least one of the component filters. For example, to obtain all the service profiles that have an assignmentState of unassigned or an association state value of unassociated, the filter is composed of two "equality" filters.
• Between - Result set is those objects that fall between the range of the first specified value and second specified value, inclusive. For example, all faults that occurred starting on the first date and ending on the last date.
• XOR - Result set is those objects that pass the filtering criteria of no more than one of the composite's component filters.

Modifier filter

A modifier filter changes the results of a contained filter. The only modifier filter that is currently supported is the NOT filter, which negates the result of a contained filter. Use this filter to obtain objects that do not match contained criteria.

Configuration methods

There are several methods to make configuration changes to managed objects. These changes can be applied to the whole object tree, a subtree rooted at a specified object, or an individual object. The following are examples of configuration methods:

• configConfMo - Affects a single managed object.
• configConfMos - Affects multiple subtrees.
• configConfMoGroup - Applies the same configuration changes to multiple subtree structures or managed objects.

Cisco UCS API documentation

Cisco UCS API documentation is typically referred to as the UCS Object Model documentation. The Object Model documentation is available with the UCS Platform Emulator or online.

Every UCS object class and method is listed in the documentation along with UCS types, events, faults, errors, and Syslog messages. The documentation is a wealth of information providing information about every aspect of a UCS managed object.

As an example of how the documentation works, you can explore the fabricVlan object.

UCS Object Model Documentation - Overview and Naming Rules

Cisco UCS Manager Documentation

The left navigation menu enables you to select an object. The right pane displays the object information divided into sections related to various aspects of the object.

Overview in documentation

The Overview section indicates whether the object is Abstract or Concrete. All objects that represent a physical or logical entity are Concrete. Abstract objects are used for inheritance where several different objects can inherit shared attributes from a base object. Abstract objects can also represent an aggregation of objects. For example, computeServer is an Abstract object that represents an aggregation of the computeBlade object and computeRackUnit object.

The Overview also contains information related to encryption, privileges, the SNMP OID and a description of the object.

Naming Rules

The Naming Rules indicate the object prefix. In the case of a fabricVlan if the object prefix is net- that means a VLAN object defined in UCS will have net- in front of the provided VLAN name. For example, if a VLAN is created with the name backupvlan the name portion of the object DN will be net-backupvlan

The Naming Rules also define the different DNs that can be assigned to a fabricVlan object. This is because UCS VLANs can be different types of VLANs and reside in different parts of the MIM.

Containers Hierarchies

Containers Hierarchies display where the fabricVlan object can be contained, in other words, where the object can reside in the MIM.

UCS Object Model Documentation - Containers Hierarchies

Contained Hierarchy

Contained Hierarchy displays what objects the fabricVlan can contain and what objects those contained objects can contain, and so on.

UCS Object Model Documentation – Contained Hierarchy

Inheritance

Inheritance displays all the objects prior to the fabricVlan object that the fabricVlan inherited attributes from.

UCS Object Model Documentation - Inheritance

Events, faults, and FSMs

Objects can be changed by an administrator or a process. Mutations or changes to the object are events. Mutations happen as the object is created, modified, and deleted, and may generate events and faults. The process of mutating is performed by one or more Finite State Machine processes (FSMs).

Events, faults, and FSMs are also objects and are attached to the parent object for which they were generated. The fabricVlan object does not have events and associated FSMs.

UCS Object Model Documentation - Events, Faults, and FSMs

Properties Summary

The Properties Summary lists all the properties or attributes of the object. Each property's name and type are displayed. Properties are grouped by the object where the property was first defined. Note that objects can inherit properties from another higher level object definition.

UCS Object Model Documentation - Properties Summary

Properties Detail

Each object property is defined completely in the Properties Detail. The fabricVlan name property has details for type, encryption, access, and more.

Note the Property Validators. The validator for range indicates that the fabricVlan name property must be at least one character long but not greater than thirty-two characters. The validator for what characters are allowed is shown as a regular expression: a-zA-Z0-9_.:-]+

This regular expression indicates that any combination of the characters between the brackets is allowed in a fabricVlan name.

UCS Object Model Documentation - Properties Summary

XML, SDKs, tools, and resources

The UCS XML API uses XML as a method to encode requests and responses via the API, and also uses XML to define the entire Object Model. The entirety of XML used to define the MIM is known as the XML schema. All UCS objects are described in the XML schema. The schema defines the objects, their attributes, and the associated values. All components of UCS are always available with the XML API.

There are a wide variety of libraries available for multiple programming languages for manipulating XML and interacting with an HTTP service. An SDK provides several convenience functions and features. It removes a lot of the overhead associated with writing XML directly.

When the Cisco UCS XML API was first released, API interactions were performed by constructing XML documents and managing HTTP interactions from a client application. Those interactions were similar to the following examples.

Authentication request and response

<aaaLogin inName="admin" inPassword="password" />
<aaaLogin
  response="yes"
  outCookie="cookie"
  outRefreshPeriod="600"
  outPriv="aaa,ext-lan-policy,ext-lan-qos,ext-san-policy,operations, pod-policy,pod-qos,read-only"
  outDomains="mgmt02-dummy"
  outChannel="noencssl"
  outEvtChannel="noencssl">
</aaaLogin>

Successful authentication requests return an authentication cookie. The cookie is used for all subsequent requests. The cookie eventually expires and needs to be refreshed. Refreshing the cookie resets the expiration time and returns a new cookie.

Query request and response

<configResolveDn
  cookie="cookie"
  inHierarchical="false"
  dn="mac/10:00:00:00:00:03" />
<configResolveDn
  dn="mac/10:00:00:00:00:03"
  cookie="cookie"
  response="yes">
  <outConfig>
    <macpoolAddr assigned="yes"
      assignedToDn="org-root/ls-SP01/ether-eth1"
      dn="mac/10:00:00:00:00:03"
      id="10:00:00:00:00:03"
      owner="pool" />
  </outConfig>
</configResolveDn>

Whether making a query or performing a configuration, the XML document needs to be prepared for the request and parsed when XML is returned in the response.

Cisco UCS Power Tool

UCS PowerTool is a library of PowerShell Cmdlets that enable the management of UCS environments from Microsoft Operating Systems, via the UCS XML API. The UCS XML schema is used to generate more than 98% of the UCS PowerTool Library. Using the XML schema to generate the PowerTool, Cmdlets ensure that the Cmdlets are completely aware of objects, their containment, properties and the details associated with each property.

The Cmdlet to authenticate with a UCS Manager is as follows:

Connect-Ucs -Name <ip-address-ucs-manager>

UCS PowerTool - Authentication

The Cmdlet to query UCS Blades and view their DNs is as follows:

Get-UcsBlade | Select-Object Dn

UCS PowerTool - Blade Query

The Cmdlet to create UCS VLAN 100 is as follows:

Get-UcsLanCloud | Add-UcsVlan -Name vlan100 -Id 100

UCS PowerTool OS support

UCS PowerTool is a library of PowerShell Cmdlets. PowerShell Desktop runs on Windows and PowerShell Core runs on Linux variants including macOS. UCS PowerTool and UCS PowerTool Core support those releases of PowerShell.

UCS PowerTool has nearly 6000 Cmdlets to manage every aspect of Cisco UCS Systems.

UCS Python SDK

UCS Python SDK is a set of Python modules, each containing one or more classes, developed specifically to automate UCS Manager via the UCS XML API. The UCS Python SDK is developed with PEP8 compliance and supports every Object in the UCS Object Model. The UCS XML schema is used to generate more than 98% of the UCS Python SDK. Using the XML schema to generate the UCS Python SDK ensures that the Python modules are completely aware of objects, their containment, properties, and the details associated with each property.

Similar to UCS PowerTool, the UCS Python SDK provides hundreds of Python modules to interact with UCS objects.

The UCS Python SDK code to authenticate with a UCS Manager is as follows:

from ucsmsdk.ucshandle import UcsHandle
handle = UcsHandle("ucs-manager-ip", "username", "passsword")
handle.login()

The UCS Python SDK code to query UCS Blades and view their DNs is as follows:

from ucsmsdk.ucshandle import UcsHandle
handle = UcsHandle("ucs-manager-ip", "username", "passsword")
handle.login()
blades = handle.query_classid("computeBlade")
for blade in blades:
  print(blade.dn)

The UCS Python SDK to Create UCS VLAN 100 is as follows, the code shown here is PEP8 compliant and will score a 10 out of 10 when run through pylint:

from ucsmsdk.ucshandle import UcsHandle
from ucsmsdk.mometa.fabric.FabricVlan import FabricVlan
# Create a Login Handle and Login
HANDLE = UcsHandle("ucs-manager-ip", "username", "password")
HANDLE.login()
# Query the FabricLanCloud, under which VLAN Objects are inserted
FABRIC_LAN_CLOUD = HANDLE.query_classid("FabricLanCloud")
# Instantiate a VLAN Object, minimally "id" and "name" are required
VLAN = FabricVlan(
    parent_mo_or_dn=FABRIC_LAN_CLOUD[0],
    name="vlan100",
    id="100"
    )
# Add the instantiated VLAN Object to the HANDLE
HANDLE.add_mo(VLAN)
# Commit the HANDLE to add the VLAN to UCS Manager
HANDLE.commit()
# Logout
HANDLE.logout()

UCS Python SDK OS support

The UCS Python SDK is supported wherever Python is supported.

UCS Ansible

UCS Ansible is available for UCS Manager and the Cisco Integrated Management Controller.

Similar to UCS Python SDK, UCS Ansible combines the UCS Manager authentication with the object mutation or object query. This makes a lot of sense because UCS Ansible modules are written using the UCS Python SDK.

UCS Ansible modules are called as tasks in an Ansible playbook. All the features and capabilities of the Ansible Domain Specific language are available to UCS Ansible Modules.

Ansible playbook that queries a UCS Manager for UCS VLANs is shown below:

---
- name: UCS Query
  hosts: ucs
  connection: local
  gather_facts: no
  tasks:
  - name: Query UCS
    ucs_query:
      hostname: "{{ ucs_hostname }}"
      username: "{{ ucs_username }}"
      password: "{{ ucs_password }}"
      class_ids: fabricVlan
    register: response

To create, update, and delete multiple UCS Organization use the following Ansible Playbook:

---
- hosts: ucs
  connection: local
  gather_facts: no
  tasks:
  - name: Test for a UCS hostname,  username, and password
    fail:
      msg: 'Please define the following variables: ucs_hostname, ucs_username and ucs_password.'
    when: ucs_hostname is not defined or ucs_username is not defined or ucs_password is not defined
    vars:
      login_info: &login_info
        hostname: "{{ ucs_hostname }}"
        username: "{{ ucs_username }}"
        password: "{{ ucs_password }}"
  - name: Add UCS Organization
    ucs_org:
      <<: *login_info
      org_name: test
      description: testing org
      state: present
      delegate_to: localhost
  - name: Update UCS Organization
    ucs_org:
      <<: *login_info
      org_name: test
      description: Testing org
      state: present
      delegate_to: localhost
  - name: Add UCS Organization
    ucs_org:
      <<: *login_info
      org_name: level1
      parent_org_path: root
      description: level1 org
      state: present
      delegate_to: localhost
  - name: Add UCS Organization
    ucs_org:
      <<: *login_info
      org_name: level2
      parent_org_path: root/level1
      description: level2 org
      state: present
      delegate_to: localhost
  - name: Add UCS Organization
    ucs_org:
      <<: *login_info
      org_name: level3
      parent_org_path: root/level1/level2
      description: level3 org
      state: present
      delegate_to: localhost
  - name: Remove UCS Organization
    ucs_org:
      <<: *login_info
      org_name: level2
      parent_org_path: root/level1
      state: absent
      delegate_to: localhost

Cisco UCS Manager XML API summary

The Cisco UCS Manager XML API, which is part of the Cisco UCS Unified API, is the foundation for everything in UCS. XML defines the Object Model schema, encodes the object in the MIM, and is used in the API to encode the requests and responses from the UCS platforms.

The PowerShell and Python adaptations for the UCS XML API abstract the developer from the XML and provide a better experience for the developer. These tools manage cookie refreshes and object mutations, provide the ability to wrap interactions in transactions, and create watch methods with callback functions that trigger when a particular setting is applied, or a state is observed.

Ansible abstracts the developer to another level and provides a declarative model that puts the burden on the module to achieve what is being declared.

The UCS XML API provides complete coverage of the objects presented through the UCS management interfaces, enabling any tool or SDK built on top of XML API the ability to control all the objects in the UCS Object model.

Cisco UCS Director

Cisco Unified Computing System (UCS) Director is a complete, highly secure, end-to-end management, orchestration, and automation solution for a wide array of Cisco and non-Cisco data center infrastructure components, and for converged infrastructure solutions based on the UCS and Cisco Nexus platforms.

Cisco UCS Director is a 64-bit appliance that uses the following standard templates:

• Open Virtualization Format (OVF) for VMware vSphere
• Virtual Hard Disk (VHD) for Microsoft Hyper-V

Management through Cisco UCS Director

Cisco UCS Director extends the unification of computing and networking layers through Cisco UCS to provide visibility and management of data center infrastructure components. You can use Cisco UCS Director to configure, administer, and monitor supported Cisco and non-Cisco components. You can use UCS Director to perform the following tasks:

• Create, clone, and deploy service profiles and templates for all Cisco UCS servers and compute applications.
• Monitor organizational usage, trends, and capacity across a converged infrastructure on a continuous basis. For example, you can view heat maps that show virtual machine (VM) utilization across all your data centers.
• Deploy and add capacity to converged infrastructures in a consistent, repeatable manner.
• Manage, monitor, and report on data center components, such as Cisco UCS domains or Cisco Nexus network devices.
• Extend virtual service catalogs to include services for your physical infrastructure.
• Manage secure multi-tenant environments to accommodate virtualized workloads that run with non-virtualized workloads.

Automation and orchestration with Cisco UCS Director

Cisco UCS Director enables you to build workflows that provide automation services and to publish the workflows and extend their services to your users on demand. You can build Cisco UCS Director workflows to automate simple or complex provisioning and configuration processes.

After they are built and validated, these workflows perform the same way every time, no matter who runs the workflows. An experienced data center administrator can run them, or you can implement role-based access control to allow your users and customers to run the workflows on a self-service basis, as needed.

With Cisco UCS Director, you can automate a wide array of tasks and use cases across a variety of supported Cisco and non-Cisco hardware and software data center components. A few examples of the use cases that you can automate include, but are not limited to:

• VM provisioning and lifecycle management
• Network resource configuration and lifecycle management
• Storage resource configuration and lifecycle management
• Tenant onboarding and infrastructure configuration
• Application infrastructure provisioning
• Self-service catalogs and VM provisioning
• Bare metal server provisioning, including installation of an operating system

UCS Director Converged

Features and benefits

• Central Management - Provides a single interface for administrators to provision, monitor, and manage the system across physical, virtual, and bare metal environments. Unified dashboards, reports, and heat maps, which reduce troubleshooting and performance bottlenecks.
• Self-service Catalog - Enables end users to order and deploy new infrastructure instances conforming to IT-prescribed policies and governance.
• Adaptive Provisioning - Provides a real-time available capability, internal policies, and application workload requirements to optimize the availability of your resources.
• Dynamic Capacity Management - Provides continuous monitoring of infrastructure resources to improve capacity planning, utilization, and management, and identifies underutilized and overutilized resources.
• Multiple Hypervisor Support - Supports VMware ESX, ESXi, Microsoft Hyper-V, and Red Hat hypervisors.
• Computing Management - Provisions, monitors, and manages physical, virtual, and bare metal servers, as well as blades. Enables end users to implement virtual machine life-cycle management and business continuance through snapshots. Enables administrators to access server utilization trend analysis.
• Network Management - Provides policy-based provisioning of physical and virtual switches and dynamic network topologies. Enables administrators to configure VLANs, virtual Network Interface Cards (vNICs), port groups and port profiles, IP and Dynamic Host Control Protocol (DHCP) allocation, and Access Control Lists (ACLs) across network devices.
• Storage Management - Provides policy based provisioning and management of filers, virtual Filers (vFilers), Logical Unit Numbers (LUNs), and volumes. Provides unified dashboards that enable administrators comprehensive visibility into organizational usage, trends, and capacity analysis details.
• Dashboards - Provides multiple dashboards to track resource and policy utilization.

UCS Director Dashboard

Model-based orchestration

Cisco UCS Director includes a task library that contains over 1000 tasks and out-of-the-box workflows. Model-based orchestration and a workflow designer enable you to customize and automate the infrastructure administrative and operational tasks. You can extend and customize the system to meet individual needs.

Cisco UCS Director programmability

Cisco UCS Director programmability is flexible and provides a variety of methodologies to automate. UCS Director is an automation and orchestration platform with several programmatic capabilities.

• REST API - The REST API and the REST API Browser enable the management of UCS Director. UCS Director handles the management of policies, groups, virtual entities, etc. The REST API also provides a way to launch UCS Director workflows.
• Tasks - Tasks are either provided out-of-the-box or can be created as custom tasks. Tasks can be atomic or monolithic and are written in CloupiaScript, a JavaScript-like language.
• Script Libraries - Can contain CloupiaScript methods, Java jar files, lists of values, and more.
• PowerShell Host - Use PowerShell Cmdlets with UCS Director via the PowerShell Host.
• Integrations - UCS Director supports integrations with a variety of services to provide everything from issue tracking, to payment services, to source code control.

Cisco UCS Director – REST API

To access the REST API through Cisco UCS Director, a valid Cisco UCS Director user account and an API access key are needed. Cisco UCS Director uses the API access key to authenticate API requests. This access key is a unique security access key code that is associated with a specific Cisco UCS Director user account.

You must pass the REST API access key as an HTTP header in the following format:

X-Cloupia-Request-Key: F90ZZF12345678ZZ90Z12ZZ3456FZ789

Using the GUI

UCS Director Enable REST API Browser

When you enable the developer menu, Cisco UCS Director GUI provides a developer menu option for developers to access the report metadata and REST API Browser. You can then access the following features:

• Report Metadata - The report metadata enables you to view the REST API URL for every report displayed in Cisco UCS Director.
• REST API Browser - The REST API Browser is accessible from the Orchestration menu of Cisco UCS Director. The REST API Browser provides API information and API code generation capabilities that make it easy to see and work with all the available APIs, including both the REST APIs and the Java APIs.

UCS Director REST API Browser

• REST Client - The REST Client is a useful widget for parsing and viewing API requests and responses. In this widget, you can enter a REST URL and apply an HTTP method such as POST, PUT, or DELETE to the URL for data manipulation. The REST Client provides a simple user interface for entering a URL to fetch data from the Cisco UCS Director server.

UCS Director REST Client

How to make a REST API request

API clients use an HTTP request to interact with Cisco UCS Director. To pass the REST API access key, each request must be associated with an HTTP header called X-Cloupia-Request-Key with its value set to the current REST API access key.

Requests made to the API have the following characteristics:

• They are sent over HTTP.
• Request format encoding can be either JSON or XML in UCS Director API Version 1.
• The request must contain a valid URL.

API VERSION 1

http://SERVER/app/api/rest?formatType=json&opName=operationName&opData=operationData

Where:

• SERVER – This is the IP address or the hostname of Cisco UCS Director.
• formatType – This is either JSON or XML. JSON is the default.
• opName - The API operation name associated with the request. For example,: userAPIGetMyLoginProfile or userAPIGetVMActionStatus.
• opData - Parameters (or arguments) associated with the operation.

Cisco UCS Director uses JSON or XML encoding of the parameters. If no arguments are required for the operation, use {} as an empty set. Before you send data in a request, encode the URL by applying escape characters as appropriate. For details about encoding the URL, see the RFC at http://www.ietf.org/rfc/rfc1738.txt.

API Version 2

Only XML is supported for Version 2 of the UCS Director API.

http://server/cloupia/api-v2/group

• HTTP method: POST.

<cuicOperationRequest>
  <payload>
    <![CDATA[
      <AddGroupConfig>
      <groupName>TestGroup</groupName>
      <groupDescription></groupDescription>
      <parentGroup>0</parentGroup>
      <groupCode></groupCode>
      <groupContact>jbesai@cisco.com</groupContact>
      <firstName></firstName>
      <lastName></lastName>
      <phone></phone>
      <address></address>
      <groupSharePolicyId></groupSharePolicyId>
      <allowPrivateUsers>false</allowPrivateUsers>
      </AddGroupConfig>
    ]]>
  </payload>
</cuicOperationRequest>

About operations data parameters or arguments

As the method and the API resource type are communicated through the opName, the operation parameters must present any arguments that you want to designate a specific instance of the resource to be operated upon.

Operations data parameter syntax

The following are the examples of operations data parameter syntax in JSON format.

• No parameters - {}
• One parameter; integer (for example, 10) - {param0:10}
• One parameter: string (for example, cloud) - {param0:"cloud"}
• Two parameters: a string and an Integer - {param0:"cloud",param1:10}
• Two parameters: a string with null value and an Integer - {param0:null,param1:10}
• Three parameters - {param0:"cloud",param1:"cloupia",param2:100}

Operation Data Parameter examples

…&opData={param0:"Create NFS Datastore",param1:{"list":[{"name":"Volume Size","value":100},
{"name":"Select Group","value":"14"},{"name":"Select vDC","value":18}]},param2:212}

• param0 - Name of the workflow being invoked through the REST API.
• param1 - Input being passed to the workflow. If there is more than one input, separate the inputs with commas and put two single quotation marks around the input names and values. If there are no inputs, use the keyword null as the parameter value.
• param2 - If this workflow is being invoked as a child workflow of another service request, use the service request (SR) ID. If this workflow is not invoked as a child workflow, use –1. When –1 is used, a new service request is created.

How to use cURL commands

cURL is a command line tool for getting or sending data using URL syntax. You can use the cURL command to execute a REST API request.

The following sample shows how to execute the userAPISubmitWorkflowServiceRequest API and pass the input values:

curl  -v -X POST -H 'X-Cloupia-Request-Key:5CF4C115F0034B189616B2B8EBA0F220' -g 'http://172.17.32.75/app/api/rest?formatType=json&opName=userAPISubmitWorkflowServiceRequest&opData={param0:"TestWorkFlowFromAPI",param1:{"list":[{"name":"A1","value":"Hello"},{"name":"A2","value":"World"}]},param2:-1}'

Custom tasks and CloupiaScript

Cisco UCS Director provides automated, profile-based provisioning, management, and reporting of infrastructure resources. Cisco UCS Director incorporates a powerful orchestration engine that enables complex operations on any element of your converged infrastructure, both physical and virtual. These operations are embodied in workflows, which are scripted sequences of individual tasks. Cisco UCS Director comes complete with a large library of tasks.

The tasks in Cisco UCS Director are written in CloupiaScript, a version of JavaScript with libraries that enable orchestration operations. With CloupiaScript, it is possible to embed scripts in workflow tasks and to write custom tasks.

SSH to a network device CloupiaScript example

function testSSHClient() {
	var client = new SSHClient(input.ipAddress, 22, // 22 = SSH standard port
input.userName, input.password);
	client.connect();
	var session = client.openShell(511,25); // (511, 25) = (columns, rows)
	var shellStream = new PrintStream(session.getOutputStream());
	shellStream.println(input.command);
	shellStream.flush();
	client.disconnect();
}
testSSHClient();

Additional UCS Director resources

UCS Director REST APIs can be called from any programming language or tool that support HTTP requests. For example PowerShell and Python or Postman and cURL. CloupiaScript is used directly or imported into built-in and custom tasks. Tasks can also call PowerShell Cmdlets through the PowerShell agent. Built-in tasks and custom tasks are used to build workflows and workflows can be invoked from the UCS Director REST API, making UCS Director almost completely automatable

Cisco Intersight

Cisco Intersight was introduced in 2018 by Cisco Systems. Cisco Intersight is a Software as a Service (SaaS) systems management platform capable of managing infrastructure at the edge and remote locations, as well as in the data center. When using the service, you can scale infrastructure up or down as needs increase or decrease. Because it provides a REST API to access the Management Information Model (MIM), you can manage the infrastructure as code. The Intersight API is consistently available with a cloud-based management model. New features can be added to the service without impacting existing automation systems.

Cisco Intersight SaaS-based Management

Intersight and Cisco Unified Computing System (UCS)

Cisco UCS Manager software provides an abstraction layer between server component interfaces and the administrator. This abstraction layer means that an administrator has a standardized method for managing server components. The abstraction layer is presented as a web-based graphical user interface (GUI) and an application programming interface (API).

Cisco Intersight builds on the UCS Unified Fabric and UCS Management experience with a Cisco-hosted and maintained management platform. With a Server Profile, which performs model-based service provisioning in UCS, you can use Intersight to configure servers, manage resources, and ensure that policies align. With this approach, you avoid failures caused by inconsistent configuration.

With the Intersight API you can build integrations with Cisco Intersight for additional tasks like monitoring, analysis, configuration, deployment, and orchestration.

Cisco Intersight API Framework

Intersight API capabilities

The Intersight API provides access to the Intersight MIM. The Intersight API accepts and returns messages that are encapsulated through JavaScript Object Notation (JSON) documents and uses HTTP over TLS as the transport protocol.

All the physical and logical components visible in Cisco Intersight are represented in a hierarchical MIM, also referred to as the Management Information Tree or MIT. The MIT is a tree structure with nodes. Each node in the tree represents a managed object (MO) or group of objects that contains the nodes' administrative state and its operational state.

For more information, see the Management Information Model section of the Intersight documentation.

Accessing the Intersight API

There are a couple of ways to gain access to the Intersight API You can use a web browser as an Intersight API REST Client, or API keys for remote or service access.

Intersight API REST client

To view and interact with the Intersight API, access https://intersight.com/apidocs in a browser. The API Reference pages hosted on intersight.com contain live information on the complete Intersight resource model. Resources can be searched by name and the Model Schema can be viewed.

Intersight API Reference and Model Browser

The site at intersight.com also hosts a REST Client that allows direct interaction with the API.

The REST Client on the site also supports the full query language of the API and details on the supported Query Parameters can be viewed in the Parameters pages.

Intersight API REST Client

Intersight API keys

You create API keys for your Intersight account for typical remote access through SDKs or other programming environments. For example, API keys are used by Intersight Ansible modules and key information is specified in Ansible playbooks. The playbooks also contain variables that you can edit as needed.

Intersight API keys are categorized into two; an API key ID and a secret key. The API Key ID is a multi-character string that is always visible after initial key creation. The secret key is an RSA Private Key that is only available at API key creation. To create API keys in Intersight, you must login at https://intersight.com and perform the following steps:

Step 1. Click the Settings icon.

Step 2. Click API Keys in the left-hand navigation pane.

Step 3. Click Generate API Key.

Step 4. Enter a Description for the key.

Step 5. Click Generate.

Step 6. Click the Save Secret Key to text file icon. A "SecretKey.txt" file is downloaded to your default downloads location.

Note: You can create Intersight API keys only if you have the required product licensing.

Ansible Modules for Cisco Intersight

Intersight supports several API integrations, including Ansible modules that enable inventory collection and configuration management of Intersight resources. Ansible is written in Python, and the modules for Intersight interact with the API using the code written in Python. This securely authenticates with Intersight using API keys and standard Ansible modules for URL based access.

Several example playbooks and Lab guides are hosted on GitHub.

Additional SDKs and resources

In addition to Ansible Modules, Intersight provides a Python SDK and PowerShell modules that are generated from Intersight OpenAPI schema (which is also referred to as the Intersight Swagger Spec). The intersight.com site hosts the latest OpenAPI specification and links to the SDKs.

Cisco Collaboration Platforms

Introduction

In this topic, you will learn about Cisco's suite of on-premise and cloud-based collaboration solutions. These efficient means of communication enable businesses to increase productivity and decrease costs.

Cisco Unified Communications Manager (Unified CM) was originally designed to route calls over an IP network, and Cisco quickly added more features to meet the growing needs of businesses. Unified CM is:

• Used to configure and automate device provisioning, call routing, and profiles and settings management in a single solution.
• Deployed in hospitals, banks, universities, and government agencies to manage the increasing number of devices and user profiles.

Cisco created many APIs to further extend its capabilities, including AXL and UDS. These APIs provide Cisco partners and developers an easier way to automate and manage the devices, user profiles, and calls.

Contact Center provides robust customer support for call centers with agent desktop, supervisor, and reporting capabilities. Contact Center can be used with Unified CM or as a standalone. Contact Center is used to manage and route high-volume calls, text, video, and data to the right agent at the right time with the right information.

Finesse is an agent and supervisor desktop. The Finesse API provides Cisco partners and developers with more flexibility and customization of the desktop to deliver customer-driven care.

Webex encompasses Meetings, Teams, and Devices. Webex simplifies the needs of voice, video, and data into one solution so that people can collaborate more efficiently:

• Webex Teams is a meetings and messaging app designed to improve collaboration. The Webex Teams API enables you to create chat bots and integrations to streamline activities.
• Webex Devices include digital whiteboards, telepresence units, and room controls. Customize and personalize the Webex Devices with the xAPI.

Cisco Unified Communications Manager

Cisco Unified Communications Manager is also known as Unified CM, CUCM or CallManager. Cisco Unified Communications Manager:

• Is an IP-based communications solution to support mobile and remote workers in small, medium, or enterprise-level businesses.
• Is an integration for voice, video, and data into a single on-premise solution for call control and session management.
• Is highly extensible, with various APIs for configuration, management, monitoring, and call control.

Purpose

The primary function of Unified CM is to manage phone users, IP phones, directory numbers, and to connect and manage calls to the desired destinations. With Unified CM you can:

• Define gateways, trunks, remote destinations, and more telephony-related information.
• Configure a full range of call handling tasks, including hold, transfer, call forward, and starting conference calls. Unified CM stores configuration data in an internal database, with a Publisher→Subscriber cluster architecture.

Unified CM Advanced Features

Unified CM's advanced features include:

• AXL - SOAP APIs (XML requests) for managing various aspects of CUCM via programs rather than the web UI. AXL is for administration and configuration of CUCM.
• UDS - Enables end users to update their own personal settings stored on CUCM.
• Serviceability - RisPort provides real-time registration and IP address information for phones. PerfMon provides real-time monitoring of Cisco Unified CM hardware and software.
• Platform Administrative Web Services (PAWS) - Lets you programmatically perform operations such as upgrades instead of performing the steps manually.
• Softphone compatibility - Softphone devices can allow a Jabber user to make and receive phone calls.
• Extension Mobility - Users can log into any phone and that phone will switch from its default directory number to the user's directory number while the user is logged in.
• Cisco Jabber Voice & Video SDK - A JavaScript library/add-on and Chrome/Firefox extension that enables you to create a web page that can act as a softphone (audio and optional video). You can also use the web page to leverage your physical phone.
• Java Telephony API (JTAPI) or Telephony API (TAPI) - Enables you to write programs that automate the way calls are handled.
• Client Matter Codes (CMC) - Enables you to manage call access and accounting. CMC forces the user to enter a code to specify that the call relates to a particular client matter. You can assign client matter codes to customers, students, or other populations for call accounting and billing purposes.
• Forced Authentication Codes - Limit access to certain directory numbers users by requiring users to enter an authentication code first.
• Hunt Lists - Lists of directory numbers. If you call a number in a Hunt List and that number is not available (busy, for example), it rings the next number in the list, and so on, until it either reaches a callee or runs out of numbers in the list.
• Music/Video on Hold - Define your own music and/or video to play when a user is on hold.

Extensions

Unified CM integrates with other services:

• Cisco Instant Messaging and Presence (Cisco IM&P) - Requires a server installed with Cisco IM&P, also known as CUP. The Cisco IM&P server synchronizes presence and instant messaging (IM) information between Cisco Unified Communications and other applications.
• Voicemail - Advanced voicemail management, requires a server installed with Cisco Unity Connection (CUC).
• Contact Center - Routes customer service requests to a pool of agents to provide efficient customer support.

• Administrative XML Layer

  Administrative XML Layer (AXL) is an XML/SOAP-based interface that provides a mechanism for inserting, retrieving, updating, and removing data from the Unified Communication configuration database. Developers can use AXL and the provided Web Services Description Language (WSDL) to create, read, update, and delete objects such as gateways, users, devices, route-patterns and much more.

  The figure shows 7 rows. Each row has a word to the left and a textbox to the right. Row 1 application application row 2 a p i a x l (administrative x m l), row 3 protocol soap, row 4 encoding x m l, row 5 transport h t t p (s), row 6 application server apache / tomcat, row 7 data storage database

  AXL and the Unified Communication Configuration Database

• 
  
  

  Purpose

  The AXL API is for administration and configuration. For example, you could write an AXL/SOAP-based application to streamline operations like adding a user, configuring which phones the user is allowed to control, configure that user's Extension Mobility (the ability to log in to other phones and use a pre-defined directory number on that phone), and much more.

  What you can do with AXL

  You can perform almost every action with AXL that you can with the Unified CM Administration Console web GUI. Examples of things that can be provisioned with AXL include but are not limited to:

  • Unified CM Groups
  • Call Park Directory Numbers (DNs)
  • Call Pickup Groups
  • Calling Search Spaces
  • Computer Telephony Integration (CTI) Route Points
  • Device Pools
  • Device Profiles
  • Dial Plan Tags
  • Dial Plans
  • Digit Discard Instructions
  • Directory Numbers
  • Gateways (Analog, T1, PRI)
  • Locations
  • Media Gateway Control Protocol (MGCP) Devices
  • Phones
  • Process Nodes
  • Process Node Services
  • Regions
  • Route Filters
  • Route Groups
  • Route Lists
  • Route Partitions
  • Service Parameters
  • Translation Patterns
  • Users
  • Voice Mail Ports

  How it works

  AXL is a SOAP interface, meaning it is based on the exchange of XML documents (defined in a schema, or Web Services Description Language (WSDL). Several APIs and development frameworks can consume the AXL WSDL to produce 'native' code/libraries. These allow you to use AXL without handling XML. For simple requests, it can be simpler to make AXL requests by creating XML strings and sending via HTTP POST.

  The methods for the objects begin with:

  • list
  • add
  • update
  • get
  • remove

  For example listPhone lists all phones, and addUser creates a new user.

  SQL queries

  You can also perform direct SQL queries to update or retrieve data in the Unified CM configuration database using ExecuteSQLupdate or ExecuteSQLquery. You need to refer to the Unified CM Database Dictionary to create your SQL statement. Please note there is no backwards compatibility between Unified CM releases when using SQL queries.

  If you want to download the WSDL to produce a 'native' library, download it from Unified CM:

  Step 1. Log into Unified CM as an administrator.

  Step 2. Select Application -> Plugins from the menu.

  Step 3. Click the Find button. The first entry in the list is the Cisco AXL toolkit.

  Step 4. Download the file axlsqltoolkit.zip and unzip it in a working directory. This kit contains AXL schema for a WSDL and XSD files for a variety of Unified CM versions, so you have a nice collection to pick from for your particular version of Unified CM.

  Versioning

  The AXL schema version is backwards-compatible for up to two major releases. This means developers can use AXL schema version 10.0(1) for Unified CM release 10.0(1) through 12.5(1). The schema version can be specified in the SOAP action header of the request. If it is not specified, the system uses the oldest supported schema. You can see the version being specified in the sample request below. You can access more details in the versioning docs.

  Sample request

  This sample request returns a list of phones and all their settings. By requesting name and specifying a wildcard character %, you can retrieve a list of all phone names.

  <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/12.5">
     <soapenv:Header/>
     <soapenv:Body>
        <ns:listPhone>
           <searchCriteria>
              <name>%</name>
           </searchCriteria>
        </ns:listPhone>
     </soapenv:Body>
  </soapenv:Envelope>
  

  Advanced features

  AXL has some advanced features. One of the most useful is the Change Notification Feature. You can use this SOAP request repeatedly to see what changes have been made to the system since the last time you ran the request. You can request to see changes about specific categories, like Phone or User, or just see all changes.

  Related SOAP-based Administration APIs

  UC Manager Serviceability includes similar SOAP-based API requests for retrieving information about phones such as the registration status, the IP address, and more.

  It also includes a performance monitoring API, and an API to manage and get the status of CUCM services. To learn more about these services, view the Serviceability developer documentation.

  Read more

  More information about AXL is available in the AXL developer documentation.

• User Data Services

  User Data Services (UDS) is a REST-based API that provides a mechanism for inserting, retrieving, updating and removing data from the Unified Communication configuration database. Developers can use the UDS API to create, read, update, and delete user resources, including devices, subscribed services, and speed dials.

  Purpose

  The UDS API is designed for end users to configure settings. For example, the API provides authenticated access to enable end users to update their personal settings for their own devices.

  What you can do with UDS

  One example of how you can use the UDS API is to create a directory search or manage user preferences and settings in your web application. Because the API provides functionality for end users to login, those end users can then change their settings to enable and disable features like "Call Forward All" and "Do Not Disturb". Examples of actions with UDS include:

  • Directory search for users
  • Manage Call Forward, Do Not Disturb, and Speed Dial settings, including visual and audible alert preferences
  • Set Language and Locale
  • Subscribe to IP Phone Service Applications
  • Reset PIN or password credentials
  • Configure Remote Destinations used with Cisco Mobility & Single Number Reach

  How it works

  UDS is a REST-based interface that sends and receives XML-formatted data. UDS implements the four common HTTP request methods: GET, POST, PUT, and DELETE.

  For example GET /speedDials returns a list of the user's speed dials, and PUT /speedDials updates that user's speed dials.

  UDS supports Single Sign-on (SSO) and Basic Authentication for authentication. Not all UDS API requests require authentication, but the UDS resources that do require authentication are:

  • credentials
  • device(s)
  • extension(s)
  • remoteDestination(s)
  • speedDial(s)
  • subscribedService(s)
  • user
  • userPolicy

  Sample request

  This sample XML request returns a list of your user's settings and preferences:

  GET https://{host}:8443/cucm-uds/user/{userId}
  Accept: application/xml
  

  This is the response:

  <user version="{version}" uri="https:­//{host}:8443/cucm-uds/user/{userId}">
      <id>{userPkid}</id>
      <userName>{userId}</userName>
      <firstName>firstName</firstName>
      <lastName>lastName</lastName>
      <middleName>middleName</middleName>
      <nickName>nickName</nickName>
      <phoneNumber>8134567</phoneNumber>
      <homeNumber>8134455</homeNumber>
      <mobileNumber>8131111</mobileNumber>
      <mobileConnect>true|false</mobileConnect>
      <userLocale uri="https:­//{host}:8443/cucm-uds/installedLocales" value="0" appliesToAllDevices="true|false">English, United States</userLocale>
      <email>someone@example.com</email>
      <directoryUri>someone@example.com</directoryUri>
      <msUri>someone@example.com</msUri>
      <department>department</department>
      <manager>manager</manager>
      <title>title</title>
      <pager>8137777</pager>
      <primaryExtension uri="https:­//{host}:8443/cucm-uds/user/{userId}/userExtension/{extensionPkid}">
          <description>extensionDescription</description>
          <directoryNumber>81134953</directoryNumber>
          <callForwardAllDestination>
              <sendToVoiceMailPilotNumber>true|false</sendToVoiceMailPilotNumber>
              <destination>4352134</destination>
          </callForwardAllDestination>
          <messageWaitingVisualAlert>true|false</messageWaitingVisualAlert>
          <messageWaitingVisualAlertPreference appliesToAllLineAppearances="true|false" value="">Use System Default</messageWaitingVisualAlertPreference>
          <messageWaitingAudibleAlertPreference appliesToAllLineAppearances="true|false" value="1">On</messageWaitingAudibleAlertPreference>
          <onACallRingPreference appliesToAllLineAppearances="true|false" value="0" >Use System Default</onACallRingPreference>
          <notOnACallRingPreference appliesToAllLineAppearances="true|false" value="0" >Use System Default</notOnACallRingPrefence>
          <voiceMailPilotNumber>5555</voiceMailPilotNumber>
          <label appliesToAllLineAppearances="true|false">label</label>
          <logMissedCalls appliesToAllLineAppearances="true|false">true|false</logMissedCalls>
      </primaryExtension>
      <accountType useLdapAuth="true|false">ldap|local</accountType>
      <homeCluster enableCalendarPresence="true|false" enableImAndPresence="true|false">true|false</homeCluster>
      <devices uri="https:­//{host}:8443/cucm-uds/user/{userId}/devices"/>
      <credentials uri="https:­//{host}:8443/cucm-uds/user/{userId}/credentials"/>
      <userExtensions uri="https:­//{host}:8443/cucm-uds/user/{userId}/userExtensions"/>
      <enableDoNotDisturb appliesToAllDevices="true|false">true|false</enableDoNotDisturb>
      <callForwardAllDestination appliesToAllExtensions="true|false">
          <sendToVoiceMailPilotNumber>true|false</sendToVoiceMailPilotNumber>
          <destination>43521</destination>
      </callForwardAllDestination>
      <speedDials uri="https:­//{host}:8443/cucm-uds/user/{userId}/speedDials"/>
      <serviceProfile uri="http:­//{host}:6970/SPDefault.cnf.xml"/>
  </user>
  

  Read more

  For more information about UDS, refer to the UDS developer documentation.

• Cisco Finesse

  Finesse is Cisco's browser-based contact center agent and supervisor desktop. Finesse has REST APIs and JavaScript APIs that can be used to build fully custom agent desktops, integrate contact center functionality into applications, and integrate applications into the Finesse agent and supervisor desktop. This integration can be accomplished in the form of OpenSocial gadgets.

  Finesse Agent and Supervisor Desktop

• 
  
  

  What is a Contact Center?

  The cisco finesse window shows a phone icon that says ready. The top section shows recent call history and the bottom section has recent state history with a table of start time, state, reason, and duration

  Customer Calling Customer Service Rep

• 

  A contact center, also known as a call center, is typically a centralized location where a company handles the customer service for their business. Customer service can be provided in the form of calls, text, email, and chat.

  Contact centers have two categories of tasks:

  • Inbound tasks - When customers initiate communication with customer service. Examples include a customer asking questions about their bill, or needing IT help, or a new customer trying to sign up.
  • Outbound tasks - A customer interaction made from the contact center agent to a customer. Examples include telemarketing, reminders for an upcoming appointment or service, or a follow-up on a previous customer service interaction.

  The workers of a contact center are called agents and their managers are supervisors. They assist the customers and are also known as customer service representatives. They use an application called an agent desktop for the following tasks:

  • Manage their incoming work (call, text, chat, email)
  • Get the customer data that was provided through a menu prompt or form
  • Get customer information from a customer relationship management or an internal database
  • Enter notes into the customer’s account/file for future reference
  • Get help from a knowledge base in order to assist the customer
  • Request help from peers or the supervisor

  Contact Center Systems

  Contact center systems are very complex. This is a high level overview of the features needed to understand Finesse.

  Contact center systems perform what is called skill-based routing, using an automatic call distributor (ACD) to intelligently route inbound customer interactions (such as calls, text, chat, email) to customer service agents by matching them based on skills and specialties using sophisticated algorithms.

  Contact center systems also provide agent and supervisor management. The systems monitor agent state so that the ACD knows who is available to receive tasks. The following are examples of agent states:

  • Not Ready - The agent is not available to take incoming task (call, text, chat, email)
  • Ready - The agent is available to take incoming task from the queue (call, text, chat, email)
  • Talking - The agent is currently handling a call from the queue.
  • Work - The agent just finished handling the task and is wrapping up work by adding notes, completing forms, and so on. In this state, the agent will not receive a new task.
  • Logout - The agent is signed out and not working at the moment.

  To provide additional detail into the agent state, there are reason codes that describe why an agent is in a state. There are typically two types of reason codes: Not Ready and Logout.

  Finesse deployments

  Finesse has two different deployments. In a contact center solution, Finesse sits on top of Contact Center Enterprise or Unified Contact Center Express and cannot function without one of these contact center systems.

  Finesse communicates with the contact center system via the CTI protocol. This protocol is different between the Contact Center Enterprise and Contact Center Express systems, but Finesse provides the same interface for the two deployments while maintaining the behavioral differences.

  Contact Center Enterprise

  Standalone Finesse that is used with a Contact Center Enterprise system is one type of deployment.

  The cisco finesse window shows a phone icon that says ready. The top section shows recent call history and the bottom section has recent state history with a table of start time, state, reason, and duration

  Finesse with UCCE Architecture Diagram

  

  There are two versions of Contact Center Enterprise (CCE), Unified Contact Center Enterprise (UCCE) and Packaged Contact Center Enterprise (PCCE). The difference between the two is mainly hardware footprint, the ease of installation and the number of supported agents. The audience for a Contact Center Enterprise system is large businesses.

  Unified Contact Center Express

  Co-resident Finesse that is used with Unified Contact Center Express.

  The cisco finesse window shows a phone icon that says ready. The top section shows recent call history and the bottom section has recent state history with a table of start time, state, reason, and duration

  Finesse with UCCX Architecture Diagram

  
  
  

  Unified Contact Center Express (UCCX) is for small to medium businesses. The hardware footprint is tiny compared to a Contact Center Enterprise system because most products are co-resident. When products are co-resident, it means that it utilizes one server/VM and therefore, one installer. Because UCCX is for smaller businesses, there are not as many features as there are in a CCE deployment.

  Finesse APIs

  Finesse was built with integrations in mind. It provides an extensive list of REST and JavaScript APIs for developers to integrate Finesse's functionality into applications or applications to be integrated into the Finesse agent desktop.

  Finesse REST APIs

  Finesse provides REST APIs for performing agent and supervisor actions programmatically. They can be used to build custom agent desktops, integrate into existing applications, and/or build a script to automate tasks. Because the APIs are HTTP-based, they can be used in both thick and thin applications. The details of each REST API can be found in the Finesse Developer Guide, but here is a high-level description of some API functionality:

  • User - Represents an Agent, Supervisor or Administrator and enables you to retrieve or update user details and state information.
  • Dialog - Represents a call and the participants. If the media type is voice, it enables you to make calls, take action on calls, and make outbound-related actions.
  • Media - Represents a user's state in a non-voice Media Routing Domain (MRD) and enables you to get information about a user and manage user state.
  • Team - Represents a team of Users and enables you to get team details and lists of team messages.
  • SystemInfo - Represents current state of the system and enables you to retrieve System Details such as XMPP Server, PubSub Domains, Node IP Addresses, Status, and Deployment Type.
  • ClientLogs - Enables you to send client-side logging to the Finesse Server.

  The Finesse REST APIs that use the GET verb are synchronous, which means that the Finesse server will return a response with the requested information immediately. The application must wait for a response before proceeding. The rest of the Finesse REST APIs are asynchronous, which means that the Finesse server will acknowledge that the request was made, but will send a notification with the requested information via the Finesse Notification Service. The asynchronous Finesse REST APIs goes hand in hand with the Finesse Notification Service.

  Finesse Notification Service

  The Finesse Notification Service is an instance of an OpenFire server that runs as a separate process on the platform. The notification service provides event notification from the Finesse server to any client that is subscribed to a particular resource. OpenFire uses the XMPP protocol as the data communication channel. Applications must communicate with the Finesse Notification service with XMPP or BOSH (Bi-directional streams Over Synchronous HTTP) for web applications.

  Finesse JavaScript APIs

  The Finesse agent and supervisor desktop is an OpenSocial container that has the ability to host OpenSocial gadgets. Finesse provides JavaScript APIs for building custom OpenSocial gadgets to be used in the out-of-the-box Finesse agent and supervisor desktop.

  The Finesse JavaScript library is a layer built on top of the Finesse REST API and Finesse notification service communication. It abstracts the details of the request and notifications by wrapping them into JavaScript classes, methods, and callbacks. By doing so, developers using the Finesse JavaScript APIs do not need to deal with the BOSH connection setup and making the REST API requests directly. The Finesse JavaScript API contains almost all of the same APIs as the Finesse REST APIs. The details of each JavaScript API can be found in the Finesse JavaScript Library.

  Finesse Use Cases

  There are endless possibilities with what can be built with the Finesse APIs. Here are some common use cases;

  • Problem - A company needs a contact center agent desktop that is custom to their agents’ needs. The provided Finesse agent desktop is not sufficient. Solution - The company can build a 100% fully functioning agent desktop that is branded and contains every single feature that can be found in the out of the box Finesse agent desktop. They will need to use most of the User, Dialog, Team APIs in conjunction with the Finesse Notification Service.
  • Problem - A company uses a customer relationship management (CRM) as their main application for their contact center agents. They want to add agent state and basic call control into the CRM to avoid needing to flip between two applications. Solution - The company will use the User and Dialog APIs in conjunction with the Finesse Notification Service. The User APIs will add the agent state capabilities while the Dialog APIs will add the basic call control capabilities.
  • Problem - A company wants to add a "Click to call" feature to their application. Solution - The company will use the Dialog--Create a New Dialog API to add this functionality
  • Problem - A telemarketing company wants a custom agent desktop that would have only outbound capabilities. Solution - The company can build a 100% fully functioning outbound-only agent desktop. They will need to add agent sign in/out, agent state, outbound features, and specific call control for outbound calls. Supported outbound features include receiving an outbound call, accept/close/reject/reclassify outbound calls, and schedule callbacks.
  • Problem - A company wants a supervisor specific desktop because their supervisors do not take incoming customer calls. Solution - The company can build a supervisor desktop that only contains supervisor capabilities. Finesse has APIs for the following features for their team: team messages, silent monitor, barge, view and change agent's state.
  • Problem - A company is using the Finesse out of the box agent desktop but wants to add agent state workflows. Solution - The company can build a custom gadget for the agent state workflow. The custom gadget has the ability to receive all of the User notification. With that data, the gadget can trigger the workflow accordingly.
  • Problem - A company is using the Finesse out of the box agent desktop and wants to integrate a different application that has REST APIs into the agent desktop. Solution - The company can build a custom gadget and integrate in the application by using the application's REST APIs. The gadget has the ability to call external REST APIs, parse the responses, and display the data accordingly.
  • Problem - A company wants to integrate a webpage into the Finesse agent desktop. Solution - If the webpage allows itself to be loaded in an iframe, they can build a custom gadget that is as simple as just an iframe that loads that webpage.
  • Problem - A company wants to change the color of the light on their IoT capable headset when the agent states change. Solution - The company will build a custom gadget that calls the headset's APIs to change the color of the light when the agent state changes. The gadget has the ability to receive all of the User notifications so it will know when the agent state changes.

  Learn more about Finesse

  For more details about Finesse, such as a technical overview including Finesse architecture and free sandboxes, take a look at the DevNet Finesse site.

  To find the documentation for the Finesse REST APIs, take a look at the Finesse Developer's Guide.

  To find the documentation for the Finesse JavaScript APIs, take a look at the Finesse JavaScript Library.

• Webex Teams

  Cisco Webex Teams is an online collaboration solution to connect people and teams through chat, voice, and video. With the Webex Teams app, you gain access to secure virtual work spaces. You also use messaging and file sharing with third-party app integrations.

  Benefits of Webex Teams

  Webex Teams lets you use a single app to contain content and information for team collaboration. Teams also integrates with Cisco Webex devices. Information remains safe and secure with advanced security and compliance built-in.

  Tour of Webex Teams

  Mobile, desktop, and web-based clients are available for the Webex Teams platform.

  Features of Webex Teams

  Webex Teams includes the following capabilities and features:

  • Create spaces
    • Invite people and teams to specific Webex Teams spaces.
    • Send messages, share files, and create or edit whiteboards, securely, with one person or a group of people.
  • Create meetings
    • High-quality video meetings with screen sharing and white boarding across all of your devices.
    • In-meeting tools, such as the ability to mute others, add guests, and turn on recording, help improve effectiveness and engagement.
    • Chats, files, and whiteboards shared during meetings can be reviewed by everyone later.
  • Work inside and outside your company the same way: Add people to your shared spaces from your company directory or enter an email address directly.
  • Place calls
    • Native in-app voice and video calling capabilities to reach other Webex Teams and standards-based SIP endpoint users.
    • These can be enhanced with comprehensive PBX calling features and Cisco IP phones when combined with one of our calling solutions - Cisco Unified Communications Manager, Cisco Hosted Collaboration Solution (HCS), or Cisco Webex Calling.

  Security

  Your users and sensitive information is kept safe with extensive controls to help you configure and control your security policies.

  • Protect messages, files, and whiteboard drawings with end-to-end encryption.
  • Manage your own encryption keys on-premises.
  • Your policies are maintained even when your employees are collaborating with others outside your company, through integration with your chosen DLP solution.

  Integrations

  Webex Teams includes pre-built solutions with third-party applications from vendors such as Microsoft, Google Cloud, and Salesforce. With Microsoft Office 365, Microsoft Exchange, and Google Calendar integrations, you can view your meeting list in Webex Teams:

  • You will be able to schedule meetings.
  • Users can share and edit files from Microsoft OneDrive and SharePoint Online directly in Webex Teams spaces.

  Other integrations can be set up using the Webex App Hub to connect Webex Teams with work happening in other tools such as Service Now, Trello, Asana, Salesforce, and JIRA.

  Webex Teams works seamlessly with Webex devices to give you the best possible video meeting and teamwork experiences, without complicated setup procedures, cabling, or productivity disruption.

  Webex Hybrid Services bridge cloud and on-premises services to smooth your transition to the cloud, while maximizing return on investment (ROI). Includes integrations with on-premises assets such as your calendar service, directory, calling system, conferencing resources, and video devices.

  Features of the Webex Teams API

  The Webex Teams API is an extensive set of APIs that allow you to interact with the entire Webex Teams platform. From managing organizations, teams, people, rooms, memberships, and messages to creating conversational bots or embedded video calls, you can extend the capabilities of Webex Teams:

  • Use the Webex API to create webhooks enabling fine-grained communication with, and control of, applications and services in response to specific events in Webex Teams.
  • Create bots that emulate Webex users and mediate with external applications to provide services (often using webhooks).
  • Use Webex Embedding APIs for Java, node.js, browsers, iOS, and Android, along with Webex Widgets, to embed Webex voice/video calling and messaging functionality into desktop, web, and mobile applications.

  All of this reference information is available in the Webex Teams documentation.

  Organizations

  Organizations represent a set of people in Webex Teams. Organizations may manage other organizations or be managed themselves. Organization resources can only be accessed by an administrator.

  METHOD	URL	Description
  GET	https://api.ciscospark.com/v1/organizations	List Organizations
  GET	https://api.ciscospark.com/v1/organizations/{orgId}	Get Organization Details

  Teams

  Teams are groups of people with a set of rooms that are visible to all members of that team. The Teams API resources are teams to be managed, created, updated, and deleted.

  METHOD	URL	Description
  GET	https://api.ciscospark.com/v1/teams	List Teams
  POST	https://api.ciscospark.com/v1/teams	Create a Team
  GET	https://api.ciscospark.com/v1/teams/{teamId}	Get Team Details
  PUT	https://api.ciscospark.com/v1/teams/{teamId}	Update a Team
  DELETE	https://api.ciscospark.com/v1/teams/{teamId}	Delete a Team

  People

  People are registered users of Webex Teams.

  METHOD	URL	Description
  GET	https://api.ciscospark.com/v1/people	List People
  POST	https://api.ciscospark.com/v1/people	Create a Person
  GET	https://api.ciscospark.com/v1/people/{personId}	Get Person Details
  PUT	https://api.ciscospark.com/v1/people/{personId}	Update a Person
  DELETE	https://api.ciscospark.com/v1/people/{personId}	Delete a Person
  GET	https://api.ciscospark.com/v1/people/me	Get My Own Details

  Rooms (Spaces)

  Note: Notice that the resource in the API endpoint refers to "rooms." The user interface refers to "spaces." These are interchangeable terms.

  Rooms are virtual meeting places where people post messages and collaborate to get work done. The Rooms API can manage, create, update, and delete rooms.

  METHOD	URL	Description
  GET	https://api.ciscospark.com/v1/people	List People
  POST	https://api.ciscospark.com/v1/people	Create a Person
  GET	https://api.ciscospark.com/v1/people/{personId}	Get Person Details
  PUT	https://api.ciscospark.com/v1/people/{personId}	Update a Person
  DELETE	https://api.ciscospark.com/v1/people/{personId}	Delete a Person
  GET	https://api.ciscospark.com/v1/people/me	Get My Own Details

  Memberships

  Memberships represent a person's relationship to a room. The Memberships API resources allow you to list members of any room that you are in, create or revoke memberships, and memberships can be updated to make someone a moderator of a room.

  METHOD	URL	Description
  GET	https://api.ciscospark.com/v1/memberships	List Memberships
  POST	https://api.ciscospark.com/v1/memberships	Create a Membership
  GET	https://api.ciscospark.com/v1/memberships/{membershipId}	Get Membership Details
  PUT	https://api.ciscospark.com/v1/memberships/{membershipId}	Update a Membership
  DELETE	https://api.ciscospark.com/v1/memberships/{membershipId}	Delete a Membership

  Team Memberships

  Team Memberships represent a person's relationship to a team.

  METHOD	URL	Description
  GET	https://api.ciscospark.com/v1/team/memberships	List Team Memberships
  POST	https://api.ciscospark.com/v1/team/memberships	Create a Team Membership
  GET	https://api.ciscospark.com/v1/team/memberships/{membershipId}	Get Team Membership Details
  PUT	https://api.ciscospark.com/v1/team/memberships/{membershipId}	Update a Team Membership
  DELETE	https://api.ciscospark.com/v1/team/memberships/{membershipId}	Delete a Team Membership

  Messages

  Messages are how we communicate in a room. In Webex Teams, each message is displayed on its own line along with a timestamp and sender information. Use this API to list, create, and delete messages.

  Message can contain plaintext, rich text, and a file attachment.

  METHOD	URL	Description
  GET	https://api.ciscospark.com/v1/messages	List Messages
  GET	https://api.ciscospark.com/v1/messages/direct	List Direct Messages
  POST	https://api.ciscospark.com/v1/messages	Create a Message
  GET	https://api.ciscospark.com/v1/messages/{messageId}	Get Message Details
  DELETE	https://api.ciscospark.com/v1/messages/{messageId}	Delete a Message

  Lab – Construct a Python Script to Manage Webex Teams

  In this lab, you will use Webex Teams APIs to authenticate, manage people, manage rooms, manage memberships to rooms, and send a message.

  You will complete these objectives:

  • Part 1: Launch the DEVASC VM
  • Part 2: Get Your Webex Teams Access Token
  • Part 3: Test Your Access Token
  • Part 4: Manage People in Webex Teams
  • Part 5: Manage Rooms in Webex Teams
  • Part 6: Manage Memberships in Webex Teams
  • Part 7: Manage Messages in Webex Teams

• Webex Devices

  Cisco Webex Devices provide access to all of Webex's features. Webex Boards, Room Devices, and Desk Devices enable collaboration through video, calling, and programmability.

  Types of Webex Devices

• 
  
  

  Webex Board Series

  The Cisco Webex Board Series are all-in-one team collaboration devices for meeting rooms and spaces. Benefits include:

  • A fully touch-based device that simplifies the meeting experience
  • Cloud-based platform that allows you to save and continue work before, during, and after the meeting
  • Cloud registration makes it affordable and easy to deploy with end-to-end encryption
  • Wireless presentations with no more need for dongles and wires
  • Digital whiteboards
  • High quality and high fidelity video and audio conferencing
  • High-resolution 4K screen

  Webex Room Series

  The Cisco Webex Room Series brings integrated video conferencing systems to every room. Benefits include:

  • 55- or 70-inch 4K screen(s)
  • Intelligent viewing capabilities, such as automatic framing and speaker tracking
  • Dual screens, dual content sources, wireless sharing, and 4K content for presentations
  • AI based noise suppression, voice-activated controls, and people counting
  • APIs and macros allow for expressive meeting personalization
  • Built for both on-premises and cloud deployment
  • Digital whiteboards

  Webex Desk Series

  The Cisco Webex Device Series brings high-quality video conferencing to your desktop. Benefits include:

  • HD Video and high fidelity audio
  • Intuitive touchscreen
  • Built for both on-premises and cloud deployment

  Cisco Touch 10

  Cisco Touch 10 is an intuitive touchscreen device for interacting with Cisco conferencing systems.

  • Supports the Cisco MX Series, SX Series, IX Series and Webex Room Series
  • Power over Ethernet
  • Wide language support

  Touch 10 customization is enabled with in-room controls, control room devices, and Touch 10 peripherals, and can integrate with Control Systems.

Programmability for Cisco Collaboration Devices

Webex Devices can be customized through the API, known as the xAPI. This enables bi-directional communication with third-party applications and control systems.

There are multiple ways to access xAPI including Telnet/SSH, HTTP, and RS-232 serial connection. Regardless of the method you choose, xAPI has the same general format, behaves similarly, and allows full device control, optimized for integrating with Control Systems.

xAPI supports both XML and JSON and provides direct access via the Command Line. It also supports JavaScript Macros for on-device customization.

Customization Examples

UI Extensions (In-Room Controls) and macros

When speaking about Webex Devices, Cisco is currently transitioning towards use of the generalized term "UI Extensions" to describe custom widgets, buttons, and other virtual controllers that you can create and deploy. These used to be referred to, globally, as "In-Room Controls". Going forward, however, that latter term will be reserved to mean only the subset of UI Extensions that are used to interact in a meeting room (for example, to control lights).

At present, you may still encounter the term "In-room Controls" used in the general sense in the documentation pages. Be sure to read carefully for context!

Likewise, going forward (as of last quarter of 2019), there is only one tool, called the UI Extensions Editor. But you may see earlier versions of this tool referred to as Control Panel Editor, even in study guides and other materials for the last quarter of 2019.

What UI Extensions do

UI Extensions enable you to add custom user interface elements to the Touch 10 display used to control room devices, as well as the on-screen control interface of the DX Series. These elements can trigger applications to control aspects of the device itself or affect in-room lighting, blinds, video switches, or other peripherals.

UI Extensions can be bi-directionally integrated with additional external control systems (such as AMX/Crestron) with xAPI. To get a feeling for the possibilities offered by custom UI Extensions, Webex collaboration devices come with a built-in control simulator that can be run directly from a web browser.

Customize In-room Controls

Launching the simulator will load a virtual meeting room, equipped with several automated systems controlled from switches on the walls (and your Touch10/DX interface, as you will see later in this step.)

The switch controls let you switch the projector on or off, interact with the projector canvas, close/open the blinds, etc.

Personalizing Collaboration Devices

As of version 9.2 of Cisco's Collaboration Endpoint software release, on-screen branding, signage and message customization options let you personalize the appearance of a room device and its Touch10 interface. This capability allows these systems to harmonize with your corporate branding, communicate info to in-room users, update with alerts, and more. While the admin can always statically configure these custom display options via the room device's web interface, you can also explore various ways to use scripts, apps or other automation tools via xAPI to automate such tasks.

Branding and customization of the room device "Halfwake" screen lets you upload your own text and images to customize the appearance of the screen and/or the Touch10 control interface.

In the "Halfwake" state, you can:

• Add a background image (screen/Touch10)
• Add a small logo image to the bottom right corner (screen/Touch10)
• Customize or remove the default on-screen welcome message (screen only)

Touch 10 Personalization in "Halfwake" State

In the "Awake" state, you can:

• Add a small logo image to the bottom right corner (screen/Touch10)
• Add a label or message to the bottom left corner (screen only)

Touch 10 Personalization in Awake State

Running Javascript on devices with macros

CE v9.2.1+ enables you to deploy custom code to the device itself via the macro feature. This feature lets you upload JavaScript code and run it directly on the collaboration device (hosted in a secure 'sandbox' environment). This custom code can interact with the device using the exposed xAPI JavaScript object.

Ideally, code developed on an external app server using jsxapi could be uploaded to run directly on a collaboration device without requiring an external server. However, the macro JavaScript environment has some limitations, including the lack of local file storage, the inability to install additional JavaScript packages via NPM, and restrictions on establishing network connections.

Project Activity 5: Network Programmability and Automation

In this activity, you will complete the following tasks:

• Design a new application for network automation.
• Use data modeling with YANG.
• Implement automation with NETCONF.
• Automate the process using Python.

Refer to the DEVASC Project Rubric below for this activity to record your process and outcomes.

Scenario

In this scenario, you will work on a new application. Your new IT team consists of software developers, network engineers and cybersecurity professionals, all with DEVASC backgrounds and certifications. Your company is looking to:

• Be more responsive to customer needs and requirements
• Have shorter development cycles (more responsive to changes, updates, customer requirements)
• Increase deployment frequency
• Have more dependable releases
• Align more closely with business objectives
• Use automation wherever possible

The team uses a common philosophy, culture, discipline, and a set of holistic methodologies to deliver and support products and services for both external and internal customers. Your manager wants your team to use the DevOps approach to demonstrate the team's ability to implement the necessary tools within your network.

In your first meeting with your manager, your team has identified many new features and improvements that could simplify network operations. You have an opportunity to also explore new problems, but your first priority is to support Level 1 Support Engineers (L1 SE) who are receiving daily calls from customers. Customers usually require some sort of network change. One common request is a need to change a description on a router’s interface.

The L1 SE team does not have management access to the network infrastructure. They escalate the requests to the L2 network team engineers, who are spending valuable time every day with simple manual configuration changes. Your manager wants to find a way to optimize these processes and has tasked your team with designing a system that would let the L1 SE team trigger some of these changes using a simple chatbot (or web interface, console application, etc.).

Because configuration is one of the requirements, your team has decided to use NETCONF. Your team will create an automated process that demonstrates how L1 Support Engineers can make updates to networking devices.

Operational Objective - Automate the following process:

• Verify the current running-config.
• Make three changes to the configuration.
• Verify the changes.
• Verify the new running-config.
• Send a notification message to the WebEx SE Teams group (L1 and L2 SEs) announcing the update.

Technical Objectives:

• Utilize data modeling with YANG.
• Implement network automation with NETCONF.
• Automate the process using Python.

Deliverable/Rubric:

• Which changes did your team choose to implement in the running-config?
• Why were these features chosen?
• Document your team member roles, knowledge and skills sets, if anything has changed in relation to this new Project Activity.
• Provide a brief description of your team strategy for completing this project, if anything has changed in relation to this new Project Activity.

Final Deliverables

At this point, your project has been completed. Your team will present to your manager:

• Presentation
• Team activities and reflection

Presentation

Deliverable/Rubric: Create a presentation. Your presentation should include:

• Application code
• Describe the YANG Model chosen
• Provide example output of running code showing:
  • running-config before changes
  • running-config after changes
  • Message sent to WebEx Teams
• Reflection points – what issues have you faced while working on this activity, how did you find solutions, what have you learned, etc.

Team Activities and Reflection

Deliverable/Rubric: Your manager is interested in knowing how everyone worked together as a team. Here is a list of questions from your manager:

• What did you enjoy about working as a team? What worked well?
• What team problems did you encounter and how did you resolve them?
• What technical problems did you encounter and how did you resolve them?
• How was each team member held accountable individually and for the team as a whole?
• What was your team's decision-making process?
• Overall, how were the team dynamics and what were any lessons learned?

Cisco Security Platforms

Introduction

It's natural for a networking company like Cisco to think about risks within the network and risks related to traffic running on a network. If you think about how much information a system needs to ingest in order to monitor and watch for problems, you soon realize that one person alone, or even a security team full of capable people, cannot use manual processes all the time to secure a network or secure an application. You need automated ways to identify threats and mitigate risks, as well as ways to configure systems with security in mind.

Scripts can ingest data faster than a human. Scripts can look for problems and identify them much faster than a person. Plus, scripts for configuration are repeatable and do not lead to breaches due to mis-typing within configuration files.

Cisco provides a large portfolio of security technologies and product families which are configurable and manageable via APIs. This topic will focus on:

• Advanced Malware Protection (AMP) for Endpoints
• Cisco Firepower Management Center (FMC)
• Cisco Firepower Threat Defense (FTD)
• Cisco Identity Services Engine (ISE)
• Cisco Threat Grid
• Cisco Umbrella

Cisco Advanced Malware Protection (AMP)

Cisco Advanced Malware Protection (AMP) for Endpoints provides API access to automate security workflows and includes advanced sandboxing capabilities to inspect any file that looks like malware in a safe and isolated way. AMP works with Windows, Mac, Linux, Android, and iOS devices through public or private cloud deployments.

Benefits and purpose

With AMP for Endpoints you can get information about endpoints and pull specific event information, or move endpoints to new groups using REST APIs. The AMP product continuously analyzes file activity across the extended network. With the information provided by the AMP API, you can detect, contain, and remove advanced malware.

Architecture

Advanced Malware Protection has a collection of subscription-based products. You manage them with a centralized web-based console, and you deploy AMP on devices including mobile phones, on email servers, or on web servers. With AMP for Endpoints, you install an AMP Connector on each device.

Integrations

AMP integrates across the Cisco security portfolio with multiple deployment options. Two examples of products with AMP integration are Cisco Umbrella and Meraki MX.

Environment and scale

AMP for Endpoints can be used in a university campus setting, within healthcare organizations, for government entities, or industrial and manufacturing environments.

Capabilities

AMP prevents breaches and blocks malware at the point of entry, then detects, contains, and remediates advanced threats that can evade front-line defenses and get to your network.

There are three main categories of capabilities that AMP offers:

• Prevention
• Detection
• Responses and automation

Prevention

AMP protects against identified threats in malware files by preventing breaches. You can use the API to create isolation sessions, preventing network connection of a device for a set duration so you have time to prevent further problems.

AMP uses global threat intelligence and can block file-based or non-file-based malware, IP addresses from a list, or block applications.

Detection

AMP continuously monitors and records all file activity to detect malware. It ensures visibility into endpoint file activity and incoming threats, as well as reporting which endpoints have been compromised.

AMP Cloud offers lookups, a signature engine, and a machine learning engine for a constantly updated intelligence database so that detection can happen on-disk. The AMP Cloud is the service you query with the AMP API.

TETRA is an antivirus engine delivered as part of the AMP Connector for Windows, and ClamAV is a similar engine for macOS and Linux.

The figure shows an arrow going from the left shorter side pointing to the right longer side with the words time to detection underneath. There are three main sections: in memory, on disk, and post - infection. Each arrow has textboxes under the heading. In memory has 2 textboxes: exploit prevention and system process protection. On disk has 4 textboxes: a m p cloud, malicious activity protection, tetra, and custom detections. Post - infection has four textboxes: cognitive threat analytics, device flow correlation, cloud i o c's, and endpoint i o c's

Cisco AMP Detection

Using the AMP API, you can look for computers or devices that have associations with a particular event or activity using query parameters. For example, if you know of malware with a particular URL or .exe file, you can see which computers have come into contact with it.

The events resources in the AMP API v1 provide 95 different types of events, from scans to installations to specific application actions, that you can use to filter results from events happening in your monitored environment.

Responses and automation

Accelerate investigations and automatically remediate malware across PCs, Macs, Linux, servers, and mobile devices (Android and iOS). Provides advanced sandboxing so you can inspect malware. In this context, sandboxing lets you activate unknown files in a safe, isolated environment. The sandbox then records the actions and reports them. These activities are also stored for later reference.

The AMP API enables you to request isolation of an identified computer or device. Isolating a computer or device blocks all network traffic except for communication to the AMP Cloud and any other IP addresses configured in your IP isolation allow list. An unlock code that you can provide with the API call enables management of the isolation session.

Read the documentation to learn all the details of the API.

API authentication

You can either use an API client ID with an API key for authentication, or use Basic HTTP authentication with a Base 64-encoded string that combines your API client ID with the API key.

API rate limits

Three X- headers provide information about rate limiting with the AMP for Endpoints API:

• X-Rate-Limit-Limit - Number of total allowed requests in the current period.
• X-Rate-Limit-Remaining - Number of requests left before reaching the limit.
• X-Rate-Limit-Reset - Number of seconds before the limit is reset.

As an example response, you would see:

x-ratelimit-limit: 3000
x-ratelimit-reset: 3588
x-ratelimit-remaining: 2980

API pagination

The AMP API uses Links to get to locations within the response, such as self, next, and last. You can also use an offset parameter to get the next number of results based on the offset value. As an example:

{
  "offset": 250
}

Sending the offset value in the body of the request provides the next set of 250 values.

Cisco Firepower Products

Firepower Management Center (FMC) is a central management console for the Firepower Threat Defense (FTD) Next-Generation Firewall. This console can configure all aspects of your FTD including key features like access control rules (traffic filtering) and policy object configuration, such as network objects. FMC provides a central configuration database enabling efficient sharing of objects and policies between devices. It provides a REST API to configure a subset of its functionality.

With Firepower Management Center, you manage devices on your network so that your network traffic is filtered and controlled based on various characteristics. You can also perform access control on network devices, using the network appliance with a central console and database.

The figure shows your application on the left and a line with arrows at both ends labeled rest a p i going to the fire power management center (f m c). A line connects from the f m c to icons representing fire power (f p) devices and another line going to fire power threat defense (f t d) devices

Cisco Firepower Management Center (FMC) and Firepower Threat Defense (FTD)

Another management option is to directly configure the Firepower Threat Defense device through its on-device REST API, which provides for similar API capabilities to the FMC API. The FMC API and FTD APIs cannot directly co-exist. You must choose one of the following management options:

• Firepower Device Manager(FDM)/FTD-API/CDO – These three options can co-exist.
• Firepower Management Center (FMC) – For advanced scenarios, FMC provides for the most product functionality through its graphical user interface. API capabilities between the two are similar.

Benefits and purpose

These products help programmatically manage firewalls, which provide rules to stop network traffic, redirect it, or choose which traffic can go through, enabling you to comply with security policies and protect your network.

Firepower takes the following actions for traffic control:

• Inspect, log, and take action on network traffic.
• Use security intelligence data to filter traffic. You can create lists of blocked and allowed IP addresses or address blocks, domain names, or URLs.
• Control which websites are available to users on your network.
• Block or filter certain files based on lists containing data about the files.
• Rate limit network traffic based on access control.
• Create protective measures to redirect traffic to a "sinkhole server", where the firewall can fake a DNS query response for a known malicious domain. For example, when a user tries to access a known bad site, the sinkhole configuration resolves to an IP address that you define. You can display information to the end-user trying to access the bad domain.

Protection

Firepower Threat Defense configuration with Firepower Device Manager also provides protective services listed here:

• Track, backup, and protect CA Certificates.
• Manage, backup, encrypt, and protect private keys.
• Internet Key Exchange (IKE) key management, which helps with site-to-site IPsec VPN.
• Provide Access Control Lists to select traffic for services. You can configure two types of ACL:
  • Extended - (IPv4 and IPv6) Identifies traffic based on source and destination address and ports. Supports IPv4 and IPv6 addresses, which you can mix in a given rule.
  • Standard - (IPv4 only) Identifies traffic based on destination address only.

Architecture

Firepower Management Center can run on VMware vSphere or Amazon Web Services (AWS). It can also run on a range of physical devices, including the Cisco FMC 1000, 1600, 2000, 2500, 2600, 4000, 4500, and 4600.

These management tools are purpose-built for customers to manage and configure their Firepower Threat Defense devices. Firepower management tools run on VMware vSphere or Amazon Web Services (AWS) and include:

• Firepower Management Center (FMC) – This is a multi-device manager for large Enterprise deployments with the need for deep correlation and analytics capabilities.
• Firepower Device Manager (FDM) - This is a "single" device manager for small and medium customers with small number of devices with simple dashboards and easy to use configuration wizards. It contains the FDM and Next Generation Firewall APIs.

These can be used to manage appliances and devices including those in the Cisco Firepower 1000, 2100, 4100, and 9300 series (which run Cisco Firepower Threat Defense and can alternatively support Cisco Adaptive Security) and the Cisco ASA 5500-FTD-X series appliances for SOHO and edge-network defense.

Integrations

Firepower Management Center (and Device Manager, though currently with a limited feature set) can integrate with Cisco Identity Services Engine (ISE). The integration of ISE with FMC lets you move particular users in or out of quarantine after they start a VPN session, blocking access to a particular IP as needed.

Other products, such as Threat Grid and Umbrella, can integrate with Firepower Threat Defense devices. For example, Umbrella can identify malicious domains and use Firepower Threat Defense to block those domains (or mark them as safe).

Environment and scale

FMC is intended for larger environments where automatic deployment and automated actions are crucial for efficiency gains and configuration accuracy.

Within Firepower Threat Defense, the Firepower Device Manager (FDM) and Next Generation Firewall APIs help small and medium-sized businesses so that they do not have to hire security experts.

You can try the Firepower Management Center REST API explorer on the device itself, at the following URL: https://<management_center_IP_or_name>:<https_port>/api/api-explorer. The Firepower Threat Defense REST API also has an API "Try it out" capability hosted on the FTD device. You can use the DevNet Sandbox if you want to try the API Explorer on FMC or FTD.

Capabilities

The APIs include Firepower Management Center REST API and Firepower Threat Defense REST API.

• Firepower Management Center API - Gives access to network and endpoint security event data and host information.
• Firepower Threat Defense API - Used to update configuration settings on the device. You deploy those changed configuration settings using a POST call. Refer to the documentation for details about deployment using the REST API.

API authentication

For the Firepower Management Center API, you use an access token to authenticate to the REST API. The token lasts for 30 minutes before the client must refresh it. To make the call, you use the header X-auth-access-token:<authentication token value>. To refresh the token, request another token from the API and then send both the token value X-header and X-auth-refresh-token:<refresh token value> with the next call.

For the Firepower Threat Defense REST API, OAuth 2.0 workflows authenticate calls from API clients. OAuth is an access token-based method, and you can read about the framework in RFC7519. JSON web tokens (JWT), from RFC7519, are used for the schema. You provide a username and password, then receive a normal token. Then, you can define additional custom tokens (sensibly named to facilitate management). The token goes in the Authorization: Bearer header of requests. Tokens can also be revoked using the API.

API limits

To limit network load, the FMC API accepts a maximum of 120 messages per minute from an individual IP address. In addition to this rate limiting, there is payload limiting where the API cannot accept a payload larger than 20480 bytes.

With the Firepower Threat Defense API, you can send a limit value as a parameter for your request to bring back a limited number of responses. By default, the API's upper limit value is 1000.

Cisco Identity Services Engine (ISE)

The Cisco Identity Services Engine, or ISE, can be pronounced as "ice" and is an integral part of the Cisco security portfolio.

Benefits and purpose

ISE provides a rule-based engine for enabling policy-based network access to users and devices. It enables you to enforce compliance and streamline user network access operations. With the ISE APIs, you can automate threat containment when a threat is detected. It integrates with existing identity deployments.

In the center is a circle labeled cisco i s e with the words consistent secure access policy. From the circle is a line pointing to a network cloud and from the network cloud back to i s e. Under the network cloud are who, what, where, when, and how icons. There is also an icon labeled context data with an arrow going to i s e and an arrow going from i s e

Cisco ISE Overview

Architecture

Cisco ISE architecture consists of nodes with defined node types. A node is an individual physical, or virtual, Cisco ISE appliance. These Cisco ISE nodes can assume any of the following node types: Administration, Policy Service, Monitoring, or pxGrid:

• Administration node - In this node you perform all administrative operations on Cisco ISE. It handles all system-related configurations such as authentication, authorization, and accounting.
• Policy Service node - A Cisco ISE node with the Policy Service persona provides network access, posture, guest access, client provisioning, and profiling services. The policy information point represents the point at which external information is communicated to the Policy Service persona. For example, external information could be a Lightweight Directory Access Protocol (LDAP) attribute.
• Monitoring node - A Cisco ISE node with the Monitoring persona is the log collector. It stores log messages from all the Administration and Policy Service nodes in a network.
• pxGrid node - The pxGrid framework integration enables the system to exchange policy and configuration data between nodes. This is how the system can share tags and policy objects between Cisco ISE and third party vendors.

The remaining pieces of the ISE architecture are the network resources and endpoints, or devices connecting to the network.

You can configure node deployments for high availability, load balancing, and automatic failover, depending on the size of the deployment.

There is also the option to have a standalone deployment. In this architecture, one ISE node runs the Administration, Policy Service, and Monitoring personas.

Integrations

In order to get the most out of the platform, there are multiple integrations available for Cisco ISE. Some are for information and data sharing, remediation, and certificate revocation. It also integrates with identity systems for identity management including role-based access control (RBAC), Okta/SAML Single-Sign On (SSO), Lightweight Directory Access Protocol (LDAP), Active Directory (AD).

Environment and scale

Cisco ISE is used in various sized environments, from small to medium and large businesses. At the largest scale, it provides support for 250,000 active, concurrent endpoints, and up to 1,000,000 registered devices.

Capabilities and use cases

You can read about more than twenty use cases on the Cisco Case Studies page for ISE. ISE's capabilities can be summarized as follows:

• Asset visibility - Bring your own devices with both guest and secure wireless access for employees. Use the ISE posture assessment functionality to allow personal mobile devices onto the network, such as at a hospital or retail location.
• Policy compliance - ISE and enforced consistent security policy integrate with Cisco TrustSec for software-defined segmentation across the network.
• Secure wired access - Cisco ISE identifies every single device and user accessing the network, whether wired, wirelessly, or remotely. After they are identified, the connecting device and user are then automatically and securely placed into the right part of the network. This segmentation offers efficiency gains as you can use one network for two separate organizations. It enables secure wired access while also giving asset visibility.
• Segmentation - For example, at a large sports event you need to enable attendee device networks as well as media output for high-definition video being broadcast to the world. The integrated system automatically segments traffic away from the rest of the network using Cisco ISE.

Cisco Threat Grid

Threat Grid is a malware analysis platform that combines static and dynamic malware analysis with threat intelligence from global sources. You can add a Threat Grid appliance to your network, or use the Threat Grid service in the cloud. It can also be integrated into other security technologies such as Advanced Malware Protection (AMP).

Benefits and purpose

With Threat Grid you can review and analyze potential threats or behavior indicators of malware activity.

A Threat Grid appliance delivers on-premises malware analysis with threat analytics and content. Organizations with compliance and policy restrictions can analyze malware locally by submitting samples to the appliance.

The user interface and API workflows are designed for Security Operations Center (SOC) analysts, malware analysts, security specialists, and forensic investigators.

To the left are file icons with an arrow pointing to a cloud that has gears, machines, and 1s and 0s with words: an automated engine observes, deconstructs, and analyzes using multiple techniques. An arrow goes from the cloud to a paper that has an analysis report and behavioral indicators sections

Cisco Threat Grid Overview

Integrations

Threat Grid is also available through integrations with other Cisco Security products, such as Advanced Malware Protection, next-generation firewalls, and Cisco ASA with FirePOWER Services. You can integrate Threat Grid with Threat Response for no additional cost as a threat hunting tool.

Environment and scale

The content subscription license has the capacity to sample and analyze between 500 and 10,000 samples per day.

Capabilities

Threat Grid offers malware analysis capabilities, both static and dynamic.

• Static analysis provides identifying information about the file, file headers, and its contents.
• Dynamic analysis actually executes the malware in a safe, specialized virtual environment called a "glovebox". This enables you to interact with the malware without harming your production system, and helps you discover file modifications, process calls, network activity or connections.

You can use the Threat Grid intelligence feed to build actions based on the analyses.

When you submit intelligence samples to Threat Grid, you can extract relevant data for use with other platforms like Firepower or AMP endpoints.

Organizations can use the Threat Grid API to build their own front ends, dashboards, or workflows.

Read more details in the Threat Grid online API documentation, which you can access with a Cisco Security account.

Cisco Umbrella

Umbrella uses Domain Name Servers (DNS) to enforce security on the network. You configure your DNS to direct traffic to Umbrella, and Umbrella applies security settings on their global domain name list based on your organization's policies.

An arc is shown labeled umbrella. Within the arc are 3 main boxes. The box on the left is labeled network and endpoint on top and h q on the bottom. Within the box are n g f w net flow proxy and sandbox. The second box has network and endpoint words up top and branch at the bottom. Within the box is router / u t m. The last box has endpoint at the top and roaming at the bottom. Each box connects to a box labeled first line that is on the umbrella arc. Lines extend to a cloud: malware c 2 callbacks phishing

Cisco Umbrella Overview

Benefits and purpose

Umbrella blocks access to malicious domains, URLs, IPs, and files. The system looks at the nature of any DNS requests and takes an action based on its threat intelligence, which is a large-scale repository of historical data about threats. In turn, Umbrella is building models that classify requests so that you build on its threat intelligence. These requests can be safe and allowed, malicious and blocked, or deemed "risky" and sent to a proxy for deeper inspection.

Umbrella threat intelligence data includes a Cisco Talos feed. Cisco Talos is a team of researchers, analysts, and engineers, who create accurate and actionable threat data and keep it updated for Cisco products to use. The Talos feed includes information about malicious domains and IPs, plus DNS data, which contains 120 billion requests per day.

Architecture

APIs and data-driven architecture provide the base of the Umbrella service. There are a few APIs to use with Cisco Umbrella:

• The Enforcement API integrates security events with Umbrella.
• The Network Devices API integrates hardware devices with Umbrella.
• The Investigate API gives you data to find more about security incidents.
• The Reporting API enables organizations to run several reports.

To learn more about each API, refer to https://docs.umbrella.com/developer.

Integrations

To use Umbrella, you will add hardware devices for management by Umbrella security. There are also API integration points with threat protection and enforcement use cases. You can integrate Meraki MR and Umbrella for wireless protection use cases.

Developers and security experts use the Umbrella Enforcement API to take actions on a domain request, or use the Umbrella Investigate API to pull threat intelligence data programmatically. The Enforcement API and its scoring is described in more detail in the Capabilities section.

Environment and scale

Umbrella is used in larger retailers, large hospital settings, and university campuses. Umbrella can protect hundreds, thousands, or tens of thousands of endpoints.

Capabilities

Umbrella's protection capabilities include:

• Wi-Fi protection when guests are on your network
• Selected application blocking
• Endpoint security for off-network (not on VPN) devices
• Web filtering

Guest Wi-Fi protection

When providing guests with Wi-Fi, you must address security concerns but also legal liability protection. You also want to ensure your network cannot be infiltrated, which might enable identity theft or unwanted information access.

Application discovery and blocking

Umbrella lets you see what is being accessed, order the applications by risk elements, and then block as needed with an included automated blocking workflow. You can also have custom block lists you set up with the Umbrella user interface.

Cisco Umbrella Custom Block List

Use preset application-level reports to study a list of pre-categorized apps: Unreviewed, Under Audit, Approved, and Not Approved.

Off-network endpoint security

Umbrella can stop breaches from traffic from mobile devices not on VPN, or other endpoints not always using the VPN. It provides roaming protection for Windows, MacOS, and iOS devices outside the network security perimeter.

Web filtering and content filters

With Umbrella, you can filter content and also enable specific teams to access named sites as needed for their job role.

The Enforcement API helps create and maintain custom blocked and allowed lists. It goes through several decision points that work to update those custom lists.

• Is the domain already present on an allow list within the organization? If so, the allow list overrules any custom or Umbrella-owned block list. This override means that while a domain may be on the custom block list, no enforcement will be taken.
• Does the domain already exist in the Umbrella Security global block list under one of the security categories? Even if the domain does exist in the Umbrella global block list, it is still added to the customer’s block list. You can check the status of a domain by submitting it to the Cisco Umbrella Investigate API or use the Umbrella Investigate Dashboard. If a score a score of -1 is returned, the domain is considered malicious.
• Is the domain considered benign, or safe, under Umbrella Investigate? A domain is considered safe when a score of +1 is returned from the Investigate API. Domains that are considered safe are not added to the block list. This is a fail-safe mechanism to prevent safe domains such as https://cisco.com from being blocked. Sometimes malware files contain clean domains being used to check for internet connectivity, which can trigger a false malicious positive by a Security Information and Event Management (SIEM) solution. Domains that are typically safe include ones that the Cisco security labs team has marked as safe or any domain found in the Alexa Top 1000.
• Is the status of the domain uncategorized? A domain is considered uncategorized when the Umbrella Investigate API returns a score of 0. If a domain is uncategorized, it is added to the Umbrella customer’s block list.

Cisco Platforms and Development Summary

What Did I Learn in this Module?

Understanding the Cisco API Platform

To help with sorting through all of the Cisco developer offerings, DevNet creates Dev Centers for each technology group, and those Dev Centers are a convenient way of grouping technologies together. Cisco Dev Centers include: Unified Communications Manager, Cloud, Collaboration, Data center, Internet of Things(IoT) and edge computing, Networking, Security, Wireless and mobile, and Application developers.

Cisco SDKs

SDK stands for Software Development Kit. Typically an SDK contains a set of software development tools integrated for developing applications for a specific device or system. An SDK can provide simpler authentication methods as well as enabling token refreshes as part of the package. SDKs often help with pagination or rate limiting constraints on responses for a particular API. Cisco provides a wide range of SDKs on different Cisco platforms.

Understanding Network Programmability and Device Models

Model-driven programmability inherits the power of models, matching devices' abilities and services to standardized models, making it easier to configure network devices. A data model is a structured method to describe any object. For example, the personal data on a passport or driver's license can describe a person in an individual way, so those are both "data models". YANG, an acronym for Yet Another Next Generation is "a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications." There are two types of YANG models, open and native. Network Configuration (NETCONF) is a protocol designed to install, manipulate, and delete the configuration of network devices. It is the primary protocol used with YANG data models today. The NETCONF protocol provides a small set of operations to manage device configurations and retrieve device state information. The base protocol provides operations to retrieve, configure, copy, and delete configuration data stores. RESTCONF uses the datastore models and command verbs defined in the Network Configuration Protocol (NETCONF), encapsulated in HTTP messages. RESTCONF is not intended to replace NETCONF, but rather to provide an HTTP interface that follows the REST principles and is compatible with the NETCONF datastore model.

Cisco Network Management

Network automation is used for various common tasks in an organization: Device provisioning, Device software management, Compliance checks, Reporting, Troubleshooting, and Data collection and telemetry. IOS stands for "Internetwork Operating System." IOS was the original operating system for Cisco Systems routers and Cisco network switches. IOS XE is the next-generation programmable platform. In IOS XE the control plane and the data plane are separated. The control plane "controls" the network, meaning it stores the routes, mapping, generally all the "signals" that are needed to run the router or switch. The data plane contains the actual client, user, or application data that needs to go along the network from one device to another.

A Cisco DNA Center is a foundational controller and analytics platform for large and midsize organizations and is at the heart of a Cisco IBN. It provides a single dashboard for network management, network automation, network assurance, monitoring, analytics, and security. Cisco DNA Center provides both a web-based GUI dashboard and the RESTful Intent API used to programmatically access its services and functions. All Intent API methods respond with a JSON-structured content payload. Intent API PUT and POST methods require a JSON request payload. Both POST and PUT requests are handled within the Cisco DNA Center asynchronously.

The Cisco ACI platform is the Cisco solution for SDN. The centralized management system is the APIC, a cluster of controllers. The ACI/MSO modules permit the simple creation of playbook elements to perform inquiry, administration, and management tasks upon an ACI fabric. To simplify application development with ACI, Cisco has developed Cobra, a robust Python library for the APIC REST API. Objects in the Cobra library (SDK) map 1:1 to the objects within the Cisco ACI MIT. Cisco Meraki is a suite of cloud-managed network solutions that enables a single source of management for infrastructure, locations, and devices.

The Meraki cloud uses the physical location of access points to estimate the location of a client. NX-OS is a data center operating system for the Nexus switch. With the Nexus switches running the NX-OS, you can automatically provision Cisco switches in the data center and orchestrate changes much the same way you configure a Linux server.

NSO enables operators to adopt the service configuration solution dynamically, according to changes in the offered service portfolio. It delivers the SDN vision by providing a logically centralized interface to the multi-vendor network. NSO has three components: Model-driven programmable interface (YANG models), Configuration database, and Device and service abstraction layers. An NSO service is a function provided by network devices. Creating, modifying, or deleting the service manipulates the actual configuration of the end devices. Service transactions performed complete logical operations meeting ACID (Atomic, Consistent DB, Isolated, and Durable) transaction properties.

SD-WAN supports third-party API integration, allowing for simplicity, customization, and automation in day-to-day operations. Cisco SD-WAN includes the common routing protocols used for all enterprise SD-WAN deployments, such as BGP, OSPF, VRRP, and IPv6.

Cisco Compute Management

The Cisco Unified Computing System (UCS), along with its software and SaaS adjuncts, provides a complete physical and logical plant for compute, networking, and storage in the modern datacenter.

Cisco UCS Manager runs on the primary fabric interconnect and is assigned a virtual IP address (VIP), with failover capability to the subordinate fabric interconnect. The Cisco UCS Manager management requests from the GUI or CLI are encoded in XML. All XML requests to Cisco UCS are asynchronous and terminate on the active Cisco UCS Manager. Cisco UCS Manager mediates all communication within the system; no direct user access to the Cisco UCS components is required.

Cisco UCS Manager servers are either blades that reside in chassis (B-Series Servers) or rack-mounted (C-Series servers). Both are connected to a redundant pair of switches are called UCS Fabric Interconnects (FIs).

Cisco UCS Managed Objects are XML representations of a physical and logical entities in the UCS system. Cisco UCS API documentation is typically referred to as the UCS Object Model documentation. The Object Model documentation is available with the UCS Platform Emulator or online. Every UCS object class and method is listed in the documentation along with UCS types, events, faults, errors, and Syslog messages.

UCS PowerTool is a library of PowerShell Cmdlets that enable the management of UCS environments from Microsoft Operating Systems, via the UCS XML API.

Cisco UCS Director extends the unification of computing and networking layers through Cisco UCS to provide visibility and management of data center infrastructure components. You can use Cisco UCS Director to configure, administer, and monitor supported Cisco and non-Cisco components. When you enable the developer menu, Cisco UCS Director GUI provides a developer menu option for developers to access the report metadata and REST API Browser.

Cisco Intersight is a Software as a Service (SaaS) systems management platform capable of managing infrastructure at the edge and remote locations as well as in the data center. When using the service, you can scale infrastructure up or down as needs increase or decrease. Because it provides a REST API to access the MIM, you can manage the infrastructure as code. The Intersight API is consistently available with a cloud-based management model.

Cisco Collaboration Platforms

Cisco's suite of on-premise and cloud-based collaboration solutions includes Unified Communications Manager, Contact Center, Finesse, and Webex. Cisco Unified Communications Manager is also known as Unified CM, CUCM or CallManager. The primary function of Unified CM is to manage phone users, IP phones, directory numbers, and to connect and manage calls to the desired destinations.

AXL is an XML/SOAP-based interface that provides a mechanism for inserting, retrieving, updating, and removing data from the Unified Communication configuration database. The AXL API is for administration and configuration.

UDS is a REST-based API that provides a mechanism for inserting, retrieving, updating and removing data from the Unified Communication configuration database. The UDS API is designed for end users to configure settings.

Finesse is Cisco's browser-based contact center agent and supervisor desktop. Finesse has REST APIs and JavaScript APIs that can be used to build fully custom agent desktops, integrate contact center functionality into applications, and integrate applications into the Finesse agent and supervisor desktop. This integration can be accomplished in the form of OpenSocial gadgets.

Cisco Webex Teams is an online collaboration solution to connect people and teams through chat, voice, and video. With the Webex Teams app, you gain access to secure virtual work spaces. You also use messaging and file sharing with third-party app integrations. Webex Teams enables you to use a single app to contain content and information for team collaboration. Teams also integrates with Cisco Webex devices. Information remains safe and secure with advanced security and compliance built-in. Cisco Webex Devices provide access to all of Webex's features. Webex Boards, Room Devices, and Desk Devices enable collaboration through video, calling, and programmability.

Cisco Security Platforms

Cisco provides a large portfolio of security technologies and product families which are configurable and manageable via APIs:

• Advanced Malware Protection (AMP) for Endpoints - AMP for Endpoints provides API access to automate security workflows and includes advanced sandboxing capabilities to inspect any file that looks like malware in a safe and isolated way. AMP works with Windows, Mac, Linux, Android, and iOS devices through public or private cloud deployments.
• Cisco Firepower Management Center (FMC) - FMC is a central management console for the Firepower Threat Defense (FTD) Next-Generation Firewall. This console can configure all aspects of your FTD including key features like access control rules and policy object configuration, such as network objects. FMC provides a central configuration database enabling efficient sharing of objects and policies between devices. It provides a REST API to configure a subset of its functionality.
• Cisco Firepower Threat Defense (FTD) - FTD configuration with Firepower Device Manager also provides protective services including track, backup, and protect CA Certificates; manage, backup, encrypt, and protect private keys; IKE key management; and ACLs to select traffic for services.
• Cisco Identity Services Engine (ISE) - ISE provides a rule-based engine for enabling policy-based network access to users and devices. It enables you to enforce compliance and streamline user network access operations. With the ISE APIs, you can automate threat containment when a threat is detected. It integrates with existing identity deployments.
• Cisco Threat Grid - Threat Grid is a malware analysis platform that combines static and dynamic malware analysis with threat intelligence from global sources. You can add a Threat Grid appliance to your network, or use the Threat Grid service in the cloud. It can also be integrated into other security technologies such as AMP.
• Cisco Umbrella - Umbrella uses DNS to enforce security on the network. You configure your DNS to direct traffic to Umbrella, and Umbrella applies security settings on their global domain name list based on your organization's policies.

Packet Tracer – Compare using CLI and an SDN Controller to Manage a Network

In this Packet Tracer activity, you will compare the differences between managing a network from the command line interface (CLI) and using a software-defined networking (SDN) controller to manage the network.

You will complete these objectives:

• Part 1: Explore the Network Topology
• Part 2: Use the CLI to Gather Information
• Part 3: Configure an SDN Controller
• Part 4: Use an SDN Controller to Discover a Topology
• Part 5: Use an SDN Controller to Gather Information
• Part 6: Use an SDN Controller to Configure Network Settings

Packet Tracer – Implement REST APIs with an SDN Controller

In this Packet Tracer activity, you will use the Packet Tracer Network Controller and associated API documentation to send REST requests from Postman and from Visual Studio Code (VS Code). Packet Tracer also supports a Python coding environment. Therefore, in the final Part of this activity, you will send REST requests from within Packet Tracer

You will complete these objectives:

• Part 1: Launch the DEVASC VM
• Part 2: Verify External Connectivity to Packet Tracer
• Part 3: Request an Authentication Token with Postman
• Part 4: Send REST Requests with Postman
• Part 5: Send REST Requests with VS Code
• Part 6: Send REST Requests Inside Packet Tracer

Module 8: Cisco Platforms and Development Quiz

1. What is a characteristic of the Yet Another Next Generation (YANG) data model?

   Topic 8.3.0 - YANG models use a tree structure. Within that structure, the models are similar in format to XML and are constructed in modules. These modules are hierarchical in nature and contain all the different data and types that make up a YANG device model.

   It uses a tree structure.

   It uses a list structure.

   It uses the JSON data format.

   It uses a MIBs structure.

2. Which two application-specific media types can be used for RESTCONF to identify a YANG construct? (Choose two.)

   Topic 8.3.0 - According to RFC 8040 11.3. Media Types, there are two types, application/yang-data+xml and application/yang-data+json. “This document defines media types for XML and JSON serialization of YANG data. Other documents MAY define other media types for different serializations of YANG data.”

   application/yang+json+xml

   application/yang-data+json

   application/yang-data+xml

   application/yang+json

   application/yang+xml

3. What is the name of the Cisco SD-WAN dashboard?

   Topic 8.4.0 - The vManage dashboard provides a visual window into the network to configure and manage SD-WAN network devices.

   vManage

   vBond

   vEdge

   vSmart

4. What is Cisco Finesse?

   Topic 8.6.0 - Cisco Finesse is a contact center agent and supervisor desktop that is browser-based and comes with many APIs.

   a browser-based contact center agent and supervisor desktop

   an application to manage phone users, phones, directory numbers, and to connect and manage calls to the desired destinations

   a network management and analytics platform for Cisco Digital Network Architecture

   an easy-to-use collaboration solution that keeps individuals and teams connected anytime and anywhere

5. Which Software as a Service (SaaS) management platform offers API keys for remote or service access?

   Topic 8.5.0 - Cisco Intersight is a Software as a Service (SaaS) systems management platform capable of managing infrastructure at the edge and remote locations as well as in the data center. There are a couple of ways to gain access to the Intersight API:

   • Web browser as an Intersight API REST Client
   • API keys for remote or service access

   A developer can create API keys for the Intersight account for remote access through SDKs or other programming environments.

   Management Information Tree

   YANG Explorer

   APIC

   Cisco Intersight

6. Which Cisco SDK is primarily a call widget that is embedded in an iframe within another web page for Cisco UCS application?

   Topic 8.2.0 - The Cisco Jabber Guest SDK for Web is primarily a call widget that is embedded in an iframe within another web page. The other piece, which is optional, is a small amount of JavaScript code in the hosting page to handle optional communication between the page and the widget.

   Jabber Web SDK

   Jabber Guest SDK for iOS

   Jabber Guest SDK for Android

   Jabber Guest SDK for Web

7. A developer is using a REST API to develop an application to communicate with a Webex Teams server. What is the default maximum number of items that can be returned by the Webex Teams API prior to using pagination?

   Topic 8.6.0 - The Webex Teams API returns up to 100 items per page by default.

   50

   150

   25

   100

8. 
   
   
   
   

   Refer to the exhibit. A network administrator is developing an application that communicates with Cisco AMP using an AMP API. A response from an AMP service shows the API rate limits information. What is the unit of value indicated under the item x-ratelimit-limit?

   Topic 8.7.0 - Three X- headers provide information about rate limiting with the AMP for Endpoints API:

   • X-Rate-Limit-Limit: Number of total allowed requests in the current period
   • X-Rate-Limit-Remaining: Number of requests left before reaching the limit
   • X-Rate-Limit-Reset: Number of seconds before the limit is reset

   seconds

   responses

   requests

   bytes

9. What is the default TCP port assigned for NETCONF over SSH?

   Topic 8.3.0 - NETCONF uses SSH as a transport. The default NETCONF SSH port is 830.

   1080

   830

   22

   443

10. Where can a corporate developer access the API Explorer with the Firepower Threat Defense API?

    Topic 8.7.0 - A developer can access the Firepower Management Center REST API explorer on the device itself, at the URL ht&#8203;tps://<management_center_IP_or_name>:<https_port>/api/api-explorer. The Firepower Threat Defense REST API also has an API "Try it out" capability hosted on the FTD device.

    on the DevNet web site

    the URL address of the device itself

    the local computer of the developer

    the domain name of the company

Prepare for Your Exam and Launch Your Career!

Certification Preparation and Discount Vouchers

Congratulations! You have completed your Cisco Networking Academy course!

Discount Voucher

A discount voucher for the certification exam is available after you have completed the DEVASC course.

If you scored a 70% or higher on the FIRST attempt of the Final Exam in DEVASC, and have a "Pass" in the gradebook, then you are eligible for a discount voucher for a Cisco certification exam.

When you qualify for a Certification Exam discount (voucher) a link will display on your class tile in NetAcad.com and on your NetAcad.com profile.

• https://www.netacad.com/careers/career-advice/certification-advice
• https://www.netacad.com/portal/faq-page
• https://www.netacad.com/portal/resources/cisco-certifications-and-vouchers

Additional Study Materials for Certification Preparation

Access additional study materials or attend free webinars from Learning@Cisco.

Registration is free. Use your NetAcad login, or if you have already taken a Cisco certification exam, use your cisco.com login. When you are logged in, use the links below for information for your certification.

• https://learningnetwork.cisco.com/s/article/devasc-exam-topics
• https://learningnetwork.cisco.com/s/article/study-material-for-devnet-associate-devasc-200-901-x

Career Resources and Employment Opportunities

Prepare for a career in technology!

You are on your way to a rewarding tech career, but have you wondered what exactly you need to do in order to be ready for the workplace?

We provide valuable career resources to help you prepare to be a part of the workforce and successfully seek out employment. These resources have been created to help you, as a Networking Academy student, succeed in a tech career. If you are looking for career guidance, virtual learning opportunities, and access to an exclusive matching engine to search for jobs – we have just what you need. Bookmark these three links and start growing your potential today:

• https://www.netacad.com/careers/employment-opportunities
• https://www.netacad.com/careers/webinars
• https://www.netacad.com/careers/career-advice

Find and apply for jobs using our Talent Bridge Matching Engine!

Our http://bit.ly/nac2career is Networking Academy’s exclusive job matching tool. The Matching Engine uses your Networking Academy profile data to display relevant positions for which you qualify. Be sure to add certifications, work experience, and geographic location to your profile so employers can find you. Then, apply for jobs that interest you, right from the Matching Engine dashboard.

Even if you are not seeking employment, you can start building your profile and see what employers are looking for in job candidates.

https://www.netacad.com/jobmatching

Build your professional network!

Regardless of where you are in your journey, you should start building your professional network. Start by adding https://www.linkedin.com/school/cisco-networking-academy1/ to your Education section on your LinkedIn profile. You will have access to the latest career advice, job opportunities, as well as be more easily found by employers searching for qualified Networking Academy students to join their team.

Ref : [1]

Modul Exam 8

Why does the Meraki dashboard API return a 404 rather than a 403 code in response to a request with an invalid API key?

• The 403 return code would indicate that there are no resources at that endpoint but the API key could be correct.
• The 403 return code would indicate that the client definitely has an invalid API key.
• The 404 return code prevents the system from indicating the existence of resources to unauthorized users.
• The 404 return code determines whether unauthorized users will try again.
• Which two statements describe the usage of Cisco Finesse JavaScript APIs? (Choose two.)
  • They can be used to build custom gadgets to be placed into applications other than Finesse.
  • They can be used to embed existing web pages into a custom gadget.
  • They can be used to build a custom gadget for the agent state workflow.
  • They can be used to build a fully functioning agent desktop.
  • They can be used to get the call history of an agent.
  • Refer to the exhibit. Which data format is used to describe the list of interfaces?
    • JSON
    • XML
    • YANG
    • YAML
    • Which three functions are provided by Cisco Finesse REST APIs? (Choose three.)
      • They can be used to build custom OpenSocial gadgets.
      • They can be used to build a fully functioning agent desktop.
      • They can be used to get the call history of an agent.
      • They can be used to get termination call detail (TCD) reports.
      • They can be used to integrate into existing applications to add contact center functionality.
      • They can be used to build a script to automate tasks.
      • What are two actions taken by Firepower for traffic control? (Choose two.)
        • directing heavy data traffic to free servers
        • using security intelligence data to filter traffic, including IP addresses, address blocks, domain names, and URLs
        • load balancing during high-traffic time periods
        • shutting down the network in the event of a DDOS attack
        • controlling which websites are available to the users on the network
        • What are two tasks a network administrator can perform with Cisco UCS Director? (Choose two.)
          • Create a direct line of communication between Cisco and non-Cisco components.
          • Load-balance data traffic.
          • Create, clone, and deploy service profiles and templates for all Cisco UCS servers and compute applications.
          • Manage multiple Cisco UCS Manager appliances.
          • Deploy and add capacity to converged infrastructures in a consistent and repeatable manner.
          • Which underlying technology makes it possible for Cisco Umbrella to prevent a user from accessing a blocked site?
            • HTTP and HTTPS
            • DNS
            • DHCP
            • Cisco Firewall
            • What are the three main capabilities provided by Cisco AMP? (Choose three.)
              • annihilation
              • detection
              • relaying
              • prevention
              • responses and automation
              • redirection
              • What does Cisco ISE do when it identifies a user or device accessing the network?
                • It automatically and securely places the device and user into the right part of the network.
                • It processes the originating IP address according to a whitelist.
                • It quarantines the device and user until an administrator releases the quarantine.
                • It logs the access attempt.
                • Which function does the AXL interface provide for users?
                  • provisions Webex Devices and customizes each display
                  • looks up the top ten OWASP vulnerabilities and identifies which endpoints are vulnerable
                  • provisions and manages objects in the Unified Communication Management Administration Console
                  • updates network device configurations with a rollback mechanism
                  • Which language is used by the NETCONF protocol to encode both the configuration data and protocol messages?
                    • JSON
                    • YAML
                    • HTML
                    • XML
                    • How are service profiles used by Cisco UCS Manager?
                      • Cisco UCS Manager saves service profiles to recover servers in case of data loss.
                      • Cisco UCS Manager uses service profiles as templates to provision policies to multiple versions of the same server.
                      • Cisco UCS Manager uses service profiles to assign a unique identity to the server associated with each profile.
                      • Cisco USC Manager uses an assigned service profile to each instance to define network policy.
                      • Which two benefits are provided by the Python-based WebEx Teams SDK? (Choose two.)
                        • It manages requests with pagination.
                        • It provides error reporting.
                        • It provides access to more API calls within Webex Teams.
                        • It integrates with the Webex Devices API.
                        • It is better supported than the Webex Teams APIs.
                        • What are two types of YANG models? (Choose two.)
                          • open model
                          • private model
                          • native model
                          • vendor model
                          • hybrid model
                          • What are three primary YANG sources in Cisco NSO? (Choose three.)
                            • configuration models
                            • NSO data model
                            • YANG service models
                            • mapping model
                            • communication model
                            • data models from devices