Zero to Hero: Building Config Automation With Nautobot, Part 2

Network Automation Nerds podcast. Hello and welcome to Network Automation Nerds podcast, a podcast about network automation, network engineering, Python, and other technology topics. I'm your host, Eric Chou. Today on the show, we continue our conversation with Anthony and Christian about going from completely manual network operation to robust, usable, and practical network automation in a relatively short time. Last week we covered kind of their introductory and their first project. If you want to catch up on that, the link is in the show notes. So this week we're going to continue to explore more of their operations, their lessons learned and all the best practices. I'm excited to dive into it. So let's get into it. Well, I guess welcome back, Christian and Anthony.

Thanks Eric, glad to be here.

Yeah, so I think last week we obviously in part one, I should say that we talked about where we left off was lessons learned on the first project. And you guys brought up very good points about, you know, maybe think ahead on the device capabilities and other tool sets that you have in the ground. Do you want to give us a little recap of what that first project was about, Anthony?

Sure. Effectively, we wanted to reduce toil, streamline processes, increase configuration consistency, so on and so forth. All the typical things you think of when you think automation and orchestration. We hyper-focused on router replacements. Streamline router replacements. Get structured data from the old one. from the old router, render it through new templates. push it to the new one, integrate some IPAM data from our IPAM system, so on and so forth.

Yeah, so I think that that's great. I mean, if I remember correctly, you were talking about you were going under you were going through a network refresh. So that was like a perfect opportunity because it's not a brownfield. It's almost a greenfield. Right. So you're more free to do any kind of experiments or operation. Not that they're easy. I'm just saying there's less less, I guess, strings attached to those kind of projects. So that's great. So after that, what are some of the day two operations? You mentioned the lessons learned. So were you able to implement some of those, I guess, from lessons learned afterwards?

So once we got this thing off the ground, we definitely had some post deployment discussions. We explored a few things. We kept trying to expand the tool in new ways. This is where somewhere in this era we started looking at… you know, declarative configurations. Okay. All right, so for day two operations. How do we manage configs with structured data? and When you talk about merge versus replace, that's a big thing. That's where you really start finding some hardware limitations. Not all vendor operating systems can handle a full config replace. And that's not uninstall or uninstall everything and reinstall your new configs. It's just resolve the deltas between your running configuration and your intended configuration. –

Yeah, back to that state again, right? –

Exactly. We started getting this mindset where, okay, running state and intended state. they should be the same, right? And if they're not, maybe report on it, send a message to somebody, say, hey, there's a Delta that needs to be resolved. So tracking state, like we were saying, is pretty difficult, right? Like, you know, for example, if you've got a trunk port or something with a long list of VLANs and you need to remove a VLAN and add a VLAN. Well, imperatively you would log in, you would run a command to remove the VLAN and then you'd run another command to add the VLAN. Well, if you were automating that… you would have to track state of the VLANs on that interface, right? So you'd have to know what VLANs are there. So you know if the one that shouldn't be there has to be removed, like, okay, you got to remove it first. And we built a little tooling around that and it was. Pretty difficult and not super user friendly. This form would pull in the VLAN data and the user would say, "All right, I'm going to remove this one and then add this one." I think the extra step of tracking state and having to remove a thing. really adds a lot of… overhead in the whole process. I think if we can, you know, at this point, we're like, okay, if we can just boil it down to, let's define the intended state. And that's all these are has to do, like, how should things be configured? And then, you know, we'll take care of the rest.

Yeah, what about you, Christian?

Yeah, I can. So yeah, I remember at one point during this we started to try to build on the existing tooling we had. As Anthony said, we were we were looking for something or we could define intended state of a device configuration. And I remember we explored with the existing tool we had for developing Jinja and YAML and trying to save full device configurations as YAML files and use that as the source of truth for the configuration data. It got kind of complex because we have lots of devices. So we had, you know. we would eventually end up with like 200 something YAML files. And I remember one day whiteboarding with Anthony, we were trying to build out like, rather than use a database, we were trying to use the file structure on the Linux server and we made folders for like each vendor, right? We had Juniper, we had Arista, we had Brocade folders. And underneath that, we tried to divide things up into like… access switches and then aggregation switches. I'm trying to organize our YAML files in a file tree that would be so that you could easily find them on the front end of our application. But it was not super user friendly. It was in the direction that we wanted to go, but it didn't seem like it hit all the right notes for what we were looking for.

Yeah, I think I've seen. two different approaches, right? One is what you describe as you organize them by function and then by vendor even just because each between vendors that are so different. And I've seen where in environments that it's relatively simple and then they organize them by features. So, you know, like these are all the L2s that I want, right, regardless of the vendor. So I would have these L2 and let's just say this port needs to be in this VLAN and I will have that declared. declarative on the VLAN. But I will have another operations that to check whether this is a Brocade, a Juniper, an Arista, or whatever, and then accordingly apply the necessary configuration. So I think those are the two approaches I've seen. But you're right. This is not an easy problem, right?

Yeah, it's not. Especially with the fact that we were trying to build the front end for it and make that nice and clean and usable. Yeah. We were trying to handle the back end and the data storage. It was becoming a bit overwhelming. The code base was messy at this point and it was hard to manage.

Oh my God, that's like, that's your hero's journey right now. You've hit the obstacle. Anthony, bring us back and give us a happy ending. Please.

So we get this tool off the ground. We're flying the plane. Everyone's using it, you know, a typical, some process that would normally take like a week or so. Yeah. It's not being done in 20 or 30 minutes. And when we install the new, the new routers, for example, it works the first time, right? Your OSPF adjacencies form great. IBGP forms. Awesome. Incredible every single time so we got a ton of value out of that tool. Yeah, so with our lessons learned well We made some career moves here. At some point, long story short, we both ended up at Northeastern University, where we– OK. Okay, another higher ed. And they were kind of in a similar scenario. So we kind of had a hard reset, right? So it's like, okay, let's do this again. And this time, let's see if we can do it better. Now, in the space between working for the first higher ed and Northeastern… We discovered NetBox and Nautobot. A guy on the RC team was like, "You guys need to look at this." "New rack elevations and cable runs and devices." You're currently working with a sea of spreadsheets, distributed spreadsheets all over the place. Why not use something like this instead? So after some exploration and tinkering, we landed on Nautobot and discovered that Nautobot really is a good platform to do… what we had already done at University of Georgia. and Yeah, the good structured framework is built on Django. It's got a database, clean GUI, and it's extensible. And there's a rich ecosystem of plugins, great community support. So that's the direction we set out in.

Nice. So, um. Well, first of all, I think we should get Network to Code to sponsor this podcast because we just did a bunch of plugins for them. But, you know, they're doing great work for the community. I know Jason and we had like five different people from Network to Code on the show. So they're really invested and their intention is very pure. You know, it's not like they're trying to make money. Well, they need to make money to sustain, but they're great contributors to communities. So we all thank them for their contribution. And then it's cool to hear that. So I'll be I'm curious just because you mentioned it. So worse was, did you look at NetBox before when you had the previous project and decided not to use it or was that not mature enough or maybe they were not aware in the community at the time and now they're just kind of growing up.

At the time when it was recommended to us. The person who recommended it had experience with both. And at the time, if I remember correctly, I think NetBox's limitation was they really had, they were sticking with the one purpose. philosophy of the tool like DCIM like really good data center infrastructure management. Yeah, right. And they weren't super open to to extending it to do things like, you know, network automation, straight from the NetBox tool. And You know, I don't know. I don't think it's that way now, but you know, I mean, for the most part, it wasn't just recommended that we use Nautobot if we're interested in automation. And so we're like, all right, let's go that way.

Kind of a philosophical difference that I mean, I understand both sides. Like you want to do one thing well, which is kind of, you know, like somebody, you know, one, one school of thoughts and the other is, Hey, you already have these and let's make it more enterprise friendly and solve more problems with these existing tools. Both are valid and as we saw, these are open source projects. So you're free to take them in either directions. And just like you have Red Hat, which is more conservative, and then you have the fedoras. So what are your thoughts about on that train or if you have anything to add for this new second generation of the toolset, Christian?

Yeah, I think it's interesting you pointed out the philosophical differences between the two. I think there's space for both, right? They both have their use cases. But just for us, really focused on network automation. Nautobot seemed to be the clear choice. I mean, right out of the gate, we made heavy use of the Golden Config app, which is great for us pushing configurations to devices. as well as, you know, just single source of truth for network config data. It seems to be right in line with that goal.

Nice. So what are some of the specifics that you can mention on– we heard about the architecture. And do you want to run us through the improvements? of the second generation tool that you kind of V2 of that V1 tool.

Sure. I want to quickly outline Nautobot and some of the things that are tangentially related to the automation stuff. Yeah, perfect. And of course, Nautobot here needs no introduction, but I'll give you a short one anyway. Sure.

No, no, please do. I think I for one, are not very familiar with all the features or the latest. So please do give us a great introduction for that.

So at its core, it's a data center infrastructure management platform, right? It stores all your data. So you have site data, you have rack data, you can do your rack elevations, you can create device objects. you know, cable data, you can plug this thing into this other thing and you can do things like cable traces and All your inventory, all your infrastructure inventory is sort of… documented in one place, right? And it's the single source of truth for these types of data. The configuration data aspect of it is really nice as well. I can go to a device object and I can see all the interfaces. I can see all the VLANs. I can see all the VLANs in a site. I can see the prefixes in a site, so on and so forth. So really automation friendly. Now, when I started this, I was thinking, all right I personally, I really like Nornir. Yeah. So I started a project where I would, you know, write, write some Nornir plays where they would run locally on my, on my machine. They would pull down the configuration data from Nautobot, right? Populate some variables. run them through a Jinja template and then configure a device. Somewhere in that process, I discovered a plugin, Christian already mentioned, Golden Configuration. that does this locally inside of Nautobot. So I immediately scrapped my project and was like, let me get this thing installed and see what it can do. And sure enough, there's an integrated, you know, they've integrated GraphQL. And so this plugin leverages GraphQL to query your data. Give me the config dataset for every device. Yeah. Run it through Jinja templates that are stored in GitHub, right? There's also an integration to Git which is super nice. Render the config, render the intended config and then store it with the device object. At any time, I can go to a device and I can look at its backup config, I can look at its intended config, and there's this third feature that is compliance, like config validation. I can use that to see. the deltas between my running config and my intended config. Ideally there would be none. That's kind of the check. That's like the validation process. So those are like, that's like the cornerstone of configuration automations, having those elements. Now the last piece was actually pushing an intended config to a device. So we extended it just with, I don't know, less than a hundred lines of Python probably. We just wrote an Nornir task to… push the intended config to devices. And it can be done at scale. A user can select one device from inventory or all devices in a site or all devices in our inventory. and run this task for all devices simultaneously. Right? Nornir is supporting threading. And so that's kind of the complete solution that we're using. We're still developing some of the workflows around it, but all the pieces work great and we're getting good adoption.

Yeah, anything you add there, Christian?

Yeah, maybe just to give an idea of a little bit more of the workflow, you know, we're also at Northeastern in the middle of network refresh, or kind of in the early stages of network refresh, replacing access switches and aggregation tier routers. So we're kind of taking that as an opportunity to onboard those devices into Nautobot and then drive the configuration from Nautobot. you know, as part of the replacement process. Kind of what that looks like is we have some Python code that can take the old, the existing old infrastructure, the access switches, for example, and import that data into Nautobot. There's some nuances, of course, with the backend logic of that because there's some old bad configs that we actually just want to ignore. Leave those behind. We don't want to import those in Nautobot because they're not good. And then there's differences between platforms and things like that as well that we have to handle. But we import the existing config data from the existing access, which is in Nautobot. And then we can create a new device, copy the data over. and then we can deploy it to the new switches that are gonna be the replacements, right? So that's sort of the workflow that we're using now. And taking this, like you said, greenfield sort of, you know, network refresh, router replacement as an opportunity, 'cause it's a lot easier than truing up our old configs to just push new, good, clean configs from Nautobot to the new devices.

Yeah, that's always safer. That's actually what I was gonna ask because… you know, this is public information, but in some of the environments I've had you would be surprised that people would just like write the new config in the the startup config, for example, and then just reboot the box. They don't really care what's out there in a running config. at the surprise frequency just because that's easier. And that usually leaves a bad taste in people's mouth. But anyway, it's kind of this thing that's complicated. And people have chosen different routes based on, again, philosophical differences. But in this case, you guys were doing Greenfield Refresh. I'm curious what would you… would have done if it was kind of an existing device where you have to you have to get it into the, the intended state, for example, right? Like what, what, what kind of. maybe like a pseudo code, right? What would you do?

That's a good question. And we're that's actually one of the projects on our books. Okay, and we have the machinery there to do that, right? The architecture I described earlier, kind of accounts for Greenfield and Brownfield. Yeah, the key piece for the Brownfield automation, or basically the workflow is, you know, We import the device's data into Nautobot. Now it's structured data. And we only import the pieces we care about, like Christian was saying. But then we turn right around and we redeploy. our new, the new intended configuration right back out to that box. And all the stuff that all the generational configs that have drifted over time, they're all gone and it gets all instantly gets all the new updated current configs. Got it. That's basically the process. And we just try to minimize the collateral damage. Right. It's all right. The blast radius is known, right? Like this is that one device and I imagine even if it's parallelism, but you're still kind of known. – Yeah, I mean, the nuance, accounting for the nuances was a huge part of the effort, right? Yeah. Oh, you can't miss that one setting that only exists on a small subset of our device inventory because if you miss that setting, then you break users. Yeah. So just another tidbit there is really try to reduce your nuance. Like snowflake configurations, snowflake networks, like artisanal networks are really, they add a lot of time to the automation effort. Yeah.

What about you, Christian? Anything to add there?

Yeah, Anthony touched on it a bit there that, you know, for for Brownfield deployment, we were pulling in the configs and Nautobot, but there's some configs that we don't want, right? They're old, they're bad. Coming from our network architect has kind of laid out what our new configuration should kind of look like generally. And it's drastically different from the old ones. We're making a lot of changes. So the issue is when you've imported some data, you're rendering a new config for your box, you see a lot of differences if you look at the intended versus running config. So now we're trying to work out, well, how do we make sure that we're not breaking things for users? How do we make sure that the same VLANs are still on the same user ports? Make sure that after the deployment that all the ports are still up and they're learning MAC addresses, for example. So we've written some scripts to parse through some of that data and look at pre and post and validate things, but we're still working through that process and trying to streamline what some of those operational checks look like.

Yeah, it seems like that 2080 rule, right? Like you really spend just 80% of your time on those 20% of nuances. This just leads me to, reminded me of situations where you know, like the leadership would say, Hey, you know, we have two vendors, like we have, you know, like a multi vendor, like a two vendor place and they compete with each other. We'll get great pricing. They, they, you know, we'd get the feature pushed through faster just because they're competing. Why don't we go for three or four or five? Let's go crazy on this and we'll save gazillion dollars. And that's just to your point, both of your points about It costs money, it costs people's time. spans and brain cells just to accommodate all those little nuances differences. I mean, when would be the day where everybody conforms on this one model where I just. You know, like do it, but I don't know. I don't have an answer for that. But the current existing situation is what you guys described. It's just all these little nuances like I cannot have in the front. I have to be a pain in the back. Speaking of…

I would really like to insert a call to action here for vendors who are pushing network operating systems that don't support config replace. Please implement this feature on all your switches. I feel like any good modern operating system should have that feature. There are other ways to deal with it, to reconcile between running and intended if you don't have a replace option. There's a repo out here., called hierarchical config, I believe., I haven't used it, but it's a good tool to have in your, in your toolbox if you must, but. You know config replace is just so clean so reliable please implement that in your operating. –

All right, so you heard it here, like vendors, if you don't have config replace, you're not getting Anthony and Christian's dollar. –

We evaluate that as like, I mean, we've sold this architecture internally so much so that, you know, as we evaluate new products to bring in, it's does this thing support config replace? And if it doesn't, then, you know, it kind of goes at the bottom of the list.

Yeah, yeah. Well, any additional thoughts there, Christian?

Yeah, and I mentioned earlier, but just reiterate config replace and also the ability to retrieve structured data from the device in some way. Let me get some JSON data or something like that via RESTCONF or, you know, even if it's XML from NETCONF, something just give me structured data. Yeah.

So let me follow that structure, the spreadsheet, right? Like you're not getting their dollar if structured data, which I feel like it should just be universal, right? Like if you're I mean, if you made it in 1982, fine, right? But if it's, if your box is made after, I don't know, 2010, you should have structured data. Even if you just pretend like I don't care if you put some bubblegums and duct tapes and just give me that. But so I could, you know, like you could improve on, right? Just, just have something that you can improve on later on. But those two, I feel. Yes, you know, there's definitely the must. So. So I think you guys mentioned it in the conversation where the lessons learned and for this day two project. And by the way, how long has it been since you guys were like just conversing and whiteboarding until like version two project? How long has it within two years?

I think so, maybe two, two and a half years.

Yeah, I would say so. About two years.

So that is super fast, right? I've been in situations where that, like just whiteboarding alone takes about six months. And then let alone writing the code right before like the first, you know, git commit. It's just whiteboarding and design thinking and so on. The UX. exploration. But yeah, so that's awesome.

I can add some additional context there. Like please, it wasn't just happenstance that we were able to get it done so quick. There are definitely some factors that directly led to that outcome. One, the network we were in the first time. was not You know, it was pretty artisanally crafted, but we didn't have… exotic configuration requirements. We didn't have exotic topologies. Like it was pretty is pretty simple and straightforward, which is a good thing, right? It met the institutional business goals for the network. It was good enough as minimum viable config for the most part. –

Right, flat layer two everywhere. –

It wasn't quite. –

Just kidding, I'm just kidding. –

Oh, the PTSD. No, we're actually currently dealing with that. So that's… one. But yeah, I mean, the UGA did a great job designing their network. There was, you know, layer three, OSPF, and then for the extensions, we ran a BGP, or an EVPN overlay with iBGP. It was great. Very good.

I didn't mean to cut you off, but like, please continue on the, you know, like kind of the thought process there.

We didn't have to digest a mountain of nuance. Yeah. That was the first thing. And then the second thing is leadership, the one that was willing to open a position on the team for a dedicated automation engineer, he's the same leader that gave us the time to do the experiments and the learning and the development and so on and so forth. And he didn't really He didn't really give us really tight deadlines or anything like that. He understood the process that you have to go through to get to the side of an initiative like this. So those two things were really key in the speed of our delivery. Yeah.

Well, anything to add there? I mean, just besides the timeline and more, maybe add a little bit more color to it. question

Yeah, I mean, I think Anthony hit the nail on the head with everything you said, the environment and the support from leadership and the fact that we had interest and buy in from other team members as well who are interested in automation. All of those things came together to help facilitate these projects that we were working for.

And I think that came from leadership and culture, right? Because if you don't have the support of the higher-ups, people start to deprioritize this, even if they think it's important. They just have so much on their plate. And then they just can't spare the time of day to talk to you about how about this config change that they need to do.

Right, exactly. Shout out to Jeff Friesi for– being a great leader. Yes.

Shout out to Jeff. I'm giving him like 2000 thumbs up and likes. I'm just that that just having the guts and the you know, like the that. the green lights for everything that you guys have done over there. Exactly.

And a quick note, I meant to mention this earlier, but after our first iteration, you know, the first big project, once we got it off the ground and people were using it, I went to try and get some feedback. Yeah. For the operations team that were using it, you know, we didn't really have a ton of communication with them. But there was one guy in particular who was like, you know, I saw this, I saw what you guys were doing. And I was like, we don't need to do that. Like, which is, you know, I can configure switches like way faster. Like I'm right. Right. Big champion. He's like, I started using it. Like I was done in like 30 minutes. Normally that's taking like a couple of days and I have to fix things after the fact. But when you use this process, it comes out the same way every time and it just works. So that was, we got a lot of buy-in by generating this thing that was user-friendly and at high value. We focused on that first. Yeah.

Yeah, I like the fact that you mentioned that because The design choice was to functional and the design choice was to be maybe not the when designer were like what Christian was saying, but it's functional and it offers value to people and it's to the to the config champion of the world that they really appeals to them. Right. Like, yeah, you could you could spend all day doing this. But, you know, last time I checked, there's no. like tour engineer out there, right? Or like nor will be in the future. You might be able to do this now today, but it's not going to be happening tomorrow. So why don't you, why don't we all get on this train? And then so now you could, you know, get off or work at five and go watch your son play soccer or like not get paged at 2am in the morning. Or if you do, you actually have a few backups and a new source of truth to check on and know what changed. So those are kind of the lessons that I took away when I was doing a similar process. So I'm happy that you brought that up and you got the actual feedback from the user.

Definitely. You know that all those points are really great.

Yeah, so I think those were, I mean, unless you have anything else to add, I mean, we could talk, start talking about like how it just kind of broad enough the scope, right? Like how can people get started with automation? I mean, those are very specific project and I'm I think we need more of these case studies, right? And I think that's one of the reasons that you reached out, Anthony, to want to share this with people. And I'm very, very happy. And I'm glad that you did that because these are sorely needed in the field today. It's just like, "Hey, I've done this and here are the steps I took. Here are the lessons I've learned. Here's how you could do it in your environment too."

Exactly. When we were first looking… There's a plethora of power tools out in the wild. Here's how you can automate VLAN changes. Here's how you can automate this, that, so on and so forth. I think there probably is some content around structural solutions, but I wanted to inject another structural solution. Here's a well-architected, or in my opinion, this is an opinionated solution for a well-architected config automation. effort, right? Yeah. I think over time we'll start hopefully we'll start seeing more of those and less of the you know the one-off scripts how to do a thing you know oh wow that's neat right. I think over time. the ecosystem will have a few really well architected solutions. At some point, I don't know when that is. It might be 10 years. It might be 20 years. It might be three years,

but oh, let's hope not. I don't think I could. I could wait that long man like yeah, but you know this.

Yeah, this one's open source. It's it's actually pretty low code for the whole end to end process and I mean we got some of our code originated with. I got it from somebody I met on the network to code Slack. He was like, "Oh, check out these jobs that I have that will configure your devices." I was like, "Well, that's perfect. That's the last piece we needed." That's the only bit of Python that we've actually injected into the process. Everything else is out of the box and you just configure the system according to the directions. You have a pretty robust solution.

What about you, question How can people get started with network automation? So I think Anthony mentioned about looking at the tools that's out there. And it seems like you cover 80% and that's only the last 20% and you customize that. What do you think?

Yeah, I think I agree with Anthony. I mean look at these tools, play around with them, NetBox and Nautobot. I'm sure there's other out there, but also– I don't think so. Please, prove that I'm wrong. I would like to know more tools. There may be a few like Bluewear, for example. I don't have much experience with Bluewear. But look at these tools. Also, just play around with Python and Ansible. And I recommend– you know, automate some simple things. I know early on, one of the first tasks I automated was I think our manager wanted to… wanted to see what ports on our access switches had been down for more than 30 days or something like that. So our simple Python script, it might have been between 100 and 200 lines, something not very long to just pull that data in and report on it, generate a CSV report that I could provide to management. So think about some of those things that you– maybe are kind of tedious for you now, you know, if you're doing manual network operations and think about how you might automate some of those simple things to kind of get your brain in that automation space.

Yeah, I like that too. So it means it's true about a structure solution, like what Anthony was saying. Like these are the structure steps that in opinionated way that you could do. But don't overlook these pointed solutions too, because that's how you get the little wins and those kind of encouragement that you would get. from just in these inevitable walls I would head into, right? Like I'm the same way. I mean, the first big encouragement that I got was… there's like a vendor bug where they're not coming out with a solution anytime soon, where I just have to go reload the boxes periodically just to bring it back into a clean state. And back then, I wrote a few lines of code and then just did just that. Obviously, we have redundancies and failovers and all of that. I was so surprised and so encouraged by that, that these developers were using my little script tool to accomplish that. And that gave me the necessary juice to move on and learn more. So these little wins are super important. And I like that about Automate the Simple Things. But to your point, Anthony, that really– structure solution that's end to end that go from like zero to something that's useful. More case studies like that. Please do share and I'm so glad that you took the time to actually organize your thoughts and share the knowledge. It's not always open. Let's just say that, right?

Yes, definitely. I would like to push my blog here. One of my resolutions was to write more and do some public speaking this year. So the first series that I've written about was sort of this architecture and the fundamentals, the fundamental components of the architecture, things that are good for you to know. Learn structured data, why it's important, learn templating, and then learn some config management tool like Nornir or Ansible or something like that. Those are like the fun. You can do everything we've talked about with just those three things. So learn those things and then the final parts of the series will be the Nautobot solution and the extension with jobs and so on and so forth. So if you follow it from end to end, the idea is you'll have a working solution.

Yeah, I checked out your– obviously, we'll have it in the show notes. I checked out your blog. And that was from JavaScript, right? Or not? Just kidding. No, it's very clean. So that's probably not JavaScript. I like how it's like that. No, it's like usual, actually. Yeah. That's what I was getting at. Yeah. Yeah. So anything to add, Christian?

No, I think, I think Anthony hit the nail on the head.

Okay. Cool. So besides the, besides the blog work, where else can people find you, do they follow you on Twitter or, just the blog as the main thing?

I'm on LinkedIn as well. Okay. trying to stay off too much social media these days. So keeping it down to LinkedIn and in my blog.

Yeah, you and I both, man. So what about you, Christian? Where can people find more of your work or they want to get in touch with you?

Yeah, check me out on LinkedIn and I'm a blog as well. I just put out my first blog post on there talking about effective coding, just how to write cleaner, better code, and I'm going to turn that into a series, so expect more of that.

Nice. Where is that at? Is that on Medium or is that on your own sites like QGo, like what I think did or?

That's on my, I have a GitHub Pages site, so that's what I'm using.

Yeah, you know, I see more and more people do that. And I like that very much on how well maintained that is. So that's great. I need to check out both, of course.

Excellent. Yeah. And the GitHub page is very easy to get started with. So yeah, low barrier of entry there.

Yeah, great. So, Thank you guys again for being on the show. I really enjoy our conversation, especially the authenticity, right? Like I don't think I could express enough gratitude toward that. It's just being real and these are truly happened and walk us through your thought process. So thanks again for being on the show, guys.

It was great. Thanks for having us.

Thanks for listening to the Network Automation Nerds podcast today. Find us on Apple Podcasts, Google Podcasts, Spotify, and all the other major podcast platforms. Until next time. Bye bye.