The Art of Network Engineering

Ep 133 - An Expert's Perspective on Network Automation and the Cisco DevNet Expert Certification

November 22, 2023 A.J., Andy, Dan, Tim, and Lexie Episode 133
The Art of Network Engineering
Ep 133 - An Expert's Perspective on Network Automation and the Cisco DevNet Expert Certification
Show Notes Transcript Chapter Markers

This episode was originally recorded March 23, 2023

Meet Ben Schuster, a man who's journeyed from the Air Force to the cutting-edge world of network automation, and the first to bear the title of Cisco Certified DevNet Expert in 2023. His background, inspirations, and career transitions light up our conversation like a well-configured network. As he reminisces about his father's influence, you'll learn about his initial fascination with networking and his transition into classified networks.

Ready to untangle the mysteries of network automation? Ben's got you covered! He'll walk you through the complexities of automation tools such as NautoBot, Ansible, and Git. Plus, he'll share his insights into the challenges of revamping a network, from organizational politics to customer-specific approaches. Our chat then dives into a comparison between the DevNet and CCNA, giving you a crystal clear idea of which path suits you best.

Lastly, if you're gearing up for the DevNet Expert Exam, Ben's invaluable tips and experiences are not to be missed. From understanding blueprints to studying effectively to managing the unique challenges of the exam, Ben's got golden nuggets of wisdom to share. He stresses on the need for a 'source of truth' for network configurations and the benefits of automation based on that. He also suggests must-read resources and provides a sneak-peek into the type of questions you can expect in the exam. Be prepared to be inspired and informed by a true expert in network automation!

Ben's Book Recommendation
Model Drive Devops by Steven Carter and Jason King - https://amzn.to/4701dxL

Find everything AONE right here: https://linktr.ee/artofneteng

Speaker 1:

This is the Art of Network Engineering podcast. In this podcast we explore tools, technologies and technology keeping. We integrate new 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 AJ Murray at no Blinky Blinky and I am so excited to be joined by the one, the only, Dan Richards at Howdy Packet. Dan, it's been so long I know I've gotten to say those words. Where have you been, man?

Speaker 2:

Living under my rock man Right. So we had a little girl and we also sold our house and moved twice now. So that's, all yeah within like six months, right. So yeah, it's been kind of weird, but now it's all good. Little girl's doing good. She's getting big, growing up, eating good.

Speaker 1:

you know how old is she now?

Speaker 2:

She's eight months.

Speaker 1:

Eight months. Yeah, it's crazy.

Speaker 2:

My son's about to. He's about to turn four next month. It's been a little little little busy, little hectic, so I kind of took a little step back. You know, nothing too wild I've been here, I've been lurking, yeah. Yeah, I made an appearance on Twitter and Matt Damon. Yeah, matt Damon, that's great. Matt Damon, net Damon.

Speaker 1:

Yeah, but yeah, that's oh, Andy. We'll have to put a link to that tweet in the show notes If anybody missed that. That was a.

Speaker 2:

That was a good gift, yeah, Well you got to talking about how he looks like Matt Damon and I was like I got to thinking about breaking bad and they had. They had that character on there which everyone called him meth Damon, because you know he obviously looks like Matt Damon, but so I thought it was fitting to be net Damon.

Speaker 1:

Yeah, yeah, that was great.

Speaker 2:

Have you been AJ?

Speaker 1:

Man, I've been busy. Yeah, you know, you and I connect and talk every now and then. So you're well aware I'm like real deep into the photography stuff now.

Speaker 2:

I love it.

Speaker 1:

I love it too, man. It's so much fun, so I'm actually getting ready to sell my photos.

Speaker 1:

There's a benefit craft show coming up in town. So the woman that used to cut my hair unfortunately was diagnosed with cancer for a second time and she's been through a bunch of treatments this past year. Things are on the up and up, looking good, but you know she's been out of work for so long. The family needs some support. So the town is rallying together. We're having a benefit craft fair. I signed up. I'm going to sell a whole bunch of my photography stuff there and any profits I get from that going to donate to the family and help them see it through until they can, until she can get back to work, which is hopefully later this year.

Speaker 2:

Well, that that's awesome. You're a wonderful person.

Speaker 1:

But I mean, I'm excited to help out her and her family. You know, not only did she cut my hair, but it was like therapy. I mean honestly, like we both have kids that are the same age and you know just you know, like screwing up or whatever. I talked to her and she's like, yeah, my daughters do that too. And I'm like, oh, okay.

Speaker 2:

So it's not just me. It's not just me. Yeah, that's always nice to relate to another parent.

Speaker 1:

Yeah, yeah. So it's been fun. So it was like heartbreaking when she got the second, you know cancer diagnosis right. So you know, any opportunity we can, we can help out someone else, like we try to do that. So, but I digress, you know I got a whole bunch of photos printed out. I'm getting ready to sell those there and then I'm trying to figure out a way like how do I continue to do that even after this event. So we shall see. But that's not why we're here. We're here to record an episode and we have a very exciting guest this evening. His name is Ben Schuster. He is one of the first Cisco certified definite experts and we want to dive into that with him. Ben, thank you so much for sharing your time with us and joining us on the show this evening.

Speaker 3:

Yeah, Appreciate you guys having me on.

Speaker 1:

Yeah. So what I'd like to do is just kind of get to understand you know who you are, what's your background, where you work, what you do, and then you know from there we can kind of roll into why. Why DevNet?

Speaker 3:

Right, right. So my background is started in the military. So I was in the Air Force for about eight years, started out doing satellite communications, learning all that basic theory behind IT back before. Well, at the time there was all this IP based stuff out there, but we didn't have any of that. All of our stuff was old serial. So I learned a lot of the really good foundational basics there. You know understanding, you know a DTE versus a DCE device and understanding your timing and how important that is. And then went from that kind of into networking because I liked it, I enjoyed it. My dad was doing networking when I was growing up. Oh, very cool.

Speaker 3:

And you know, in the nineties he was doing stuff with Cisco and I was that was cool.

Speaker 3:

I didn't know what it was, but he would talk about it and I thought it was really cool.

Speaker 3:

I remember he tried to teach me subnetting when I was like 10 and I was like, I think, I think I get it, but I don't understand why I'd ever use this.

Speaker 3:

And then, yeah, I started getting into routing and switching later on in my Air Force career about probably four or five years before I got out and then ended up getting out around 2016, did some contracting back towards the same place I was working I'm just kind of switched one cubicle down doing the same thing and over there I was doing what they call CSSC commercial solutions for classified and that's where they do like wireless classified networks and so you got you can go on like the NSA's website and look up their solution designs and how they do that and it's kind of like a two or a three tier thing where you got your black network, gray network and then red networks and how all those come together and you learn a lot about you know managing your certificates properly, having all of your stations for checks along the way, with security and all of that.

Speaker 3:

So I learned a lot doing that and then pretty much went right over into Cisco to be an NCE over there and then moved up into a technical leader and right now I'm a TL for the law enforcement region within the federal space at Cisco.

Speaker 2:

So you said a bunch of acronyms right there. What?

Speaker 1:

do all those mean? Yeah, I heard.

Speaker 2:

NCE On your titles there.

Speaker 3:

Yeah, oh yeah. So NCE is a oh man, network consulting engineer is what they call that, and that's those are the nerds at Cisco Farms out to go on site with you and help you out with your own network on day to day, get embedded in the operations and be your liaison back to Cisco and help you. You know, if you run across any, any issues throughout the day, you know they're there to help you. Or if you have bigger design problems and they can be with you every step of the way through that. And then TL sorry, that's technical leader. It really is kind of a pointless title. It really just means that I help other customers and more customers and I have other NCEs that I help along the way and help build and bring up and mentor other NCEs. That's really all that means. Okay, gotcha.

Speaker 1:

So along the way, did you get Cisco certified, like while you were in the military, after you got out, was there any like CCNA, ccmp?

Speaker 3:

Right, yeah, I got my networking, my CCNA. I got it, I don't know, sometime in the military and then I eventually ended up getting my CCNP about a year or two before I got out of the military and it was one of those things where I just studied really hard but I never really worked on that stuff. So it was one of. Those is one of those book knowledge things versus a lot of experience. I didn't have the experience. I had my section and this is all I work on, right, but I wanted to learn more so I did a ton of self study and that's been a lot of my careers is everything I do is self study on that type of stuff.

Speaker 3:

Even for my round switch, ie was all self study.

Speaker 1:

Okay so you're from CCI.

Speaker 3:

Right, so I have a CCI in routing and switching and then the DevNet expert.

Speaker 2:

Okay, when did you get that IE?

Speaker 3:

I got that in 2019.

Speaker 2:

2019,. Okay yeah 61492.

Speaker 3:

There you go.

Speaker 2:

So some of the previous experience that you've been talking about. I haven't heard you say anything about coding yet, so what got you into the DevNet side of things?

Speaker 3:

Like I said, that's all self study, so I absolutely love it and I think that that's exactly where our customers should be and I want to get ahead of them.

Speaker 3:

Okay, some of my customers are starting to adopt automation, they're starting to use it.

Speaker 3:

There's some that are a lot farther along than others, and there's some of my customers who have really far with automation on the system side of the house but the network side of the house is lacking, and so it's really me trying to get ahead of all of that. Right, and so you know, I have been working with a lot of my customers to get them to do to start doing this stuff day to day, and I do a lot of training and helping them understand the basics and and why and how we're doing these things and where, where all this track is going. But, as far as you know, do I go and build my own software programs and stuff like that? No, no, that's not me. I Google stuff and I find examples of other people that they've done and I put it together and then I take that and then my enterprise experience, I put on top of that and make something that's scalable, sustainable and survivable, that can take it to the scale of what my customers need have you played around with yes, sorry.

Speaker 1:

No, no, I just like what you said there the scalable, sustainable, survivable.

Speaker 3:

Right, yeah, right. Everything I say when I, when I'm talking to my customers, every solution that I do is everything has to be scalable, sustainable and survivable. If it doesn't meet one of those three pillars, then you shouldn't implement it. When you're talking about scalability, you know this needs to be able to go. You might think you're in a lab environment now and doing this little tiny thing, but you need to understand that this may explode, and we've all seen examples of that in our career, where you know we've all heard about the root certificate out there, for the enterprise says test root is the name of the root certificate, because you never know where your lab environment is going to go, and I have seen that, and so everything that I do, I want to build it from the start to be as scalable as I could possibly dream of, and then sustainability is all about.

Speaker 3:

You know you have n number of manpower right. We don't expect you to get an influx of a whole bunch of people coming in to help you out anytime soon. That's not the way the industry's going. So we keep asking for more work out of our engineers, but at the same time, there's only so many engineers and so many hours in a day and we all have families and we want to go out on the weekends, right? So how do you keep this, how do you keep your workload sustainable? And so you have to be able to lower with everything you do.

Speaker 3:

You need to be lowering the amount of O&M requirements to make it sustainable, because I'm not lowering your O&M requirements now with whatever I'm adding on top then, as the next person that's going to come in, when they don't do that, you know you're just going to end up burning yourself out and or you're going to need to bring in other people, which isn't a survival, isn't a sustainable business model, right? And then survivability is obviously about, you know, keeping your keeping your stuff up, whether that's reducing your, your mean time to recovery through automation and we're increasing your security posture through standardization, having all of all your standardized config sets everywhere and being able to push that out to every device and have everything be the right code, all the right config settings, everything is set up the way it should be so that it can survive an attack.

Speaker 1:

Wow, that's, that's great. It all makes sense. I've just never heard it presented like that, and that was great.

Speaker 3:

Yeah, I actually came up with that a few years ago, so yeah. I was actually. I was writing my resume. I came up with that I'm like dang, I kind of like that. And I've actually just stuck with that for quite a few years.

Speaker 1:

Hey, I can see why, man, that's great, that's great, all right. So when you have those conversations with your customers and network engineers like what, where does that automation journey discussion kind of start right, like if you're trying to get them to really latch on and understand you know this idea of network automation. And how do you, how do you get that light bulb to turn on?

Speaker 3:

I start with the quick winds.

Speaker 3:

Yeah something, something small, just because there are some people I've worked with that they don't want automation, because they don't either trust it or want it, or scared about it, it doesn't really matter, or they just. They just try to throw a policy in your face to say that this isn't possible, right, so I just start with the smallest, quickest when it can be. I don't care what it is, whatever. What's your daily thing that bothers you, that you have to do? Let's make a quick win out of that, let's do something super fast. And then what I try to do is have a very fast turnaround on that, from the ask to here's your final product. And what I do with it is I make sure I run all the security scans and then I go here you go, here's all your security scans, here's your sonar cube report, here's your you know, your linters, your best practices. You can have all those reports right there. So when I give it to you, so when they come back and say, oh well, I don't know if security is going to accept this, I'm like well, here's your full, entire package of how you can get this approved. And so that's the way I start with it Extremely small, very good use cases and are very simply easy wins.

Speaker 3:

And then from there I start with the source of truth Everything is around the source of truth of the network and then building out from there. What I want to do is I want to establish my intent on my source of truth. I don't want to go out and take all my network configs and put them in one place, just like at some other backup repository, because whatever's out there might be wrong. What I want to do is I want to build my source of truth to be on my intent of the network. I take that and I start automating based off my intent.

Speaker 2:

So how do you document that process Like your source of truth? What do you do? Do you use a tool Like? What do you do there?

Speaker 3:

My favorite is not about yeah, that's the way I do it. I use not about as a source of truth. And then from there I got my get repose where all my actions just happen. That's where all my code is. It's going to go actually do the CI CD pipelines and do something. I have AWX up here to kick off any jobs that I want over top. So this is kind of the layer that's going to either add something to my source of truth and or kick off a job. So this is my abstraction layer. And then you have men.

Speaker 3:

Based off of what you're trying to do, you have other tools and there's a whole suite of tools out there to do it. Whatever, one's the simplest, don't overthink which one you're doing. What bothers me is when people say, oh, we need one tool and we're going to work towards one tool and that's going to do all of our automation. Well, there's a whole host of tools out there and it's like trying to use a flat head screwdriver on a Phillips screw. It's going to work. There's a better, simpler way to do it. So just look at the fact that you have more tools in your tool bell here and learn each one of them and the benefits of them and when you can use each one, and so I don't limit myself towards what type of tool down here that I use, as long as my framework architecture is the same. I have my intent, I have what's going to push it out, and that can change AWX, asl Tower, lro, nso, it doesn't really matter. And then you have Git, which is going to kick off my CI CD options.

Speaker 2:

Gotcha and CI CD. Can you explain that a little bit so people who don't might not know what those acronyms are?

Speaker 3:

Yeah, continuous integration and continuous delivery and or deployment, typically with a delineation of those is one's going to actually push out something to your network automatically. The other one's going to stop just before delivered, just before deployment has going to hold until you say go. And so from that point is those are all your tools that are going to automatically kick off based off your jobs. You know you could have anything in what they call pipeline all your build, your tests, all your stages, that you have for your production environment, your dev environment, staging environment, it doesn't really matter. And that's based off of how you build your Git repo, to how you want Git to do automatic actions off of that.

Speaker 2:

So, like in your experience, you know you're talking about your framework and everything like that Do you start like certain sections of a network to pull into that framework, or do you just do it in one big bang, get everything in there or like what's your typical? But here's, I guess here's. Another question is are you doing a bunch of greenfield, are you doing a bunch of brownfield when, when you're helping customers with this, this kind of you know, getting them ready for automation, like just kind of go through that a little bit with this?

Speaker 3:

So typically with lab environments, quasi greenfield. So I can either apply my production configurations into my lab environment or I can have this go out and push my intent to what my lab environment should look like. At the end of the day, shouldn't it be the end state the same? So does it really matter? But to answer your question more directly, is brownfield? You know, everyone I work with already has networks, or I wouldn't be there, right?

Speaker 3:

I wouldn't be employed. So they all have their networks and there's very few that are just like oh, let's just stand up a new network. So most of mine is all brownfield and I get those questions a lot about. You know how am I going to make this change within my organization? And every single one of them I approach differently, based off of who the customer is. There's a lot of different customer sentiments and you know, some people love their policies, some people love change control, some people love all sorts of other stuff. Like you know, they just love the politics of their organization or say they don't love it, but then they become a part of their own politics, of their own organization, and so you just got to approach each one differently and that's just like an outside looking in type thing, right?

Speaker 2:

Right, okay, so I could see that right, like the you talking about the politics. That's a big one. You know, I've experienced that myself of how do you get people on board with something that they don't want to change the way they've done stuff right, and especially when you're just talking about putting your entire network into this. You know automation framework that you were going over earlier, I don't know. So when you do come across that, what I mean? What? How does that conversation typically go? I mean, they obviously have hired you to do something right, so someone is ready to move that direction. But, however, some of the working with the engineers, I guess there's a lot of questions here, sorry.

Speaker 3:

Quick, quick clarification.

Speaker 2:

I had two coffees today, so I'm a little.

Speaker 3:

Yeah, I mean, I'm not directly hired to do any of this.

Speaker 3:

I come in and I give my advice and my best opinion and my best knowledge of what they should be doing and where they're going. From a consultancy standpoint, I'm here to help guide you and grow you and make sure you are successful. That's what I'm there for. I don't sell stuff. They don't pay for me to go in and do stuff. Now I will go help you do stuff, but that's not what I do. What I do is just take it from. Hey, I've been a customer right, I've sat in that chair and I have seen all the politics that I have to go through to make things happen. So from that standpoint I can relate with you and then help you drive organizational change. And then I forgot to rest your questions.

Speaker 1:

So the problems that you're brought in to consult on aren't necessarily around network automation. It could be any kind of issue, and then if you see an opportunity where network automation could solve the problem, that's when you present it.

Speaker 3:

Right, right, yeah. So you might call me because you got an issue with ICE and you're, which is your identity services engine. So let's say, all your 802.1x is you know you want to make some change there, but you want it to go across whatever, doesn't matter. Maybe that's a bad example, but you know and I might be like, hey, we can do this faster with automation because you know you don't have to do this so many different times or whatever. And that's when I bring up that conversation, and most of the time that's very well-received because they have an immediate problem and it's going to take them a while to do it. Right, yeah. And then it's going and solving that problem as fast as possible and you start to get those quick wins. And then the organization starts to realize those quick wins and when they got that realization and they want more, that's when I can start bringing in the concepts of source of truth and the framework and how all that's built out. And, by the way, I didn't come up with that framework.

Speaker 3:

If you guys are interested in it, it's called model-driven DevOps. There's a book out about it Stephen King, I believe one of the authors of it that came out mid last year. No, stephen Carter I believe it.

Speaker 2:

I was about to say was it a horror book or something?

Speaker 3:

Because there's a Carter and a King in there. I'd have to look it up, I don't remember. Anyways, yeah, it's a great book for starting model-driven DevOps from the beginning, and it tells a story about how you get into this and how you start, or what can happen if you start small with automation and you think that you're like, hey, I read this and let me just go do this, and then you break stuff. It starts kind of small with that and then builds upon it and then builds all these building blocks of your Git repositories, your source of truth, how you can leverage different technologies such as Ansible and NSO, and all that together to create this framework that is scalable, sustainable and sustainable.

Speaker 1:

Yep, so I've got the book right here Model-Driven DevOps Increasing Agility and Security in your Physical Network through DevOps. And there are several authors, but there is a Stephen Carter and a Jason King, mike Yonkers and Josh Lothian. Okay, cool, we will have a link to that book in our show notes and I just might pick up a copy for myself.

Speaker 3:

That sounds interesting, yeah yeah, it's an excellent book. I enjoyed reading it. It's a quick read. It'll probably only take you a couple of days to get through.

Speaker 3:

You know reading an hour or two a night and I read it on a couple of couple flights and it's pretty enjoyable and it really does paint a very good picture for the need for Model-Driven DevOps and then how you can go about it. And then there's a whole along with that book is there's an entire repo of every code that they show in the book that's actually usable and that's that's up there and there's a link in the book to get to it and I can probably give you guys the link if I Google it real quick. If you go to GitHub and look up mdd Model-Driven DevOps, there it is yeah, githubcom slash. I mean, before I say it I'm gonna be wrong yeah, slash model-driven-devops, and there's the mdd base there and that is a great, great starting point when you're reading through the book. It walks you through these repositories and how they work, with the storyline of a network guy trying to do this in his own environment and then goes through some of the pitfalls and problems he has with his organization and all that.

Speaker 3:

So it's a really cool way of presenting the concept of Model-Driven DevOps.

Speaker 2:

And did you say it's coming from the perspective of a network engineer?

Speaker 3:

Sort of. So there's like a there's like a sub storyline within the book and there's like all your technical knowledge and why you should do this and all that type of stuff, but then there's like a sub storyline of a guy trying to learn, you know, any form of, like, you know, automation.

Speaker 2:

Okay, gotcha. Yeah, we'll have to put that in the show notes as well, If you will just email us that link or something and we'll get it in there. All right, do you want to talk about some DevNet specific now or?

Speaker 1:

Yeah, yeah so. So when you decided to go down the DevNet path, did you do all three of the exams? Did you do the associate professional and the expert, or did you just dive right in?

Speaker 3:

So I did. So. I started with the associate and then I did the specialist, which is the core exam that you have to do to take the expert and then took me a couple tries on the core exam that one was surprisingly tough and then going up to the expert and I was going to take more of the professional certs but then I learned the expert was coming out and just decided to go for it. I'm glad for punishment that way, I guess.

Speaker 1:

Which other specialist exam did you do to finish the DevNet professional?

Speaker 3:

I never finished a professional.

Speaker 1:

Oh, okay, gotcha, Gotcha.

Speaker 3:

So I just did the specialist and then went to take the expert lab.

Speaker 1:

Okay, interesting, so there is a lab with it. Is this a lab like the CCI lab, where you have to go to Richardson, texas, and you can only take it there, or is this one a little bit different because it's more developer based?

Speaker 3:

Right, yep, you still have to fly down to Richardson. Still an eight hour exam. First part of it is your design portion and then the second part is your configuration portion.

Speaker 1:

Okay, so is it focused on more network automation solutions, or is it like I'm trying to figure out a way to ask you a question about the exam that doesn't violate any sort of like? Right?

Speaker 3:

So the way that it's kind of broken out is you have your design phase, which you can see in the blueprint which I can talk about, everything on the blueprint I learned. So within the blueprint you can see and we can, I can send you a link to it. If you just Google DevNet expert blueprint, it comes up. But 20% of the exam is design, 30% of it is infrastructure as code Scroll down, 25% is network automation, 10% containers and 15% of it's security and it's all about automation driven of each aspect of those. So the design portion is all about what you can read right there and what they want. They want you to answer questions about reliability, high availability, resiliency, scalability, latency, rate rate limiting.

Speaker 3:

I could go on for like an hour reading this thing. It's huge, but it's all about understanding software development and then how to develop software on an enterprise scale. So all of those things that you would come with learning how to develop software, handle or implement some sort of DevOps or automation solution or whatever. It is any of that that you would need to know from a cloud perspective, that you would need to know from an on-prem perspective. How do you develop this software? Do you need to have circuit breakers in there because you're having too much throughput coming through or too many requests coming into this AWS region or whatever, and all that type of stuff, and then how you can load balance across and all of that type of stuff. That's all those portions that you're going to need to know if you were to develop and put a cloud native app in the cloud.

Speaker 2:

That's intense, it's eight hours of that right.

Speaker 3:

It's a monster of an exam. Not going to lie, it sucked my life away.

Speaker 1:

How long did?

Speaker 2:

it take for you to study for that one.

Speaker 3:

So let's see from March 2022 to January 2023.

Speaker 2:

Okay, so you're just fresh off of it. Yeah.

Speaker 3:

Yeah, so the test was first offered in March 2022. Okay, so it got offered March 2022 and I went and I took it right away just to see what was on it. There's no. Well, at the time there was no boot camp you could go to. There was nothing about it, because nobody'd pass the test. How they're going to boot camp for it? Right? There was no bookers. The only study that you had was the blueprint and then going out and finding your own and understanding it and learning it from scratch, going through the entire thing.

Speaker 3:

Since then, there is one boot camp out there I would have to look up his name and I can give it to you.

Speaker 3:

A guy out in England, the first guy who ever passed the DevNet IE, started a boot camp and I think this is like his fifth or sixth IE, something like that. He built a boot camp out of it and it's like a two week boot camp and he's got all the labs built out and everything like that and he's got thousands of what he says, thousands of tests and different simulations you can go through to learn it. Not that I'm I don't know the guy, we're not friends or anything. I didn't take that course, but sounds legit to me, but I never took it. But that's the only one I know that's credible. The problem is there's a lot of fake ones out there for this exam because, let's see, so I was the third person to pass it. There's this guy, andreas, in Norway, by my name, mark, who's thinking like Iowa or something, and then me and at the time there was, there were only three of us had passed.

Speaker 3:

In January there was five or six different websites out there selling bootcamps. How are you going to be legitimate when I know whoever wrote that never passed the exam?

Speaker 2:

Slam pickings, yeah. So yeah, there was only the one available, but you can google.

Speaker 3:

There's a bunch of them out there. You know, a ton of those domain names around definite expert have been sold. You just google, just pick a domain name and start looking them up and there's people have coming up some crazy names around it To try to. They apparently want to build and sell this school. If you think about it, it's a odd opportunity. There's not that many times a new ie comes out, right yeah that's true. I guess that's one of was one of my driving factors towards wanting this get in early on something unique.

Speaker 3:

So so, having taken Sorry, I also really enjoy it nice, nice, um.

Speaker 1:

So. So, having taken the, the cca route switch, how does that exam compare to the, the dev net? It is it, you know, on the same plane Is it like a solid expert level exam?

Speaker 3:

Yes, I would say it's on the same plane. For the sheer vast amount of knowledge that you could be tested on and required to know, um, I would say that this one was harder than my route switch. Oh wow, just because there was no bootcamp you could go to, there was no ine courses you could watch In which you know who passes a route switch, ie without watching an ine video or cpt nuggets video these days, right right everybody.

Speaker 3:

There's a go-to's, those guys are great and Um, so it's all going and finding your own, reading the documentation, really trying all the stuff out for yourself, um, and so that's what made this one a lot harder. There's also Like, at the same time, I think in the future, when, when boot camps do come out, books come out and think and there's a whole lot more study material out there for this, I think it's going to be end up being just on par with all the other ies and how hard they are. I mean, none of them are easy, right?

Speaker 1:

Um, it's still eight hours of banging your fingers against keyboard, no matter what you, no matter how you look at it, um, but yep so Do you think that having your your ie route switch helped you to prepare for this Uh devnet expert exam, in that you know, you understand the challenge in front of you. You studied for something like this before, so you you at least had that experience, right?

Speaker 3:

Yes, I think it helped me with understanding how to study because my first idea I way overstudied for it, this one, I Studied a lot but it took me a lot of tries for some just simple, simple mistakes, um, and it was the reason why this one was easier in in that regard, from the studying aspect is I knew the challenge I was up against, um, and I knew how to really read the blueprint to understand what you're looking at. And there's this isn't like some secret thing, there's very direct ways that those words are within a blueprint. Those aren't just arbitrary words there. So if it says to, I'm reading the first one design a solution Based on an on-premise, hybrid or public cloud deployment, considering these factors Deployment, sustainability, modularity, containers, vm, orchestration, automation components, infrastructure requirements.

Speaker 1:

That's the first bullet, um all that for one thought yes but that's, that's one dot one.

Speaker 3:

Yeah um, so, but that, did you catch that first word design. Design, yeah, yeah, that means you're probably not going to be going in and hand jam and configuring that. What you need to know is to go and study that and understand that and be able to answer questions about that. Because it said design a solution. So there's, there's a thought and logic and put into these. Um, here's one create a scalable solution for infrastructure automation, considering areas such as network, network impact, risk and tool selection. So that one said create.

Speaker 3:

So I need to know how to Actually hand jam that, build, manage and operate python based rest apis and and web application frameworks. You guys start to get the point about how those actually Excuse me, how those action verbs apply. When you're reading a blueprint, which is something that I was like, oh duh, like we all have reading comprehension, how come? In the 90th time I read through this, I didn't actually catch that. Yeah, but that's, there's A methodology behind how they build these and they're not trying to trick you. They're trying to trying to tell you how to study with the blueprint.

Speaker 1:

Excellent, I like that. That's uh, I guess that's something that I even pick up on before because, yeah, I see, like recommend a deployment strategy. So you're not, you're not, you know, hand jam and code in that one and then using, get some troubleshooting, consume and use a new rest api. Given the documentation, okay, all right, interesting. Yeah, that's the only way to look at these. Um, can you take us through, like what, when you're studying for this, what does like a typical study session for you look like? Do you, do you have it? You know, plot it out? Are you following the blueprint diagram or the blueprint to like a tee on this, or do you just like pick a topic and sit down and See what all you can learn, do and break?

Speaker 3:

Um, I tried my best to follow a plan but, like all nerds, I started to go down rabbit holes when I tried to find something or I couldn't figure something out, right, which is fine and hey, that didn't bother me too much doing this Um.

Speaker 3:

But the way I built out my whole study plan, um is I kept all my notes and azure devops. Everything I did that I wrote down. Started with first time, when I started doing this, it was all excel and I started building out this, this, this devnet expert, the blueprint, and then making more tabs and doing all sorts of other stuff and linking all these other pages and linking documentation and just totally was getting lost. So I switched over to trying to do git lab and use issues tracking with issues and. And then I went to trying to use the boards and have milestones for myself and timelines to try to keep myself on track studying. But I didn't pay for the good version of git lab, um. So I started using azure devops and azure devops ended up being an absolute win for me when it comes to studying. I was able to.

Speaker 3:

What I did is I built out my in the entire blueprint and I put it into A project plan and microsoft project linked that to azure devops.

Speaker 3:

So then all my project and all my tasks are there and then I could have my con bond boards for what I'm studying, actively studying what I've completed and then have my notes within there. I can tag issues for things I haven't figured out and I can have, you know, track my entire study progression, start to finish. And it was a little bit of overhead work to get all that in and maybe it's excessive for some people, but having that all there and being able to track those issues and, you know, being able to link those within the wiki, because I built the wiki and in azure devops I built that out and then everything was all my notes were in there and then I could tag different tasks. So you know 5.1, 4.2.b, I can tag all those so I know when I'm at with studying, to the blueprint, and then all your repos are all built right into azure devops and so it's like everything was just right there and just clicked for me and made it a real easy way for me to consume it all.

Speaker 2:

Did you get your pmp while you did all that?

Speaker 3:

No.

Speaker 2:

Because that sounds like project manager to me right there. That's awesome, though that's very structured.

Speaker 2:

Yeah see, I I struggle with that when I do studying, trying to come up with a plan on how to tackle it, because I, like you mentioned at the very beginning, you know there's a bullet point and then I start kind of digging into that bullet point and then I'm like, hey, what if I could do this as well? Or how deep do I need to go in on that bullet point? You know that happens to me all the time, like I feel like I got to over study it or something.

Speaker 3:

Um, so I can relate to that right, um, a lot of it was keeping really good notes with what websites you're going to, because you'd go to 150 websites a day trying to figure something out.

Speaker 3:

And you'd finally find the answer and you'd wake up in the morning. You know, like I know that was somewhere, but I don't know where that was, and you're like digging through your history and there's way too much there to figure out which one it was. It was 3 am and now it's 7 am. You got just a few hours of sleep trying to work and then trying to remember where you were. So what I did is I kept all that stuff as I go.

Speaker 3:

I made sure I did everything in the wiki. I just trained myself to have it all in there so that I wouldn't forget. Everything was. Every page that I liked was a link, and then I would go back and I'd clean it up if I started to go back and reuse it and I'd link those two to things that I remember seeing and ways that in solutions that that could have helped me. Um, and just started building out of this to me, this pathway forward, you know, because I had my combine board and I'd move stuff over to completed. Like I know, I got that question correct, all right, so I know this is right. There's no other way. This could not be right.

Speaker 1:

Although.

Speaker 3:

I was wrong a few times on that. Yeah, um, and so I, yeah, just went through all of them and it was. It was a Miserable few months.

Speaker 3:

I'll admit it, but I really do enjoy the topic. It's just you know, if you've ever gone through an IE and anyone who ever has knows that it sucks your life away. There is no other heart of this. You got to have a really loving wife and a really understanding family to understand that they need to leave you alone and let you study so you can accomplish this goal of yours, or else it's going to be impossible.

Speaker 1:

So how do you go through that journey of studying for any expert level certification and not burn out and maintain a sense of balance? I mean, yes, you have to have an understanding family, but you still have to spend time with the family. I mean you can't lock yourself away 100% for 10 months and study for the thing. Yeah, I don't know.

Speaker 3:

I don't know.

Speaker 3:

It is yeah, my first one. I would wake up at three for my route switch. I'd wake up at 3am every day and I would study until 7am, where it was time to go to work, and every single second at work when I was free I'd be studying. I'd get off work, drive back home and then I would study until about 10, 11 o'clock at night, and I did that every day during the week and I worked at a minimum. I forced myself to study eight hours on Saturday and I did. My day off was four hours on Sunday and I did that for a year and a half. Wow, golly, that's what I say when I way overstudied In this one.

Speaker 3:

I did not take that approach because I knew better. I went and I found out where my weak points were on the exam and I took that and then had my plan with Azure DevOps. I had my plan and I'd worked towards my plan and it kept me on track way better than where I was. Just, I don't know. Let me go over BGP again. I don't know what I'm going to do today, and so this really kept me on track until where I was and what I was working towards, and then, once I thought I was ready, I went back and I took it again and I did a little bit better and then I had to recalibrate, go back to my common board, drag that stuff back. Nope, didn't know that as good as I thought I did Start back over until eventually I probably passed by the skin of my teeth. I don't know, that's a really hard exam. To say that, you just know it. It's a really tough exam.

Speaker 1:

Wow. So can you compare the number of hours you put in studying for the DevNet expert versus the IE? I mean, you did like eight hours a day, six days a week and then a four hour day one day a week and you didn't over study or you didn't study as much hours wise.

Speaker 3:

Right. So someone asked me the other day I put around 1,100 hours in for the DevNet IE over eight months after work, after school work, because I'm in college too, so after school work and that. So I made for some long days, had a goal and had an understanding wife that was supportive of it. I don't know why I had that goal, but I did.

Speaker 3:

But I'm glad. I'm glad it's over with. Can't say I've put a whole lot of it to good use yet Looking forward to putting it to good use. But I do have a heck of a lot of appreciation for those guys that wrote it, that's for sure, as much as I might have cursed their name in the past when I was studying. There's some good dudes and they know what they're talking about. With a lot of this stuff it's a very intense exam. The design portion was far and above harder than the config portion.

Speaker 1:

Wow Okay.

Speaker 3:

I don't think I can talk too much about why it's harder. It's just harder, Trust me it's harder.

Speaker 1:

Don't underestimate your design portion.

Speaker 3:

Yeah, you might think you're right and it might seem like the most logical answer to you, and I thought I passed the design portion in my first attempt. I was like duh, it's got to be this one. No, I think overall, on my first attempt I scored like a 10%. And so, yeah, just don't underestimate that design portion, because it'll get you.

Speaker 2:

But, like on your first attempt, you didn't. You had no study or anything like that, you just did it to get your feelers out right.

Speaker 3:

Well, yeah, I mean, I had been not studying for this, but I had my associate, I had my core exam. I had been trying to do this for a while. I had my own lab, my own setup. My entire home network has set up infrastructure as code. I do this stuff quite a bit just for myself, not only for work stuff, but I do it for my own fun, and so I thought I knew a lot of this type of stuff. But yeah, no, I didn't. I had a whole lot of learning to do.

Speaker 1:

All right, I want to pivot a little bit with your background and what you do for work and consulting and having all the experience with the IE and the DevNet expert. Let's say you're talking to someone that's wanting to get into network automation. Where would you guide them? What would you send them to for resources? Where would you tell them to start? Would it be something like an Ansible or would it just be Learn Python, or is it something else?

Speaker 3:

So I would ask them to find a problem you want to solve, in the same way we were talking about with helping a customer find something that you want to do. Keep it simple, very simple. Let's just say this isn't even a real world application. Let's just say, hey, you know, what would be cool is if I can just configure these VLANs from this switch. All right, awesome. Well, go to you know, just look it up, google it See, go to chat GPT and ask it's the right one.

Speaker 2:

That was one of my questions I was going to ask you.

Speaker 3:

I've been waiting all night. Yeah, go ask it to write you a Python script to do this. But then ask it why and how it works, and learn and understand how that works. And then but I wouldn't say just to pick one thing I would say look at that one thing. Let's say, configuring a layer three interface, a loopback or whatever. Learn it with Python, learn it with Ansible, learn it with Postman, learn it with Terraform I don't care which one you do and then figure out which one you like, figure out how it works for you, which ones do you understand more, which ones do you enjoy more? And then learn more about.

Speaker 3:

Okay, let's say I want to configure EIGRP. Let's say I want to configure you know, two different types of devices. Let's say I have, you know, I have Linux and a switch. I want to configure both of them. So which tools will allow you to do that? And then build on that story with all of the tools, find out which ones you'd like and just keep going.

Speaker 3:

Hey, you know I did this. This is the exact same thing with Ansible. I wonder what this would look like in Python, I wonder what it would look like in NSO, I wonder what it would look like in Terraform, and do them all. I wonder what it would look like if I just wrap this up in a docker and let GitLab push out for me. Just keep with the same problem and just keep trying it different ways, and then you'll be amazed at how fast you start to pick all of this up. You might seem like you're taking on 20 different languages at once, which might seem counterintuitive, and maybe a lot of people wouldn't agree with me. When you start to do that, you start to realize how each one of these tools can fit together and how they can all work together versus I know Ansible, and if it's outside of Ansible, don't ask me. So I just say go for it. There's a whole lot of resources out there to do the same exact thing. Go, try them all.

Speaker 1:

I like that approach because you're taking something that you know how to configure a layer through an interface. You're familiar with that as a network engineer, right? But the concepts of doing it in those different platforms are new to you. So you're taking something you know and you're learning how to do it a bunch of different ways and, like you said, you'll probably settle on a way that you like best by trying it all out, right?

Speaker 3:

Yeah, I mean maybe. I don't know if this analogy works. When we all learned routing protocols for the first time right, you had the first one you learned, and man, that was cool. And then someone tries to teach you another one and you're like, wait, but this one already know how to do. You're like well, hold on. There's benefits, there's positives and negatives to each one, and you need to know when to use each one. That's the same thing with automation and all of the tools out there.

Speaker 1:

Yeah, no. I think that's a solid analogy. Yes, For anybody studying for the Cisco DevNet. What could you recommend to them? You know, within the scope of Cisco NTA, right Like yeah, so one.

Speaker 3:

I would read that model driven dev-off book. It's going to give you a good reason of why behind it. Then the next major resource that I used was the Azure well-architected frameworks. I used those quite a bit and none of it directly ties to anything. It's not like you're going to find some question that was derived out of there. This is just understanding your software development methodologies, and there's a lot in there for designing hybrid cloud or designing on-prem and to migrate to cloud or cloud only, cloud native and all of those, and how you design your software differently, and I think it's a very well put together, well-architected framework. That's what's called, but I think they did a very good job with that documentation. Aws has one as well.

Speaker 3:

I did not rely on that one as much, but I did compare and contrast, but I just for some reason gravitated over to the Azure ones just for the format. I guess there's no reason why, but I did read those and I read them. There's quite a few hundred pages. I probably read it a dozen times and then what other one was there? Actually? Let me go find it, because I answered this question not too long ago. Oh yeah, the Google SRE, I think is a great book to read and understand and I call it a book whatever. It's free, just go look it up there and it is a great way to see an enterprise and then how to go and still change in that and then how to have your operational environment work in a scalable, sustainable, reliable fashion. So I really did enjoy the Google SRE books and they were directly applicable to what I was trying to learn. For the DevNet IE, there is the 10-factor app. You should know that one. You should know and understand OSWAP principles that's right there in the blueprint and those were my main reading ones that I can remember, besides just Googling and finding other code repos and reusing other people's code and going to developersyscodecom and checking out all the different videos and courses that they have on digital-learningsyscodecom whatever their learning library that's out there. So going through the NSO courses, going through ACI automation and all that type of stuff, and then that was it.

Speaker 3:

Just had my small little lab and you believe it or not, my lab was tiny for this. It's not like you got to replicate automation over thousands of devices to see the fact that it's going to happen a thousand times. Right, I had two IOS XE just 1000Vs. I had two NXOS devices sitting in all in CML and then I had the client workstation, cws. That it's an OVA that you can download from Cisco.

Speaker 3:

That is the exact OVA that you will be using on the test. It is the exact Linux machine that you're going to see so you can get comfortable with the environment of what you have. All the exact same tools are installed on there, all the same packages and versions and all that is all right there for you to see so you can start to play with this and understand kind of the nuances of the version differences, because they post that requirements text for you so you can see all the versions that you're going to be tested against. So if there's a nuance in that, if you're trying to do you know something and it's fixed in this version, but in the version you're using, as you can't do it that way or that, that feature hasn't been implemented yet. You need to understand what you're at with your requirements dot text. So highly recommend using that client workstation or, when you got pulled up, I think, cws, something like that.

Speaker 2:

When you go get the blueprint.

Speaker 3:

You'll see it right there on the website.

Speaker 2:

So you mentioned your small lab. What were some of the tools that you use like? Did you use Ansible in your lab, or what were some of the different automation tools that you did use?

Speaker 3:

When I was directly studying for this. So get lab CICD. That's what I learned for all those CICD portions. Then I had, you know, ansible for everything you know Terraform, nso or your Python PyATS, all those things that you're going to see in the blueprint, and then the ones that you don't have in the blueprint. You know you're going to have your always on sandboxes for from Cisco and I use those heavily for all the rest of the things that I didn't have, and you could use the always on sandboxes for your if you don't have a CML instance set up. I just had CML stood up and use that, so it was great for it.

Speaker 2:

So would you recommend the CML then?

Speaker 3:

Oh, cml is fantastic. I can't believe we. I can't believe we learned anything without it. It's an amazing little piece of software that I shouldn't call it little people with a lot of work into that. It's amazing piece of software that you can use to put anything. That's a anything. You can virtualize network functions and put it in there.

Speaker 3:

And I got I have Windows, windows 20, 21 or whatever it is domain controllers in mind. I have, you know, full PKI, windows PKI set up in mind. I have a full SD WAN in hierarchical SD WAN deployed out in it. And I got all these laptops are in the one things I don't have in something like something like ice and my controllers and all that all sit outside of CML. But it directs Connectly into my environment so I can ping from my laptop into paying my virtual devices right now. So it's fully connected and routed. My the edge CML device, which is a 1000 V, has OSPF neighborhood ship with my actual Cisco switch sitting outside of my server. So it gives you full connectivity all the way through. You spin up a you bunch of VM in there and pseudo up, get update and bam, you're off and running.

Speaker 2:

So you know, the internet gets it right yeah, it's fantastic.

Speaker 3:

I absolutely am a huge proponent of CML.

Speaker 1:

Well, why the testing? Automation well, while you guys were talking, I found the the details on the candidate workstation and the requirements dot text that Ben was talking about. So I will definitely put that link in the show notes. But it literally goes over all the different virtual machines, the specific versions, what all is on the candidate workstation, every single application, the specific version of everything. So drop that in the show notes for you to reference and build your own definite expert lab.

Speaker 3:

Yeah, they're definitely not trying to like trippy, trip you up and hide something. It is all right there. That's comprehensive if it is not in that those requirements dot text, it's not going to be in Python, you don't have to worry about it. So you can kind of understand and start to build your logic around how you're going to study this for what you think you might come across. See.

Speaker 1:

So I mean, I guess, with that in mind, if, if it's not on the list, you shouldn't study for it, right, or you shouldn't really put a whole lot of effort to it, and I guess to say, is it worth it to try to go learn some other tool? Can, while you're in the definite lab, can you install, you know, your own binaries or the tools that you use on to that Linux machine, or is it, you know, walled off from the outside world? You can only use what's on there.

Speaker 3:

Yeah, it's totally air gapped. But to your point, yeah, there is some benefit to go out and learning this, the other portions of it because it's going to be something you want, you're going to want to use today and if you look at that list, it's quite a few versions behind what would be considered standard and secure today. Well, they have to have a cut off point right when they're developing this test. They got a, they got a, have a fork and this is how we're going to test it. Because if you're, if you're paying X amount to go take this test and fly out there and get a hotel room and you have a bug that you run across looks bad for everybody and then you have unhappy test takers so that they they it's quite a few versions behind, but they picked very stable things that they understand and know.

Speaker 3:

This is where we might run into an issue and here's how we can alleviate anyways or not have that part be on the test, and that this is just my logic. I don't know that. That was my understanding when I was so, yeah, don't expect this to be like, hey, this is what I can use in my environment today. Well, because it's going to be way out of date. You don't want to do that. And I'm not saying it's way out of date like what you're going to learn is unusable. It's out of date is in like compliance, security and there's a few newer packages that might make things a little easier for you.

Speaker 3:

You know, as Python go rows and develops stuff like that, and then also remember to your question is that the requirements dot text is just Python is still Ansible, terraform, you know get lab, cicd, still a whole lot of other aspects out there, and you know, looking at the blueprint you could still see. You know FMC, dna, aci, learning to automate with all of those. So they're still outside of what you're going to see in just Python. You're going to have to. Maybe do you know some sort of long chain of Ansible kicking off a pipeline to go do terraform to configure some switch, just making stuff up. But there's, you never know what snare you're going to be getting in there.

Speaker 1:

Wow, wow, ben, this is. This has been a lot of fun. This, this is a lot deeper than than I guess I expected, although you know I have not actually looked at the DevNet expert track yet myself. I've done the DevNet associate. I would like to do the dead net professional. I had grand visions of tackling that last year, but work at work at other plans as we. As we wrap up the show here, dan, are there any last minute questions you have for Ben? And then Ben, is there anything that we should have asked you that we didn't?

Speaker 2:

No questions here. I'm curious to see if Ben has anything we should ask him.

Speaker 3:

No man, I really should have come up with something. So I sounded really smart there, but Didn't happen?

Speaker 1:

Are you on social media LinkedIn anywhere people can find you if they want to learn more about what you're doing? Do you have like your own get repo where you show off which what you worked on?

Speaker 3:

No to pretty much all of that. Oddly enough, yeah, I mean I nerd. I nerd to pay my mortgage and I nerd to retire as soon as possible, but my life is outside of a computer as much as possible. I don't do any social media. I don't have anything like that. I don't have, I don't have any public repos About. The close thing you can find is my LinkedIn and I have about three words on there yeah, don't really use that that much, so not a real huge presence out there. I enjoy doing this stuff and I enjoy working on it. Thankfully, because I'm stuck doing it quite often, way too often. But yeah, after work now I don't, I don't do any of this type of stuff.

Speaker 3:

Yeah yeah, I don't know. I stay far away from my phone.

Speaker 1:

Yeah, some days I want to drop mine in the lake too. This has been a fun conversation and if you're enjoying the conversation, you can support us by leaving a review on Apple iTunes or Apple podcasts. Rather, there's also a new Spotify rating system. You can rate the podcast on Spotify and if you haven't done it yet, definitely go check out our new podcast cables to clouds. It's a hybrid networking podcast with three network engineers that have made the shift to hybrid cloud networking and they're sharing their experience or interviewing guests, and they're having a really good time.

Speaker 1:

Episode three was released earlier this week and I'm sure by the time this episode drops, they'll be out to like four or five, so you can check the link in our show notes for that, then. Thank you so much for joining us this evening. This has been a really fun conversation. We'll catch you all next time on another episode of the Art of Network Engineering podcast. Hey everyone, this is AJ. If you like what you heard today, then make sure you subscribe to our podcast on 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 NetEng. You can also find us on the web at ArtOfNetworkEngineeringcom, 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.

Interview With Cisco Certified DevNet Expert
Networking Certifications and DevNet Exploration
Network Automation Framework
DevNet vs CCA Route Switch Comparison
Tips for Studying and Understanding Blueprints
Guidance for Getting Into Network Automation
DevNet Expert Track Overview and Materials

Podcasts we love