I have been reading up on model-driven programmability using NETCONF and YANG models and found myself playing around with these after a Reddit user was having difficulty updating a Cisco IOS-XE interface description and VLAN. Other than reading about YANG and getting the basic capabilities from my lab router, I hadn’t actually configured anything using NETCONF and YANG models before so this seemed like a good challenge to get me thinking in the right mindset. I suspected that it had to do with the XML namespace the user was referencing, but I had to figure out a way to prove it. In this post I will cover a little bit about NETCONF/YANG as well as how you can explore using it with your Cisco devices. This guide isn’t meant to be a complete overview of these protocols, just something to get you started on learning about them.
I have been exploring the Cisco DNA Center REST API as part of studying for the Cisco Certified DevNet Associate certification exam. Today while reading through the official certification guide it talked about how authorization into the API required that your credentials be passed as a base64 encoded string, but it didn’t indicate how to accomplish this.
With multiple Cisco NFVIS software upgrades planned in the near future I thought I would explore the API to see how this might help speed up the process. My initial goals for exploring the API were to:
The move away from decentralized management of network devices has been a huge time saver when it comes to gathering data on these technologies. Although there is no single centralized manager or controller which manages all networking technologies, instead of querying each individual network device you have centralized managers for particular networking functions. Cisco DNAC for your wireless and switch infrastructure, Panorama, Cisco FirePower Management Center (FMC) or FortiManager for your firewall infrastructure, and in the case of this article Viptela’s vManage for your SD-WAN overlay. While no centralized manager will be perfect, for many common bulk tasks it will save you quite a bit of time because of the API’s that they expose to their administrators.
The increasing complexity of network infrastructure devices has drastically changed what is required to perform a thorough health check to ensure it is operating correctly and efficiently. Take for example SD-WAN; what used to be a relatively simple health check on a router now requires deeper knowledge of the specific traffic traversing the device. In the past a few checks of system health (CPU, memory, hardware status, interface status and errors, routing changes) has now evolved to also include app-routing and application aware functions (app routes, SLA’s, BFD, NetFlow, QoS, among many others). Health checks on a site router can now consume valuable time in driving the incident to resolution. Then take into account all of the devices in a network path between a source and destination, of which many of these devices now include rapidly evolving network technologies, and it becomes a painful battle to beat the clock as your business is being impacted by a critical incident.
The Cisco Support API’s provide some very useful end-points that enable you to gain efficiencies on managing your Cisco hardware and software inventory. In this post I present the use of the End of Life (EoX) API that allows you to identify end-of-life equipment within your environment. The code snippets below will be written in in Python and closely follows my Cisco Support API Query Repo on GitHub. Feel free to clone the repo, I intend to include more API end-points in the near future.
Managing your network infrastructure hardware, software and maintenance lifecycle workflow tends to be a painful process. It means gathering large amounts of telemetry from your network devices, transforming that data into a format (excel, csv, etc) that you can use to compare, update, and track and then determine the actions you need to take. A year later you get to wash-rinse-repeate the whole process over again. If you are fortunate enough to have a configuration management database (CMDB), this becomes easier, but often these applications require some level of manual effort to keep up-to-date. They can also cost you financially, sometimes more than you are willing or able to pay.
Welcome to my site! I’m looking forward to sharing all sorts of exciting posts on networking technologies and automation. I have a particular interest in SD-WAN, security, and automation with python.