EVPN/VXLAN Vs. TradCore

Added: 2026-05-30

[00:00:00]Sponsor Auvik network management discovers your complete network inventory, displays real-time performance metrics, backs up configs, generates compliance reports, and more in an intuitive, simple-to-use tool that scales as big as you might need. Get your free 14-day trial at auvik.com/heavynetworking.

[00:00:20]That's a u v i k dot com slash heavy networking. Welcome to Heavy Networking, the podcast for network engineers. If you've been perusing eBay for an old 6509 to use as a coffee table, you found your tribe. I'm Ethan Banks and Drew Conry-Murray, and you can chat with us on LinkedIn and the Packet Pushers Community Slack group, and and please do. You should also subscribe to the weekly newsletter Drew and I curate for you. It is called Human Infrastructure, and it's a resource for you to keep up with blogs, opinions, news, and vendor announcements network engineers might care about all in one place. Why dig for all of that yourself when Drew and I do it for you for free?

[00:00:54]So, visit packetpushers.net and find our newsletters, our Slack group, and other good privacy- respecting resources with no membership, no login required. Just just go get the good stuff. On today's episode, we consider how to determine whether Tri core or EVPN VXLAN is right for you. Uh this isn't This isn't purely a technology discussion. There are tradeoffs that go up through layer eight, and if you remember the show we did earlier in 2026 called EVPN all of the things from a That was That was a few months back.

[00:01:22]And maybe you had questions about that episode. Uh this discussion might answer some of those questions for you, and our guest is Tony Burke. Uh we've known Tony for a long time, and he's a seasoned instructor who teaches automation, network design, and more for hands-on folks. Uh Tony, welcome back to Heavy Networking. And uh hey, you're not jumping out of a plane today. I appreciate you taking the time away from plummeting to the ground with ferocity to to chat with us. Hey, no problem.

[00:01:46]It's great to be here.

[00:01:47]Yeah. Uh okay, so you pitched this idea to us. Why don't you set set this up cuz you're This is a challenge you're seeing with uh with some of your students, I think, and and some network design discussions.

[00:01:57]So, the the thing that that brought up about was when you're building out especially data center, but it could also be like a a campus network or any other kind of network.

[00:02:07]Uh whether or not you're going to go with EVPN VXLAN or not and or some other fabric technology. There's a couple others out there, but it's mostly a choice between uh what we what you you the term I love is trad core.

[00:02:19]Uh which is this uh I think it might help to define what we're talking about with trad core like >> Yeah. You've You've seen it. You If you're watching this, you've seen trad core. It's the core Like a girl in a flowy dress talking about raising their own chickens and stuff.

[00:02:33]>> [laughter] >> Yeah, it's it's um SVIs and VLANs. So, there's no overlay or underlay. There's no VXLAN. It's a core aggregation access layer stack or a collapsed core.

[00:02:46]Um and there's it's kind of hard to There's a like a lot of different names for it. Like Arista calls it layer two leaf spine.

[00:02:52]Uh core aggregation access layer or there's like other names for it, but I think trad core encapsulates it very well. It's the traditional networking stack that we've had for like oh almost two decades. Yeah, it came out of Cisco training. That was one of the models that Cisco would talk about. And so, a lot of us that grew up with CCNA, CCNP, and so on training probably hit that in in some of the course material and we we all built and or worked on a lot of networks that were that. You've got your your core layer. You fan out into an aggregation layer and then the edge is is an access layer where you're actually plugging in stuff to to connect to the network. And then in between those you deal with a routing protocol and some and a lot of spanning tree. And then like you said, Tony, there's no overlay.

[00:03:34]So, it's it's simple, right? It's the fundamentals. It's the building block basics of of any network, yeah? Yeah, absolutely.

[00:03:44]Okay, so if we've got trad core and that is You So, what what's the argument here? That that is still a viable choice in certain circumstances and the other choice in 2026 would be EVPN VXLAN?

[00:03:55]Yeah, I think for most networks you're going to want to pick one of the two, especially in the data center, but again, even in the campus it's it's also a choice.

[00:04:02]But we either we're going to go trad core or we're going to go EVPN VXLAN.

[00:04:07]There are some other choices in some different situations.

[00:04:10]Like you could do do just a purely layer 3 network, so no no EVPN VXLAN just layer 3, but then you have a different subnet in every rack.

[00:04:21]So that doesn't allow for workload mobility, which is usually what we need.

[00:04:24]We need to provide workload mobility. I need to be able to put any workload in any rack. So every subnet has to be available in every rack. So both trad core and EVPN VXLAN provide that. Pure layer 3 doesn't. And we've had that requirement for over two decades.

[00:04:41]And then the risk in in in the trad core design of of that cuz I've I've been here and uh and and lived with that mistake on some level was when you extend a particular layer 2 domain across a whole bunch of racks, if you have a problem in that layer 2 domain, it can extend to a whole bunch of racks and that can be really bad. Yeah.

[00:05:01]>> Yeah. Um so but that's that's a data center concern in my mind more than a than a traditional campus design. Is that is that fair? Yeah, in in the in the campus design they're doing more and more or people are starting to take a look at EVPN VXLAN for that because you can have every subnet in every building and every floor and then you can assign through network access control when someone like boots up their laptop or the workstation or on the phone or tablet they get put into the segment that represents their security status, sales, tech, etc. So you can build policy based on their identity instead of their location.

[00:05:41]That's kind of the same thing. Not so much of an issue with like the trad core versus EVPN VXLAN discussion. Again, depending on what your network is, it's a little bit more murky, I think, in the campus.

[00:05:52]But in the data center, it's a pretty even it's a pretty clear distinction.

[00:05:55]We're either going to go tradcore we're either going to go tradcore or we're going to go EVPN-VXLAN. And I think they're both valid choices depending on your situation.

[00:06:04]Well, okay, so this is what people listening to this are going to want.

[00:06:06]They're going to want Tony, just tell me how to choose. Is it is it size and scale? How do you how do you make that decision?

[00:06:13]Well, first, I think it helps a little bit to if you're looking at either tradcore or you're looking at EVPN-VXLAN, there are a couple of things that people think about EVPN-VXLAN giving them advantages, and I think we should talk about that first.

[00:06:25]Um for one thing, EVPN-VXLAN, the way that we do it in the data center, the modern data center, in the enterprise, does not provide us more than 4,000 VLANs. We're still stuck with 4,000 VLANs.

[00:06:35]Mhm. Now, VXLAN gives us uh 2 to the 24th power, so that's 16,777,216 segments. I have that memorized cuz I've taught VXLANs for Okay. You were a broken man. Yeah.

[00:06:47]>> [laughter] >> But well done. Yeah. So, um but every VXLAN segment every domain every broadcast domain in V in VXLAN needs to be assigned a local VLAN.

[00:06:58]Yeah. So, in most cases, we're going to build out a network where we have a global mapping of a layer two VNI to a local VLAN. You don't have to do it that way. There are ways around it to get more than 4,000 VLANs. In fact, like ACI, that's how they do it under the hood. Mhm.

[00:07:14]>> significantly complicates your environment. So, most situations, we're still going to be stuck with 4,000 VLANs.

[00:07:21]Uh another one is multi-vendor. I really try to uh push people away or or advise against doing multi-vendor with EVPN-VXLAN.

[00:07:30]Um there are so many moving parts and so many different interpretations of the standard, and then so many different show commands and vent you know, getting the different vendors on a call, that kind of thing, it it really increases the operational overhead. So, for even for >> Well, it's just I'll push back a little bit in that discussions we've been having recently with folks who've implemented EVPN VXLAN have said that interoperability has certainly gotten a lot better than it was say three or five years ago. Is that fair? Yeah, I think that's fair to say at least in unicast. In multicast, there's still some iffiness there. And I think there's one vendor and I can't remember who it is.

[00:08:07]Uh they have a slightly different interpretation of how there's certain behavior in multicast for something called OISM, which is optimized inter-subnet multicast for EVPN.

[00:08:18]Which basically takes care of the problem of that like you're not dealing with one M router, you're dealing with like a distributed M routers setup. So, there's all sorts of like little tricks that EVPN can do to make that work a lot better.

[00:08:31]But the different vendors might interpret that differently. So, I don't know if the if that's going to be a good idea. But beyond that, like I set up a Frankenfabric once. It was Cisco, Juniper, and Arista.

[00:08:42]And I was surprised even how different it was configuring Arista and Cisco even though they're like very similar in the command lines, the way that they implement EVPN VXLAN is vastly different. So, you've got a very different configuration set. You've got especially Juniper, that's going to be very different. But even Cisco and Arista are going to be different.

[00:09:01]And then you've got all their built-in tools. You've got CloudVision for Arista, you've got Nexus Dashboard for Cisco, you've got Apstra for Juniper, which ostensibly can work with other vendors, but Which ideally you're going to be using one of those tools. You are not going to be configuring all this stuff artisanally by hand. You need a tool to provision that EVPN VXLAN fabric and manage it.

[00:09:21]>> And then also the monitoring stuff, you know, the each of these have really great tools for pulling information out of these devices, which you could do on your own.

[00:09:28]But it's going to be a lot easier in a lot of cases to rely on these vendor tools that are that they've spent work, you know, they spent a lot of time on.

[00:09:35]So, I try not to do multi-vendor in EVPN-VXLAN even though technically you can do it for the administrative overhead that it causes. I mean, think about getting two different vendors on a phone call for a sev-1 outage and like them pointing fingers at each other. So, Do you feel like trad core then there's better multi-vendor support for all of the the protocols and configurations that you have to do? Yeah, because there's just a lot less going on. We're basically we've got a VLAN and we've got a trunk and a VLAN and that's basically it. So, we've got uh link aggregation, we've got LACP, and we've got 802.1Q and that's pretty much it. So, it's a lot easier to throw different vendors in that mix than it is to with EVPN-VXLAN although it's I mean the configuration is a lot easier in trad core, too, because you don't have to do the underlay and the overlay and the [snorts] VLAN VLAN mappings and all that, route targets, route distinguish errors.

[00:10:29]I still would try to build a single vendor fabric if I could just for the administrative benefits or the lower administrative overhead, but it's a lot easier to mix and match with trad core.

[00:10:41]Yeah.

[00:10:42]Yeah, I've never worked at a site where within a particular site of that company we had all just a random mix and match of of devices. We always tried to consolidate and homogenize on a vendor and an operating system if at all possible. It was even Well, we're all Cisco which you know, sure you are NX-OS plus iOS plus you know, whatever you end up. It still ends up being kind of a an operational mess, but but yeah, that was the intent.

[00:11:07]And even between sites within a larger global LAN, we tried to homogenize just for that operational consistency made a lot of sense for sure. And and right, but but again, if you had to, it's certainly easier with trad core to go go multi-vendor.

[00:11:22]Okay, so those are some of our decision points with EVPN-VXLAN versus trad core that is the 4,000 VLAN limit is a is a thing. It's uh it's an open question for some folks that are in larger environments. And then whether or not you multi-vendor is another question mark.

[00:11:40]Okay, so with those starting points established, Tony, what about scale?

[00:11:45]Like if I'm going really big for some definition of really big, maybe you've got some numbers in mind, whether that's number of uh access ports perhaps or a number of switches. Um does do we get any guidance or wisdom that way about which direction to go? Yeah, I think uh uh two good considerations are going to be scale and redundancy. Uh those are two big factors in your decision. Actually, three three big factors. Scale, redundancy, and operational overhead.

[00:12:11]So, let's go with scale. Uh I think it's pretty clear if you've got 200 leaves that EVPN VXLAN is going to be your choice uh because EVPN VXLAN scales out to sizes much much larger than you can get with or would would be appropriate for trad core.

[00:12:27]On the other hand, if you have two switches and you're just going to have two switches, uh I don't think EVPN VXLAN makes sense at all. I think you should just do the simple trad core, put the two devices in MLAG, and then you're done. And it's it's much much simpler than throwing VXLAN in there cuz I don't think EVPN VXLAN has any benefit in two switches, at least not any major significant benefits.

[00:12:49]So, the point of VX I'm sorry, of MLAG here, a multi Well, it depends on which vendor you're talking about. But basically, multi-channel multi-channel multi Multi-chassis link aggregation.

[00:12:59][laughter] My name is something that you can you can uplink to uh two different physical switches from one device and have redundancy between the two, but treat it as if it is uh one Right. logical interface. Yeah. Yeah, we're we're taking two switches and we're making them appear to be a single switch from the outside world's perspective. So, uh they have the same bridge ID and they have the same LACP system ID, and they share their forwarding tables. And um different vendors call it different things. Arista calls it MLAG, Juniper calls it MC-LAG, which is also my rap name. My name is MC-LAG. My clothes be fresh. [laughter] And also divided by a hash of their headers.

[00:13:38]Cisco [laughter] calls it VPC uh, for the Nexus line. And there other vendors have different names just like which I can't remember off the top of my head. But it's basically the same technology.

[00:13:47]It is proprietary, which scares a lot of people, but I don't think that it's a big deal. I think people tend to overblow the the that or get really afraid of that term.

[00:13:56]It's only proprietary between those two devices. That's it. The rest of the world, whatever you've got going on, you can connect to it.

[00:14:05]And it presents as um, uh, as 802.3ad, but that's not that anymore.

[00:14:11]They that's been updated to the new standard >> Yeah, 802.1X, yeah. Yeah, it's right.

[00:14:16]But LACP, it presents as a standard protocol. It speaks a standard protocol even though you're talking to two physical devices. It's only the the proprietaryness, as you say, is only within the way the two different devices share their information and share their control plane and and all of that.

[00:14:32]Um, so you can't make a Juniper box and a Cisco box be part of a multi-chassis link aggregation group.

[00:14:38]That's not a thing. Correct. Yeah, they they have to be the same vendor and in this is where there's a slight advantage to EVPN VXLAN because they have a way to do it's not MLAG, but it's similar, uh, called EVPN all active or EVPN ESI. Um, with MLAG with the different vendors uh, implementations, you have to have the same hardware and the same software. And if you want to do upgrades, there's a uh, there's a pretty strict path. You have to make sure that you might even have to do some intermediate upgrades.

[00:15:07]Whereas EVPN VXLAN, it's much more flexible.

[00:15:10]So that could be a factor there when you're considering doing one or the other is um, even though I'm building out the same vendor, I have more flexibility in the versions of software that I'm using and I'm more flexibility and the hardware that I'm using.

[00:15:24]Especially in today's world where we're we're in our second uh uh um supply chain crisis of of this decade. Of the decade, yeah. Yeah, with AI grabbing up all of the uh the memory and and storage.

[00:15:39]>> Yeah. Which you know, but thankfully we get a lot of AI slop on Facebook, so it's worth it.

[00:15:45]>> [laughter] >> Definitely a great trade-off.

[00:15:48]So [snorts] >> said you said scale, redundancy, and operational overhead.

[00:15:53]>> Well, before we get to before we finish scale, we've said two switches and 200 switches. There's still a lot of room in between. How do we suss that out? Yeah, so um from a purely scale perspective, EVPN VXLAN's going to scale a lot better.

[00:16:08]But when you get below a certain number of switches, like I'm kind of pulling this out of the air, like 20 switches.

[00:16:14]Below 20 switches um the you know, it could go either way. Um or even like 40 or 50 switches. It could kind of go either way. There's definitely a lot of situations where like let's say if you did have 20 switches, it could you could do one of the other and there would be advantages and disadvantages kind of, but it wouldn't be an obvious choice. Or wouldn't be like there's like Go ahead. You say when you get into a whole bunch of switches that obviously EVPN uh VXLAN is going to scale a lot better. Why? Explain that. So the the the there's a couple of benefits. One, um you could scale at your spine layer.

[00:16:48]So with trad core, you've got two devices that are going to be your first hop. That's your default gateway for your hosts. Just two devices. And that's going to limit how big you can make it, and it's a scale up thing. Whereas EVPN VXLAN is a scale out thing because we can build more and more spines to get more and more ports.

[00:17:06]And then when we run out of spines and run out of ports, typically you can only do about six or eight spines um because of the uplinks on your uh end of row or top of rack switches typically have your front facing host ports, which are like 25 gig today, and your uplinks, which are either 100 or 400 gig, depending on the model. You've typically only got six to eight of those high-speed uplinks.

[00:17:29]So, that's that's going to limit the number of spines you have to like eight, six or eight.

[00:17:35]If you need to do more, you can do pods.

[00:17:38]So, I can have I can aggregate discrete sets of leaves and spines with super spines. So, I can scale to hundreds of leaves until where you really start want to shopping you want to start shopping things up just from a blast radius from a an availability zone basis instead of just how big can I actually make this? You can make it real real big.

[00:18:00]We call that a five-stage cloth or a super spine fabric.

[00:18:03]So, that's going to scale out much better. You can't do that with with trad core. At least in in that that that scaled out EVPN VXLAN network, you still have workload mobility throughout the entire fabric. You can't do that with trad core. Trad core's going to have a definitive limit on how many leaves you can do, depending on how many line cards you can shove into a chassis.

[00:18:26]And if you run out, you then you have to buy new chassis.

[00:18:29]And you only got two of them. That That's another problem because that gets into the redundancy thing.

[00:18:34]Which is another factor in choosing between trad core and EVPN VXLAN.

[00:18:39]You could do something crazy like a like if I remember right, virtual chassis in the Juniper world, you could go to more switches, but I don't know too many people that have loved doing that.

[00:18:46]>> Yeah.

[00:18:48]Yeah, I don't I don't know of any consistent like common technology where you can do more than two cuz MLAG is two. Because those two devices are in MLAG.

[00:18:58]You could do like >> [clears throat] >> you could do like um like a stacking, but that's not going to get you the bandwidth you're going to you're going to need between your your line cards cuz you need a you need a fabric backplane.

[00:19:08]That's going to have like >> Not not a daisy chain or You know, backplane. You're going to be bandwidth constrained with that scenario.

[00:19:14]>> the aggregation or the collapse core is going to be in an MLAG pair if you're doing trad trad core. So, it's going to be vPC or MC-LAG or MLAG. And then you're only going to be able to have two of them. So, that's going to limit your and that's going to reduce your redundancy.

[00:19:27]So, with and typically when we're doing trad core, one of the decisions is do we do a chassis or do we do like an end-of-row switch?

[00:19:36]If it's like six switches and you need to connect them to an aggregation layer or a collapse core, then they could probably you can probably get away with uh doing an end-of-row because you're probably not going to have the budget at that point to build out a chassis because chassis are typically much more expensive than an end-of-row device.

[00:19:54]But, the chassis provide that redundancy in terms of you got redundant line cards, redundant fabric modules, redundant supervisor modules that you're not going to get in a in a fixed device in a fixed switch. Uh-huh.

[00:20:06]So, if you only can have two, then you're and this is where the redundancy factor comes in. If you can only have two, then you ideally you want a chassis because it's got the redundant components.

[00:20:20]Yep. But, if you do EVPN VXLAN, we can do three or four. Like, three and four are kind of the sweet spot for the number of spines you can have in an EVPN VXLAN fabric. Uh-huh. Because if you just have three, if you lose one of them, you still have uh 66% of your capacity or 67% of your capacity and you still have redundancy.

[00:20:38]You can still lose another spine.

[00:20:41]But, if you have two in the trad core at your aggregation layer as your first hop, if you lose one, you've lost all redundancy and you've lost 50% of your forward capacity.

[00:20:49]>> Capacity. Yep.

[00:20:51]So, um So, some organizations just are not going to be able to afford uh to get a chassis. So, they might need to do trad core with out that extra redundancy of a chassis or they can do a more limited EVPN VXLAN and go with three spines.

[00:21:09]All All right, so scale and redundancy, we've hit those pretty hard. Operational overhead, in in my mind EVPN VXLAN adds adds quite a bit of operational overhead. Am I thinking about that right?

[00:21:20]>> Yeah, absolutely. It is a more difficult, more complex configuration.

[00:21:25]And it's not a it's not a little bit either. It's it's a lot. There's a lot more. You've got route targets, route distinguishers, overlays, underlays.

[00:21:33]You can have a different routing protocol on your underlay. You've got MP-BGP in your overlay exchanging EVPN route types, type two routes, type five routes, type three routes, type one and four routes. And that's just for unicast.

[00:21:43]So there's a lot there's a lot there.

[00:21:46]In addition, if you're going to deploy an EVPN VXLAN network, you want to automate. You want to have some sort of automation technology, whether it's homegrown like Ansible and Ginger and Yaml, or you're going to use Nexus Dashboard or Apto or CloudVision or AVD.

[00:22:03]You're going to want to have some sort of implementation for automation to be able to put to generate the configs and push the configs.

[00:22:10]You've got a lot of students coming through your classroom. What do you see people typically doing? Going with a vendor solution or rolling their own with Ginger and Python and open source tools? Most of the most of the students I work with are are probably going to go the Well, it depends on the size of the company.

[00:22:27]Small companies probably aren't doing EVPN VXLAN. So they're probably just doing tried core because with smaller companies, you have a smaller team. They might be responsible for a lot more of the environment. They might be responsible for the network and the printers and the soft phones.

[00:22:44]And just Not they might be, they are.

[00:22:47]>> [laughter] >> They're probably doing the whole cloud computing stack and the the CEO's, you know, the CEO, "Hey, I can't get I Why is my email not working?" Like they're doing that kind of stuff.

[00:22:56]And I feel for you cuz I've I've done that. Um And [clears throat] the larger companies are usually going to have a more sophisticated um infrastructure a homegrown something or maybe they're using it in conjunction like a common one I see in the Arista world is they use CloudVision to deploy the configs but they generate the configs outside of CloudVision. They generate them on like a on Ansible or they have an open source great open source tool called AVD which will generate the configs and then pushes them into CloudVision and CloudVision is responsible for the checking the config syntax and then pushing it to the devices.

[00:23:34]Um and then in the middle somewhere it it could kind of go either way. It's just you need to have the skill set.

[00:23:40]For trad core you can totally manage it without automation. You can automate it but well I mean we've been doing it for over 20 years. We've been or you 30 years cuz I was doing trad core like the the the precursor to trad core on Catalyst 5000s back in the 90s.

[00:23:58]So and that's you know there was no auto I mean can't say there was no automation but there's very little in the way of automation. We're just doing everything artisanally.

[00:24:06]We had expect scripts and Pearl Tony and we liked it.

[00:24:09]We did not.

[00:24:10]We [laughter] had them. We didn't like them.

[00:24:14]Do you feel like you said you know it's there's less complexity in the trad core design. To my mind that almost makes it more a candidate for automation in that it's there's less to go wrong potentially.

[00:24:27]Yeah I mean certainly something you can automate trad core. I'm just saying that there's a lot of organizations that don't quite have the automation skill set yet. They don't have the tooling and the the knowledge and there's still a lot of network people that are very hesitant to go with automation.

[00:24:41]And for those people the trad core environment even if it's a toss up between trad core and EVPN that might tip the the scales in favor of trad core because we can manage it effectively manually.

[00:24:54]Yeah you can't it's not there's fewer things to go wrong. You can you can template it in your mind or at least you know, have a standard way that you deploy like I got to put a new VLAN out because reasons and how you do that can be pretty pretty cut and dried. And if something's wrong, you got a connectivity problem or there's just not nearly as much stuff, not as many layers to go through to troubleshoot where the problem is. They're kind of it's kind of predictable and known and and and very common place. You see it everywhere.

[00:25:22]It's not like you're walking in you've never seen this sort of design before.

[00:25:25]Everybody's pretty familiar with this.

[00:25:26]So you kind of know how to deal with the spanning tree aspect of it and deal with a pruning your VLAN trunks and and where your SVIs are and all of that.

[00:25:37]And there's just it's just a much smaller domain of things that can go wrong. And so in that sense, you can get away without automation. Although Drew, I agree with your point. You're not wrong in that well, with less stuff to automate, it should be easier to automate, right? Um but also, if you're not there yet, um it's just easier to >> run that thing by hand if you have to.

[00:25:56]>> Yeah. Yeah, personally I wouldn't I I would automate it just because I've got the automation skills and it's relatively easy for me to do so. But I can absolutely see a lot of organizations who haven't gone into automation yet, at least at a significant level, they want a simpler operational model. So you can do that with trad core, no problem. I would never recommend doing any kind of EVPN VXLAN manually except for the lab. It's important to do it manually in the lab just so you know how it works.

[00:26:23]But in production, it should be automated in some form.

[00:26:27]You're very adamant about that. What what why?

[00:26:30]Um there's so many different configuration points. Uh we had um we did a uh a video podcast video on EVPN VXLAN a couple years ago.

[00:26:40]And you used a phrase that I really loved and I use this all the time in my classes is is there's a lot of spinning plates.

[00:26:47]So you know, when a packet comes into a a then it's got its front VLAN, which might be translated into an internal VLAN, which is then sent into a layer two VNI, which might get switched into a a routed into a layer three VNI, sent over to the destination leaf, and then tran- back. We've got our local forwarding tables. Uh we've got our local uh MAC addresses and our MAC tables, just like we normally would have.

[00:27:12]Plus, we've got our our VXLAN tables.

[00:27:15]We've got our /32s for the endpoints that we learned.

[00:27:19]And those are distributed and propagated throughout the fabric via this the type two route. So, there's two different types of type two routes. There's a MAC route and a MAC IP route.

[00:27:27]You know, you get the point. There's just a lot more going on, and these all have to be configured. Route distinguishers, route targets, what's the difference between them? They kind of look the same. Um there's a lot going on in the config.

[00:27:40]We're taking a quick break for sponsor Auvik network management. And if you've not heard of Auvik, they've been around for many years, and they have the goal of making it easier to run your network.

[00:27:49]Good visibility into what's going on, network maps, proactive alerting so that you're aware of a problem before the help desk starts lighting up, compliance reporting to make the auditor happy, config backups so you can go back to a known good state if you need to. You get the idea. Now, here's how Auvik works.

[00:28:05]You deploy an Auvik collector, which discovers your network and then figures out your network topology and maps it all out for you. You You don't even have to know how the network is connected.

[00:28:14]Auvik's going to talk to your network devices and figure that out. All right.

[00:28:19]Now that Auvik knows your network topology, it's going to begin monitoring your network. And you don't have to tell Auvik everything you want it to monitor.

[00:28:25]There are 64-plus preconfigured alerts built in, dashboards for every device, and Auvik can talk all kinds of different protocols. SNMP, can talk APIs if you've got devices with APIs, it can it knows how to parse syslog. It can do netflow and do flow collection and more.

[00:28:41]So, you get this really useful repository of all of your network telemetry in one place. There you go.

[00:28:46]And Ethan, that sounds like red light, green light network management more or less.

[00:28:51]Yeah, but there's a lot more than that.

[00:28:52]You're going to get inventory tracking.

[00:28:54]You're going to get config backup and restore as well as application identification and geo data through traffic analysis and all of it scales, too. If you have one campus or you're managing the networks of many different clients that you might have, Auvik can get it done. So, check out auvik.com/heavynetworking to see your live network map in minutes with their 14-day free trial. That is a u v i k.com/heavynetworking.

[00:29:23]auvik.com/heavynetworking if you're in the market for a new network management solution. And now, back to the show.

[00:29:31]Yeah, and by the way, since Tony mentioned that he and I did a series together. That I don't know, it was six or eight parts or something on kind of walking through an EVPN VXLAN fabric. But, if you go to the Packet Pushers channel on YouTube and search for that, it'll it'll come up.

[00:29:44]You can browse through and find that there.

[00:29:46]All right, Tony. So, scale redundancy, operational overhead, those things which are going to vary from company to company and there isn't any one single correct answer because there's a whole lot of it depends that we just talked through. But, that can help us make the decision one way or the other. But, that gets us another driver which is why. Now, you've mentioned workload mobility. Like, I assume you're talking about like vMotioning between VMware clusters, that sort of thing. Yeah, almost every environment's going to need workload mobility. There's very few data center environments that I've ever come across that can get away with just pure layer three, which means every rack is a different subnet or a different set of subnets.

[00:30:21]Most of what we need to do is going to be every rack has to have every subnet available to it.

[00:30:27]Now, vMotion is one of the things that benefit from that, but also just be able to put your workload wherever it makes sense. Huh. So, it makes much more efficient use of power and cooling because I can just spread my workload across my racks without like overstuffing one rack and having another rack that only has a couple servers in it because it's the workload in it is only is very small.

[00:30:48]And we still we still separate workloads by by networks, by subnets typically.

[00:30:52]Not always, but we do.

[00:30:53]>> I There was a data center build that I was a part of a while back, and in that project there was an instruction from the data center manager, we have to be able to put any subnet in any rack. We need that design.

[00:31:05]But we're scared. No, you have to do that, so figure it out. Yeah.

[00:31:08]>> [laughter] >> I mean, it was a straight >> forward enough technology. You know, a way to set it up, VLAN trunks, and off you go. Um But at the time it was a little bit novel, and there was still a school of thought that was like, no, one subnet per rack, you know, kind of thinking.

[00:31:21]But moving into the new data center, that was not going to fly. We needed to have that flexibility to be able to put that workload wherever we needed it because of spreading work around, electrical distribution was a thing, weight in the data center was actually a thing, where certain servers are going to be located physically. All of that stuff mattered.

[00:31:40]>> And and changing IPs, this was this was not the time. We were not going to do that.

[00:31:44]>> [laughter] >> Yeah, it was So does this mean that workload mobility is Oh, sorry, go ahead, Tonya. Oh, just a little bit about the the workload mobility. It really started in 2006.

[00:31:54]I think that's the year when uh it might have been 2005, but uh 2006 was the year when uh uh AMD and Intel came out with extensions to their processors that allowed virtualization with almost zero performance penalty, like 1 or 2% as opposed to before that time it was about 30% give or take, depending on the platform.

[00:32:14]But all of a sudden we could we could virtualize our workloads, and then they wanted the vMotion part of that, too. So pretty much every network built after that time, we had to go to workload mobility, and it was so beneficial in other ways, too. We're you know, we're stuck with it. We've learned to live with it. I mean, there's We don't like to have layer 2 everywhere, but we pretty much do now, and we've learned to live with it, and it works okay.

[00:32:38]Yeah, it was about 2008-2009. I remember provisioning networking for VMware clusters and there were dedicated ports and networks just for vMotion to be able to pick up a workload and move it. So that all that all aligns, Tony.

[00:32:50]>> Yeah.

[00:32:51]So, which design then do you feel like is better at supporting workload mobility or is it again it's a trade-off?

[00:32:57]>> do. They they both provide the same support for it.

[00:33:01]Um EVPN VXLAN is a little bit easier if you want to do multi-data center. Uh a little bit easier to do it that way.

[00:33:07]So that could be a consideration.

[00:33:09]But even without it, you could still use VXLAN and even EVPN VXLAN to do multi to do DCIs, but it's a little bit easier to integrate it if you do EVPN VXLAN uh because it's built for it in the in the uh in the main part. But in terms of inside of a single data center, they both do the same job.

[00:33:25]Okay. It's going through my head if there's any benefits like with ECMP, you know, across an MLAG versus in VXLAN and I'm not really coming up with any. It's going to be roughly the same hashing mechanism where we might be overloaded on a particular link when when a workload moves, for example. Is that right or am I forgetting something, Tony?

[00:33:43]>> and I'm not um 100% sure, but I think it uses the exact same circuitry to do the a hash computations for both layer two and layer three.

[00:33:52]Uh is if it's like layer two, layer three, layer four headers, whether it's a packet or, you know, whether it's uh going over a ECMP link or if it's going over or ECMP set of links or it's going over a LAG link, it's pretty much the same.

[00:34:04]Yeah.

[00:34:05]So do we just tell people it doesn't matter?

[00:34:07]>> [laughter] >> We we did we did not help them make a decision at all, did we?

[00:34:11]No, it I mean we we told people that it it depends and but we've given people what I hope we've given people some guidelines. So we've got the scalability, we've got the operational complexity, we've got the redundancy. So scalability, redundancy, operational complexity. So those are all factors that we can use uh to determine and with that lens we can see that two devices, you know, we're not getting any additional redundancy with EVPN VXLAN.

[00:34:36]We get a lot of extra complexity with EVPN VXLAN. Does it make sense for two devices? No, I don't think so. Um in fact, every now and then I run into someone that does recommend it for two switches, and I'm like, "What are you talking like, why? Why would you do it for two switches? There's so much >> [laughter] >> configuration >> you do you remember the argument for that that Jeff made back in the EVPN all the [clears throat] things show? I honestly [snorts] don't know.

[00:35:01]Yeah, as I recall, the the point was made of even if you have a very small setup, well, you can grow into whatever you want. And so, if you start now, you can you can expand. And I I I think that's a reasonable point. Yeah, it's a reasonable point, but like you'd have to grow a lot to get to where like the benefits of EVPN VXLAN really start to shine. So, that would have to be like 40 switches. So, could you go from 20 or from two switches to 40? Sure.

[00:35:25]Um but probably it's not going to be an organic like just adding a couple switches every couple of of months. Um it's probably going to be like, "Oh, we've got this big new project." It's probably going to be a fresh build.

[00:35:37]Yeah, I Yeah, I have mixed feelings about that. I used to do things like I'm going to set up a first hop redundancy protocol on a single switch because at some point I'm probably going to add a second switch. And even though I don't have one today, when I do, I'm not going to have to take any kind of a a service hit to install that second switch and make it part of the first hop redundancy protocol.

[00:35:56]Um but it may added for extra complexity on the uh that SVI interface. Was it worth it? In a few cases, yeah, it was.

[00:36:03]Cuz it's like, "Yay, I got the second one in and now I'm going to add it and they'll be redundant and I didn't have to take any kind of a maintenance window to do it." Um I probably did anyway, but uh but but there was no downtime and it was wonderful. Um so, there is a certain line of thinking that that we go through as network engineers where it's like, "If I'm ready [clears throat] for the future, what am I going to do that I don't need today, but I'll be so glad I did it?" And that might be one of those.

[00:36:25]But I'm like, uh I'm sorry, uh EVPN VXLAN does feel like overkill if you're never going to get there. Yeah, it's it's overly complex. Now, there is a situation where I think EVPN VXLAN would be a good idea. It and it's adding switches, but it's not the two switches because like I said, you'd have to get to a lot more than two switches to where it really makes sense in my at least in my mind to do EVPN VXLAN because you can add two more and still do trad core and it's probably the best choice for four switches. And then you're going to have to figure out which one of those that you're going to have to have some aggregation switches or collapsed core switches and and and growing.

[00:37:01]So, you're going to have some disruptions either way.

[00:37:04]But, um if you only have two aggregation devices, let's say you've got 10 switches and you've only got two aggregation devices, but you really want the redundancy, adding a third switch adding a third aggregation, you know, a a thirds Excuse me, adding a third spine is going to be a is is relatively easy to do on EVPN VXLAN, especially with automation.

[00:37:29]Um so, then you can start to scale that out. So, maybe you don't have three today, but you you've got it on the budget for next year, next quarter, whatever.

[00:37:39]Adding it is relatively easy, but converting from trad core to EVPN VXLAN can be complicated. I mean, you can do it, but Couple of questions. First, one other potential consideration in trying to decide um over on the Packet Protector podcast, we're talking more and more about zero trust and one of the tenets of zero trust is network segmentation or even microsegmentation. Yeah. Does one or another design support microsegmentation better than the other? That might be a consideration. I don't think so. Um it depends on how you do the microsegmentation because there's a lot of different ways to do it. Um you know, there was Cisco ACI. They had the one of the earlier implementations of it with their EPGs and then their micro EPGs. Uh-huh. It never really worked out. It's hard to do on the network devices themselves.

[00:38:28]Um, it's more like, can we shunt traffic through a firewall to do it? Or, are we going to use the hypervisor to do it?

[00:38:34]Like NSX. In that case, either one works. It doesn't really matter whether or not you do trad core EVPN VXLAN. So, that one That's a hard question to give a blanket answer for because there's so many different approaches to, um, to microsegmentation.

[00:38:48]Um, but they both should support it.

[00:38:51]Okay. The other question, operationally, is it seems like with EVPN VXLAN, there's a lot of complexity and a lot of upfront work, but if I am also embracing automation, does that mean I get payoff in the long term? Like, an automated EVPN VXLAN environment might be easier to operate than uh, trad core environment because of that automation discipline? Uh, I don't know if they're easier to implement, um, trad core or EVPN VXLAN. I don't think either of them are easier to implement or operate if you're using automation.

[00:39:22]Um, it's just one is more of a requirement for to use automation, but they both can be operated with automation just fine. Um, and whenever you do automation, uh, you spend a lot more time on the front end.

[00:39:34]So, you spend a lot more time, uh, building up the automation infrastructure, getting your repos, getting your automation tooling going.

[00:39:42]So, um, usually I'll spend, if I'm going into an environment, I'll spend a couple of days doing that part, like the day zero part.

[00:39:50]Uh-huh. Um, if you're doing it manually, day zero is pretty quick.

[00:39:53]And then day one, where you're standing it up, that takes a long time in in when you're doing it manually.

[00:39:58]But in automation, it's flipped.

[00:40:00]Automation, you spend a lot of time in day zero, and I can do day one in like two hours.

[00:40:05]Yeah, maybe it's not I guess my the thrust of my question was, if I do the upfront work and I'm operating an EVPN VXLAN environment with automation, how does that compare to operating uh, trad core without automation?

[00:40:18]Uh, >> If if I done that upfront the automation yeah, automation is always worth it in the long run as opposed to manual operation of any kind of network.

[00:40:26]>> Absolutely, it does yeah, it doesn't matter if it's tradcore or VXLAN. You're you are going to be faster, more accurate, and more stable generally speaking by doing automation if you then dive into doing it by by hand. I personally and now I've been teaching automation for a number of years now.

[00:40:42]I've been teaching it for you know, depending on what kind of automation we're talking about. I've been teaching it for for decades.

[00:40:48]But because I have the skill set, I personally would only operate any kind of data center network through automation whether it's tradcore or not because I'm going to be quicker, I'm going to be more accurate, I'm going to be more reliable.

[00:41:01]But it's whatever the organization's capable of and you know, do you have that skill set yet? Do you need to obtain that skill set? Do you have the ability to the time and the train you know, the time and the training budget to obtain that skill set?

[00:41:14]Well, just I mean we we are making a big deal out of that for automation which is especially true if we're rolling our own, but just as a reminder, there are vendors that offer vendors are offering solutions out there we mentioned Juniper Apstra. I think I just actually did a check on this before we recorded this. They call it Apstra Data Center Director nowadays and then there's Arista CloudVision and of course the open source AVD resources from Arista.

[00:41:39]Cisco's got their Nexus dashboard and their Catalyst Center which both are components of Cisco has a lot of branding that covers a lot of products and so they're kind of like these umbrella labels, but but yeah, within Nexus dashboard and Catalyst Center depending on whether you're doing data center campus operations, they'll do that for you.

[00:41:59]Meaning they're they're abstracting away some of the nitty-gritty and the details in there and it's you have to learn how to use that tool as opposed to well, what I assume you're talking about when you say I teach this stuff, Tony, is like you're teaching people you know, Python and Jinja, and Ansible, and you know, basically making a whole bunch of open source tools work together.

[00:42:17]Well, I teach I teach both. I teach the past couple years I've been teaching the Arista world. So, I teach CloudVision, either using it by itself to do all of the automation, to automate both the configuration or the configuration generation, configuration push, and I've been or using AVD, which generates the configs outside of CloudVision. You can put it into CloudVision. And I've also been teaching automation of just using purely open source free tools like Jinja, Ansible, Python, etc. So, there's, you know, that's a whole other episode of a discussion.

[00:42:52]But even if you're using the vendor tools, and they tend to be easier at the trade-off of flexibility, they tend to be easier, you still need to be able to operate them and and know the ins and outs of them. And and it's going to take more than like a week to to get used to them and get to get to the point where you're proficient enough that you would want to use it in a production environment.

[00:43:11]And just for more completeness, I also want to mention Nokia has their event-driven automation for data center networks as well.

[00:43:18]Yeah, they've got and there's and there's more stuff, too, true. Yeah, EDA is a great great callout.

[00:43:23]Yeah, Nokia has has done a lot of great stuff in that area. I'm not as familiar with them. I just haven't played around with them as much, but they're they're very well regarded.

[00:43:33]It's it's cool. We got a bunch of videos on our YouTube channel where we do some work with EDA. It's it's a lot of a lot of power there. Let me ask you an old school question, Tony. When doing MLAG designs back in the day, we were always worried about split brain. That is, the two devices that are participating in the in the MLAG group losing touch with one another and both deciding that they're operating on their own now, and then madness ensues. Is that a big problem in 2026, would you say?

[00:43:58]>> Not really. I mean, the two MLAG implementations that I'm really familiar with, so Nexus and Arista, they're as, you know, not to say that there can't be problems, but I haven't run into any problems with them. So, I haven't ever heard of about a problem with them for a long, long time.

[00:44:13]Uh, other vendors I'm not quite sure, but generally speaking, I think that it's a solid technology. It's been around for 20 years. Like, we've been doing >> has. Yeah, it was it's been around and it's a solid, mature, um, uh, project and I I don't consider the proprietaryness of it as a problem because again, it's only two devices.

[00:44:32]And fun fact, there actually is an open standard for MLAG. It's called DNRI or DR DNR DRNI.

[00:44:39]Um, it's part of the IEEE standard uh, I 802.1AX and uh, and only one vendor uses it. As far as I know. So, it's it's effectively proprietary.

[00:44:49]It's every vendor does their own thing, which is fine because it like I said, just two devices.

[00:44:55]And then one other set of terms I was hoping you could uh, help us understand in more detail. That is ESI, uh, Ethernet Segment Identifier, uh, versus MLAG. I think we can compare the two of those. Is that fair? Yeah, so uh, the another consideration might be or maybe not a major consideration, but um, they're two different technologies to deal with how are we going to connect a host to multiple switches.

[00:45:20]Now, MLAG's been around for like 20 years where we have two switches, they present themselves as a single switch.

[00:45:26]So, in all these cases, whether it's ESI or MLAG, the host connecting to it or the the CE in service provider parlance, thinks it's connected to one switch.

[00:45:37]Gets one LACP system ID. If it's connected to another another switch, it gets one bridge ID through uh, spanning tree.

[00:45:46]How are you going to combine it?

[00:45:47]MLAG is the traditional method. You can use it with EVPN VXLAN.

[00:45:51]Um, but it's the only option with Tri-core.

[00:45:54]And it's in in my in most cases, I think it's perfectly fine. Um, I'm not I'm not put off by the proprietaryness of it.

[00:46:02]It's a little bit less operationally flexible because of the software and hardware requirements.

[00:46:07]But the appropriateness, I don't care about. And you can only do two.

[00:46:10]Now, ESI is avail is another option that you have available to you in the EVPN VXLAN world. You could do MLAG or you could do uh um Ethernet segment identifiers. Um so that's kind of like a distributed um it's a distributed LAG.

[00:46:26]And it uses what's called an ESI, which is a 10-byte identifier to identify which um ports on all of your switches throughout your fabric participate in that same LAG. So it's like a kind of like an LACP system ID. And there is also a separate >> you said distributed. Yeah, I'm not married to just two devices that are an MLAG pair that present in that way. I can distribute ESIs all over the fabric across whatever switches.

[00:46:51]Little hard to imagine use cases where I'd go all over the place all over the place, but we have flexibility.

[00:46:56]>> you have the flexibility to do more than two switches. I generally don't see that as a huge benefit though just because of the way that we typically rack and stack things. It doesn't make a whole lot of sense to like go to three or four.

[00:47:07]>> to like two tours and those two tours are right next to each other in the same rack.

[00:47:11]>> Yeah. Yeah, so like yeah, you can do more than two devices, but you really like like the the Thor emoji?

[00:47:20]>> [laughter] >> Okay. So and the other one the other operational actually there's two more operational benefits. Not major ones in most situations I think.

[00:47:31]One is your you don't have to use the same hardware in the different switches that have the ESI segments attached to them.

[00:47:38]Um so you could do like a different hardware models of the same better or even different vendors. That's not really a Like I really don't consider that a benefit cuz I'm trying to avoid the multi-vendor fabrics. But you can do like uh like a like a 7050 X2 and a 7050 X5 or don't even remember if those are real model numbers, but like that kind of thing.

[00:48:02]And it's fine.

[00:48:03]And the difference >> hallucinate, Tony, they're real. You're confident. Yeah. And then they're and then the software versions that they have on them don't have to match. As long as they're both capable of it, that's fine.

[00:48:13]Another one is typically with MLAG in most implementations of MLAG, you eat up two ports on each switch.

[00:48:20]Because you want to you have to have a peer link.

[00:48:22]Yes, and you need two of them because you want that redundancy because you don't want the split brain thing we were mentioning earlier.

[00:48:29]>> Yeah, and usually they can be the small the slower speed ports like the front facing ports.

[00:48:33]And a lot of cases that's not really a big deal, but with ASI, you don't do that. You just you do you don't have to connect the switches to each other.

[00:48:41]With Cisco's VPC implementation, in some situations, you can actually use the peer link over the over the spines.

[00:48:48]So in that case, you don't need to to connect the devices to each other. But there are some sites that are like we want every port. We want to get every dollar out of every port we can, so we're not going to have the we're not going to burn up two ports of a 48 port switch to connect to each other. So those are some operational considerations. Usually not a big deal, but those those can be some some deal breakers.

[00:49:12]Tony, I don't know that we helped anybody.

[00:49:14]>> [laughter] >> We're kind of we're kind of at the end of our conversation. I don't know if we helped anybody make a decision about Trill or versus EVPN-VXLAN.

[00:49:21]But cuz there's so much of it depends though. I mean that's that's the thing.

[00:49:24]>> Like any good network design, it's really hard to you know, it's it's our our good friend Ivan Pepelnjak, it's really hard to give like a definitive yes no for for any situation. It's like, all right, tell me more. Let's let's you know, spend the next 20 minutes of your life telling me about your network and then I can give you some recommendations.

[00:49:41]There is one point worth making here, which is especially for smaller shops. I I know that EVPN-VXLAN has become in fashion with a lot of VARs and a lot of vendors. They want to sell you that design.

[00:49:55]And so the question to be asking is, "Yeah, but why? Why do we need this?

[00:49:58]What are the drivers that you see we need to implement this technology?" Um because maybe you don't. I mean, Tony, I think one of the cases you've made here is maybe you don't. Maybe you don't need this. It's got its advantages. There's reasons why maybe you do, but but but also maybe you don't, particularly if you're not going to be growing any bigger than you are.

[00:50:18]Yeah, for smaller shops, for shops that have a smaller team, or a team that has a lot more responsibility going to be on the network, um you know, tried core is probably going to be a better choice.

[00:50:30]Um for really large fabrics, EVPN VXLAN is almost certainly going to be a better choice. And you know, we talked about all the factors here.

[00:50:38]But I'm of the opinion >> [clears throat] >> I'm of the opinion at least that there are plenty of situations where tried core is the better choice.

[00:50:46]Not always, of course. Um and there are definitely situations where EVPN VXLAN better choice. And then there's some where you could go with either, and you'd probably be just fine either way.

[00:50:57]Um and it all depends.

[00:51:01]Okay, everybody. If you're listening to this, I hope if you had listened to that episode which uh Drew found for us as episode 809, EVPN all the things. He put it right in our notes while we were recording here. It's a great episode, by the way.

[00:51:12]>> that. And and and yeah, that you're going to get one perspective and and get a lot of good things to chew on and think about. And then now here's a different perspective um where maybe you don't EVPN all the things.

[00:51:23]Um and that's that's something we value around here, sharing a lot of different viewpoints and different ways of thinking to help you think about your environment and what you're doing and and what the right decision might be for you because because [laughter] it depends. We just We say it all the time and it's cliche, but I mean, it really does. It really does depend. And another word of respect to the to the guest you had on on that on that episode. I can't remember his name, but Jeff Jeff Jeff McAdden.

[00:51:45]>> Yeah, I agree with like 95% of what he says. I just think that there are some cases where EVPN maybe not everything.

[00:51:52]Okay.

[00:51:53]I mean I do >> Jeff want to have a debate.

[00:51:55]>> [laughter] >> I I do feel like this is channeling Greg Ferro, but he was very dismissive of doing things just because it's in fashion. Yeah, and it does feel like EVPN VXLAN is the fashion. So >> Yeah. If you want >> to explore as a technology. I think if you're a networking person and you haven't worked with it yet, it's a good thing to start playing with.

[00:52:12]It's going to probably benefit your career pretty substantially at some point at least.

[00:52:18]But it is definitely a I think a must-have skill set if you're working in the data center at this point. So and it has great advantages and great opportunities with it, but it's but it certainly is in fashion right now.

[00:52:30]But you can still hold your head up high if you are running a trad core network.

[00:52:33]Yeah, with your long flowing dress and your >> [laughter] >> your influencer channel and Yeah.

[00:52:40]>> [laughter] >> And your >> [clears throat] >> Tony, if people want to ask you questions or maybe they want to see what you're teaching next, is there a place they can get in touch with you? Yeah, you can find me on LinkedIn. Tony Bourke b o u r k e. You can find me on I've got a YouTube channel Tony B.

[00:52:54]And be probably linked in the show notes and You can also just email me tony.the.automator@gmail.

[00:53:04]Send me some questions email.

[00:53:07]Tony, say that one more time. Tony Tony the automator with a dot in between each word. Tony.the.automator.

[00:53:14]Yeah. Okay. Got it. Not not [email protected]. [laughter] >> [laughter] >> Okay everybody, thank you very much for listening all the way to the end. If you made it this far, leave a comment wherever you're listening that says either EVPN all the things or trad core for the win. Comments are a way to signal to the algorithm that rules us all that this podcast is super awesome because it has high engagement and we win internet points for that. So if this podcast made you feel things, tell us your thoughts at packetpushers.net/followup.

[00:53:46]Like, share, and subscribe. Watch our pleasant faces on Spotify and YouTube.

[00:53:50]You can buy some merch at store.packetpushers.net.

[00:53:53]Join the Slack. Sub to the newsletters.

[00:53:55]Check out our many other podcast series with super smart hosts who know things and share them with you. All that stuff.

[00:54:01]Or or two of those you do, which is which is nothing at all. That's fine.

[00:54:04]We're not We're not trying to give you homework as much as let you know what's available out there for you in the wonderful world of packet pushers. And until next time, just remember that too much networking would never be enough.