Speaker 1: 0:00

This is the Art of Network Engineering podcast. In this podcast, we explore tools, technologies and talented people. We aim to bring you information that will expand your skill sets and toolbox and share the stories of fellow network engineers. Welcome to the Art of Network Engineering. I am AJ Murray and you can find me at all things online at NoBlinkyBlinky, I am joined this evening by Kevin. He is at AdjacentNode. Kevin, good to see you. It's been a while. I'm like I'm almost stumbling through this because it's been so long since I've recorded an episode.

Speaker 2: 0:41

It's been a while. It's crazy. I'm feeling it long since I've recorded an episode. It's been a while it's crazy. It's definitely a little rusty, a little rust on there.

Speaker 1: 0:50

I'm going to scrape that off and throw a little WD-40 on this thing. I am very excited to be joined by both John Capiobanco and Danny Wade. We've got a very special episode we're going to dive into here right now. Let's get started on this. So you guys have recently published a book through Cisco Press called Cisco Pi ATS Network Test and Automation Solution Data-Driven and Reusable Testing for Modern Networks. We got to break this down, guys. So first of all, congratulations on the release of the book and thank you so much for spending some time with us tonight.

Speaker 3: 1:26

Well, thanks for having us. This is really exciting for us. We worked very hard on this and it took probably from inception to publishing, you know, almost two years. Danny and I actually met just after Cisco Live last year on premises to really sit down and talk about it and make sure he was interested in joining me and introduce him to the people at Cisco Press Nancy, and had a wonderful kickoff. And, no, we're really excited that the book finally materialized after all that work and effort and we had a really great time writing the book and we're really excited about the reaction and the response from the community Really a quite overwhelming response to the book. So couldn't be happier. Aj, thanks again for having us. Yeah, absolutely.

Speaker 4: 2:13

Yeah, um, it's. It's been quite the experience with with john. Um, john has some experience writing a book, but, um, this is my first book first cisco press book, for sure, and um, so it's been pretty cool, it's been interesting. I think a lot of people just assume there's the writing process and then it goes straight to publication, and this was definitely different from that. The writing process was about, I don't know, I would say about 70% of it and the last 30%, I would say, is almost tougher than the writing process, just because of the amount of edits and different level of edits. So you have your technical edits and grammar and so forth. So it was very interesting going through the whole writing process, but it was awesome doing it with someone like John.

Speaker 1: 2:59

Nice, nice, that's great. So let's start at the beginning. What is PyATS?

Speaker 2: 3:08

First of all, is that how you pronounce it, pyats?

Speaker 3: 3:13

Yeah, so here's the first mistake people make is they call it PyATS?

Speaker 2: 3:16

That's what I've been calling it for the last couple of days. So, thank you, yes, yes so no, don't feel bad.

Speaker 3: 3:21

I went around, honestly, six months of making YouTube videos and public all kinds of stuff and I called it PyAtts, to the point that Cisco DevNet reached out to some of the developers and said Could you get the name right? So it is actually Python. Automatic Testing Solution is what it stands for PIATS or ATS. Now, if anyone's familiar with something like Django, which is a web development framework like a scaffolding included, batteries included, as abstracted as they can possibly make it Meaning, it's nice where you just say PyATSlearn or devicelearn, right, pythonically writing automation code.

Speaker 4: 4:15

Yeah, I mean to add to what John said with PyATS. It's really a big framework. You can kind of look at it from multiple angles. There's a few different libraries that are involved Under the hood. There's a connection library called Unicon and that deals with all the device connections. Think of it as like a pair of MECO, netmeco and so forth.

Speaker 4: 4:37

And then you have PyATS, which is the testing framework, the one that kind of tracks all the results, tracks all the test cases and allows you to organize your code and write those tests, test scripts.

Speaker 4: 4:51

And then, lastly, there's like the PyATS library, or better known as Genie. They're kind of moving towards the PyATS library instead of Genie, so you'll kind of see that throughout the book, the PyATS library, which is kind of confusing, but anyways, that's where's where kind of your parsers and your data models. So John mentioned PyATS Learn. That's a feature within PyATS that allows you to learn and grab data off the network and parse it into a data model that's vendor agnostic. So you can learn from Cisco devices, juniper devices, whatever says support, a device, and then you get back that uniform data model. And the purpose or the reason for that is it's very easy to parse and take that data and do further testing or configuration with. So there's a lot built in and obviously each one of those libraries I just mentioned have individual features and we talk a lot about each one of those features in our book.

Speaker 3: 5:51

It's partly why it took a year to write, because, it is fair, we wanted to write like literally, the book on PyATS, more from a story and a journey, and here's a feature and here's how you can actually use it and here's some code that goes along with it, as opposed to just, you know, like a raw, the raw documentation. So we had our skeleton outline and I reached out to the PyATS team at Cisco to say you know, here's I think at the time it was 15 chapters, here's 15 chapters I've come up with. Did I miss anything? And they came back with an additional four or five chapters that Danny and I should cover. So we actually reached out to the development team behind PyATS and had some insight and had some guidance. And really that's why it took so long, because we really wanted to cover the entire framework and make a comprehensive book.

Speaker 2: 6:46

All right, so I'm not very well-versed in the programming automation world. What would you say is the primary purpose or advantage of PyATS for the average network engineer?

Speaker 3: 7:00

Go ahead, Danny, and I'll follow up. Go ahead, Danny, and I'll follow up. Okay.

Speaker 4: 7:03

Yeah. So I guess from a network engineering perspective, with kind of minimal programming background or knowledge, I think you kind of have to think of automation as a whole, and a lot of automation stems from configuration management. A lot of people jump to like Ansible, or hey, how do I push this VLAN across all our devices, and what kind of cool Python libraries can I use? This kind of takes? It has configuration it built into the library. But it's not the main purpose. The main purpose is to do network testing. And so you might ask yourself, well, what is that? Think of it as you're running your show, your show commands, your read-only commands, across your entire network and then you're doing assertions based on that data that you get back. So let's say, you want to validate that there's a specific VLAN configured on every device. You can do that very quickly with PyATS in a structured way, in an opinionated way. It does follow kind of some other Python libraries, so it doesn't kind of just build a structure on its own. But you know, you kind of can build those tests and it's a very, very low risk task to do versus configuration management.

Speaker 4: 8:16

That's kind of something I always tell people is like if you're a network engineer. Start with network testing, and it doesn't have to be PyATS, it could be a mix of you know, norni or network testing, and it doesn't have to be pi ATS, it could be a mix of you know, nor near pi tests, it could be whatever. But start with doing a read only against your network versus pushing configuration, because that can help you build those little baby steps towards doing something in a more automated fashion. So, uh, kind of just validates what's on your network and how your network's actually operating versus what you think it's operating Because you know. I'll just take a quick example of a lot of network engineers design a network with a purpose and having a design in place that they think they know how routing works, they think they know how layer two operates. But using a network testing framework or tools allows you to validate all that and very quickly and with, I would say, almost no risk. There's always some risk, but minimal risk compared to pushing configuration.

Speaker 3: 9:11

Yeah, I would echo that I made a personal mistake of jumping right into a very complex, massive change with Ansible as my first taste of network automation and that actually soured me on the whole deal of Agile and CICD and NetDevOps. And I was soured on it for a few weeks after my first experience because I chose to maybe overestimate how easy it would be to make a massive config change as my first and my organization and my team's first experience. I like what Danny's saying here. And the other thing is, given its automation, there's certain things that you just would. I don't think would be a good use of a human's time, right. So let's take input discards, crc, errors, half duplex. Do I have the right descriptions on the right interfaces? Now think about that at scale. Some of our devices are stacks of switches with hundreds of ports, and now we think of that at scale. Some of our devices are stacks of switches with hundreds of ports, and now we think of that across the enterprise. You know you're never going to log into each device and see. You know how many. How are my counters doing right With a simple PyATS job?

Speaker 3: 10:16

Well, there's 16 or so different counters you can test with PyATS, learn interface and that's as simple as it is. One step to connect to your testbed and we'll talk about testbeds in a bit. So your testbed is your topology, all your devices that you describe, and so you go ahead and connect to them and then you write some simple tests they're like two or three lines per test, get the CRC errors on this interface and, if they're greater than a threshold or zero or whatever, fail the test, mark it as failed. So then at the end there's a log viewer that's an HTML page that will show you the results of your job and you quite literally see green red. Okay, that interface has CRC errors. That interface is half duplex. This interface has a description that doesn't match my intent.

Speaker 3: 11:07

So the other thing I'll mention is, in addition to testing, which is really low risk for someone that's brand new, like right out of the gate I would recommend testing and also documentation. So we write a chapter in the book that shows you how you can, because we're getting structured JSON back, even just that JSON file of your routing table or of your CDP neighbors, of your BGP neighbors, whatever. Having artifacts as JavaScript object notation is great. We go a step further and show how you can call a Jinja2 template API and make CSV files and make mind maps and make HTML pages. So then, if we think of this in the larger picture, maybe we store all of those artifacts in a Git repository or GitLab or something on-prem, right?

Speaker 3: 11:56

So now, every four hours, or eight hours, because it's so fast, because of the Unicorn connection that Danny mentioned, you could literally document your full network a few times a day. And with the Git differentials, what changed, what broke? Why is this not working all of a sudden? Well, I can look at my Git differentials and see oh, danny added a route, oh, john added an ACL, oh, this neighbor got lost, or whatever. It literally bubbles to the surface with these differentials, right? And what does everyone complain about or look for in time of need?

Speaker 2: 12:31

Network documentation right and no one has it. So now you can make it on your own for free right. You sold me I'm sold All the stuff I don't have time for and don't want to do. Do it with this. I got it.

Speaker 3: 12:47

Do it with this, that's right, and then when you're ready and more comfortable and confident with your code. So it's funny, we talk about test-driven development as something from the software development world, tdd. That has two main purposes. One is to keep design simple and I would argue if you've ever looked at a PyETS script, right, setup section, testing section, cleanup section it's quite simple. And the other thing, the main thing about test-driven development, is to inspire confidence. So I would suggest right, we lack confidence as network engineers in our code because we're new at it, we might not be trained at it, we might have no idea what to expect as results, right, but if we follow the simple, you know, can I test for a CRC error and get a pass or fail? You're going to start building confidence up as you go, but also confidence in your network. Well, I know it's not meantime to innocence, right. I know it's not meantime to innocence, right, I know it's not the network, because my dynamic documentation doesn't indicate any changes, right.

Speaker 2: 13:52

Yeah, makes sense.

Speaker 1: 13:53

So let's walk through a couple of different use cases and try to show some opportunities for folks listening to utilize PyATS. To utilize PyATS, I mean, I'm coming from professional services background and I feel like you could easily use this to test and see if a switch stack replacement was successful or a router replacement was successful. Like are all the same routes, there Are all the same neighbors there and all that good stuff. So let's walk through some scenarios and some use cases for it. I'm sure you guys have plenty of those in the book. So what are some common use cases for PyATS?

Speaker 3: 14:28

Well, I think you just described it.

Speaker 1: 14:30

For maybe somebody with not a ton of. Well, actually, let's back up one second. So, before you go and use PyATS, what level of experience does someone need to have? Do they need to be a Pythonista or a Python novice Like? What kind of skills do people need? What are the prerequisites before you know?

Speaker 3: 14:57

stepping into the PyATS world Right. So me personally. I approached.

Speaker 2: 14:58

PyATS without any Python experience.

Speaker 3: 14:59

Now. I did have some computer programmer experience with other languages, but I had never interacted with Python before. I also would suggest, in this day of artificial intelligence, that you can get some help from AI to write your Python code pretty easily. I would suggest it's a very low barrier for entry in terms of the Python knowledge. Now there's some things that come with Python.

Speaker 3: 15:22

When I say a virtual environment for Python, not everyone has made a virtual environment right. It's recommended you run PyATS inside of a Python virtual environment. How to pip install PyATS right that's something maybe not everyone has done is install a package. However, once you've made your virtual environment and pip installed PyATS, you're basically ready to go. The other thing is it has a command line interface. So let's say that this idea appeals to you of getting structured data back or models back Right from a command line. You can just type PyETS, learn, bgp, testbed and the name of your testbed right from the command line and you'll get JSON back. Now what I like to do is do this all inside of VS Code. So I'll have VS Code with an Ubuntu terminal with PyATS inside of a virtual environment, and from there I never connect to switches. I'm just running PyATS commands to get the data I need. And the other thing is I'm not logging into a switch running command, pasting it into a notepad file, trying to analyze it. You know the friction involved in extracting data from a device. You just run commands and it will return you a structured payload.

Speaker 3: 16:35

But I think you mentioned some use cases. Danny and I talked about CICD pipelines and a key component of PyATS are differentials. So you had mentioned a router replacement or upgrade, right? So in that sort of use case I could, as one step of my PyATS code, capture the current routing table or neighbors or convey or whatever, make my upgrade, my software upgrade, recapture the new state after the device comes up and settles and then do a differential between the two and it will give you a plus, minus Linux differential. So minus, minus, minus, three routes. Ah, what happened to these three routes between my upgrade? Like that is a real scenario that we talk about in the book.

Speaker 4: 17:22

Yeah, so that's actually what I was going to touch on there. So I guess, to answer your former question about what kind of Pythonista do I have to be, you really just have to know how to install a Python library. There are multiple ways to write or create Python or PyATS test cases, so one being just straight Python code, and that involves some Python decorators and maybe some more advanced topics in Python. So I would say, like there's at least an you'd have to have an idea of how maybe classes work, methods, and so there's a small barrier for that. However, as John mentioned, there is a CLI available to where, if you just wanted to see okay, I'm doing an upgrade tonight, I want to see what the before and after state look like you can just run PyATS, learn against the device and store all the output in a folder, or essentially a snapshot, and then do your upgrade, run that same snapshot again and then do that differential, and all of that can be done in the CLI. You don't have to touch any Python code and everything. All the data gets stored for you, all the artifacts, all the, everything from the parse, what the parse data looks like, to where, as John mentioned, the differential of like hey, this was added, hey, this was removed to the console log of okay, what commands were ran? What was the raw output? Like I'm a network engineer, I need to see my raw output, all that stored for you so you can do that from the from, like I said, the PyATS CLI and there is kind of a few other ways.

Speaker 4: 18:54

There's a really neat feature within the library that we have a whole chapter dedicated to, called PyATS Blitz, and essentially that's like if you ever wrote an Ansible playbook and if you haven't, it's essentially just a YAML file. And if you're like, what's YAML, just take it. If you take a quick look at an example, you'll quickly understand how easy it is. It's not a programming language in any way, but essentially you build a YAML file that's very human, readable and you can just declare your test cases through that. So PyATS Blitz is another very low hanging fruit, easy to just get up and running, and you can take advantage of PyATS Learn and all these different things we're talking about on top of creating test cases, so you could do assertions if you're looking for a particular value. You know before and after that upgrade.

Speaker 3: 19:44

Yeah, and and just the other thing I want to add is that there is an entire chapter about REST APIs and there's sort of two sides to this coin. There's the APIs that are within PyATS, and we cover quite a few of those API examples, but there's also ways to interact with, let's say, rest Conf or NetConf or GNMI, or, let's say, your identity services engine or your Catalyst Center or your Meraki or your Amazon S3 bucket, right? The beauty of it being Python is that it really supports REST API interaction as well, so meaning you can write tests against things other than what Danny and I have been traditionally talking about routing tables and neighbors and next hops and things like that. You can actually test basically any JSON payload. The key or the key value pair can be tested with PyEPS.

Speaker 2: 20:43

Yeah, that was gonna be my next question about how does it integrate with other automation?

Speaker 3: 20:46

systems that are already existing out there.

Speaker 2: 20:50

Do you guys cover how to integrate that in your book?

Speaker 4: 20:53

Yeah. So towards the end of the book we have a chapter on CICD pipelines and you might be like, okay, hold on, I didn't ask about that. However, cicd pipelines essentially is that integration that you're talking about. Where in the chapter we talk about how we can use PyATS alongside Ansible. It's just being automated in a GitLab CICD pipeline. So if you take GitLab CICD out of it, it's just essentially running the automation for you. But if you break it down, ansible pushes configuration, pyats does your network testing validation. So in that chapter it shows how it can be used with other tooling.

Speaker 3: 21:33

Yeah, and it does tie in with Danny has a wonderful chapter on robot framework. If anyone's out there using robot, already, PyATS integrates with that. I really learned a lot from that chapter because I'm not a robot user and it was all foreign to me, so that's an excellent chapter. The other thing about CICD pipeline like in my previous life, we had Azure DevOps and you could package up. So another chapter in the book is about containerization and making Docker containers for PyATS to make it cloud ready or run it in a Kubernetes cluster or something. So, yes, it is portable and it can be a cloud solution as well as an on-prem solution.

Speaker 3: 22:18

And I'm trying to think about some other integrations. We also tried to show integrations with, like, making chatbots. So the example in the book is WebEx, but it could be Slack or Teams or anything else. Now PyETS has this wonderful WebEx integration where if you have a WebEx token and a WebEx room ID, you can append that to your PyETS job and then the results of that PyETS testing will go to your mobile or to your WebEx. Of that PI ETS testing will go to your mobile or to your WebEx. Now that is really handy on a mobile device, right On a phone to have your testing results and your alerting come right to your device wherever you are. It's pretty powerful.

Speaker 1: 22:55

So completely left field question, because it's a testing platform, is this something that you could use for network monitoring? Is this that not? Not what it's for? Right? Because you're talking about notifications going to your phone, Can you do a periodic or scheduled test and, if the test fails, send the message?

Speaker 3: 23:11

Yeah, so we have a chapter on it. So let me do a quick preamble. There might be some concerns with some people with experience with Python that all you're going to end up with is distributed pockets of tests that different engineers have and they're all disparate and they're all over the place and there's no real organization, right? The code has to be maintained and all that stuff, right? So we wrote a chapter on a tool called Expresso, and Expresso is free, just like PyETS is free from Cisco, and Expresso is a container that you can run that lets you centralize and schedule and integrate with WebEx and other platforms as a central, gui-based dashboard tool.

Speaker 3: 23:58

So that chapter was quite difficult because it was a lot of screenshots and you know, I really wanted to make it palatable for people because once you started with a few tests, like you said, well, that test was great. I would love to run that every five hours, like why wouldn't? I want to know if a description got changed or if I started to get discards on a port or something right? So I wouldn't say monitoring, but continuous testing. So, yes, you can enable the continuous testing, which kind of is a monitor in its own way, right, but it's not monitoring in, in that we're getting telemetry and making visual dashboards out of it. Right, sure Right.

Speaker 4: 24:40

Yeah, I would say it more complements your monitoring tool. It wouldn't replace your solar winds or whatever you have for monitoring, but you know, john mentioned Espresso you could also, if you wanted just to run a PyATS job let's say you created a job you wanted to run you could easily set up just a cron job and just have it run, and there we haven't really touched on it. But there is a really cool reporting tool the way the, how reports are archived and way you can sort through the results. So the reporting can be. There's JSON and XML output to where you can kind of parse, take those files after a PyATS job finishes.

Speaker 4: 25:19

All those job results are archived into the JSON or XML and then you could use additional. It could be Python, it could be anything that can read text files and you could parse that data out and you can present that data however you want. So the reporting, the artifacts are there, and so that kind of leads to I don't want to say endless possibilities with integrations, but you could take those results and you could send it to a Slack bot or you could send it to a text message. So you can get pretty creative. So those results what I'm getting to is those results are saved as artifacts. It's not just something that shows up on your screen, you know in your terminal to tell you pass or fail. You can take those archive results and figure out however you want to distribute them.

Speaker 3: 26:08

You know, one thing that might have an advantage over a traditional monitoring tool is the dot configure capability. So I know we shied away from dot configure. However, a testing framework, a good testing framework, should include the ability to remediate right Now. In our world of networking, remediation means configuration, obviously right. So even just bouncing a port, now how many problems would the first human reaction be just to bounce the port? Probably quite a few, right? You would say, well, just bounce the interface and see if I get the access point back, or the phone back, or my neighbor's back or whatever, right? So why not fail the test, follow that up with an automated action of shutting and no shutting the port, and then retest it again right Now.

Speaker 2: 26:56

Be very careful here right Now, be very careful here right, Especially on interfaces. Went down WAN facing ports and things like that. Yes, yes.

Speaker 3: 27:03

But maybe that's not a great example. Maybe we're testing and seeing if descriptions match our intent right. So in our intent we can describe that here's router one, here's gigabit one, and I want the description to be WAN, facing port with, with verizon right, or then the circuit number or something, and we test it and it's not present. Well, we can fail the test and then go into dot, configure and put that string in from our intent to remediate that the description was lost or or not saved or changed or something right okay, so, so this is definitely something you could use for configuration, auditing and compliance right.

Speaker 3: 27:43

Oh yeah, Greenfield deployments. It supports Jinja templates. So configure supports a few different methods. It's a single string, a multi-line string. So let's say you wanted to shut, no, shut, add a description or whatever, or a templated config from Jinja. And even more so, if you wanted to, let's say, add a description, there's even an API for that, so you don't even need to do the configure and then the description. You can invoke the PyAPS API for interface description and paste in the description there as well. Danny, am I missing any other configuration methods? I and you can post through a rest comp as well.

Speaker 4: 28:24

Yeah, so you can. Like you said you can create it can read from a text file. So let's you know if you wanted to create a config and and send it to the device. You can do it that way. Yeah, there, there's a whole chapter about configuration management as well. It's not, it's a I don't want to say the strong suit. You know configurations built into the framework to allow, like what John said. Like if you're testing and let's say, eh, let's shut down that interface which would kill that routing neighbor, and then do the test again, you know that's where configuration would come into play. So it's kind of part of your testing if that makes sense. Versus, hey, I want to push this VLAN out to everyone, let's just use PyATS for that. You could do that. But StrongSuite is the testing piece and you're using configuration to kind of complement that.

Speaker 1: 29:12

All right, all right. What's like the biggest, coolest thing you guys have seen or done with PyATS?

Speaker 2: 29:26

What's some wow factor here. I was waiting for Danny.

Speaker 3: 29:27

So I did something really cool At a previous employer. Our disaster recovery facility was completely stood up and managed by PyATS and intent-based code. So we took the trouble. Because it was a greenfield, we took the trouble of making very good testbed files, the YAML file that describes the topology.

Speaker 3: 29:47

So once we had everything defined in that testbed file. It was a matter of generating intent and then pushing that intent through Jinja templates. So if a disaster was invoked, we could literally stand up the site in a few minutes, two or three minutes. Everything VLANs, vrfs, you name it. Some other edge cases like ASA firewalls. They have PyETS. You can actually interface with ASAs with PyETS, so things that seem completely out of reach. Documenting our firewalls.

Speaker 4: 30:21

We use PyATS to make CSV files and mind maps and stuff from ASA state where they may do a routine site upgrade or kind of what we were discussing before, where you're doing hardware upgrade or so forth, and they had a list of checks like run these show commands or run these certain commands and verify these lines are there, there's no input errors, there's no this, there's no that, or even down to environmental factors, like both power supplies are operating. You know, cpu memory look good. All that can be accomplished with PyATSO and I've helped build test cases and tests to kind of be able to validate all of that and kind of automate that process. And you know it's kind of twofold it helps the engineers but then it also helps management and if there's any sort of problems with that site after a refresh, you can quickly look at it could be attached to any sort of ticketing system and just validate. Oh yeah, we did that. Here's all the output and then here's kind of the tests that we ran. So I've done stuff like that. But honestly the coolest thing I would say is probably writing that CICD chapter and being able to see how it can complement other tools, because I guess I'm kind of in the mindset of every tool has its purpose and doing something really well is better than trying to do everything subpar. So you know, sticking to network testing, I tried keeping the example of. Ansible is a very popular configuration management tool and PyATS, popular network testing tool. And let's try to automate the process of when we push configuration run tests against, you know, certain number of devices at, let's say, at a, a site, and validate everything looks good and then store the artifacts so that way you can download the artifacts after that. You know that pipeline runs. So being able to kind of see that all the way through I think is one of the coolest things.

Speaker 4: 32:31

And two other integrations I didn't mention but I think are kind of neat facts, one being there's a it's called a contrib package but it's basically a contribution library within PyATS and there's a way you can generate a PyATS testbed from a NetBox inventory. So if you're using NetBox you can quickly spin up that testbed, really with little experience with YAML or anything like that. Right Essentially just needs an API token, go out to NetBox, spins up your test bed for you. That's one integration. And then a second is if you're using Cisco CML, you can it can create a test bed from your lab. So you know you can do that.

Speaker 4: 33:15

I don't. I don't know the exact clicks through the UI, but there is actually an API endpoint for any lab that you build in CML. It will create that for you. It will create a testbed for you. So if you're out there testing with CML and you're like it'd be really cool to run PyATS against this, it can spin up that testbed for you and then, like we talked about PyATS, learn, give it a testbed file and then just you can see all the data it collects from your CMO instance.

Speaker 3: 33:43

Yeah, there's a couple of other neat things I had thought about given the chance. One is a ping test. I think that's really cool. It has the ability to ping and it has modifiers such as source interface or source IP or whatever. Now the ping, you get json back, so it's not just like dots and exclamation marks and then a summary. It's that information, but restructured as javascript object notation. So success rate, number of drop pings um, high, low, medium response times. So you could have these little probes and once you, let's say you set a threshold of, I'm just going to say, 30 milliseconds or 10 milliseconds, if I cross over that threshold with my ping response, fail the test.

Speaker 3: 34:32

I know this link is congested or there's something going on with connectivity. Additionally, there's a trace route, which is the exact same thing. You can run a trace and you get JSON back that you can test. So let's say you're doing path analysis and you want to make sure the next stop is correct throughout a path or see where traffic's going. You can use trace route testing as well. And we've made it. What? Almost half an hour, and I haven't even brought AI up yet.

Speaker 3: 35:00

Well, I have to bring up AI. Now there is a chapter in the book, so this is the coolest thing. I will show you in the book how to take PyATS and ChatGPT APIs, or another Python framework known as Langchain, so we can use. Frameworks can complement each other. So the PyTS framework to get the JSON data, to load it into a langchain so we can chat with things. So anything that's JSON we can. There's a JSON motor and langchain. We can load it and chat with it. So why not chat with your routing table and I've done many, many examples of this right. Do that process and then say what is my default route. If I was a packet going to this IP, what interface would I use? You just chat with it, right. So that is probably the coolest thing I think that I've personally done with PyATS is actually incorporate it as a foundation layer for artificial intelligence.

Speaker 2: 35:55

I was going to say, like testing isn't sexy.

Speaker 3: 35:58

It's a hard question.

Speaker 2: 36:00

Aj's question about like what's the coolest thing, Because testing in itself is not sexy, it's all the stuff that is really really important for, especially if you're in, you know, in operations, doing the work, the testing is invaluable. But to say like what's the coolest thing? So I'm glad you brought up the AI integration, because it's a hard question.

Speaker 3: 36:22

Well, I think what's cool relates to the individual. So like, if we take, let's take. So Danny can speak to this more. But he had a particular need where he wanted to parse the show inventory command and on the iOS XE platform there was no parser for show inventory. So Danny and this is I read his blog post about this. It's out there on the internet, but he also wrote a chapter sorry, an appendix to the book about how to contribute back up to PyETS. So you know, an individual may have some edge case or some specific command that they would love to test the wireless LAN controllers. Now that they run iOS XE, you can parse show wireless commands right. So it really depends on your specific show command and if there's a parser for it. But, danny, can you maybe speak to the ability to, if there isn't a show parser available, how easy it is to contribute?

Speaker 4: 37:18

Yeah, I'll touch on it real quick. Basically, in the back end it's always most of the time it's regex is the answer, and in this case it really is regex. So regular expressions allow you to quickly parse through data to look for kind of key, key points or or key values, and so with PyATS it's just screen scraping at the end of the day. For the most part we talked about rest conference, some other ways to interact, but you know, just as as you would with like a net Miko, you're logging into the device with SSH and your screen, you're just screen scraping what's there and then you're just screen scraping what's there and then you're taking what values you're looking for, just with regex. So you're kind of parsing through each line of output and saying, hey, is there anything particular? John was close to the command that I was looking for. It wasn't show inventory, it was actually show license summary.

Speaker 4: 38:17

Show license okay sorry, which we all can laugh at because it was literally right when they started switching over to smart licensing in that debacle. So I was trying to validate are all my smart licenses registered? And the certain state they have to be in. And so, yeah, I wrote a parser to figure out, to get those values or quickly get those values and validate okay, it is in a registered state.

Speaker 3: 38:40

But think of doing that manually. Okay, cisco's got new licensing. Someone's got to hit all the devices and start making tables in Excel, right? Who wants to do that right?

Speaker 4: 38:53

Yeah, pay turn.

Speaker 1: 39:00

Earlier in chat, dan said that I think tools like this make documentation gathering and inventory tasks far more interesting and likely to get performed. Once we have an easy, repeatable way to retrieve the data, we're more likely to do it. And I mean, I can't agree more. And just like you guys mentioned, like who, when you have free time, sits down and thinks I want a document now Because it's as you said previously, been a very manual process, so this is a great solution to that.

Speaker 1: 39:29

Gentlemen, if you don't mind, I want to pivot a little bit to the writing process and what it's like to go through and write a Cisco Press book. Danny, from one blogger to another, how does this compare to writing a blog?

Speaker 4: 39:43

So it's kind of interesting. Um, it's funny you asked that, cause that was one of the first hurdles I kind of had to get over was um, you want, at least for me and this is just from my personal experience I, I felt like I still needed to put my voice in there um, a little bit, but I obviously couldn't be. I had to be a little more formal than some of my blogs. Sure Cause, yeah, you can't throw in any sort of emojis or memes or anything, it's just good.

Speaker 2: 40:10

I think it'd be better, honestly, unfortunately, yeah, yeah.

Speaker 1: 40:14

Reach a new audience.

Speaker 4: 40:15

Yeah, but yeah, no, it was a very interesting experience with figuring out where the facts line um, but, more importantly, what I tried to get through whether it was my voice or kind of a voice of the network engineer, um is to try to tell a story, and I know john was kind of on the same page with me as we wrote the book is reading a textbook, especially nonfiction. A lot of times they're certification guides with Cisco Press. That's a lot of how people relate to Cisco Press. I wanted to be able to tell a story to where, if you pick up this book, like you said, network testing is not sexy, right, kevin? Kevin said it so and it's really not, and it's just reading through some of the documentation.

Speaker 4: 41:01

But we wanted to be able to tell stories of if you were to do this or we were talking about documentation. We're talking about um, configuring a device, why, why would you do that and tell a story from? You know, start to finish, um, a use case, almost, um. And so we tried doing that in each chapter, which really helped. Helped because I like to write my blog posts in that way too, where I'd like to start to finish. Here's a story, here's a use case. Or here's a really cool thing I found online. I tested out my lab and this is where I probably would use it at work or, you know, in production. So yeah, I think the storytelling kind of helped bridge that like informal voice in me that I had from blogging and then kind of bridged it with the facts that I had to write as part of the framework documentation. So that I think, helped out a lot.

Speaker 2: 41:50

Was it difficult to have to co-author? Blogging, you're kind of you're doing your own thing, but when you guys are working together co-authoring, is it hard to like, mesh your voices and get cohesive.

Speaker 3: 42:08

I'll let John answer and I'll just put my two cents in. But um, well, I so I didn't. I, I did not find that. No, now I think a lot of it had to do so.

Speaker 3: 42:11

A lot of the success of the book has to do with the fact that danny and I collaborated in the past on live streams together and we had some technical challenges at times and we tried to tell a story together and neither one of us wanted a second job per se, like I didn't want to do something that felt tedious or that I have to write or oh, I got to sit down and do this chapter this week. I wanted to enjoy it and I wanted Danny to have fun, and it was. We had a wonderful. You know, in this day and age it's not phone calls, right, we just instant messaging hey, I'm working on this chapter 10, hopefully done by Friday. I had a look at your, your chapter last week. I've added some comments and some edits, so we, we bounced back and forth constant communication throughout the thing.

Speaker 3: 42:57

Now I got to be upfront. I'm not much of an editor. I'm not much of for reading someone's chapter, like Danny's chapter, and saying strike this and add that and change this and you should have said this, and that's just not in me. I don't like to judge that work Other than you know, obviously, if there's some additional ideas or some things that maybe were missed or that I had done or had experience with that Danny hadn't seen in PyATS. And, equally Danny, the edits he gave were very similar. There was no like he wasn't like the English professor taking the red marker to my work. So I enjoyed the process. I would write another book with Danny. That was enjoyable. Um, I found it easier to do this in collaboration with someone than my first book that I wrote as an individual alone. It was.

Speaker 4: 43:50

it was actually quite a bit easier to collaborate yeah, so I was I would say definitely echo john like Working with John was very easy, it was awesome, it was like writing a book with your good friend. No, I couldn't really even make up anything, to be honest. You could try.

Speaker 2: 44:11

I mean come on.

Speaker 4: 44:13

Well, john did tell me no. No, it was a very easy experience and I think the difference with this sort, this sort of book with co-authoring, is we kind of figured out the chapters early on, who would write what, and so each chapter there was kind of a. There were some like chapters where we would say, all right, you'll see this concept more in detail further in the book, you know here, further in the book, you know here. But most of them were kind of self-encapsulating of here's a topic, start to finish, tell the story, explain how this feature works and then kind of wrap it up and then you know it could be me or John's chapter that's next.

Speaker 4: 44:49

But it was kind of cool though. You know I I learned a lot from John's chapters since we were writing, you know, about different topics. I learned a lot and, like he mentioned, he has a whole chapter about AI. I'm definitely not as involved with AI as John is, so it was really cool to see his perspective and things that he's actually wrote, like there's code in that chapter that works and that he used. So it was really interesting to kind of learn from him really along the way.

Speaker 3: 45:19

I think what helped too is that we both are. I can speak for both of us. I think we really took ownership of the chapters. So, like Danny mentioned that, we had the outline, and that really helped. Here's what we want to write. And then it was kind of like, I mean, I did a little bit, maybe more forcefully say here's the ones I want to write, here's the ones I don't want to have anything to do with.

Speaker 2: 45:42

Hopefully you want to write them.

Speaker 3: 45:44

And here's some other ones that are somewhere in between. Right, maybe you could write them or I could write them. We'll flip a coin or something. But there were certain topics that I didn't really want to have anything to do with because of a lack of expertise. I wanted Danny to write them because I had read his blog posts, right, seen him on his streams talking about the topic. Why would I write that chapter? He's already got an amazing blog about contributing to PyTS or Clean or some of these other tools. Right, so that really helped was taking ownership and really having a clear delineation of here's the 12 I'm going to write, here's the 12 you're going to write. Here's our timeline according to Pearson's contract that we have, right, a certain number, a certain percentage of chapters done by a certain date. No, it was good. It was a really good experience.

Speaker 2: 46:31

Now that the book's been released and people are reading it, have you had any feedback? Would you change anything?

Speaker 3: 46:38

I, you know. I wanted to add more.

Speaker 3: 46:42

You've got to at some point you've got to say, okay, like that's enough, we have to cut it off, right? So I guess I wish I had written a little bit more about using, like a chapter on Ansible using the Genie libraries or the PyETS libraries libraries or the PyATS libraries, like just a chapter on a PyATS or, excuse me, an Ansible playbook, and how, inside of an Ansible playbook, you can invoke PyATS code. That was one thing that I personally chopped. I didn't want to muddy the waters between two different frameworks, so I thought it might be more confusing than helpful. But in terms of feedback, I mean I see the posts, people sharing selfies of them getting their books all over the world. Someone said that it's changed their life. Other people are saying that I'm finally documenting my network.

Speaker 3: 47:32

No, it really is. It's been really special. The response all over the world has been really heartfelt, like. It means a lot to me. We didn't do this certainly to make a lot of money off of it. It was a passion project. We had a similar goal of trying to help other people adopt network automation broadly speaking, and this happens to be the tool that we both love and enjoy working with.

Speaker 4: 48:02

Yeah, I mean, we haven't really received I would say, I don't, I at least I haven't seen it any sort of true negative feedback Like hey, this sucks, it's the bearded guy, awful writer, and what are you doing?

Speaker 4: 48:16

You know I didn't, we didn't get any of that, at least that I've seen it's been. I mean, just like you guys have experienced, aj and Kevin, like the network community is is always is pretty tight and very encouraging and supportive, and we felt that on, you know, twitter, on Twitter X, whatever you want to call it On LinkedIn, we've definitely, you know, getting direct messages, just a bunch of support, and we really appreciate all the words that we've, you know, kind words we've received.

Speaker 2: 48:48

Yeah, it's amazing how networking is such a huge field but it feels like a very small community. It's very weird in that way, so it's been very cool. I also saw these selfies and that's how I knew the book got released, because I started seeing the selfies everywhere people taking pictures of the book, but we.

Speaker 3: 49:03

As a cisco press author, you get a certain number of copies of your own book and um I I started to see selfies and I'm like I don't even have my books.

Speaker 2: 49:12

I don't even have my. What's going on here, all these?

Speaker 3: 49:15

people are getting their copies early before me, so that was a little weird actually to say like can I get a copy please?

Speaker 1: 49:24

You know I I I'm excited. I haven't read the book yet I do plan to read the book. I think things like this break down barriers right. Like you guys are providing a very instructional book on how to utilize PyATS, why you would want to and how to go about doing that, whereas you know when something like this first comes out, you know there's early adopters, there's people who really understand Python and programming and can look at something like this and say, okay, I know how to use this, whereas you know you have some more novice people that could really use something like this, but they don't know how to get started. And you guys are doing that for us, and and so, on behalf of the network engineering community, thank you so much for because I yeah you know, honestly, like while I was doing the pro services stuff, I looked at PyATS.

Speaker 3: 50:14

I'm like, oh my God this could like do so many things for me and I'm like I don't know how to do this. Well, it's a very within the niche of networking right, the even smaller niche of automation and now an even smaller niche of PyATS. Now, I don't know.

Speaker 3: 50:30

I think I can say this now actually the fear of reprisal. I don't think Cisco has done a very good job advocating promoting marketing, letting people know that there is PyATS. Now, it's not a revenue generating thing for them, right, so right, they're going to lose money for all the marketing they put in behind some big PyATS tour, right so it's almost a word of mouth tool. Or, as you start searching for network automation, maybe you stumble across some blog or some video or something mentioning pi ets. I know, danny and I have been talking about it non-stop since about 2019, but we're just a couple of people, right like. We don't have that much influence. So I'm hoping that an actual cisco press book, right with the name on the cover of the book, will help people understand that. Hey, wow, cisco has an automation framework in Python. Cool, and it's free and it's relatively easy to use. So you know, I don't. I sort of wanted to popularize Ansible with my first book and now I have a similar goal of trying to popularize PyETS, let's say, Very good.

Speaker 1: 51:40

I want to take a moment to remind our listeners. If you want to support the show, the easiest way you can do that is give us a like or subscribe and follow us wherever you find our podcast and your favorite podcatcher. If there's any way to rate the show, like in Apple or Spotify, please go ahead and do so. That really helps us out a ton. Gentlemen, as we start to wrap up our hour here, is there anything about PyATS that we should have asked you, that we didn't, or the writing process?

Speaker 3: 52:09

No, I don't think so. But if you are inspired and want to try your hand at writing, honestly it's like anything else you just sit down, dedicate half an hour a day. An hour a day, if you know the fact that Danny and I people that are very much like you, network engineers we're not special in any way, we're just very passionate and open about our knowledge, right? So you know the KDP platform on Amazon, kindle Direct Publishing if you want to publish your own self-publisher book that's how I got started Cisco Press is always taking proposals for Cisco technologies or adjacent technologies for Cisco Press books If the writing is something you're interested in, even if it's non-technical if you just want to tell your own story or write a short story or something you know, the barriers are very low to entry to get started as authors.

Speaker 3: 53:04

The only other thing I guess I'd mention about PyATS is that there is Danny and I both on our GitHub repositories which we can put in the notes, have a ton of code. So if you're curious where to get started or you want to see what some of this code looks like, just hop on our GitHub repositories and you can get started there.

Speaker 4: 53:29

Yeah, I think we covered everything, pyats. I just want to say that if you're interested in writing or you know you've appreciated people's blog posts over the years. Like John said, it could be technical, non-technical, but let's just use technical as our example. Try to get started on your own. I'll say AJ kind of helped me get started with my blog years ago, and so John referenced my blog a few times in this episode.

Speaker 4: 54:00

I just kind of wrote and posted and published. You know I didn't really think too much about. You know I wanted to make sure it was factual and correct. You know I'm not trying to post things that are incorrect online, but I wasn't worried about oh, does this sound right? Is it too long? Is it just just write and post and share? Reach out to people online. You know I'll sign myself up If you reach out to me and say hey, I wrote a blog post, could you reshare it or could you read it? I've done it in the past and I want people to not feel too nervous about it. Especially blogs, they're supposed to have some sort of personality in them. You know they're not supposed to be like a nonfiction book where it's just facts, facts, facts. So you know, the more memes, the more emojis, the more just relaxed conversation in a blog post, the better. So, you know, don't feel too nervous, or hey, this isn't right for me. Just spin up, you know, wordpress site, whatever, something gets started and just start posting.

Speaker 3: 54:59

Yeah, we need more of it. Every voice counts. We need much more activity from from network engineers to emerge as leaders and emerge in the community. If you're lurking and you and you need some inspiration, look at the four of us. Look at the platform the art of network engineering is built in just a few. You know just a short period of time. Platform the Art of Network Engineering is built in just a few. You know just a short period of time, the followers that we have and the LinkedIn influence that we have. It takes a bit of effort but we really need it. We as a network community have had a rough, a very rough 12 months with layoffs and with you know, people passing in the community, community leaders that have passed on.

Speaker 3: 55:38

So the more the merrier, the more voices we have, the better. The more diverse conversations we have, the better, I think, the only thing we have as humans is the ability to communicate with each other, right and now, in this day of mass social media platforms, we can all have a voice and contribute to the conversation, hopefully in a positive way right.

Speaker 1: 55:59

Yeah, I love that. I mean. Very well said, john, and I'll just throw it out there again. If anybody wants to write but maybe doesn't want to have a blog, the Art of Network Engineering blog is always open for submissions. So if you have an idea for an article, you want to write something up and again, you don't want to go through the trouble of maintaining your own website or anything like that, please reach out. Hit us up on our contact page. We're more than happy to take submissions and post whatever content network engineering related on our own blog for the community to consume. That's awesome. The book is Cisco Pi ATS Network Test and Automation Solution Data-Driven testing for modern networks.

Speaker 2: 56:41

It's not a math at all.

Speaker 1: 56:43

I know right, find it on ciscopresscom if you're looking to purchase it. Gentlemen, where can people find more of you, danny?

Speaker 4: 56:54

I'm kind of pretty much on Twitter X and LinkedIn, so DevNetDan is my Twitter handle. Um LinkedIn, it's Daniel Wade, but uh, you'll, you'll be able to find me on there, john.

Speaker 3: 57:06

Yeah, John underscore capital Bianco on Twitter and I do have automate your networkca. Get hubcom slash. Automate your network for my code. I don't do a lot of blogging anymore but occasionally I will break out some blogs on automateyournetworkca. The primary spot to find me lately is YouTube. I make a lot of short and long form videos on YouTube, mainly primarily lately related to artificial intelligence, but that's probably the best place to find my content lately is on YouTube.

Speaker 1: 57:36

Awesome, and we will be getting a few copies of the book to give away. I don't know if there'll be physical or digital downloads, but we'll have those ready by the time we release this episode. So, folks in the live chat here, please join us back on our social media platforms to give away some of these books. We're really excited to do that. Gentlemen, thank you so much for joining us. This has been a lot of fun and we'll see you next time on another episode of the Art of Network Engineering podcast.

Speaker 1: 58:01

Hey everyone, this is AJ. If you like what you heard today, then make sure you subscribe to our podcast and your favorite podcatcher, smash that bell icon to get notified of all of our future episodes. Also, follow us on Twitter and Instagram. We are at Art of NetEng, that's Art of N-E-T-E-N-G. You can also find us on the web at art of network engineeringcom, where we post all of our show notes. You can read blog articles from the co-hosts and guests and also a lot more news and info from the networking world. Thanks for listening. We'll see you next time.