Speaker 1: 0:00

This is the Art of Network Engineering podcast.

Speaker 2: 0:11

In this podcast we'll explore tools, technologies and intelligent people.

Speaker 1: 0:15

We aim to bring you information that will expand your skill sense and toolbox and share the stories of fellow network engineers. Welcome to the Art of Network Engineering. I am Tim Bertino and we've got a bit of a co-host crossover for this episode. I am joined by Chris Miles of the Cables to Clouds podcast. What's happening, chris hey?

Speaker 2: 0:35

man, not much. Yeah, glad to be here. I always love coming back on here and chatting with the A1 crew. So, yeah, not much, man Just holding it down.

Speaker 1: 0:44

Yeah, everything going good, work life. Is there a balance?

Speaker 2: 0:48

Works busy, life's busy, Everything's busy. But you know at least we're heading into springtime, slash summertime here in Australia. So we get to tell you guys sucked in, as they say, because we are going into the warmer weather where you guys are freezing.

Speaker 1: 1:06

So what would you, in this time of year, what's like the average temperature? And you're going to have to give me Fahrenheit because I don't know anything else.

Speaker 2: 1:15

Let's like today. So it's probably about 70, 75 degrees today Somewhere. That's perfect. It's dude. It's funny because, like we say, we went through winter. I've been wearing shorts every single day. I just change whatever I'm wearing on top. So yeah, that's not bad at all.

Speaker 1: 1:31

That's awesome, all right. So we are continuing our recent tradition of guests on this show with really cool names. So I'm going to try to do what I've done with the others and guess what would be a good profession if this person wasn't doing what they're actually doing in their day to day. So we are joined by Danny Wade. I'm going to say Danny Wade is an NFL quarterback. Chris, what do you got?

Speaker 2: 2:00

There's actually a very famous skateboarder named Danny Way, and it's just too close. So that's what that's where I put you at. You're a very extreme man, jumping out of helicopters under the half pipes and things like that.

Speaker 1: 2:11

So so, danny, thank you for joining the show. Let's, let's put you on the spot right away. If you were not a network automation enthusiast, what would you be doing?

Speaker 3: 2:22

So you guys were pretty close. I mean Tim, you're saying NFL, chris, you got skateboarder, I got to go with basketball player. At least try to Okay.

Speaker 2: 2:33

Dwayne.

Speaker 3: 2:34

Wade not going to say.

Speaker 2: 2:35

I'm related to him or not.

Speaker 4: 2:36

How did I miss that All the same?

Speaker 3: 2:38

basketball player. I don't have anywhere near the skills he does, but I got to rock basketball. Basketball is my number one sport.

Speaker 2: 2:46

Which franchise are you playing for? That's the important question. Well, I can't play for the Miami.

Speaker 3: 2:49

Heat because Dwayne's got that on lockdown. Um well, I'm probably like geographically I'm closest to the Washington Wizards and they've stunk for a while, so I mean they need some help.

Speaker 2: 3:02

I'm here for you could be that number one draft that takes more of the top. That's right.

Speaker 1: 3:13

So, danny, let's, let's start it off with you kind of giving us a background. How did you originally get into technology and how did that shift into networking as a focus and then deeper into automation? Yes, so I guess it started out.

Speaker 3: 3:27

I think it pretty much how everyone starts out with tech. Right when you're younger you normally figure out how to fix your parents' computer. So that was kind of one of the very first things. I think I can't remember the specifics, but basically parents' computer something happened, virus something locked it up, kind of started diving the details and ever since that moment that kind of break fix, that really sparked my love for technology Moving into, you know, late high school, early college, got a job at a computer repair shop so got to understand computers and I think that's a really important thing.

Speaker 3: 4:12

But I've got to get to know that I've been working with all these computers, did some networking there, very basic residential networking, like hey, wi Fi is not working. But then kind of where it really started specifically with networking is. I got an internship at a global enterprise and really got to dive into specifically Cisco networking and understands everything in the OSI model so team. So it's not like the intern had to go pull cables. I got to see everything. I got to see things break. It's things I didn't understand. There's the EIGRP routing issue. I had no idea what EIGRP was, but just being in that war room and getting to experience that was great. And then from that internship it actually turned to a full-time job after school and so I was able to kind of start where I left off. So I got to experience enterprise networking. And then for the past about three years I've been with a consulting company called NetCraftsman. Recently we're now a blue ally, so I'll kind of throw around either of those terms, but we're blue ally now. So that's kind of where I'm at.

Speaker 1: 5:30

I tell you I can relate so much with that story in the internship in school because I feel like I learned a lot of good stuff in college. But I also had the opportunity to have a desktop support slash help desk role at the school I went to and I would tell you my college experience would not have been complete without that. That was such a pivotal point in learning because, like you said, you're not just sitting in a classroom and reading through a book or hearing a lecture, you're actually out in the field getting to see things break, maybe breaking things, some things yourself and then having to step through that troubleshooting process. So yeah, that's a I can definitely relate to that. It's so beneficial.

Speaker 3: 6:14

Yeah, and I mean I think even the smallest thing like having to open up a computer right, like open up the side panel of a desktop, like that's groundbreaking for someone that's in school. We're just learning about these sort of components and so that in itself the physical like nature of, like you know, swapping RAM sticks, even starting that early on, like that, that was things you just can't learn in their classroom. Respect layer one Exactly, yeah.

Speaker 2: 6:44

Another point you made that I can definitely relate to is is fixing things for your parents, and I will say after doing that it's amazing that I'm even still here, because the amount of times my grandmother has asked me to like fix her email, where it's just like something moved, like a button moved across the screen or something in Gmail, it's yeah, it's a wonder I'm here today, to be honest with you. But yeah, it's good, it's good you made it.

Speaker 1: 7:06

On the other side, so you spent some time at the hardware level, you got into networking and then you hit a point where you started getting interested in you know. I'm guessing you can tell me if I'm wrong, but I'm guessing you hit a point where, okay, networking is cool, but how can I make this better? Is that where the trigger for automation and abstraction and orchestration came from?

Speaker 3: 7:31

Yeah, so it's kind of interesting because I always liked in school and college, I really liked programming and I thought it was interesting and just being able to build something right. You know it wasn't physical but you're kind of designed and built something from the ground up. But I hated, you know, any sort of math class like calculus and everything that you had to do to get in the computer science program. So you know, I took programming classes, but then you know, my degree is in technically an IT, you know information systems. So, like, I always liked programming.

Speaker 3: 8:08

So whenever I found my first step into it was Cisco DevNet, and so I was able to understand like, oh, I can use my programming skills to interact with the network and do it at a mass scale. Because the biggest problem that at least I found, pretty much one of the first things I had to do as a junior network administrator, was, hey, we have new, you know, logging servers. You got to have to configure this new logging host IP on every device across the entire network and I was like, okay, like I can do that. And then about the 10th device, saying, you realize, man, this sucks. So you know, you quickly figure out, okay, there must be a better way and you know, that's kind of how I got into network automation.

Speaker 2: 8:52

Yeah, it's been a blessing to install the notepad warriors of the community out there.

Speaker 1: 8:57

Yeah, Can you, for people that may not be as familiar with the concept, can you explain what Cisco DevNet is in a nutshell?

Speaker 3: 9:06

Yeah. So Cisco DevNet is basically. It's a platform that allows you to they have lessons and learning paths that you can learn a bunch of different things about automation and automation tooling. So there's lessons on Ansible and Terraform. There's obviously lessons about Cisco DNA center and specific Cisco tooling. So you get the learning paths, you get the. You can go through step by step. But the best thing and I think one of the keys to Cisco DevNet are their sandboxes. So there's two different types of sandboxes. There's ones that you can reserve and then there's ones that are kind of just open to the public, that like hey, I haven't seen Cisco SD-WAN or what it looks like. You can go to a URL and log in with a demo account and you can click around. They're read only so it's not like you can go in and just break a bunch of stuff. But the sandboxes, I think, really help expose people for free, expose you to new tooling.

Speaker 1: 10:12

Yeah, that makes a lot of sense. It's back to that labbing mentality. I mean we talk about that as network admins, network engineers, all the time, whether you're trying to study for a certification or if you're just wanting to check what the outcome of a change might be before you do it in production. You either create a physical or work through a virtual lab. So that kind of sounds like what DevNet's providing with those sandboxes, is that lab environment that people don't have to have locally. They can just connect to Cisco's lab environment and do it through DevNet. That's pretty cool.

Speaker 3: 10:48

Yeah, absolutely yeah, especially with network automation, something you're going to have to. Testing and validation are two things that you have to do before you're pushing out any sort of automation to the network. Because I always like to say I don't know where I heard it, but it's the best quote I can say about network automation Network automation all it does is increase the blast radius. So if you mess up on we're talking about copy and pasting commands if you do it to one device, okay, cool, you learn your lesson. But if you do it with automation, you're pushing that out to 20, 30, 50 devices at once. You're taking down half your network. So really, the testing and the validation piece is huge with network automation.

Speaker 1: 11:32

Yeah, increasing the blast radius and fail at scale are the ones I've heard before. That's a good one. So we started talking. You gave one example of a use case and it's the quickly configure something here or there across a bunch of different devices, so at scale, like we were talking about. I can see that beneficial for stuff like that. And then also things like security vulnerabilities. So if there's a vulnerability that's been released for a specific device or a specific code level, sometimes there are workarounds where, yes, this vulnerability is susceptible to the version you're running, but only if this feature is running and maybe you don't need that feature and you just need a quick way to disable that across the board. I can see automation being a quick way to do that. Can you kind of give us some really good, maybe in-depth, examples of use cases that you've come across so far that have been pretty successful?

Speaker 3: 12:37

Yeah, so I think you kind of nailed it right there. One of the biggest use cases is configuration management. Right, cognition configuration to a device. I think that's one thing everyone wants to do right away. But I would say that's the one thing you should not do right away. I know it kind of goes against the grain because people want to be able to going back to, like that logging host example. People want to push that out at scale. They know it's not really a breaking change, right, there's nothing. Routing shouldn't change. Obviously there's software bugs. So I'm not going to say it's not a breaking change.

Speaker 3: 13:12

But I think where you should really start is the testing and validation of your network. What I mean by that is not necessarily scanning your configs and looking for a feature or whatever that might be in configuration management. I'm talking about more the operational state of the network, right? So hey, go out, pull your network and see is routing working as you expect? Right? How many devices out there are running even something simple as software versioning? Right, you can get that with almost any tool out of the box nowadays, but you could easily do it with automation as well. You can do any sort of validation that you're looking for right.

Speaker 3: 13:59

If you're looking at CPU memory, hey, is there anything running hot in my network? That jumps more to observability. But really looking at the operational state of your network, right, because we all have designs and we all have implementation plans. But how many times do we actually go back and say, oh yeah, routing is working as we expect? Right, and, by the way, all of what I'm saying is our read-only actions, right, there's really no risk to it. The only risk is if, like I said, you hit that weird software bug where you run a certain command at a certain time of day and something breaks, but it's all read-only and you get a wealth of information.

Speaker 2: 14:40

Yeah, that's a good point. I think when we talk about network automation, the rope-read one, or the one everyone thinks about, is deployment. Right, it's like you're standing up and maybe standing up new kit, maybe deploying changes to existing kit, et cetera. That's kind of where all the focal point goes. But the operations piece, the observability, is a huge thing. I'm curious, for someone that's deeply ingrained in this, what kind of scratches you're itch more, the deployment piece, or does that observability and reactiveness reactive to failures and things like that does that seem interesting to you as well?

Speaker 3: 15:23

Yeah, I mean, if I had a preference between the two, I really like the validation, the testing, only because it unveils it. You learn things about the network that you may have not known before, so that could be something. I always like to use a routing example, because there's so many ways that you can collect routing information and then you could also validate, piece things together and see, hey, this isn't exactly how I expected it to work. The configuration is neat and I think it makes sense, for, like you said, it's the breadwinner where everyone wants to do it. But really understanding your network and kind of getting the operational state in check, I think is huge.

Speaker 1: 16:06

So we've been talking so far quite a bit about network automation and how we handle this potentially at the enterprise level. I'll call it Chris. I kind of want to shift to you a little bit. Can you draw any parallels to what you've seen both on the enterprise networking side with automation and orchestration, versus what you've now seen in cloud infrastructure?

Speaker 2: 16:32

Yes, that was actually something I was going to bring up today and I'll toss it back to him after I make this statement to get his take on something. But yeah, so the thing is like with cloud. These are all platforms and environments that are built. They're built API first and foremost. They're the very API driven. So automation is kind of at the forefront of a lot of these constructs. So things like Terraform just completely make sense. You built a wrapper around the CSP APIs and you can deploy, operate and tear down as much as you want. So the testing, especially the testing piece within automation, is very easy. Like I can literally stand up a one for one kind of copy of what I'm going to test against, run my tests, see what happens and then tear it down, and that cost me maybe a few bucks, maybe a couple hundred bucks, whatever, but to the business that's definitely worth it, right?

Speaker 2: 17:36

I feel like probably the biggest pain point for on-prem automation is kind of that piece, the physical component, the orchestration of a lab. You can't really replicate things one for one whenever you maybe work at a large enterprise that runs like a several core MPLS network, right, you're not standing then up in a lab without a project backing you, giving you funds, budgeting, all that kind of stuff right. So I will say in another point, that is probably a pain point, at least that I hear about from on-prem. I don't get to interact with this very often, but I hear a lot of criticism about vendor APIs on networking gear. Not going to call about anyone specifically, but obviously Terraform is something that would rely on those. So I'm just curious in your experience, dan, if you're using Terraform, are Terraform providers for API or on-prem vendors? Are they very lucrative? Are they? Is there a lot of people using those today?

Speaker 3: 18:42

Yeah, so I mean you had a lot in there, but yeah, so I guess to answer the most recent question you had there. So Cisco does have and I'll call them out specifically, just because I know for a fact they have this they have a provider for iOS XE and specifically using Rescomp to configure devices. It's an interesting take as far as configuring with it because, as you know, with Terraform you have your plan, you deploy, you change your plan and let's say you deploy three servers with your plan, you take out a server, it destroys that server, right. So if you reapply, I haven't really messed around with the iOS XE provider too much. But as everyone knows, with configuration it's more procedural where you can basically you configure something and then you can back out just like a part of it without. It's not atomic in that way, not as much as Terraform. So, yeah, so they do have a provider with Terraform.

Speaker 3: 19:47

I would say Terraform wouldn't be the number one tool to use.

Speaker 3: 19:52

But as far as network APIs, I think we're in a little confusing time right now with that because I think the goal and I'm sure people, listeners have heard of Yang Data Models that's like a pretty popular network automation topic, that kind of drives home, I would say, some of the quote unquote APIs for your traditional router switches.

Speaker 3: 20:20

So that's, I think, one of the easiest ways to interact with network devices. The problem that I think everyone's running into now is there's a lot of devices that don't support that. Right, you have old network devices and that kind of is where we fall back to the least common denominator of SSH and screen scraping. Right, you're NetMica, you're Scraply, and so it stinks because you pull away from that API driven testing and you're now going back to screen scraping because that's your lowest common denominator in the network side. So we're in a weird lull right now. I think in a few years it's a few more refresh cycles. I don't know. I can't really say much because you hear the stories or you see the pictures on Twitter. Now, x of like those uptime for those 6509s that have been up for 20, 25 years.

Speaker 3: 21:15

Oh, brother. So yeah, I think, hopefully soon, sooner than that. But the point being is we don't really have that common, like you know, like you said, everything in the cloud is API first. Network devices were not that way, right, so we're finally, we're turning out around a little bit. I think there's definitely initiative to, but yeah, it's going to be. It's tough to be very declarative when you when your screen scraping a lot of, a lot of data or a lot of configuration.

Speaker 2: 21:47

Yeah, the standardization and the commonality seems to always be a hindrance with it. It's you can't everybody, you can't get everybody on the same page, it seems like. And that's not even just automation, that's you know standards and things like that. So it's, it's, it's all over the place.

Speaker 1: 22:00

Now, do you think a big hang up to that is older devices, older software running on those devices, or is it more the, the network community itself, the vendors that are that are pushing out these devices, that that is the hang up? I really don't think it's the, the vendors, because, like you said, cisco's really been pushing programmability and other vendors as well. I shouldn't just call out just Cisco. So where do you, where do you think that hang up really is of why we aren't leveraging more programmable ways like southbound ways of connecting, like NetConf and ResConf, and we're still relying on things like SSH?

Speaker 3: 22:38

There's. I think there's a few ways to answer that question. I think one you kind of nailed it with the vendors. They definitely, I don't think, are the hold up in that way. I mean, if you've seen, you know I mentioned Cisco again their software release cycle is much, you know, more aggressive, right. They're releasing much more often. You can say whether it's good or bad, you know, depending on the amount of bugs that you find or that you've experienced. But you know, back when you know I mentioned the 6509s, they're still running that code from 20, 20 years ago, right, so, like it was very stable, you may have only pushed updates every maybe, maybe once a year, you know, twice a year max. Now it's like once a quarter. There's a new, you know, recommended software version for a device and with that comes, you know, obviously you think about features and security patches. But you know, going back to automation, and you know the Yang data models, any sort of updates you know to the Yang data models, those are included with those software updates. And then you know you were mentioning about like interactions using NetConf and ResConf.

Speaker 3: 23:46

I think that you know there's there's definitely a barrier for some to get over. You know all the acronyms and the ways to interact with the devices, and I think it's just. I think it's just plain scary for some people, right, because it's not. If you can SSH to a device and you get exactly what you want in the time that you want, you know what, why would I open up Postman or why would I try to interact, you know, using HTTP versus just SSH to the device? But yeah, I think that's.

Speaker 3: 24:18

Those are kind of some of the commonalities that I see. And the other big thing is feature parity, right. So within Yang, you have different feature parities. You have, you know, I triple. We have different Yang data models. You have, I triple, we open config. You have native data models that come right from the vendor that have a little just a little extra functionality in them, right. So there's just that in itself is something to learn. So it's just, I think, the capacity of do I really want to learn this if I'm doing it right now and it's working right?

Speaker 1: 24:52

So so when you were talking there about software, that kind of triggered me a little bit because thinking about another use case for automation is that software releases on network devices, like you said, come out often. You want to make sure you're staying on top of operational bug fixes, security vulnerabilities, that kind of thing. Do you have any any use cases, any experience with leveraging automation to do things like software upgrades within the network infrastructure?

Speaker 3: 25:24

Yeah, I mean I've done some. They're they're always very tricky right, because as going, you have to remember automation definitely. There's definitely not snap of your finger and everything just is fixed. You know you basically just automate that manual process and for anyone that's ever done upgrades, you know it's. It can be painful sometimes and it can be. You know you can be a little anxious as you wait for that device to come back. So yeah, it's basically just, you know automating that, those manual steps of you know TFTP, ftp, scp, get that image over to the device and then go through that reboot process. You know some of those steps.

Speaker 3: 26:06

I would say it's kind of hard to automate, right, because you're waiting. That especially that waiting period, just because it varies per device and we've all had it to where same software version, same hardware and there's just that one switch that takes just its own. You know it's on its own schedule and so you know in that case automation could break because that switch is on its own schedule. But yeah, definitely, it's definitely doable. And you know you can use pure Python, you can use tooling like Ansible, pretty much any out of the box tooling nowadays. You can get that functionality.

Speaker 2: 26:42

I'd like to hear a story about someone that upgraded their you know VSS core switch with automation. That'd be quite a story to hear, sure not a painful one at all.

Speaker 1: 26:54

So we've talked a bit about leveraging automation for operational the read only to get started and in even past that, be able to go and get operational state of your network whenever you want or need it, and we also talked about the configuration piece. Now take it a step further. We've kind of heard and seen, especially with things like DevNet and the different vendors, pushing programmability and network automation. We've seen this concept of things like infrastructure as code and leveraging, using our and configuring our networks as if they were software code. Essentially, do you think long term, that is how we're going to manage our networks is as if they are software platforms and leveraging more data model driven programmability.

Speaker 3: 27:50

So obviously this is my perspective here, because I know some people disagree, and that's okay. So personally I think the network should be treated as software. Everything rides on top of it and just as users expect their software to be stable, software developers expect their network to be stable and users that are on Wi-Fi or connected hardwired. And there are ways to do it. And borrowing a lot of software development practices I think makes sense. These practices have been around for a while. Topics such as unit testing, integration testing, ci, cd, all the buzzwords you can just enter it here, but no, it really. These have been around. These practices have been around software development for a while.

Speaker 3: 28:44

Going back to what we were talking about model driven programmability and then also just being able to manage the network without using that least common denominator of screen scraping, because that can always give you funny results.

Speaker 3: 29:02

And yeah, I think being able to manage the network programmatically and then also using, like I said, those software development practices make the most sense for the future and we're building and there's tooling out that are that's making that possible. Now, you know I think we talked about testing you know there's tools, you know even G, gns, three, cisco, cml that's. Personally I use that. And then there's also another tool container lab. Huge shout out to that team because they're they're making it happen, because you can run basically a you know four or five node network on your laptop in containers with that tooling and it's all free for container lab. So I've been a huge advocate of that recently, just because it allows people to get you know spun up on something very quickly and it allows you to test all your changes just locally on your laptop. So yeah, it's, I think. I think we should get there the path there. It'll be interesting.

Speaker 2: 30:00

Yeah, I'm curious because you're so in your, in your role at which I guess that was blue ally, formerly nets net craftsman. I assume you're interacting with customers on a daily basis that are trying to implement network automation. Is that correct?

Speaker 3: 30:14

Yeah, yep, yeah, that, or there's you know projects that lean towards that would network automation applies to, right? Yeah, you know whether it be? Hey, we got to push out these new features. Network automation makes sense for that. Yeah, so yes, the answer question yeah.

Speaker 2: 30:33

So I'm curious that you know, since you're doing this on a regular basis, what is the biggest hurdle. You see, you know your traditional network engineers. What's the biggest hurdle for them to try and get over? Moving to an automation mindset, a new framework? Because I remember you mentioned CI CD just a few minutes ago and I remember, like moving to the cloud, like CI CD is everywhere, and that was that was a huge thing for me that I struggled with. It was just like this order of operations doesn't make sense to me, like how do you, how do you do the unit testing, how do you work this in? So it what's? I'm curious from your customer base, what it, what is toughest for them?

Speaker 3: 31:11

It seems like I think a lot of it. Well, the unknown, I think, is one of the biggest things you know, and that's not that's no dig or anything like that. Network automation is a huge topic. I mean, we've just spent a while just talking about on this. You know call, and so you know where to start right and how to do it safely. I think a lot of people are like going back to configuration management, pushing config. Yeah, we can push config, but how do we know it worked? How do we know that config actually is on the device? And so you know.

Speaker 3: 31:44

Just, the unknown, I think is, is the scary, is the scary part. And then, but also having the time to learn it and have the patience to learn it. You know a lot of people are heads down every day having to, you know, churn out changes, address, you know firefight, you know network outages, and there's just not enough time in the day and there can't be an expectation for everyone just to learn it. You know, spend your evenings learning network automation every night because it's an ongoing thing. I've been doing it now for I don't know five, five, five years around and I mean I feel like I've made strides, but every day there's something new, right? So you know you learn something new. Or you know as you've probably caught on with CI CD like there's just always something like a new way to do something, a new method. You may read someone's blog posts and be like, oh, that makes more sense than what I'm doing now. So, yeah, I think it's, it's the unknown, and then also just having the time to learn it and then establish it as a process.

Speaker 2: 32:52

Actually, I think that's really cool, that's a really good answer, because, if you notice, the two things you mentioned are what you don't know, which is just, you know, fear of not knowing something. That's totally understandable and then making the time for it. No, the answer was not the technology, right, because the technology is not the hard part. We can all do that if we just can make the time and lean into it, right? So I think that's I think that's a really good way to look at it.

Speaker 1: 33:13

So to take that, the next step, what would be some of your recommendations for people that, let's say, you got a group, you're sitting in front of a group of what I call traditional network engineers, people that are typical on the CLI show commands, config commands. What would be your advice on talking to those people that want to do things more efficiently. They want to get that state of their network when they need it. They want to be able to push configuration changes at will at scale. What? What's your advice for those folks to get?

Speaker 3: 33:48

started. So I and I've had these conversations before. You know, one of the first things is it's going to take time and that people obviously will shake their head and say Yep, yep, absolutely no, really like you have to stick with this, you know. At least you know, if you're starting from nothing, at least nine months to a year of really getting a process down to where everyone trusts it. That's the thing too. You, I could teach you all day about how to program with Python or use Ansible, but being able to trust the process and getting it to down to where, oh, I got to make a change tonight. It's a small routing change. Do I mess with this? You know file, or do I just SSH in and just you know break, you know console cowboy into it? So like we don't need to do that. You know you got to be able to trust the process and once you have something established, being able to actually do it. But once that, you know, assuming that's agreed upon, I think one of the biggest things is to start small.

Speaker 3: 34:47

Do something that you would do every single day. Take, give me a task that you do every day or you have to weekly, whether it's for management or whether it's for just the health of your network. Do you run show commands, do you log in and do something and I'll show you how to use. You know a library like scrapply or net me go and with 10 lines of code I'll show you that I can print it programmatically to your console and then, with another 10 lines of code, I can show you how to run it against.

Speaker 3: 35:14

You know your device and then save it to an Excel sheet or a CSV, and then I'll show you how to add the rest of your network devices that you want to do it on and then run it from there. And that way you have all. With a click of a button. You have all that output that you normally would have to SSH into multiple tabs. You know open up multiple tabs, ssh multiple devices and also not have that you know. You might actually have seen it before, where you access a multiple tabs, you forget which one you're on and you know you copy and paste something that shouldn't have been pasted in one of those tabs and he caused some sort of outage, right. So I have something that's repeatable.

Speaker 3: 35:49

I just felt that in my heart. Yeah, we've all been flashbacks, but yeah, so it was a lot longer answer. But basically, always start small. Right, you could, you could jump right in to say here's how CICD works. Right, you will lose that crowd in five minutes. Right, because, especially if you explain it from a programming side, they won't care about unit testing. You know they're not there for integration testing. Or, hey, how do I get this runner to work? It's we.

Speaker 3: 36:20

You always have to start small and take a task that you know they're they're doing at the moment. And then how to just iterate on that. Because once they have that one script working I've seen it where you have a script working and they might save it. Maybe you're just on a centralized server or something, but they'll run that script over and over again. And then maybe a few weeks from now they'll say, hey, you know what that script works out. Great, why don't we iterate on it? Or can we create a new one that does this or that? And then sooner or later, you got a whole collection of scripts and then that's where you can have a more you know, mature conversation about, you know, a maturity model, an automation maturity model is kind of what I'm getting to, to where you can get into hey, let's now, let's flip the script, let's quit doing manual task and do more automation.

Speaker 2: 37:02

Yeah, I think that's that's really good advice to start small, because it's like, like you mentioned, automation is an elephant and you're not eating that thing all at once, right? You got to do it one by at a time, right?

Speaker 1: 37:13

So yeah yeah, I love the advice about finding that, that practical use case, because it's not only the concept that we talked about earlier at the beginning of this, that doing what you can to get that experience, you're doing something practical, and I think that's what helps things stick, when you know you're not just learning something because you think you have to learn it, you're learning something because it's actually going to help you do something else. It's kind of that best of both worlds approach and that makes a lot of sense to me and I've heard that advice from similar people that are in the network automation like yourself. It's not here, read this book on Python, or here, write up these scripts that don't make sense to a network engineer. It's no, find something that makes sense that would make your life easier in your environment and start there.

Speaker 1: 38:05

I just I love that advice. I think it makes a lot of sense. So I do want to ask for a bit of a hot take and you can definitely plead the fifth if you want. But there are so many different ways that people can script things and automate and abstract. Do you ever see a point where vendors will come to save the day, both proprietary and maybe non proprietary or vendor agnostic solutions to be able to really abstract the, the network automation, away from network engineers having to do it? Or do you still see down the road that that's a skill, still, a good skill set for those traditional network engineers to have long term?

Speaker 3: 38:52

So, yeah, I mean that's. That's a loaded question. I'll break it down in a couple ways. So, network vendors abstracting away the network and trying to basically sell tools that, hey, you don't have to go in the CLI anymore, click here, click there, you're done. That's already being done, right? Yeah, there's a very popular cloud platform that's doing that right now and it's, you know it's, it's being resold and we're actually moving your quote unquote traditional network switches into it. Right, that's a feature of this tool. It's this good, maraki, if you haven't guessed, but you know that's and it works right. It just works out of the box. And so you know that's happening now and it's, from what I understand, is pretty successful.

Speaker 3: 39:44

And switching back to the individual level, I think you know, obviously, network vendors want you to buy their products and you know, for, depending on the audience, I think it may make sense, for you know a certain audience, right. So you know, if you're a very small team, you know, call it like five people, three to five people, and you have offices that are, you know, you may have hundreds of offices, right, or thousands of offices, but they're all very small branches. Something like a Cisco Maraki makes sense. You're not, don't overcomplicate it. And you know, obviously always do your due diligence of you know, feature parity and everything like that. But you know, and that's just one example, I'm not saying if you don't have that sort of setup, don't use Cisco Maraki. That's not what I'm saying at all. But as an example like that would make sense.

Speaker 3: 40:38

But let's say you have a blended environment where it lets you might have a couple of remote offices. Then you have a big data center that requires, you know, just a little more hardware, different types of hardware, and maybe you have a you know, a different vendor, a mixed vendor environment. Right, you have some Cisco, some Juniper, palo Alto, arista. So having that one platform, whether it's, you know I haven't really seen that platform yet that's truly vendor agnostic, to where feature parity is good across the board for every vendor. Feel free to let me know if you know, if that's out there.

Speaker 3: 41:11

But you know, having something like that, you may have those platforms. Let's say you would have a Maraki or you know another product for the data center and so you might have multiple products. But then you could use program you know programming, not in the network automation sense of like hey, let me plug in and use NetMica scrappley or just using it, you know one of those traditional Python libraries or you know whatever. Maybe you use something to interact with those platforms and you would bring all that data together and you could configure the network that way. So being able to do that, I think, provides a level of freedom that you may not have if you get locked into some sort of platform.

Speaker 3: 41:53

Right, not saying everyone should do that. Right, because you have to have the right skill set, the right number of engineers. Right, you can't expect to. You know one or two people, the script, you know the scripting engineers, as people would say to go in and manage the entire network because, hey, they can script. It's just depending on the audience. And I think you know. To wrap up, the answer is you need the network engineer to still understand the network, right, because data is data. But, inferring that data, you still need that network engineer mindset to be able to understand what's going on.

Speaker 1: 42:28

So I guess I don't need to ask the next question of do you think people that want to get into automation should understand networking first? Probably don't need to answer that, right? No, that's great. I love that answer and I love that you bring up the part about you may need a vendor agnostic approach, and that's where things like homegrown scripts in open source utilities can really make a lot of sense. So that's that's. That's cool. This has been a really cool conversation. I do want to shift, before we finish up, to a bit of a side project that I heard you got going on. You want to let us in on what you've been doing lately.

Speaker 3: 43:13

Yeah, so, um, john Capabianco I'm sure, if your listeners know, he's been on the show a few times um works at Cisco, um, so me and him are actually working on a book for Cisco Press, um, for it's going to be about Pi ATS and testing automation within, you know, the networking sphere. So we're we're working on that. We're about I want to say we're close to halfway done Um, and yeah, so it'll be all about Pi ATS. It'll be about test driven development, um, and really, you know, going back to my point earlier, you know um, um, where talking about running tests and validating your network first and using that test driven approach, um, before just blasting configuration, um, this book will be able to help you understand that and then also understand how Pi ATS, the framework um, could really help you help you with that, because it truly is, you know, for those that understand or have heard of Pi ATS, um, it truly is. You know, batteries included. It has everything you need to get up and running.

Speaker 3: 44:21

Um, some people like it, Some people don't, uh, but it definitely has everything you need, uh to get up and running and start testing your network. Can you give?

Speaker 1: 44:29

us like that 50,000 foot view of Pi ATS and I'm yeah, sometimes I will say uh, you know, for our listeners I'm not even saying that this time. This is for me because I don't understand. Can you, uh, can you clue me in?

Speaker 3: 44:41

there. Yeah, so, um, pi ATS, it's a, it's a testing framework, uh, built on Python and uh, it really is everything from. You can create a test bed with your network devices in it. Um, it is I want to say this lightly but it is vendor agnostic. Um, it does support multiple vendors.

Speaker 3: 45:03

Um, like I said, it's depending on the features that you're looking for, might not have that exact feature, but it does. It's not just a Cisco product, um, and it allows you to run those validations against your network Um or against your test bed, which would have your network devices in them. Um, there are ways that you can plug it up to a source of truth, like like NetBox, so that way you have that dynamic inventory and you can read from those sources of truth, so you don't have to manually build out these test beds, um, so what it the framework allows you to do is you connect to the network device. You can learn or you can parse data from the device. Um, it's really cool.

Speaker 3: 45:47

There's a feature where you can, when I say learn about the network device, it, regardless of the vendor, right, as long as Pi ATS supports the vendor, it can learn um about a network feature, and when I say feature, I'm talking um think OSPF is a network feature, bgp is a network feature, vxlan, um. It will learn about that Um and it will come. It will basically bring all that data to a common data model and then you can do your um validation and your assertions on that learned data right. You could programmatically say hey, find me the number of routes for BGP. If there's greater than 50, let me know this test. You know, say pass, fail, whatever you know for that test. So it has all those parsers. It has that, like I said, vendor agnostic data model. It builds for you Um. It really is an interesting tool and you know there's a lot more to talk about it, um. But I definitely highly recommend all the documentations out there, um, and there will be a book near you soon.

Speaker 1: 46:54

Uh, it's super cool and I can definitely see the use cases in that. I will tell you, I am sitting in a studio full of authors and I feel lazy as hell Because I know uh, chris, I know you're in the thick of that as well.

Speaker 2: 47:06

Yeah, I'll tell you, man, if you're, if you're thinking that, do not envy me at all, Cause it is, it is, it's rough dude. Yeah, it's, uh, this. I don't know about you, Dan, but this is my first book that I've ever written. And then, um, yeah, I never realized how scary a blank page is. It's like the probably on my top five most scary things I've encountered in my life. Now, Um, but yeah, you kind of just it's kind of like automation, you just kind of lean in, start small, just like start putting words on the page. And um, yeah, Our books are on different topics, but I think we'll probably have the same uh approach to it. It's, it starts small there as well. Yeah, absolutely.

Speaker 3: 47:45

It's. Uh, it's interesting too. You know, before this it is my first book as well, Um, but before this, you know, writing blogs was. I loved writing blogs and I had my, you know, a certain tone to my blogs, or I'd want to include something that you know, um, might be my own take on something, and it's like you have to remove yourself from the book and know, hey, this is for a general audience and it's about a specific topic, uh, which, luckily, I liked the topic I've had multiple blog posts about pie, TS and and Jeannie, and so it's easy to write about. But then you do have to like, I've literally wrote a paragraph or two. You know I must fill the page and then I have to go through and delete it because I'm like that, yeah, that's something that belongs in a blog post. Like that, that's something that should not be in a book.

Speaker 2: 48:30

I think, I think what you should do is you should write, try to using John's voice. So all caps, everything's smiley faces, all over the place. That's it.

Speaker 3: 48:41

Yeah, I think you'll. Uh, yeah, we've, we peer review each other's um chapters that we write and I think you'll definitely you'll you'll know John wrote it. Yeah, you'll know exactly Not that I write as you know. I'm not writing in a different way, that's pessimistic or anything like that. But yeah, you can tell when John writes. Why does this text look loud?

Speaker 1: 49:07

I'm just kidding, john. We, we love the personality and the passion you put in your work. It's awesome. Well, danny, this has been a lot of fun. Is there anything that you want to hit on before we wrap up here that we uh, we haven't had a chance to to touch on yet?

Speaker 3: 49:21

I don't believe there's really anything else. Um, you know, I I definitely anyone that's you know struggling or wants to get in a network automation Um, I'm out on the socials so I, um, I love talking about it, I blog about it. Um, and yeah it's, I'm out there as a resource. I just want to keep people motivated and want them to be successful, cause, like I mentioned, you know it's network automation is a journey and I'm still in my journey as well. It's not like I don't want to sit actually, I'm on a high horse right now and say, hey, if you need to talk to the king of network automation, you come see me, cause I'm no way, I'm no way that guy.

Speaker 3: 50:02

I'm not that guy, so, um, but I am a resource and I can give you, you know, whatever I've seen or what my thoughts on things. You know, I'm out there and I'm here. I'm here for you.

Speaker 1: 50:13

And if you check out our YouTube channel you can see Dan's social handle. Behind him in a sweet neon sign DevNet Dan. It's pretty cool.

Speaker 3: 50:23

Yeah, yeah, you get one of those man. Yeah, my uh, my wife got it and it's awesome. I just got a hug.

Speaker 4: 50:30

It was super cool, very cool.

Speaker 1: 50:32

Any uh last minute thoughts from you, chris.

Speaker 2: 50:34

Uh, no, this is. This has been a really fun conversation, I think, dan, I think you've made some great points and, um, you know, you, I think the the key here is start small, right, if you, if you're, if you're, don't focus on what you don't know right now. Um cause, if you can spend all day worrying about you know how far behind you are and what technologies you don't know, it's just you just got to lean in and and, like we said earlier, eat the, eat the elephant, one bite at a time, right, and so I think that's um a really good message for those that want to get into it.

Speaker 1: 51:03

Yeah, I love, uh, I love the approach, Dan, of what you take to network automation and look at it from a practical standpoint. Don't try to go learn all the things just to know them. Make sure it makes sense to you and, uh, we'll work in the environment. So love that approach. Looking forward to the book on Piety T S coming out from you and John Chris really appreciate you taking the time to our listeners. You can find us at artofnetworkengineeringcom on the socials, at art of net inch cables to clouds, cables to cloudscom Check it out everywhere. Thanks for joining us for another episode of the art of network engineering.

Speaker 4: 51:43

Hey there friends, we hope you enjoyed listening to that episode just as much as we did recording it. If you want to hear more, make sure you subscribe to the show and your favorite pod catcher you can also give that little bell rascal a little ring, a dingy, so you know when we release new episodes. If you're social like we are, you can follow us on Twitter and Instagram. We are at art of net inch, that's art of N E T E N G. You can also find us on that weaving web that is the internet at artofnetworkengineeringcom. There you'll find our show notes and some blog articles from the hosts, guests and other friends who just like getting their thoughts down on that virtual paper. Until next time, friends, thanks for listening.