The problem PTM is solving seems so obvious, but are any other vendors supporting PTMd on their switches? After all, it’s Linux, and most switches are running Linux, so what’s holding them back? Unfortunately, it’s still not that simple due to feature delivery, product management and development, internal processes, etc., but if anyone does have information of any vendor planning support for PTMd, I’d love to know. Write it and let me know!
Okay, so how does the Nexus 9000 support PTM?
In theory, it doesn’t. But, there is no reason the concepts of PTM cannot be applied offline by comparing active run time data via LLDP/CDP with a prescriptive topology document that was put together by a network engineer. PTM works by describing the topology in a graph describing language – a text file following the language that ends with the file extension .dot.
While I’m sure it would be possible to develop a dot file for what I did, I chose to use another description language that is already well known (it’s just not a graph, so there is some redundancy built into the file). I chose to implement this in YAML. YAML is becoming more popular these days and I’ve written about it before because it’s the same description language that Ansible uses to define their playbooks.
The Example
While I have usually been integrating this kind of script into Ansible, this time, and for this post, I’m trying to emphasize more on the outcome, but if you end up wondering as you read this post, the short answer is yes, the Python script that I’ve built can easily be ported over to any DevOps automation framework. Okay, back to the example…
The following diagram depicts the current physical setup that I’ll be verifying.
Now that you’ve seen the topology, here is a look at the YAML file that describes this physical topology.
In the following test, the Python script gathers active CDP data from both Nexus 9000 switches using the NX-API and compares it to what is described in the YAML file. The filename is topo.yml.
After a run of the script, here is output. As you can see, all is cabled properly!
Two other scenarios and screen shots to show:
A connection is described in the topo.yml, but is not found in the active CDP tables. A non-existent connection was added to the YAML file to perform this test.
From a comparison perspective, remember PTMd runs locally on the device as a daemon so there is no need for an external script or DevOps tool integration and it’s just “part of Cumulus Linux”….but, even Cumulus recommends deploying the .dot files via a DevOps tool, so there could be really interesting integrations all around for PTM-like functionality going forward. Huge thanks to Cumulus for open sourcing PTM.
We must remember that we don’t necessarily need a feature ON THE BOX too. In fact, it may be more scalable and be better off being off box to support 3rd party and multi-vendor environments in certain situations.
As always, I’d love feedback. Would this be helpful for you? What types of issues have you run into that this may have prevented?
Note: I haven’t posted this code yet to GitHub, but may do that very soon.
Thanks,
Jason
Twitter: @jedelman8