I’ve been supporting datacenter network automation and programmability from within DevNet for a while now, and have received lots of thanks and appreciation for the wealth of information DevNet offers around ACI programmability. However I’m often asked, “when will we have something for customers who chose to use Nexus switches in NXOS mode and Datacenter Network Manager (DCNM) as a controller?” To be honest, I’ve had to dodge the question a bit. Not because I didn’t think that it was important, but there was a lot of work that had to be done before labs could be released.  Now, I can confidently face the question of “wen DCNM?” Because now the answer is “now.”

DCNM sandbox

Towards the end of last year, we introduced a DCNM sandbox within the DevNet Sandbox ecosystem.  This sandbox includes a fully functional instance of DCNM 11.5(1), along with a (6) node N9Kv topology (and a single CSR1000v acting as an “external network”) backed by CML.  Much of the base configuration within this topology was preconfigured, including fabric names and attributes. This allows developers to focus on the outcome of their API calls, Ansible playbooks, or Terraform plans – rather than the humdrum of building a fabric from scratch with each sandbox reservation.

DCNM sandbox

New Learning Labs

The sandbox, however, isn’t enough. We need learning labs to explain the functions of DCNM, how to use the APIs within it, and how to leverage tools (like Ansible and Terraform) to perform common tasks using DCNM as a centralized controller. Much like the sandbox, a lot of work had to be done to ensure that the learning lab modules and provider behaved the way that we expected. After many hours spent working through issues (and the PRs to go with them) everything aligned to start working through the labs themselves. I think you’ll find they are worth the wait. The entire set of labs is contained within a Introduction to DCNM Programmability learning track. There you’ll find three modules covering three different technologies:

  • Introduction to DCNM Programmability
  • Introduction to Ansible with DCNM
  • Introduction to Terraform with DCNM

Introduction to DCNM Programmability

DCNM learning lab 1

The Introduction to DCNM Programmability module focuses on the basics of DCNM and how the platform operates.  It familiarizes the user with the two-stage commit process, how to navigate the web UI to verify that the automation worked, and then introduces the API tooling within DCNM. You’ll learn about the API tool (which inspects API calls and their payloads from UI interactions) and interrogating the DCNM API using a pre-built Postman collection hosted within DevNet’s public workspace.  For those just becoming familiar with the platform, this module is valuable in your learning journey.

Introduction to Ansible with DCNM

DCNM learning lab 2

The Introduction to Ansible with DCNM module expands on the API knowledge you acquired in the first module, by comparing the tasks done manually through raw API calls from Postman (or from UI interactions) and places them in an Ansible playbook using the DCNM modules.  The learning module also walks through debugging and understanding when and why certain errors are thrown during the running of an Ansible playbook. It includes when certain conditions are not met, or timeouts during task runs are set too short for the action to return a successful code.  While not a complete walkthrough of all Ansible actions within DCNM, it serves as a strong starting point to become acquainted with how DCNM and Ansible interact.

Introduction to Terraform with DCNM

DCNM learning lab 3

Finally, the Introduction to Terraform with DCNM module covers the use of Terraform with DCNM.  In much the same fashion, the individual labs align directly with the tasks in the previous modules.  In some instances, Terraform is stretched outside of its intended use-case to interrogate APIs directly using the dcnm_rest resource.  In these instances, it is noted that this is not the ideal usage of Terraform, but that the exercise provides valuable knowledge (e.g., around usage of files as reference payloads).  The learning module concludes with an exercise in how Terraform handles long-lived connections (e.g., adding additional devices to DCNM’s inventory), and what a practitioner should do to ensure these actions are successful.

You’re Not Alone!

In addition to the guided learning track and the prebuilt Postman collection, all code used to complete the learning track is available in a sample code repository within the Cisco DevNet Github organization.  This code can be used either with the learning tracks or separately as part of your own desired learning and exploration path.  Additionally, since the functionality provided by the Ansible modules and Terraform Providers is constantly changing, if there are any changes that need to be made – you can fork the repository and submit a pull request.  What better way to increase your NetDevOps knowledge than following developer workflows to help contribute to upstream source!

I hope that you have as much fun working through this learning track as I had putting it together.  As always, if you have any comments, questions, or have ideas on how we can improve this learning track – please reach out to me.  Please leave me a Comment in the space below, or reach out to me on Twitter. I would love to start a conversation.

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Facebook | YouTube Channel


Quinn Snyder

Senior Technical Advocate

Learning & Certifications