Python Automated Test System
For starters, it is pronounced [pie-A-T-S], and yes, I’m having a devil of a time adhering to that pronunciation too!
As I continue to delve into the world of network automation, I’m always striving for a clearer understanding of not just what but why. What exactly is network automation? And why should traditional infrastructure guys like myself care about it? More importantly, I often wonder how – how will automation make my job easier and the networks I support better? What are the use cases that speak directly to me?
The answers to those questions gained a little more clarity a few weeks ago. I’d just driven my freshman mini-me back to his college campus after the holiday break, and was heading back home. Thinking about the year ahead and tech goals I wanted to focus on – network automation was top of mind. And for good reason. Aside from my own curiosity, my company is also wading evermore into the network automation waters. The inevitability of a more automated approach to how we deliver, maintain, analyze and improve networks is no longer a distant reality. So, time to level up!
Facing the three hour drive back to Charlotte, a quick Spotify search on the topic turned up The Art of Network Engineering podcast. The episode that illuminated the answers to some of my questions was “Practical Network Testing and Automation with pyATS“. The discussion that unfolded really was, not to be too dramatic, revelatory to me.
Okay, maybe a little dramatic. But the conversation really did grab my attention and ignited my imagination as it presented scenarios and use cases that really did speak directly to me. In fact, I’ve been so fascinated with it since that drive home that I purchased Cisco pyATS Network Test and Automation Solution (Data-driven and reusable testing for modern networks). The book is written by Jon Capobianco and Dan Wade, the featured guests on this particular episode.
So…what is pyATS?
pyATS is used to comprehensively test & validate networks, and to provide configuration management – all through automation.
A Python-based framework, pyATS was developed by Cisco engineers for Cisco engineers, and after years of internal use, was made public in 2017. It is powered by Python, but one does not need to be proficient in the Python coding language to instantly take advantage of pyATS. A major driver behind that fact is the pyATS companion library, Genie. That said, for myself, my automation journey includes a track where I am learning and increasing my Python knowledge daily, and of course that has been beneficial as I lean into pyATS and automation in general.
In addition to network testing and validating, pyATS can be used for tasks like provisioning and on-boarding new network gear, applying software images and baseline configurations, and more.
Pre-defined and Custom Tests
Genie supplies some pre-built tests engineers can use to automate common network validation tasks, including:
- Connectivity & Interface Status: test/verify device reachability, confirm interface status and correct provisioning
- Routing: checking the status and the configuration of routing protocols like EIGRP, OSPF, IS-IS or BGP
- Device Status Monitoring: monitoring device health through device performance metrics and resource utilization
- Pre/Post Change Validation: capture and compare network states before and after changes are applied during a change window, or before and after an unplanned outage
pyATS also empowers engineers to extend its capabilities through the creation of custom tests tailored to their network’s specific needs. For example, you can build an event-driven test, that when used with other tools like scripts, can automate an action in response to any number of network events (i.e. traffic thresholds exceeded, link failures detected, resource utilization thresholds approaching, route flapping, blocked traffic attempts, etc.)
All of this can be done at scale, in a highly automated and reproducible way. The tests are data-driven and adaptable to varying network scenarios.
Testbed files
pyATS defines a network device and its links within a YAML file, known as a testbed. Tests are ran against the testbed. The advantages of which include:
- Centralized Management: a single testbed file can define an entire network
- Reusable: properly configured testbeds can be reused, saving time and providing a level of consistency across multiple tests
- Device Abstraction: connections like SSH can be abstracted from the testbed and allow an engineer to interact programmatically with devices defined within the testbed
- Scalable and Adaptable: testbeds can be used in scenarios ranging from small labs, to small production networks, to large scale production networks
Parsers and APIs
pyATS uses parsers to analyze raw data outputs from network devices and pull information out into a structured format. pyATS connects to a device (as specified via the testbed) and executes commands (e.g. show ip route, or show ip bgp). The raw output returned from the CLI commands is passed through a parser that extracts relevant information and organizes it into a structured data format. By transforming raw device outputs into structured data, pyATS enables – at scale – the automation of network testing, validating, analyzing & troubleshooting. In other words, parsers serve as a key part of pyATS functionality. Custom parsers can be developed to deal with unique data outputs.
APIs – Application Programmable Interfaces – are used to interact with network devices programmatically.
Use Case Scenarios
- Network State Validation: proactively identifying issues within the network by checking the operational state of the network with regularity
- Regression Testing: test software updates and proposed configuration changes to make sure such events will not alter functionality in an unexpected way
There is a lot here to unpack, and a ton more to learn and I am beyond excited to continue learning and finding ways to implement pyATS testing into my own workloads. As I do, I am grateful to know that I can reach out to John himself for clarification to questions that I am sure will arise.
Thank you John!
Dave Brown 