{"id":8052,"date":"2025-09-23T20:00:00","date_gmt":"2025-09-24T01:00:00","guid":{"rendered":"https:\/\/networktocode.com\/?p=10943"},"modified":"2025-09-23T20:00:00","modified_gmt":"2025-09-24T01:00:00","slug":"scaling-intels-data-centers-with-network-automation-sponsored","status":"publish","type":"post","link":"https:\/\/ddi.mohflo.net\/index.php\/2025\/09\/23\/scaling-intels-data-centers-with-network-automation-sponsored\/","title":{"rendered":"Scaling Intel\u2019s Data Centers with Network Automation (Sponsored)"},"content":{"rendered":"
<\/div>\n
\n

Eric Chou (0:05 \u2013 0:28)<\/p>\n

Hello and welcome to the Network Automation Nerds podcast, where we explore the latest in network automation from a practitioner\u2019s perspective. I\u2019m your host, Eric Chou, a network engineer who loves everything about network automation. Today, we\u2019re talking to Greg Botts from Intel, who transformed 5,000 plus network devices across 56 data centers with a small team. Greg started with YAML files and DNS records and ended with a scalable data center design that is the perfect foundation for AI workloads. In the process, he discovered that although not for everyone, sometimes open source solutions are better than commercial ones. This episode is sponsored by Network To Code, and I\u2019m joined today by my co-host, Ethan Banks. Let\u2019s dive in. Welcome to the show, Greg.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (00:29)<\/p>\n

Thank you. Thank you for having me.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (0:30 \u2013 1:15)<\/p>\n

Yeah, Greg. So before we start, one question that\u2019s kind of burning in my mind, even when we just initially talked, right, like you know this, that give us some context about your role at Intel and what actually drives the massive network infrastructure demand, because Intel to me has always been just manufactured, right? I go to Best Buy, buy my computer, and there\u2019s Intel inside, right? So what\u2019s driving these massive network demands for Intel?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (1:16 \u2013 3:27)<\/p>\n

That is a great question, and I think I\u2019m going to answer it kind of backwards. So I\u2019ll explain first kind of how we categorize our data center infrastructures. There\u2019s basically four different kind of disparate infrastructures, and maybe they live in the same data center. Some places, maybe they don\u2019t. We have data centers worldwide. But the four kind of categories, we have an acronym for it. We love acronyms. So our acronym is DOME, D-O-M-E. D is for design, which I\u2019ll get into in a second. O is office, M is manufacturing, which you were talking about, and E is enterprise. So my realm is the D and the E, so design and enterprise. Design is kind of what it sounds like. It\u2019s where all the chip design happens, right? That\u2019s all the software. I have no idea what our customers do. They\u2019re brilliant, and that\u2019s where they\u2019re doing all of the things that go into design, right? Even progression testing, all that kind of stuff. So for us, that\u2019s very heavy compute, very heavy storage. That\u2019s where we have our scale at the data center. They just beat the tar out of our stuff. The E, enterprise, that\u2019s kind of where we get a little more customized, a little more complex. It\u2019s like we host our supply chain systems. We have a lot of on-prem hosting solutions that are actually hosted in the enterprise infrastructure. Tons of web applications, that sort of thing. So again, for us, a lot of customization, a lot of security, a lot of different solutions we have to implement. A little bit more complex, not the scale of the D. So again, for me, I\u2019m kind of a senior network engineer for both those environments. Like you said, that if you total both of those, we run the same platform underneath everything. We\u2019re at like 5,500 network devices. So I do that, and then I\u2019m also on this little small team that helps automate against both the D and the E.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (3:27 \u2013 4:41)<\/p>\n

Yeah, I love acronyms too. So I\u2019m glad you broke it down into just D-O-M-E. And I remember in previous live, I was kind of in the same role on just managing, but they\u2019re just so different, right? Because in previous live, we have hyperscaler, the cloud, and the office, the enterprise. And they\u2019re almost diverge at the very beginning. Almost like when you\u2019re writing, there\u2019s like fiction and nonfiction. Because the enterprise tend to be very wide. So they need to do a little bit of wireless. They need to do a little bit of wire networking, firewalls, and all of that. That\u2019s very tailor-made, even at the office level. But the other side where the Hyperscaler that we want, they almost have to be concerned with just standardization. They need to do at massive scale. At scale, everything breaks. So the fundamental needs are almost diverging. So how often do you find yourself just kind of splitting between the two sides and switching hats? And has that been difficult for you? Or that goes into like your background, right? Like how did you come to Intel? And what was your previous experience like?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (4:41 \u2013 5:35)<\/p>\n

Right. So I think all total I\u2019ve been here with Intel, better part of 15 years. Oh, wow. I actually grew up, you know, computer science in school. First job right out of college was a Linux sysadmin or Unix sysadmin, which turned into Linux. Having that background, by the way, I think that\u2019s how everyone should start. Whenever anyone wants to get into anything IT, even if you want to be a developer, if you can get a little job as a Linux admin, if they even still have those anymore, that would be my recommendation. Anyway, I had a couple of, you know, I was more on the server side doing little Bash scripting here and there. What was the one that gave you response back? And you had to, gosh, it\u2019s old. I can\u2019t even remember it. Thank you.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (5:36)<\/p>\n

Expect.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (5:36 \u2013 6:22)<\/p>\n

Yeah. It was appropriately named. Anyway, so I joined Intel. I still wasn\u2019t even a network guy. I ended up morphing into a network guy and I started on the E side of things. So I kind of grew up in that environment, left Intel for a couple of years, came back and came back more into the D side of it. So now I kind of have both. And where we\u2019re going, and I\u2019m sure we\u2019ll get to this in a little bit, with our new kind of automation system and some of our new standards, we\u2019re trying as much as we can to kind of blend those together. We, you know, staffing is always short, right? And thin. So we really want, you know, the same network engineers working on both environments. And we\u2019ve come a long way in that regard.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (6:23 \u2013 6:31)<\/p>\n

You mentioned customers early on. And I\u2019m assuming your customers, Greg, from your perspective, are internal Intel folks that use your network to do what they do.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (6:31 \u2013 6:51)<\/p>\n

Yes. Up until recently, in the D space, now we\u2019re starting to get some external customers. And so we\u2019ve had to kind of put some overlay on that infrastructure so we can isolate workloads and be secure. We don\u2019t personally, right? We\u2019re more on the infrastructure side. So the folks I interact with, yes, 100% internal.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (6:52 \u2013 6:58)<\/p>\n

And then you also said 5,500 network devices. I\u2019m assuming that\u2019s multi-vendor, perhaps with a lot of diversity?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (6:58 \u2013 7:16)<\/p>\n

We\u2019re always kind of, it seems like, in between a migration, right? And so we\u2019re at the tail end of getting the last platform out. And those 5,500 are all, you know, varying SKUs, right? But same vendor, same platform. That\u2019s our ideal state.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (7:17 \u2013 7:19)<\/p>\n

Same vendor, same platform with common programmatic interfaces you\u2019re accessing?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (7:19)<\/p>\n

Yes. Yes.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (7:20)<\/p>\n

Lucky.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (7:21)<\/p>\n

Yeah, I know, right?<\/p>\n<\/p><\/div>\n

\n

Eric Chou (7:26 \u2013 7:28)<\/p>\n

You owe me a dollar there, Greg.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (7:29 \u2013 8:06)<\/p>\n

That was one of the coolest things when we did transition. You know, it was probably six or seven years ago. So it was before COVID, BC. We started bringing in a new network platform. And for us, the game changer was, you know, yes, they had awesome, cool interfaces and, you know, nice software that went with it. But for us now, every device came with its own API server. And that was, for us, a game changer. The previous platform, I mean, we had automation, but it was a lot of, you know, screen scraping and the automation had to be a lot more complex. So now we\u2019ve got 5,500 APIs out there, which really, like I said, that was a game changer.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (8:07 \u2013 9:37)<\/p>\n

Yeah, I want to double click on that because I think that\u2019s kind of the foundation where we move forward with. Because, you know, there\u2019s a great paper that you guys recently published, Scaling DC with SDN. And I want to give a lot of attention to that. If you haven\u2019t read that paper, I think it\u2019s a very honest, it\u2019s a very thorough paper. You know, sometimes I wish when I was reading it, I almost wanted to just click into it, right? Like I want to speak to the person who wrote that part, which happened probably somewhat to you, right? You were the co-author of that paper. And I think that went into a lot of your, you mentioned six year journey from, you know, just the 1.0, the orchestration, the automation, picking the vendor, going through that process of build or buy. So besides just pointing that paper, people who are interested will include that in the show notes. But if you could just walk us through on just the automation part on the very beginning, because, you know, it went through 1.0, 2.0, the design changes, you know, aggregation and interconnecting with, you know, quote unquote classic or legacy devices. That is a huge amount of tasks and that paper actually went through the whole thing. So if you just walk us through just the automation part, because we don\u2019t, we don\u2019t have days to go through that to summarize the six year journey, but just the automation part on what was that like if you take us to the beginning?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (9:38 \u2013 11:46)<\/p>\n

Absolutely. So this was the six to seven years ago, the BC, you know, time for network refresh, right? And, and so we had our platform, we had our, our stuff at the same time, right? We were figuring out like, what is our network design going to look like right now? We were going to do a leaf spine design. So we\u2019re figuring out what that looks like. We\u2019ve got a new platform. So it\u2019s a new OS we\u2019re dealing with, you know, and at the same time, hey, we want to automate all that stuff, right? So all of that\u2019s happening at once. In hindsight, that\u2019s, that\u2019s not ideal. It turns out, unless you have a really huge team, but anyway, so, so to start, right, we had to go quickly. So we, we did leverage our vendor had a really slick turnkey solution really around provisioning. And that was awesome. We started with that. It needed to be fed some data. So, you know, this is the start of this evolution that goes, you know, for several years, right? It needs some data. So like you alluded to, we started out literally with a YAML file, and then there was some part of the provisioning process where we had to do kind of a dynamic association between serial number and host name. And so we ended up using DNS text records. And that was like, that was our data, right? That was our version 0.1 of, of a network source of truth, it turns out. So anyway, we start there, right? Our enterprise, you know, it\u2019s working in the lab, right? We start rolling out some enterprise boxes. The system\u2019s working. The design side starts going and that\u2019s the scale side. And once that got going, the D, we, we outgrew that, I mean, in about a week, right? It was just not, not scalable. You know, you\u2019ve got this 10,000 file, you know, 10,000 line YAML file, there\u2019s a syntax, there\u2019s an extra space somewhere in there, right? And you gotta go deal with it. So not scalable. So pretty quickly evolved and took our little YAML file, DNS text record, and put that into a database, a proper database. You know, we had to come with the schema and that sort of thing. Then we needed a render engine, which I call a Rengin.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (11:48 \u2013 11:51)<\/p>\n

Did you copyright that or the Rengin?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (11:51 \u2013 14:12)<\/p>\n

It\u2019s really like, I couldn\u2019t, I kept saying it too fast. It came out Renjin. So we made this Rengin, which was basically a bunch of Python code that was, we had logic to enumerate the values, right? As we generate config. So like for instance, we kind of have the DHCP server for our ASN numbers. You boot a device, it needs to know what ASN number it gets for BGP. Some of them have to be the same. Some of them have to be different. We had that whole logic, right? That\u2019s all a bunch of Python scripts. We had VXLAN VNI numbers that we wanted to calculate. We had an algorithm. It\u2019s a Python script, you know, feed it your device name. It\u2019ll come back and give you, or your VLANs will come back to your VNI. We had Jinja templates to take all that data through, you know, run it through our templates and the end product is our code. Well, that Rengin needed an API server, right, for us to call as part of the workflow. So now we\u2019ve got this whole workflow. The vendor turnkey solution is still in there, by the way. And this is all this evolution, right? Step by step by step. And I keep saying we. Everything I just described was predominantly one individual, not me. I was involved, but we had just a brilliant guy, grew up as a network engineer, started growing in Python, and just has become a unicorn that you mentioned, right? Now, you know, his horn was developing over all those years. And so now we had a full fledged unicorn, which really enabled us to get there. And then the kind of the cliffhanger that I\u2019ll finish your question with is that all spanned about, I don\u2019t know, four years or so. And then we kind of hit this inflection point. So the vendor turnkey solution, their roadmap was changing. And the component that we leveraged a lot for the provisioning was going away. The, you know, it wasn\u2019t free, right? And the licensing was per device. And now we have a lot of devices. So there\u2019s a there\u2019s a dollar factor in there. And our system had just become very complex, right? That database now had tons of tables and some of them were needed for one thing. Some of them were needed for another. Some of them were for the D, some were for the E. It just wasn\u2019t very approachable for our team of network engineers to kind of participate. And then I always joked, right now we\u2019re one lottery ticket away from being in trouble.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (14:14 \u2013 14:19)<\/p>\n

That is your unicorn goes away. Now you\u2019ve got this homegrown system that no one else, no one else seems to know how to maintain.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (14:20 \u2013 14:24)<\/p>\n

We kind of knew, you know, we could manage, but yeah, it would not be ideal.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (14:24 \u2013 15:20)<\/p>\n

Yeah. Yeah. That\u2019s, that\u2019s not a winning combination, is it? Like it costs a lot of money and it doesn\u2019t meet your needs. And now it\u2019s going away too. That sounds like a crisis to me, right? Like if we were in the Phoenix project, that\u2019s like the highlight. It\u2019s going through like the hero\u2019s journey where you\u2019re faced with this mountain of challenge that you need to go solve. So what did you, what happened next, right? Like, so I think that\u2019s really the burning question here. So, you know, you have this commercial solution. You have a bunch of Python script, which what you describe as a lot of relationship between different components. When you\u2019re rendering in real time, I bet that\u2019s not very fast or that\u2019s not, you know, all the logic gets bundled into the code. And that\u2019s not very fun to manage. And, you know, you\u2019re relying on this unicorn person that to do manage it. So what happened next? Can you walk us through the next step of your evaluation process?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (15:21 \u2013 15:57)<\/p>\n

This was kind of the cool opportunity where we could, you know, step back and it was, and start from scratch, right? That\u2019s so rare, especially in a big infrastructure, but that was our chance. We weren\u2019t now designing our new network infrastructure anymore, right? That was solid and humming. So really we could just focus on automation piece. So it was time to go shopping. And the first thing we bought, we actually got a DevOps guy that I had worked with previously. Fantastic hire, very skilled in DevOps. So now we\u2019ve got, you know, a unicorn, a DevOps guy and half of me. So we\u2019re at two and a half now.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (15:57 \u2013 15:58)<\/p>\n

Nice.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (15:58 \u2013 16:22)<\/p>\n

Which I don\u2019t necessarily recommend as a number. Really it\u2019s, there\u2019s a lot of boxes you have to have checked for what skills do you need to pull something like this off, right? And it\u2019s a lot of varying boxes to check. And so now between the two and a half of us, all those boxes that we needed were checked. Maybe you can find one person to check them all. Maybe it takes five. We have two incredible folks.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (16:22 \u2013 16:27)<\/p>\n

But that person wouldn\u2019t have enough time in the hours in the day to check all those boxes, right?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (16:27 \u2013 17:18)<\/p>\n

That is also true. Yes. So now we are going shopping, right? And we\u2019ve got our list of criteria. And a lot of our criteria was focused around supportability. So we wanted off the shelf as much as possible, right? We knew we would probably need some customization because we do some weird stuff, but off the shelf as much as possible. Abstraction was really good to the extent possible. Open standards was a big thing for us. You know, not a black box, right? So if we could find something vendor agnostic, which in the realm of, you know, network automation, a lot of the open source stuff happens to be vendor agnostic. So that was huge. And we wanted a light administrative burden. Previously in our previous system, there was a lot of kind of overhead for sysadmin type work. I found myself going back to my first job out of college, right? And being a Linux admin and all that stuff. So that was our list.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (17:18 \u2013 17:27)<\/p>\n

So do you mean the overhead, meaning the learning curve you have for that specific tool, right? Like the unique aspect of that. Is that what you meant?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (17:27 \u2013 17:59)<\/p>\n

It was more the hosting part of it, right? So a vendor solution, typically, right? They\u2019ll sell you an appliance, maybe. Or we were kind of rolling our own. So it was a VM, but it wouldn\u2019t work in our hosted VM farm for many reasons. So now I\u2019m running a bunch of KVM servers. And I\u2019m responsible for the hardware, the OS stack, the KVM, which is what I was using, and then putting their stuff on. And then it\u2019s clusters of those. And then it\u2019s our API server and all of the things, all of our workflow, just a hosting burden, really.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (17:59 \u2013 18:19)<\/p>\n

Right, right, right. That\u2019s kind of surprising. But I think that makes sense once you explained it, right? Because initially, I was just thinking about the soft part of it. But yeah, a lot of times they stick into this uniqueness that only works with their thing. That combination, that winning combination that we talked about, right? So yeah, that makes a lot of sense.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (18:19 \u2013 19:13)<\/p>\n

That was a big item, I guess, on our shopping list, our criteria. So what happened was really cool. We went out to go shopping. And we realized the ecosystem around network automation tooling had just blown up since we last looked. And it was, I mean, it was a little bit overwhelming. But, you know, it\u2019s like, Steinzi, you had him on his map, right? We\u2019re looking at the map and trying to sort through everything, which was fantastic, right? So we had lots of options. Now it was almost too much. So we had to kind of narrow it down. We knew in our old system, that database that our unicorn had, you know, that schema, that was kind of our bread and butter. So we decided we need to start with like a network source of truth. And honestly, it was also attractive, because there weren\u2019t a lot of choices for a network source of truth out in the ecosystem. So it was a little easier to make a decision. It\u2019s like when I go to Costco, I know, you know, if mustard\u2019s on the list, there\u2019s only one mustard.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (19:14 \u2013 19:14)<\/p>\n

Right, right.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (19:15 \u2013 19:29)<\/p>\n

We wanted that. And then we wanted, you know, in network source of truth, it was like, let\u2019s find one that has as many features as we can get, right? Maybe it would be an extra bonus if it came with a Rengin, for instance. So that was our shopping experience.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (19:29 \u2013 19:44)<\/p>\n

I tell you, you got to copyright that term. I imagine from now on, you know, whatever rendering engine I was, I\u2019ll just start quickly to Rengin and think of Greg that first heard it here. Right. I was X years old when I heard it here.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (19:46 \u2013 19:51)<\/p>\n

There\u2019s probably a real word and I\u2019m just not up to speed on it. But that\u2019s my that\u2019s what I call it.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (19:51 \u2013 20:21)<\/p>\n

Yeah, no, it\u2019s great. So now that you have, you know, you went to Costco Trader Joe\u2019s where you have limited options, right? Like there\u2019s just a few options that\u2019s out there. So what ultimately what tool did you ultimately decide and what was the reason behind it? Because people might think they\u2019re the same. People might think they\u2019re different. And everybody, if you talk to the vendor, they will tell you what was so cool about them. But I want to hear from your perspective, like what was the reason that you ultimately picked and choose Vendor X or Tool X?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (20:21 \u2013 21:10)<\/p>\n

Yes. So we did end up open source and we went with a Nautilbot. And really it was, you know, the network source of truth stuff was there. Right. Now our data, you know, all our tables that we were all our schema, like it\u2019s baked in there. It knows that a VLAN can belong to a VIRF and a VIRF can belong to a data center and, you know, et cetera. So that was all there. One of the game changers, right. We also wanted more off the shelf features, you know, as many as possible. And so there\u2019s a, I don\u2019t know if it\u2019s called an app or a plugin. I don\u2019t know the nomenclature, but it\u2019s golden config. Okay. It\u2019s golden config. And that for us, that was something we were going to have to do. Right. That\u2019s like our engine. Right. We\u2019ve got all our data. We\u2019ve got our templates. Like, how do you pass that data through the templates and end up with a config? And that was kind of baked in. So for us, that was win. And that\u2019s where we started.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (21:11 \u2013 23:00)<\/p>\n

That\u2019s awesome. Because I remember when I, a lot of times when I read that Kirk Byers blog or, you know, other people\u2019s blog, it\u2019s always like, hey, you know what the best part is? Somebody else already did it for you. It\u2019s like, hey, you know, you don\u2019t have to live through it. You don\u2019t have to burn through the midnight oil. So, and I think that\u2019s what a lot of people ended up with open source tools as well. I mean, you could talk everything about the Linux core that\u2019s open source, but how many times do you compile that core and how many times do you, you know, work on that core, right? No. You take it as this. You trust the open source community, get enough eyeball on it that I trust that it\u2019s going to work. And then, you know, once that core is there, it\u2019s like, okay, what now? Right. It\u2019s all these little tools that\u2019s on top of Linux that\u2019s making it useful as the system admin. I think you would agree with me that it\u2019s not just the Linux core, but it\u2019s all these other tools that was previously established for Unix that\u2019s been ported to Linux. The PWDs, the LS, the CDs, and all these zip and tar, all these other small tools that\u2019s helpful. So, I could see why you ended up choosing a platform that already has a lot of apps that\u2019s baked in. And you\u2019re just like, hey, you know, why not? Let me just take it. But I also wanted to ask that, you know, it seems like going from a vendor solution to an open source solution is quite a big jump. Maybe not from an engineering perspective, but from a management perspective, right? Like, who do I call when there\u2019s an issue? What do I do when I wanted this feature to go into that software? Do I need to go hire people? So, all of these are legitimate concerns. Did you go through that with your management? Or was that just kind of a culture that Intel already have? So, there\u2019s not a big issue there.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (23:00 \u2013 24:06)<\/p>\n

We did. And that\u2019s a great question. And we\u2019ve had a ton of support from our management, whether it\u2019s technical management, business side management. And one of the big pros, you know, we weren\u2019t just getting random pieces of software somewhere. We were getting one that did have the option of enterprise support. If we wanted that, if, you know, we were between billing cycles at the time. But, hey, if this is going to look good and we want to scale this, there is that option out there. There is a company sponsoring it, right, that you\u2019re probably familiar with. So, having that as an option was another key piece of the criteria. The other thing is that you worry about with open source is maybe it\u2019s going to die on the vine, right? Or maybe the contribution goes away. So, one of the things that the DevOps guy that we hired, he had this idea when we were kind of shopping and comparing. He looked at contribution history, you know, over time and looked at the repos and looked at the commits. And I thought that was a brilliant idea. And, you know, the one that we ended up going with was definitely on the ramp. So, those two things kind of gave us the confidence, right, that it\u2019s going to be there for the foreseeable future. And if we want or need, you know, that enterprise support, that\u2019s a button we can push.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (24:06 \u2013 25:32)<\/p>\n

Yeah, it\u2019s not so much an issue now, but previously when, you know, when that first book came out, people had that question about Python, right? Like, is it going to go away? Is it going to have enough features or enough developers contributing to the features that I could bank on it with when I go to my manager and write thousands of lines of codebase just based on that? And in this case, I think you don\u2019t get a product for popularity, but you get it for the results that popularity brings, right? Like, that brings in attention, brings in money, brings in a lot of other, you know, conferences that people are liking it or like-minded people for bug fixes and so on. So, in this case, I think miscongeniality really tops the number one crown there. You know, popularity really brings a lot of benefits, not just because it\u2019s popular because of all the, you know, surrounding benefits for open source projects. So, it makes sense that you pick one that fits kind of that mode. And I think a lot of open source projects, they\u2019re being successful by having a commercial vendor backing it. You know, you think of Red Hats or you think of Elastic, you think of, you know, Kafka. So, all of these projects, yes, you could get far with open source, but at the same time, you could also get deep into it and you have, you know, backups if you\u2019re willing to spend some money to get the support that you need.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (25:32 \u2013 26:00)<\/p>\n

Greg, what I\u2019m curious about, you settled on Nautobot as a source of truth and there\u2019s a lot of other things that you can do with that tool. Okay, as you alluded to Steinzi\u2019s network automation landscape document that is just massive with the tool explosion. How do you see that landscape evolving? I mean, Nautobot\u2019s one piece of, I assume, a larger platform that you guys have built. Does that landscape consolidate over time? Are we just going to see even more tools? And what\u2019s interesting to you guys as far as that landscape goes?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (26:00 \u2013 26:05)<\/p>\n

I should probably go look at it because since we\u2019ve been shopping, it\u2019s probably blown up even more, right?<\/p>\n<\/p><\/div>\n

\n

Eric Chou (26:05 \u2013 26:06)<\/p>\n

Exponentially. Now it\u2019s like page one of 10.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (26:07 \u2013 26:43)<\/p>\n

Right. Some things that I think, right, kind of like what we would be looking as we go forward. One thing is around the validation, network validation specifically, right? There is some stuff out there. There wasn\u2019t a lot last time we looked and it seemed to be maybe not getting as much contribution action at the time. But that validation piece, right? We have all our data. What if we could, you know, before we push a change, you know, see exactly what is going to happen. And then after we push a change, you know, or take a snapshot, right? The copy, push your change, take another snapshot and see the diff. Like, did you just break something upstream? You know, that sort of thing.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (26:43 \u2013 26:55)<\/p>\n

Well, you\u2019re talking about like testing libraries, these kind of things. I had 1,500 routes in this OSPF autonomous system and I still have 1,500 routes. Or I have 1,510 and that\u2019s what I was expecting. That kind of stuff?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (26:55 \u2013 27:04)<\/p>\n

That sort of thing, yes. I just pushed a change down on this leaf, which was pretty innocuous. But did I just impact something, you know, on my service leaf?<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (27:04 \u2013 27:08)<\/p>\n

And now we can\u2019t reach our data center in Brussels. What the heck?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (27:08 \u2013 27:15)<\/p>\n

Right. Exactly. That to me seemed like an area where I would love to see some growth on that map.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (27:15 \u2013 27:37)<\/p>\n

Well, what are you looking for in that regard? I\u2019ve heard a lot of people talk about testing. And most of the wisdom seems to be everybody\u2019s environment is somewhat unique. And so you have to build your own library of tests and some of the tests you\u2019re going to learn the hard way. Had you only known to test it that one time, you would have caught that thing. Well, now we know. Next time we\u2019re going to test it.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (27:37 \u2013 28:01)<\/p>\n

And that\u2019s fine too, right? We do know our environment. And even, you know, I\u2019m talking about two different infrastructures that we\u2019re dealing with here. And so they\u2019re going to have different rules, right? This infrastructure, I don\u2019t care about data point X, Y, Z. But over here, I really do care about it. So, you know, we would be totally, I would expect to develop some of those. It\u2019s just, you know, all of the guts behind that. I want something off the shelf with abstraction. There was, you know, some stuff out there.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (28:01 \u2013 29:21)<\/p>\n

Yeah, like Batfish or, yeah, I\u2019ve had Ratul on the show before. And so, yeah. And he actually, you know, he\u2019s a professor at UW now. And I\u2019m a UW grad, right? So, you know, all the power to him. But I would totally agree. I think the validation and the, if you carried it forward enough to do digital twin, that you could simulate enough of your network, at least the important parts. You don\u2019t need the 5,000 devices, but you need the smallest deployment unit, your pod, to be able to test and have enough confidence so that you go into that maintenance window knowing what changes that you made. And so from just running simulation and algorithm to calculate, you know, so the thing with maybe Batfish or other validation tools was that they were able to use algorithm that you don\u2019t need to run it into the devices. You could do the, you know, the results output. But then at some point, you do want to run through maybe your virtual devices. Then you run through your physical devices in your lab if you\u2019re big enough that you could do that. So I think all these degrees of validation depends really on your size. And I do agree. I think at the end of the day, my point is I do agree with you. I think there\u2019s a lot of space that could be filled, but it\u2019s a big space. So where do we start?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (29:22 \u2013 29:44)<\/p>\n

And we\u2019ve done exactly what you said, right? We, you know, have a little bit of emulation software. You know, I remember one really complicated change. We modeled it out in the VM space, worked like a champ, rolled it out. And there was, you know, a certain toggle on the hardware side that you just couldn\u2019t emulate in the VMware side. And so, you know, there\u2019s, yes, there\u2019s a lot of holes that could be filled there.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (29:44 \u2013 29:53)<\/p>\n

Yeah, exactly. Like your microburst on the buffer between like your backplane, right? I mean, I\u2019m saying it because I have the scar to prove it.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (29:54 \u2013 29:55)<\/p>\n

Yeah, same.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (29:55 \u2013 30:24)<\/p>\n

Yeah, you know, I think that\u2019s a great observation. And only for someone who had lived through all of that, Greg, that really pointed out, then it makes sense to have that. But at the same time, I am glad that the community is thriving and really takes all of us to push any area that we see fit. And that\u2019s part of the beauty of open source, right? Like if you see something, you could go do something about it for me. So I don\u2019t know if you have any additional thoughts on that.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (30:24 \u2013 30:38)<\/p>\n

And we did just that. We saw something that we needed. And we were able to, and right, there\u2019s the community, right? Now you\u2019ve got an entire development team. That\u2019s huge, right? There\u2019s a Slack channel, folks are responsive.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (30:38 \u2013 30:42)<\/p>\n

May not always be polite or in the same time zone, but hey, the team is there.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (30:42 \u2013 31:07)<\/p>\n

It\u2019s okay. So we were, we were able to influence, you know, there was a certain, I don\u2019t know if it was a bug, right? But there was a thing that we really needed and it was like, yeah, here\u2019s what the problem is, was pointed out to us. We were able to, you know, my DevOps guide got in the repo. You know, we tested it out, found the solution. I think it was less than 10 lines of code probably. You know, did the pull request. It got merged in and solved our, what was going to be a huge problem.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (31:07 \u2013 31:16)<\/p>\n

And just for clarification, you asked for this to be solved or you actually wrote that code? Your DevOps person wrote those 10 lines and got the PR submitted?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (31:16 \u2013 32:05)<\/p>\n

He did. We got guidance, right? We were like, hey, this is happening, you know, because I don\u2019t know anyone\u2019s seen this, right? There\u2019s a great modeling of, you know, for a chassis device, right? That has a bunch of modules. We have this case where that\u2019s a good number in our D environment. That\u2019s a good number of SKUs out there are like that so that we can be flexible, right? This row needs, you know, that chassis is going to need 10 gig line cards, you know, four of them and 200 gig line cards. But in the next row over, it\u2019s vice versa. And we didn\u2019t want to model all those possibilities. So there was this great model of, hey, your device can have modules. You know, it mimics the, just swap out your line card, right? Your slot. That was working fantastic. We were trying to set up extra, like some peering relationships into those interfaces. And that part just, it was, you know, hadn\u2019t been tried, right? It wasn\u2019t a test apparently. So we needed that to work. And the Slack channel was like, hey, this is right where that\u2019s happening. Here\u2019s the URL to the repo.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (32:05 \u2013 32:08)<\/p>\n

So it was a combo of the community built around. We\u2019re talking about Nautobot in this case, right?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (32:08)<\/p>\n

Yes.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (32:09 \u2013 32:50)<\/p>\n

So it\u2019s a combo of that community and then someone on your team, the two and a half people that was able to do that. That was another thing I wanted to clarify. I mean, Intel, you guys have been involved as Intel, the bigger company in networking and having networking products and being on the bleeding edge of networking and so on for a lot, a lot of years. It\u2019s not like you had to tap into some deep inner Intel resource that the rest of us don\u2019t have to get done what you needed to get done. It was just someone that knows a bit of coding and was able to get it done with some help from the community.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (32:50)<\/p>\n

Exactly.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (32:51 \u2013 34:01)<\/p>\n

I think that\u2019s just so great about, that\u2019s what draws me in from the open source community in the beginning, right? Because now that you made the contribution, the next guy or the next person, you know, guy, person who faces that same issue, they could either use what you already contributed or they could build on top of it. And now everybody benefits. So I think it\u2019s great that you, your team have done that. And the two and a half guy, the sitcom, right? Like, you know, yeah, it\u2019s, it\u2019s just, just standing on shoulders of each other and this, you know, collaboration across different continents, across different companies. And I would be the first to tell you that a lot of these open source things are built for initially for one company specifically. And then the company was gracious enough to open source it. And now everybody gets to use it. So it\u2019s great that you\u2019ve done that. And, you know, I look forward to more of that from you, from other companies, and we can all benefit from each other. And I guess that\u2019s the model for Ubuntu, right? Like people who are holding hands and in a circle saying Kumbaya.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (34:02 \u2013 34:05)<\/p>\n

Yes. We\u2019ll join that circle. Yes.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (34:05 \u2013 34:52)<\/p>\n

Yeah, exactly. So I think, you know, we\u2019ve, we\u2019ve gone through, you know, just walking back our previous conversation and your experience, right? So you, you started with your needs for the company, you went shopping, you clarify, you know, the features and you picked a tool, maybe multiple tools that you mentioned or did not mention. You run through these tests, the features and make sure that they fit your needs. And now, what did you, what were you able to show for it, right? Like, at the end of the day, I saw some amazing stats from that paper on what ended up going from that journey, not a short one, but any specific measurable outcomes like your incident reduction, device growth, and that you gain from just going through all these pain.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (34:52 \u2013 36:31)<\/p>\n

The one that jumps to mind is, is our provisioning speed. Previously, right, it was a bit more dynamic, right? And then it starts doing, you know, where, who\u2019s my LLP neighbors and that\u2019s how we set our peering and, and things like that. So, and that\u2019s a tough one to measure, right? Because our network engineers are doing 10 different things at once and they\u2019re trying to provision something quickly. But we did some analysis and figured that was taking about eight hours, you know, to provision stuff. Now it\u2019s down, we conservatively said two hours. What enabled that was the ability to pre-build all of that stuff. So now they can upload a minimal amount of data, you know, into our network source of truth and it\u2019s enough to spit out the entire config. So now when that thing, you know, boots up, now ZTP process isn\u2019t just giving it the bare minimum to get on the network. Now, if they\u2019ve done that step ahead of time, now it\u2019s up on the network, it\u2019s appeared and it\u2019s ready for, for client connections. So that workflow really, that was an efficiency gain. That was pretty nice for us that we do every day, right? That\u2019s how we\u2019re keeping up with that growth. The other thing we\u2019ve seen is, and we put this in the paper, was incident reduction. I think if you go back to like 2020, we had maybe 12, what we would classify as major incidents across the landscape. And then if you look going forward in the D space, we had like four years in a row with zero. Wow. And some of that was a new platform, right? And we weren\u2019t dealing with capacity things. But a big piece of that, in my opinion, was the config standardization, right? We didn\u2019t have the one-offs, it\u2019s the one-offs that those are the landmines. Yeah. And we didn\u2019t have as many of those. So I think that attributed to some of those numbers.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (36:32 \u2013 37:18)<\/p>\n

Yeah, they kind of impact each other, don\u2019t they? Because of the repeatability, you change your mindset about what we could do. Because it\u2019s so easy to bring up new devices, maybe the solution today is actually to throw more money at it, right? Like, you know, because of business needs. Sometimes that\u2019s the right direction is just to have more capacity. And the capacity meaning, you know, more devices, more scalable, your leaf spine design, where if I read it correctly, it was like a five stage, right? So that\u2019s actually a little bit more than enterprises today. But at the same time, it is a very scalable design for now and for the future. So that, you know, we could have multiple options as opposed to the traditional, you always have to scale up as opposed to scale out.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (37:19 \u2013 38:08)<\/p>\n

I would totally agree with that. You know, we were constant in the old core distribution access, right? We were constantly chasing layer two issues. We were constantly fighting congestion. We architected the leaf spine for the peaks. Right. So now we\u2019re not spending our time dealing with congestion. We\u2019re not chasing the layer two issues because it\u2019s all plumbed out with layer three. And that led us, right? And then we turned around. It\u2019s like, oh, now you have this giant underlay, especially in the D, right? That five stage. Yeah. One that you\u2019re talking about. This is a huge underlay. So now when we came in, when we do get those external customers, oh, we need to isolate that workload. Well, I can do that with an overlay now. And I know my underlay is all standardized. It\u2019s all got plenty of capacity. I can just throw some overlay on top of that. And we were able to deliver solutions pretty quickly that way.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (38:09 \u2013 38:10)<\/p>\n

You\u2019re running a five stage clos fabric?<\/p>\n<\/p><\/div>\n

\n

Eric Chou (38:11 \u2013 38:14)<\/p>\n

You said five stage, right? Yeah. I saw that. I highlighted it.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (38:14 \u2013 38:15)<\/p>\n

One of our big ones, yeah.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (38:17 \u2013 38:45)<\/p>\n

Yeah. I mean, to me, that\u2019s always been the trick of scale out. If you want to succeed at that, you\u2019ve got to keep everything homogenous. It\u2019s all got to be same, same. As soon as you have one offs and corner cases and little weird things, oh, we have this one exception on this. No. No. You just have to say no. You don\u2019t want to be the guy that says no, but you have to. Or else the whole thing just falls apart. And how many, do you know how many access ports you\u2019ve got in that fabric?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (38:46 \u2013 38:48)<\/p>\n

Oh, I should have that number, but I don\u2019t.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (38:48 \u2013 38:53)<\/p>\n

It\u2019s got to be, yeah, it\u2019s got to be many, many thousands, tens of thousands, I suppose.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (38:53 \u2013 38:55)<\/p>\n

My network source of truth knows.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (38:55 \u2013 38:55)<\/p>\n

Yeah, yeah.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (38:56 \u2013 38:57)<\/p>\n

There you go.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (38:59 \u2013 39:01)<\/p>\n

You can do that with an API. Yeah.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (39:01 \u2013 39:25)<\/p>\n

API or GPT, right? Like, Nautobot just came out with Nautobot GPT. Although it\u2019s in beta, but hopefully one day we can actually use natural language so anybody could ask, say, hey, how many access ports, how many distribution ports do we have out there? Which brings me to the next question, which is AI, right? We have to mention AI because that\u2019s the day of age we live in.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (39:25 \u2013 39:28)<\/p>\n

You don\u2019t have to, Eric. You just did.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (39:28 \u2013 39:30)<\/p>\n

I resisted, but I resisted long enough.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (39:30 \u2013 39:32)<\/p>\n

You can\u2019t have a podcast without it.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (39:32 \u2013 40:14)<\/p>\n

Yeah, exactly. The AI police isn\u2019t going to come and get me. But yeah, you did mention about the huge underlay and something we didn\u2019t even touch on, the business flexibility, right? Like your agility to integrate new features and new requirements relatively easy without redesigning your architecture. So now that we have AI, which I imagine puts a lot of stress on your infrastructure or did it? So what is it about the automation that you built, the infrastructure you have underneath that enable you for the new possibility that\u2019s what we will generally label the AI, right? The trainings, the usage.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (40:15 \u2013 41:33)<\/p>\n

So now we\u2019ve got this, step one was the data, right? We\u2019ve just set the table basically for like an AI feast. We have the data. So step one, check. Now we\u2019ve got this in our system, we\u2019ve got this combination of abstraction. And then if you throw some AI tools at it, maybe now like we don\u2019t have to go to the unicorn farm, right? And find more unicorns. Now our network engineers, that onboarding ramp to participate in the automation system and develop the next, you know, whatever thing we need to add onto it. That just got less steep. Very approachable now for our uplevel, for our network engineers to uplevel. Now it\u2019s not, hey, you need to become an expert Python programmer so you can contribute to our solution. That\u2019s, you know, a hundred thousand lines of code and a database with some tables. Now it\u2019s, hey, you know, look at how our data is modeled, figure that out, figure out if we need a new data component, figure out how that gets modeled. That was a fun thing to kind of learn when we did this. It\u2019s a different skillset, right? Data modeling. And then, you know, do some Jinja and things that are very, very approachable now. And like you said, there\u2019s the possibility now to interact with our data in a very simple way, right? Write me a report. Tell me how many access switches I have in my data center. So Ethan can have this question answered. Write me a job to go, you know, do this thing, that sort of thing.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (41:33 \u2013 42:04)<\/p>\n

You\u2019re using AI in a couple of different ways then in your mind. One is to mine the data that you\u2019ve got to find out interesting facts about the network, things that are useful. It could be the number of unused access facing ports that I\u2019ve got. It could be, you know, the number of VLANs, you know, statistics, reporting, these sorts of things. But then also you\u2019re saying you want to use AI to help you with automation. I need to develop this new feature or a new template or whatever it is. Help me generate that stuff.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (42:04 \u2013 42:51)<\/p>\n

Exactly. We have a list. In fact, you know, we kind of keep our backlog on our little two and a half person team of things that our team needs, right? And most of them are in the Nautobot parlance, their jobs. And Nautobot\u2019s done a great job of stubbing out, right? That you don\u2019t have to write all that Python from scratch. It\u2019s got some of that stubbed out, but that\u2019s still a, that\u2019s a Python program, right? Script that you\u2019re running to go do the thing that you want to interact with the data. Maybe you\u2019re interacting with our devices, doing logic, whatever. Things like that. If we can, you know, throw some AI at that. We haven\u2019t yet. We just finished this. In fact, don\u2019t tell our managers yet, but I haven\u2019t quite finished the migration. We\u2019re down to like the last couple hundred devices. So we\u2019re almost done. And that\u2019s what we\u2019re hoping to kind of do next.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (42:51 \u2013 43:42)<\/p>\n

That\u2019s a great point. AI is both, you know, you\u2019re actually doing two parts, right? You\u2019re building the infrastructure to enable AI. But at the other side, you\u2019re also a user and consumer of these end result AI product after they\u2019re trained, they\u2019re, you know, specialized, tuned or whatever. That\u2019s, it\u2019s on both ends. So it\u2019s a very interesting aspect, which I think it leads logically to the next question I have for you, Greg, is that, you know, just from our short conversation, we\u2019ve gone through so many iterations on, you know, skills, the tools, the everything that we\u2019ve gone through and all the way up to how to use AI to, you know, right now about jobs, for example. So if you were to start your journey over again today, right? Like knowing what you know now, this is actually my favorite question. What would you do differently, if any?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (43:43 \u2013 44:56)<\/p>\n

For this journey and for our situation, I 100%, if I could go back and go back to that phase one, go back to that BC time, I would do 100% of our config be automated, right? We were, we started out in that phase one, and there was, you know, maybe 80%, a good, a good chunk of it for sure, more than we had done in the past. But there was, it was very easy to add on that other 20% or for customization, right? And that you\u2019d be surprised how many corner cases, how many one-offs you can end up with an environment this big. With phase two, we are now rendering 100% of that config. And as, so what the migration looked like was, hey, bring in all the data, you know, from your current network device, our unicorn wrote this fantastic jobs, not about jobs to go bring in all the data into not about, render the new config and then kind of compare it, right? A DevOps guy wrote a tool that says, here\u2019s the rendered config. Here\u2019s the running config. What are the differences? And, you know, I can push that out to the box for you. And, you know, I thought we\u2019re going to be very clean. You know, there shouldn\u2019t be hardly any drift. And sure enough, there was, there was more than I thought, right? And like we just talked about those one-offs, those are the landmines that blow up at some point. So if I could go back, I would, I would do a hundred percent.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (44:56 \u2013 45:54)<\/p>\n

Yeah, but also the point is now, you know, right now, you know, so you know what\u2019s the road ahead of you as opposed to previously. Maybe you were in the dark until something goes wrong and that bites you in the butt during a maintenance window or not worse, right? So, so yeah, now, you know, so these, these lessons were not wasted. And, you know, these are hard fought battles that, that gave you this confidence. And now that now we know what to tackle. So I think we\u2019re, we\u2019re kind of, you know, moving toward, toward the end of our podcast here. And we could feel like we could just go on forever, but I do want to ask like looking forward, where do you see the biggest opportunity for network automation is, especially for environment like Intel? You know, we\u2019re years of, of automation, years of process or doing the orchestration lessons learned. Where do you think that the biggest opportunity for network automation is in this area?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (45:55 \u2013 46:20)<\/p>\n

So, so in my space, in the D and E space out of DOME, the validation that we talked about to me still is, would just really be the next kind of, kind of game changer. I would also like to tackle taking streaming telemetry from all those 5,500 devices and being able to, you know, that\u2019s more data for AI engine to, you know, now you can start looking at self-healing kind of activities, right? Go agentic with your, with your AI.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (46:20 \u2013 46:34)<\/p>\n

Do you have a scheme for that? Because you\u2019re talking streaming telemetry of 5,500 devices. That is an enormous amount of data. Do you have a specific thing in mind, like the kind of telemetry you\u2019re looking for, as opposed to just turn it all on and we\u2019ll figure it out?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (46:34 \u2013 46:40)<\/p>\n

I don\u2019t know. I\u2019m going to go to Steinzi\u2019s map and see what, see what\u2019s out there and see how much it can handle and then go from there.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (46:40 \u2013 46:42)<\/p>\n

Yeah. Is that before or after your crash?<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (46:43 \u2013 47:23)<\/p>\n

But to speak to your point, it sounds like you want to surface maybe gray failures. There\u2019s an optic that\u2019s going down to the data center. How do you detect that? And would you have that many devices? It can be a challenge, but AI is really good at finding those oddities in the data that might go unnoticed because you\u2019re still passing traffic. But all of a sudden you\u2019ve got some number of, you know, discards or retransmissions or something happening that you can pick up on from that streaming telemetry perhaps. And then AI can put the pieces together and go, there\u2019s something wrong and it\u2019s in this part, this tier. I think it\u2019s this switch. You should look at this and see what you can find. In that exact voice too.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (47:24 \u2013 48:05)<\/p>\n

I think in general, right, to summarize the answer to that question, we\u2019ve now democratized our network data. And so really looking for like, I think we can increase efficiency kind of across Intel IT, right? Now maybe our cabling techs can work off the same data, you know, instead of like us passing a spreadsheet around and generating spreadsheet and making mistakes. Now that, you know, we\u2019re all working off of the same data, right? The server guys, rack and servers can look at the same rack that our network switches in and we\u2019re all working off the same data. So that can just lead to like self-service applications, right? And so on. So I really want to, I think that\u2019s kind of the other big opportunity that we\u2019re looking for.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (48:05 \u2013 49:29)<\/p>\n

Yeah, I think observability and telemetry has always been just a huge headache for networking. Even in previous lives, any vendor that came in that they swear and pound the table, say it\u2019s not going to break, right? Like we\u2019ve seen things that they don\u2019t say, that\u2019s not a problem without, when we put it under stress, when we put it under scale, that\u2019s just going to break. We have, I know in the paper you mentioned S-Flow, right? So as opposed to NetFlow, you have S-Flow that are sampling and, you know, you could decide to be aggressive or not and all that. And we have like the, you know, like the big databases, right? Like the schema list or like the relational, non-relational databases that we have out there, but still, there\u2019s still this huge gap that I see for, you know, deep inspection, the deep telemetry data, which just like you, I hope we\u2019ll find solutions one day. And to me, I am biased toward open source and biased toward, you know, all these solutions out there that I think somehow we could put all of our brains together, put our brilliant minds together, all the DevOps, all the unicorns, and then we\u2019ll come up with something that works for everybody. But I don\u2019t know, it\u2019s been years. I have that hope and I still don\u2019t, I don\u2019t see any promising projects. I don\u2019t know. What do you have in mind? I mean, or was it just, you know, kind of, we\u2019re in the same boat there.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (49:29 \u2013 49:58)<\/p>\n

We\u2019re kind of in the same boat. I mean, what\u2019s encouraging to me now is there are, you know, conferences. There\u2019s an AutoCon. That\u2019s a thing now. That wasn\u2019t a thing five years ago. Right. So people are, and it\u2019s growing. Yeah. Just the, the ecosystem, the fact that there\u2019s a map out there that Steinzi has and that it\u2019s growing is, is encouraging. So it, it takes a deeper look. We haven\u2019t been able to, we\u2019ve been kind of the two and a half guys were saturated kind of getting to this spot, but I\u2019m encouraged now more than ever in this area.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (49:58 \u2013 50:16)<\/p>\n

I agree. I agree. So before, before we wrap up, is there any, you know, last call to action or, you know, if you were to, if somebody else is listening to this podcast and wanted to know what is the first step, right? Like, so is there any call to action from your end before, before we wrap up anything you want to cover?<\/p>\n<\/p><\/div>\n

\n

Greg Botts (50:16 \u2013 50:19)<\/p>\n

I think first thing is they should listen to your podcast.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (50:19 \u2013 50:21)<\/p>\n

I appreciate that. Thank you.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (50:21 \u2013 50:51)<\/p>\n

I would honestly like to, to think, I mean, both of you guys for the work that you\u2019re doing, because what you\u2019re doing, going and evangelizing, right. Going and telling these stories. That\u2019s one of the reasons I think that when we went shopping, we were able to kind of navigate that landscape because we, you know, you hear what other folks are doing. You realize there\u2019s a map out there, right. Go look at that sort of thing. Your podcasts are also enhancing the RTO experience as a site. There\u2019s your tagline. Enhancing RTO.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (50:51 \u2013 51:17)<\/p>\n

I\u2019m going to crop that and be the promo for this episode. And I want to echo that. Right. So I\u2019m the newcomer here, but Ethan\u2019s been doing this for like 10 plus years. I feel like it\u2019s 10 plus years. I don\u2019t know if exactly. It\u2019s pretty close. Right. Ethan.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (51:07 \u2013 51:08)<\/p>\n

It\u2019s 15. Yeah. I started podcasting in 2010. Yeah.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (51:09 \u2013 51:37)<\/p>\n

We can end this on a positive note, right? Yes. There is a community. There is a ecosystem that is growing. And yeah, if I remember correctly, it was, you know, 600 people from Autocon 4, but Autocon 3. I\u2019m sorry. Autocon 2 and 3 is probably, you know, a little different because they\u2019re in Europe, right? So let\u2019s just compare four. So it\u2019s going to be over a thousand that we anticipate for Autocon 4. Ethan\u2019s going to be there. I\u2019m going to be there. Greg, I hope you\u2019re there as well.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (51:38 \u2013 51:39)<\/p>\n

Hope so. Trying.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (51:39 \u2013 51:47)<\/p>\n

Thank you, Greg and Intel for sharing your story. Thank you, Ethan, for joining us today. I couldn\u2019t ask for a better co-host.<\/p>\n<\/p><\/div>\n

\n

Ethan Banks (51:43 \u2013 51:47)<\/p>\n

Thanks for inviting me, Eric. I enjoyed it as always.<\/p>\n<\/p><\/div>\n

\n

Greg Botts (51:47 \u2013 51:52)<\/p>\n

Well, thank you very much. I enjoyed talking to you both. Thanks.<\/p>\n<\/p><\/div>\n

\n

Eric Chou (51:52 \u2013 52:12)<\/p>\n

And thanks to Network To Code for sponsoring today\u2019s episode. Don\u2019t forget to check out their solution at networktocode.com. Do you have any feedbacks for Network Automation?Our guests great today or this episode? Please do send us some follow-ups at packetpushers.net forward slash follow-up. We do want to hear from you. Last but not least, remember that too much network automation will never be enough.<\/p>\n<\/p><\/div>\n

Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Eric Chou (0:05 \u2013 0:28) Hello and welcome to the<\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[250],"tags":[251],"class_list":["post-8052","post","type-post","status-publish","format-standard","hentry","category-podcast","tag-podcast"],"featured_image_urls":{"full":"","thumbnail":"","medium":"","medium_large":"","large":"","1536x1536":"","2048x2048":"","chromenews-featured":"","chromenews-large":"","chromenews-medium":""},"author_info":{"display_name":"Network To Code","author_link":"https:\/\/ddi.mohflo.net\/index.php\/author\/networktocode\/"},"category_info":"Podcast<\/a>","tag_info":"Podcast","comment_count":"0","jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/posts\/8052","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/comments?post=8052"}],"version-history":[{"count":0,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/posts\/8052\/revisions"}],"wp:attachment":[{"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/media?parent=8052"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/categories?post=8052"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ddi.mohflo.net\/index.php\/wp-json\/wp\/v2\/tags?post=8052"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}