Intro

Hello again! It’s been a few months since my last post, so I figured it was time to give a little update on what I’ve been up to!

After my last attempt at the Cisco DevNet Expert, I was pretty burnt out studying for certification exams. I wanted to do something that reinvigorated my passion for automation, so I decided to revisit a project I started last fall: NetCheck.

NetCheck

The NetCheck project is a side project I started in September 2021. It started as a small project to help me learn how to build a web app/API using FastAPI, but it quickly turned into an app that I could see other network engineers using for network validation/analysis.

Purpose

In case the purpose wasn’t already clear, NetCheck is being built to help network engineers run validation checks on their network device(s). These checks can range from environmental checks (like CPU, memory, power, etc.) to L3 routing checks (number of neighbors, number of routes, etc.). The goal is to have the tool be driven by the engineer’s expectations of the network. The engineer will provide what they believe the network should look like (think declarative) and NetCheck will help validate that expectation.

Aren’t there already tools out there like this? Most likely.

Then why build it? Simple answer – To learn.

I’m not expecting to make the next groundbreaking tool that will shock the networking world. I’m simply building a tool (in public) to help myself, and possibly others, learn more about software development and network automation.

I find that many engineers’ first roadblocks after building their first scripts (Ansible playbook, Python script to connect to a device and execute a command, etc.) is how to actually build a tool or piece of software. Obviously, we (network engineers) don’t all need to build software, but I find that many network engineers are curious how to get to that “next level”. My personal goal with this project is to learn how to build something bigger and get to that “next level”.

Tech overview

Let’s go over the project at a high-level. It’s built on FastAPI, which provides the framework for the web and REST API interfaces. The network validation/testing is driven by the pyATS framework and uses a combination of the Genie library and ntc-templates to parse network device data. For the backend, it uses a relational database to store network validation test results and device inventory. For testing purposes, I’m using SQLite. However, I plan to look at other database engines, such as PostgreSQL, for production use.

Latest update

Before we talk about the latest updates, let me provide a little background. Last fall, I had developed two “static” validation tests, which focus on common use cases for network engineers: circuit upgrades and switch installs. The tests are considered “static” because the testcases didn’t allow for dynamic parameters. Parameters allow users to provide key data thresholds that they expect to see in their network. Data thresholds, such as CPU utilization percentage and expected number of BGP neighbors for a device, were statically set in the tests. Obviously, this doesn’t scale and will not work for individual users’ use cases. I initially built the tool like this just to see what was possible. Now that I understand the process, I’m figuring out how to make the tool more robust and scalable.

So what have I added over the past few weeks?

I’ve added two important features: custom validation and a simple device inventory.

The custom validation feature allows users to select the testcases via a drag-and-drop web interface. This allows users to build their testcases “a-la-carte” and test only the network features they want to test. The simple device inventory is just that – a simple inventory system that keeps track of the devices you can run tests against. This is still in progress, but here are a couple screenshots of each feature:

Moving Forward

As you can see, we are still in the beginning phases of NetCheck. I want to emphasize that I’m not teaching how to become a software developer, or even stating that I know all the software development best practices (because I don’t!). However, I’m working to understand those best practices so that I get better at developing code and, ultimately, build tools that help network engineers. This is a learning process for me, so I invite others to critique along the way. If you’re interested in the project, have suggestions, and/or want to contribute, please open an issue or pull request (PR) in the NetCheck GitHub repository.

Lastly, if you’re interested in watching live development of NetCheck, I have weekly development streams on Thursday nights @ 8pm EST.

Conclusion

Thank you for reading about my NetCheck project. I hope this blog post made you curious about my NetCheck project, and possibly made you interested in contributing. Even if you aren’t looking to contribute, feel free to join my Thursday night YouTube livestreams! We talk about all things network automation!

If you have any questions/feedback about this post, please feel free to hit me up on Twitter (@devnetdan). Until next time!