Back to Posts
Understanding NetDevOps Main Use Cases

Share this post


In this article, I am going to walk you through major use cases for network automation with NetDevOps.

As we know, CLI was created for humans and is optimized for manual interaction where you configure one device at a time. Given the nature of manual modification, it is obviously prone to error and tasks are NOT easily repeatable. Future network operations with NetDevOps toolchain would allow us to apply version controls to all configuration changes and where it is the single source of truth. In this new paradigm, automated systems would perform configuration changes, carry out testing at each stage to ensure that network changes don’t result in downtime and finally push those configurations to respective devices.

Now, before we proceed further, let me revisit the primary use cases for network programmability and automation. There are at least seven main use cases out there.

  1. Device provisioning
  2. Data Collection and Telemetry
  3. Compliance Checks
  4. Migrations
  5. Reporting
  6. Troubleshooting
  7. Configuration Management

Let me explain each of those.

Device provisioning is a two-step process, where first step is to create the configuration file and then pushing the configuration onto the device. In order to build configurations, you’re going to need a data file and a template file with variables inside. In my blog posts, I will be using YAML format for data and Jinja for templates.

Traditionally, data collection is done using SNMP which is more or less vendor agonistic and has served us well over the past 29 years. However, it is totally inefficient to pull oodles amount of data each time you poll a device or an interface on a router only to use small portion of it. Using automation with python, you can either use a vendor provided or third-party libraries such as Netmiko to collect output from a show CLI and parse it to extract out exactly what you need to know. Monitoring is highly efficient and pretty straightforward with network automation. You can also use network automation tools to audit a given network, let’s say if you want to collect hostnames, IP addresses, platform and serial numbers. It could literally take days if not weeks if you were to perform this task manually, with automation, it can be done in a matter of minutes with 100% accuracy.

Now, compliance can take on many different forms, however a simple use for compliance would be to ensure that your network changes are in accordance with the established security standards that are relevant for your business.

Migrations can also take on many forms, but let’s say you want to migrate from a Juniper to a Cisco router. Automation can really come handy in this use, since you can separate out the configuration “data’ which is vendor-agonistic from the configuration “format” or “layout” which is obviously vendor specific. What do I mean by that? If you’ve ever configured Juniper and Cisco routers or switches, you know that the two configurations are worlds apart.

Reporting is a lot more streamlined once you have embraced automation to create and deploy your network configurations.

Gathering data is precondition to just about every kind of troubleshooting. With automation, you have pretty much real-time access to network devices which makes troubleshooting a whole lot easier. Another example of troubleshooting that can really use automation is routing protocol related issues such as neighbor adjacencies. As an example, you can pull neighbor adjacency status and then parse all the other relevant “show” CLIs until you narrow it down to a known problem.

Configuration management is nothing but the actual deployment and management of configuration files to networking devices. Let’s say if Cisco were to publish a PSIRT which requires pushing an ACL on 100s or 1000s of routers and switches. With automation, you can deploy an ACL to block the malicious traffic as described in Cisco vulnerability notice. Another example could be to add an eBGP neighbor each time you add a new customer or a business partner.

Now, last but not least, I invite you to come and join me on Full Stack Networker Blog. I will soon be discussing NetDevOps toolchain and pipeline stages in more detail.

1 Star2 Stars3 Stars4 Stars5 Stars (Be the first to Rate)

Leave a Reply

Your email address will not be published.

Back to Posts
sample guides, quizzes and discount
We hate spam as much as you do.