Earlier this week Cisco announced in its semiannual Cisco IOS and IOS XE bundled software security advisory publication some very concerning security advisories (3 critical, 11 high and 11 medium severity), one of which allows an attacker to bypass authentication on devices configured for netconf or restconf. After an attacker has bypassed authentication, they can install, manipulate, or delete your Cisco IOS XE devices configuration or cause a memory corruption that results in a denial of service (DoS) condition.
Ansible can be a very powerful automation tool, allowing you to interact with hundreds or thousands of network devices at once. The automation is defined through a combination of inventory files, variable files, and playbooks (with optional task files and roles). The combination of these features makes a very powerful automation tool, but with that comes a high-level of risk. In this guide I highlight a few best practices to follow when executing Ansible playbooks. By following these best practices you will have increased confidence that you are implementing the correct tasks against the correct set of devices, and avoid any surprises!
The pandemic has rapidly advanced the need for high-quality and secure remote access VPN solutions (RAVPN). As a result, many RAVPN solutions provided by vendors have been targetted by hackers. This has resulted in newly identified vulnerabilities and security advisories being released by the vendors. One area of concern is around user credential management and multi-factor authentication (MFA). The configuration examples, provided by Cisco and authentication providers, for configuring SAML and Cisco AnyConnect fail to highlight how to configure multiple group-policies so that you can restrict access appropriately for each business unit and vendor. Instead, they highlight have to apply a single group-policy to cover all of your remote access users. I’ve written a blog post for my employer Optanix that provides a production-grade example of how to deploy SAML for Cisco AnyConnect, using multiple group-policies and LDAP attribute maps for fine-grained access control.
The need to query network devices for information on a repeated and consistent basis always been a critical function of performing network management. Monitoring the health of your network devices, building reports for use by management, querying the status of a particular function, and so on. There are an increasing number of ways to perform this type of data gathering. From the extremes of manually logging in to run a CLI command or check a web GUI, to using the latest API or Netconf, network engineers have their choice of protocol to use. However, nothing is as common and widely deployed as Simple Network Management Protocol (SNMP). Most network monitoring platforms will rely on using SNMP, especially if a particular network platform is a decentralized platform like common routers and switches, requiring each network device to be queried individually instead of through a centralized controller.
With the various methods for performing network automation, one of the challenging aspects to consider is inventory management. One of the tools available to us is Ansible which expects an inventory file in YAML format with specific variable or to use a dynamic inventory. But Ansible doesn’t solve all automation use-cases. I have used Ansible for configuration management, but I have also used many different Python scripts for generating reports and performing complex operations that seemed easier to implement directly in Python than in Ansible. There is no ‘one size fits all’ solution to network automation.
With the ever increasing number of vulnerabilities and security advisories that are released by networking vendors, having a well defined plan for performing software upgrades each platform in your network is critical. Cisco ASA firewalls are most commonly deployed at the edge of your network, many times with interfaces that are connected to the public network or to a network that you may not manage. I’ve written a blog post for my employer Optanix that defines a well-defined plan for upgrading Cisco ASA firewalls.
Having worked in the Network Management / Operations industry for over 15 years, I have been involved in the implementation of network changes on many ocassions. I have also helped drive process transformation of how various teams implement changes based on best practices that I have picked up along the way. I’ve written a blog post for my employeer Optanix on some steps that you can take to help increase confidence and success in network changes.
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.