After assessing how big a leap I had taken forward going into ACI, I am reeling it back to NX
When digging into ACI further it became apparent that I had taken a huge leap over some foundations that comes before it like just learning to work with API Configuration on Nexus switches in general, so I am officially taking a step back to Nexus Switching in my CML Lab with an emphasis on API usage.
CML has an absolutely excellent API Documentation page integrated into the dashboard here that I will take a look at in addition to creating Postman libraries for API calls to the CML Nexus switches, which is not something I have learned very in depth so there are some fundamentals to cover here.
I did also add some ASAv appliances to practice a new deployment configuration of ASA’s to get two subnets talking over a VPN, as I generally work with existing configurations that I troubleshoot and fix, I need to knock the rust off my ability to configure things like VPN / NAT / Phase 1 and 2 Configs / Etc.
This article will only focus on setup of a CCNP Data Center lab within CML, using CML API Documentation to create API Calls to then use in Postman, and some niche issues.
I may add to this as I find and resolve more niche issues, but there will be no device configuration of ASA’s or Nexus switches in this post, just the setup process and issues I’ve run into.
A look at CML 2.0 API Documentation, how to use it, and configure CML devices to work with it!
First just to give a peak at a couple of screenshots of how extensive the API documentation is:
And then the specific module I am working with is “GET” for the NXSW1 device:
This library with an embedded script / API Call test with HTTP Response code output is AWESOME!
I will be moving to using Postman for API Calls to get some collections going and really to get comfortable with working in it regularly, but for initial lab setup in CML this is just amazing.
Before diving into that 404 error shown in that last screen snip, wanted to explain some elements:
This was a bit tricky here to figure out as I configured each Node with its “Hostname” configured on the CLI of the devices, as shown in the screensnip below:
Having this as the Node ID in the test API Call powered by the awesome Swagger API Docs in CML Dashboard I thought maybe an API Service was not enabled that needed to be on the Nexus SW1, however when I went to my “Breakout Tool” page to launch a Telnet session to NXSW1:
The odd thing is I cannot find this default Node ID anywhere in the main CML Dashboard that shows all different lab topologies, or in this lab topology in device details anywhere – Only in Breakout Web GUI.
For this reason if you change the Node ID in the Topology for any reason, I highly suggest you make a note of the original Node ID in the notes (shown below) and the new ID if your not using Breakout:
As soon as I switched this value from NXSW1 to n7 in the API Test page I got a 200 response back:
Wanted to document this somewhere for anyone looking at CML 2.0 for labbing DevOps and CCNP Data Center topics as this is an odd “gotcha” that the nodes retain their default node id, and that its not specific to the device but in which order it was added to the topology.
If anyone knows a different way to find existing device default node ID’s, please comment!
I’d be very interested in where this information is located outside of the Breakout Tool, though if you’re using CML I highly advise you check out the Blog below to install Breakout Tool to use Putty here.
Using API Documentation in CML to create Postman collections for labbing!
I’m familiar with Postman from playing inside AWS API Gateway / Lambda and just general DevNet studies, however Postman can also be used to communicate into CML Lab devices that respond to API Calls so you can add that program to the things you are learning to be awesome at working with 🙂
To accomplish this there is a little clipboard button to copy the “Curl” text from the API Doc page:
curl -X GET “https://192.168.160.136/api/v0/labs/9fa8f2/nodes/n7/config” -H “accept: text/plain” -H “Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJjb20uY2lzY28udmlybCIsImlhdCI6MTYxOTE4MDYwMiwiZXhwIjoxNjE5MjY3MDAyLCJzdWIiOiIxMDEifQ.gQbLizFWKNEMT3rdGxxZ6hVRB_-sLagpjevHZHn4fzQ“
If you are labbing Nexus I am assuming you know how to read Curl API requests to pull information shown here, such as the Method (GET), URI, and Header contents / Bearer Token to plug into Postman.
All I needed was the URI and to set “Bearer” Auth with the API Key to get it working:
This of course requires the VM running CML to have either NAT or Bridged configured on the network adapter, and I’m running into some issues trying to run API’s to devices in CML right off the bat, but I’m sure it is just a learning process with some issues to hammer out like any virtual lab environment.
One behavior I found with more than 2 NX-OS Switches in CML, in my Topology NXSW1 and NXSW2 (n7 and n8) would not fetch the running config locally in CML and Postman API GET calls failed as well, however I added a Nexus 9K to the Nexus 7K switches and it has no issues.
I tried to wipe / delete and replace the two switches that would not fetch their config, I am not sure what the issue was (I suspect it may be a smart license issue), but I’ve changed Topologies to move on:
Postman is verified working to the current Nexus switches so that will work for labbing concepts, and will give me some devices to setup Postman collections of API calls to work with on configuration, so that is coming down the pipe soon.
I’ll end this post here as I have some setup to get through to begin really labbing in the near future!
I was hoping to make this more of a comprehensive CML / Postman lab setup for Data Center switch labbing (or how I’ll be labbing Nexus concepts), however its kind of gone off the rails of lab setup into documenting issues I am running into, so I will get this fixed and will be trying to review both ASA Refresher material (Concepts and configuration of VPN / NAT / ACLs) or more Nexus.
Until next time!!!
The DEVNET GRIND! 