In this article we will explore the various methods used for authenticating against Palo Alto's PANOS API which allows administrators to programmatically interface with Palo Alto firewalls and Panorama appliances. The methods discussed cover both the XML and REST API's. There are a few considerations to make when deciding how to configure your appliances to authenticate API requests as well as how to handle API authentication in code.
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:
Discovery which end-points can be used for hardware and software inventory reporting
Determine how to update the IP receive ACL's
Automate transfer and registration of the new NFVIS image files
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.
For a more general overview of the Cisco Support API's refer to
part 1 of this series.
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.