N4N065: Well Actually 4: Multicast, MPLS, and More

0:00Welcome to NSFN Networking on Ethan Banks with Holly Podbilac and I, but a networker for decades and Holly, well just a few years. Well together, Holly and I explore and explain the fundamentals, jargon and endless acronyms of networking. So if you're maybe your college student or you're an IT professional and you're caring for a network for the very first time or you're a salesperson selling networking gear for the very first time. Hey, you found your podcast on today's episode Holly and I share some of the comments. You've sent us about episodes that we've done over the last six months or so. Some of these are well actually where maybe you're correcting or or in this case for the well actually is today, it's like you guys went and dug and found more information or knew more than we got into in a particular show and you wanted to share. So we love to hear from you guys. This is I don't know of all the podcasts I've done over the years and is for networking

1:00is the one where I get the most comments sent Holly and I hear from you guys more than any other podcast I've ever been a part of. You can send us your comments via packetpushers.net slash follow up or you could ping us in the packet purchase community Slack group which you can join for free at packetpushers.net slash community and Holly and I are both on LinkedIn as well. Holly before we get into all the comments, you've been public that you've you've changed employers you're working for for Palo Alto. I think maybe we've talked about that on the show before, but I was just curious how you have found the leap to a company focused on cyber security. That's a great question. I'm loving it. I think what I'm really loving is that I'm still doing the podcast. So it's forcing me to keep in touch with my core networking knowledge. But the cyber space, especially what September 2026 is crazy with everything happening in AI, all of these agents going rogue.

2:01I just think it's the place to be for me right now. I'm love rapidly changing industries and technology and every day, Palo acquires a new company and I haven't even bought up to speed with their current technology. So it's it's keeping me real busy. But in saying that, I think having a core understanding of networking has made that transition so much easier. I have heard that from and worked with a number of folks that are involved in in cybersecurity over the years. And that's been a universal truth. Man, if you know networking and you're involved in cybersecurity, it only helps because there's so many factors and attack services and technical detail that matters in cybersecurity related directly to networking. So the more you know about networking, the better you might have success in the one hundred percent. I'm at the end of the day. Those packets you all trying to protect flow over the network. So you have to have a good understanding of how everything connects, what protocols

3:02are being run and everything else. You don't have to be an expert, but it definitely makes the communication between security teams and networking teams much easier. Well, okay, to pull this script together, Holly, I went back through the archives and I selected 14 different sets of comments that came through. I don't know that we're going to get through all these today. We'll see how it goes. And those of you that wrote to us again, packetpushers.net slash followup is where most of these today came from. Some of you hit us up in LinkedIn DMs or on a Slack message somewhere. And there are way more messages that came in that we're going to cover. So if you don't hear yours today, sorry, we do read them all for sure and share them with each other as you guys write to us. So the first few comments here are just those you guys that were kind of sending us the love we're feeling the love from you. And Holly, why don't you read off the first one? Sure. So the first one came through June, May, June, gosh, don't know my days. But anyways, from somebody who was anonymous and they wanted to thank us.

4:03And I really love this one because this person has been trying to study for their CCNA certification for almost two years. And they were struggling with the motivation. And I think we have all been there. It's a lot to get through. And they wrote in just to tell us how much N is when networking has been a huge part in helping them get over that hurdle. And what's really exciting is that they were able to pass the exam. And the podcast was really a big part in helping them do that. So they thanked us for the great work and just commented that it was a great resource for people who need a little help in their journey. Awesome. We also heard from Ben back in May. He wanted to give us a quick thank you for Anderson for networking. And he says I'm quite new to the networking world. I've been managing a network for a school district in Minnesota. But I've only been doing it for the last couple of years. I've done some basic home networking stuff. But it's been crazy managing 18 sites and learning networking in a more advanced way.

5:04Ben's mentor left a while ago. And so he's been having to dig in deep himself. And as really thank those for the podcast. We're helping him get going. And he appreciates us immensely, which that was feels like responsibility, Pauli. But that is awesome. Thank you, Ben. Hopefully we show the correct information if you're using it for your production networks. Next we had Frank in June. Also feeling the love. Frank said that he would love to see a future podcast explaining what an overlay network is. And not necessarily in terms of specific technologies, but just fundamental understanding. And what's key is that in episode 26, we discussed what is a tunnel. And we talk a little bit about overlays and underlays. So I would suggest doing that. But I do think moving towards more technical topics like EVPN VXN, which eventually we will cover. I would love to do a little bit of a deep dive into this whole

6:07overlay, underlay, understanding as well. Well, I think, yeah, I mean, Frank's asking about it was suggesting like, like, not like a more of a generic episode and overlays and underlays. So maybe we do maybe there's an episode they're just talking about that and the principles of it. I mean, it's weird because in my head it's simple. It's like, I used to work on what we didn't call them underlays. We call them networks. And then we added a bunch of tunnel fabrics on top of the network. And that became an overlay. This thing we laid over on top of it. And so it was like this natural evolution. I saw happen over over the decades. I can say as someone who did not see said natural evolution, that it is not simple. I struggled to understand what this whole overlay underlay concept was because maybe I didn't see that natural evolution. So it was like, well, is it a physical thing? Like there's tunnels that it's a lot, it's a lot to understand. So I think it's definitely worth spending some time there. It is. And it's funny. I realized that in a sense I had a cheat code.

7:09In the beginning, I was building one-off tunnels. It was an IP-set tunnel to connect a couple of organizations across the internet. Or it was a GRE tunnel that would just connect two endpoints. And it wasn't an overlay. It was a thing that went over the top of the network. We were putting these packets in the tunnel. And then that concept just got expanded over time. I ended up working with DMVPN, which was a multi-point GRE tunnel. A GRE tunnel that can go to a bunch of different destinations. I think that's basically an overlay. And then software defined when came. And like I said, I had a cheat code. I kind of sought in the end. It was just steps. Yeah, and it saw it happen. Ben wrote to us in July. And another bit of feeling the love here from Ben. He was watching our podcast. He's been hooked. And he's learning the content to help fill in knowledge gaps. Ben works in cyber security. And he's found that most good security folks are rock solid and networking. And Ben has passed the CISSP.

8:11But then felt like he needed deeper understanding to really understand more than the surface level. So he thinks the podcast is awesome. Thanks Ben. Dude, I have looked at the CISSP. And I just said, no, I'm not going to take there was so much material. I was like, I'm not going to take that on. I didn't want to do it. I had done so many other sorts. I was dealing with so props to have in the CISSP. And to be right again, as you're digging in, I just be curious as you develop your networking knowledge, what those aha moments are that you come up with in the world of cyber security. Things that come together as you as you get stronger with your networking stuff. Oh, Holly, then we got Peter Lamb, who wrote to us back in April about to multi-cast fundamentals. So, okay. So we did two parts on multi-cast with your friend Lenny, Lenny Juliano. And that was those really popular episodes. It was episode 50 and episode 52. And Peter worked at CISCO.

9:12He was CISCO's multi-cast product manager from 2010 to 2014. And a different company called Pocket Networks Back in the day. And so he had, he's got memories. He shared a bunch of different memories about how multi-cast was being deployed in the real world and some of the challenges that were going on there. And so on. And he mentions that Lenny's point on use cases for multi-cast really landed because for the longest time, the only people paying for proper multi-cast architecture, financial institutions and stock exchanges, which we talked about with Lenny. That was one of the main use cases where we see multi-cast being used. And then of course, live broadcasting in sports, Peter says, finally forcing the broader internet to abandon brute force unicast where everybody gets a copy. Because you can't, that doesn't scale globally. It just doesn't, which was overdue. And Peter shared many more reflections and thoughts and notes. But where the future is really going.

10:14SRV-6 is a part of this that's source routing using over IP version 6. And then beer, which I think we mentioned beer and passing with Lenny. B-I-E-R, a bit index, crap, not, I don't remember now. But it was a different, it's tied to, a multi-cast. Multi-cast can work in a stateless way. And Peter, if you don't know, Peter Lam, Peter, L-A-M, you can follow him on LinkedIn and he's posted some thoughts on multi-cast. And this episode, and so Peter be a great guy to follow on LinkedIn. Someone who, if you like to follow people who are deep inside the nuts and bolts of networking, what's going on? It's been the industry a long time. There's lots of them out there and Peter's one of them. So go get Peter a follow and if you got some multi-cast stories to share and reflect on, Peter's not like a good guy to connect with. So great stuff. And he thanks us for taking time with Lenny to unpack the history of multi-cast. It's because in 2026, who's talking about it, right? Well, we're trying. We're trying. Yeah.

11:16I was awesome. I really enjoyed recording those episodes. I think it was a lot of fun. I learned a lot as well. So we also then had Zach Jay, who commented on episode 51, which was the MPLS fundamentals episode. And he said that his timing is terrible because he listened to the well actually three and then submitted this afterwards. So likely there's a well actually four here. And he said he has a dream about a network podcast format that doesn't seem to exist, but the MPLS episode came close. So I'm glad we are edging towards your dream on that. He said that he'd like to be able to also listen to interviews with network professionals. And I think we try and do that a bit where we bring in some guests. And he said it doesn't have to be about a specific topic. He just likes to hear them talking about something they do. And some real life experiences, which could be fun to do. Ethan, take some of the trauma and chat about it from everybody.

12:16But he said, yeah, we got to figure out how to wrestle it into our format because we have so many podcasts on packet pushers and the packet pushes network. Zach, I don't know. Like if you scroll through some of the episodes on heavy networking, a different series in the packet pushes network, you might find you will definitely find some shows like that where we don't we're not really talking with a vendor. We're not really talking about a specific technical topic as much as someone just worked on a project and they had lessons to learn or they learned things and they're coming on the show. They actually share their lessons as they work through that project. So that might might get there. I think we do someone in this friend networking. Yeah. And I think Alexis and Kevin on life in up time, starting a series specifically on that bringing in people in the real world and discussing things that have gone right, things that have gone wrong. So Zach, it may be worth checking that out and seeing what comes out of that part as well. Yeah. Yeah. There's there is a ridiculous amount of content in the form of podcasts that we're putting out

13:20of packet pushers. So not just end is for networking, heavy networking, but we have about a dozen series that are active right now, putting out a show either every week or every other week. So it's there's a lot and Zach, you can you can find stuff that it's again, there's no one series that is like dedicated to exactly the format you're talking about, but there are definitely shows in the catalog where what you're looking for does come up 100%. So I'm glad you like the show. Thank you for the suggestion. All right. Mike wrote us in July again about the MPLS fundamentals episode and he says he's known for a long time that MPLS existed. But you know anything about it. And that's fine. He didn't need MPLS in his job exactly, but he but he then had a moment where he says fast forward to last week we've been having performance degradation when we fail over to our secondary connection to our managed service provider ISP. And he was scheduled for a troubleshooting call. And one of them pull up a diagram on what happens to the network after it leaves his network.

14:23And what do you know that traffic diverse is a bunch of MPLS hubs. And so the episode we did helped him like, oh, okay, I kind of know what's going on there because he'd listen to the MPLS episode that we did. So he knows what those hubs are doing and had much more confidence about what was happening, even though he doesn't know all the details couldn't run an MPLS network. He's got a clue now. So that that that was great. And so he just is thanking us for for so many diverse topics that that we cover and so on and then concludes with now for BGP. Okay, we have started recording BGP and planning BGP episodes. They're happening. They are happening. And again, if you won't have listened to the first BGP episode yet on the hauling I recorded it. And Holly, like we said at the conclusion of that, we're not going to do this blockbuster six episodes series right in a row, but we are going to begin sprinkling in additional BGP topics over time where we've got we recorded the first one, which we called a

15:27gentle introduction to BGP. And we're going to have there's someone coming on who's going to talk to us about the best path algorithm. We've got our friend Andy Laptebs going to come on and talk about some traffic engineering with BGP and more. We've got more topics coming on BGP. So so yes, hopefully we'll we'll be satisfying everybody on the BGP topic over the next several months. I don't know if I'd say that. I don't think you can satisfy people with BGP. There's too much. We'd have to have a whole dedicated show to it. So hopefully we peak your interest to BGP. I think that's a good way to put it. We'll get to the basics anyway. Yeah, you're not wrong. There's so much material out there. It's been overwhelming just how much material, how many books long books have been written about it. So yeah, so satisfy probably too strong for word. You're right. Yeah, give you enough to understand the start of those books and then yeah, let you run with it. Yeah, exactly. And then you go from there. We got some follow-ups from Garrett

16:29on the wide knack walk through episodes, which were episode 55 and 56. He wrote in saying that he really enjoyed the recent episodes featuring experts on the specific topics and that he really enjoyed both of the commentaries and that it's fun to have someone who's got a little bit more experience on the topics there. And that was also great to hear from Jay Jay as a guest as opposed to a host, which is always fun. So thank you for that and that he'll be exploring some other options like ClearPosts and told us to keep the packets flowing. Excellent. Yeah, so the way we're thinking about bringing on guests is is kind of like it depends. So for me, I have my experience with expertise in certain things. I've been an instructor. I've been writing since 2007 about networking topics and so on. So the certain things that I feel comfortable that Holly and I can get together and cover that topic. But there's other things where it's like, yeah, we want Jay Jay, because she knows this stuff very deeply, this very narrow specific topic and that's her world,

17:33that's the thing that she knows and like Lenny on multicast and the other guests that we've had because they raised their hand to talk about that specific thing and we'll bring those in. But I will tell you just from a logistical standpoint, when we schedule with a guest it's hard to get everybody's calendars coordinated because people work and it can be a tougher so, they'll be a mix. You'll have to put up with Holly and I talking about things. But then, you know, we'll bring in guests for variety and their deep knowledge. Anonymous wrote us back in May and and chatted about episode 56, the wireless snack walk through and pointed out that the topic of certificates came up and mentioned that me and Jay Jay both hinted at web service certificates, although the concept of certificates for authenticating a radio server kind of glossed over the concept of an internal a PKI or purchasing search for public entity and applying them to internal servers and so on. Yes, we definitely glossed over that. That is a very fair observation.

18:36Because it is a show all its own, you know, at least to get into certificate infrastructure and maintaining your own internal certificate infrastructure and so on. There's a lot to it and there's a lot of you'll be on just building it. There's also securing it properly and then dealing with your own browsers and adding them to the trust stores and so on. There's a bunch going on there. So your question anonymous, would you be willing to go into some operational practices for handling certificates internally, do most companies purchase their certificate from a public entity like DigiSert or GoDaddy or somewhere else with multiple subject alternative names and apply them to their internal servers, etc. Do you have any working internal PKI? Okay, so will that does feel like a show at some point because there's use cases beyond radius about that? I know you have the specific products that you're working on at Palo Holly, but there might be some folks in Palo that I suppose are really good at this. Yeah, this is definitely in the

19:38wheelhouse of what we do. Since I'm still quite new, I'm still trying to figure out who all these people are. No, but I know one of the companies we recently acquired works a lot in this space. So if we want to do a show on this, I can definitely hunt some people down who would love to chat with us. We have access to, we know people, Holly, we know people. Yeah. Exactly. I can find a friend, you know? Yeah. All right. All right. So next we had Mike right in about episode 57, which was the art of troubleshooting. He said that he is still loving the NSF on networking podcast and he looks forward to every episode. The latest episode on troubleshooting had him thinking of a few things. And he mentions three general topics and goes into them, but mentioned that troubleshooting is a valuable skill that really does develop with experience as we definitely talked about in depth. He said, be careful

20:41when you say it usually isn't the network. I think Ethan, you can say this because you're a very good network engineer. You got cold out even. But he said when someone is newer to networking and is setting up a new network, something and something doesn't work, it's much more likely to be the network when you're the one who set it up. So I think that's a great point. Yeah. That's fair. That's fair. I understand what you're saying that Mike. Yeah. It's funny. It's just some of my resistance to it's the network is it's kind of a running joke. It's kind of a meme in the networking community. Like you get that ticket. What did you change the classic one I got at one company was what changed on the firewall overnight because my app isn't working anymore. I think, you know, I think change. Why did you ask? It's like you led with, okay, we know you did something in your guilty. Just tell us what you did. It's like nothing changed. And then it's like, well, just tell me what the problem is. Let's get our heads together and figure it out. So there is a meme that makes us a bit

21:42defensive as network engineers about that. But Mike, your point, I understand your point, depending on your level of experience, maybe it is more likely to be the network all depending. So fair enough, fair enough. Yeah. And that's actually something I struggle with, especially now that I've moved into a different industry. I always assume that it's me. I assume that I don't know something. I don't understand something. And honestly, I haven't found a time where that was correct. It actually hasn't been me yet. But I think, you know, that all that comes with confidence in time understanding, like as he said, either you've been in the industry for a long time. So you get a good feel of the bat, whether it's the network or it's not where, you know, if you might not have that instinctive understanding. And then, yeah, yeah, go ahead. It makes that point. Yeah, humility. You know, yeah, yeah, humility. That's exactly it. That's exactly it. It's like last point about troubleshooting was humility, which we did talk about because

22:44sometimes it really is the network. And that's fine. You can't, there's no reason to get all upset and angry or defensive because it happens to be the network that the you're responsible for. That's the thing that's broken or the thing that's at the root of the problem. Yeah, you gotta be, gotta be humble. And then Mike talks about a whole scenario here where Mike was, Mike was, a vendor was saying it has to be the network. And his response was, I don't think so. Everything looks fine. The logs look good. A lack of evidence isn't proof. So I'll look in further, but I don't think it is. And as Mike dug in, he found out there was an access list that that turned out to be the problem. And so he sorted that and then found out that not only was the access list a problem, the lack of evidence was there was no denies being logged. And so the the thing he didn't see is because it wasn't being logged. So as we also talked about, he actually had two problems, you know, the access list. And then the lack of logging that would have,

23:46would have helped it troubleshoot it. So yeah, humility is key at the end of the day, no matter what. Yeah. And sometimes the problem is because you don't see what the problem is, which it's very tough. From Paul back in June, commenting on episode 59 where we talked about twisted pair cabling. He was listening to this podcast while running and terminating a four wire for four network wires for a new area of the office and like most of us, Paul doesn't do much wiring these days. But a lot of us have that were around back in the day. And he says this dearies is great. Lots of old memories and that he suggests this series to all of his staff along with the other pack of pushy shows, great content and help with walking my dogs. We I know that we help walking dogs and I've got mowing the lawn as well. So if you mow your lawn that I know we keep quite a few people company on on their outdoor journeys on that.

24:47We also had Michael right in about that twisted pair cabling episode, which I'm surprised that we got so many follow ups on that because it's cabling, you know, you assume it's a boring topic. But Michael said that the twisted pair podcast was excellent that an IT person asked what a RJ45 was. So this was a good episode to include. He also added some information about technical topics like about 10 and a hundred megabits per second. This is a small school stuff. Yeah. Using only two pair pins. I don't know if it's stuff Ethan. Yeah. Yeah. Yeah. Back in the day you'd have a twisted pair cable that would have eight conductors in it like we were talking about. But if you were at 10 or 100 megabit per second speed, those very early iterations of Ethan had only used a two pair of the four pair in that sheath. Pins one and three and pins two and six. And then we moved to gigabit, 1000 megabits per second. Oh boy, we're using all four pairs.

25:48So that was that was a thing. And the reason it was a thing for some of us is because we did bad things with the wiring. We did. We would split pairs. And so knowing you had eight conductors in there are four pairs in that twisted pair cable. You could you could if you knew what you were doing split the pairs. So you take one, two, three, six and terminate that at a jack at a jack and then you take the remaining four, five and seven eight and terminate that at a second jack. And you just have to do the wiring on the other end to make sure you could actually get signal down there. The problem is as soon as you go to gigabit, it don't work no more. That's bad. And you'd be I had I had not heard of the split splitting pairs trick that some people would use to get more jacks into a cubicle or something without having to run a whole new cable. And and I think I was there to troubleshoot why gigabit wasn't working something like that. And I remember pulling the face plate off and been like, what is this abomination?

26:51What is happening right now? And then then someone explained it to me. I'm like, that is that is clever, but that is horrible. You get to do that. But then can you go backwards? Can you put them all back together? Or because as long as you deal with the other end? Yeah. But in the end, you lose you lose a jack in that split parake scenario where you're not supposed to be splitting pairs to get two jacks. And again, this is this is deep history. This goes this is a deep cut way way back. It was 30 years ago. We were doing nonsense like this. We still weren't supposed to do that. It's just, you know, you know, things and you're you're like, ah crap, I got to put an extra jack in there. There's no way I can run another cable. It's all too hard. I'll just I'll just split the pairs. It'll be fine. Till it isn't. Then Michael, you also included tons of notes about power over Ethernet in your note. And rather than get into that, Holly, that's a show. We definitely should do a show on power over Ethernet because there's power over Ethernet, P O E plus P O E plus plus. There's coming up with

27:56power budgets. There are cabling requirements. There are there's signaling and messaging that goes over during P O E negotiations. There's there's all kinds of stuff in that. And that that's worth talking about. So yeah, 100% that that's got to be a show. Yeah. Another one out to the list. Another one to the list. Well, well, in your juniper days, I know you were selling some wireless. So you, P O E must have been part of your conversations. Oh, 100% wireless and switching because there sometimes people want P O E on their switching ports as well. So got to make sure sometimes depending on what wireless they have, they're buying switching. You need the correct as you mentioned, the different types of P O E. So a lot of conversations around that more than you would think. Well, all right. We've got another comment here from Greg who wrote to us back in August in response to our your first Wi-Fi network series. We did three parts episode 60, 61 and 62. And we got we got a few different comments from folks about the six gigahertz range, which we

28:59did not get into in any particular detail. And so this is another one where yet again, Holly, here's another show where we're going to talk about Wi-Fi 7 and then like dig into the six gigahertz spectrum and some of the details around that specifically. But Greg shared a lot of thoughts here about Wi-Fi 7 capabilities, including the six gigahertz requirements that are tied in here. So Greg says that Holly mentioned OFDMA and Wi-Fi 6 has a decent OFDMA capability. But Wi-Fi 7 takes OFDMA to another level. The for example, the resource units in Wi-Fi 7 no longer have to sit on a contiguous block of subcarriers. The access point can now assign non contiguous or multiple resource units to a single client device. So that means to me with OFDMA, you don't have to have a subcarrier, some part of a frequency block there. They don't all have to be right next to each other. You can split up and have multiple subcarriers that are in use there rather than have

30:00them be. I can use one, two, three, and four subcarriers right next to each other. Well, no, you could use one, six, and nine, non contiguous and assign them. So you get more much more flexibility there. And to me, that also means you're going to get better use of the subcarrier space. And great continues that layered on top of that OFDMA change in Wi-Fi 7 is preamble puncturing. I have not heard of this one. Okay, what does the was great say here? Preamble puncturing allows a single access point to service far more clients. So it's a great technology. If part of a wide channel gets jammed by interference, the resource unit can simply skip over that interference and still use the remaining healthy spectrum. Okay. In every previous version of Wi-Fi, once a sub-channel interference, the entire channel became unusable. Interesting. Okay, that is cool. That is great technology. We don't lose all the spectrum in that channel just because some part

31:00of it's got interference or something. That's pretty cool. Very interesting. And I've dealt with those full channel changes. So it's very cool to see that there's another option to that. And great continues about six gigahertz and Wi-Fi 7 on the six gigahertz side. One thing worth mentioning is AFC or automated frequency coordination. Standard power access points operating in six gigahertz aren't allowed to just pick a channel and blast away since that spectrum is shared with incumbent users, people that are already there, as well as such as fixed microwave links. And this is something interesting. If you get into wireless networking, you can run into someone whose license spectrum or they're running a microwave tower of their own. I did this in one place as I worked. We had a microwave link across town. We had one set of offices up on a hill, another office deep in the middle of the city. And the office up on the hill could see the top of the building down in the city. We shot microwave between them with spectrum that we licensed

32:05ourselves. No one else could use it. But there is even though it was a tightly beamed sort of a transmission, there's still bleed from that interference that can happen. Anyway, great continues. So before a standard power access point can transmit, it has to report its exact location to an AFC automated frequency coordination system, which checks that location against a database of protected incumbents and people that are already there, the incumbents, and returns a list of channels and power levels that are safe to use without causing interference. That is cool. I did not know. Have you heard about this? So I think the reason why this came up in as follow up is I definitely glossed over geolocation in the episode. There's something about the standard power versus low power indoor. And this is it where if you are able to transmit GPS coordinates or your geolocation, you can start running standard power inside. But you have to be

33:06able to report your exact location. So if you're in a building and there are a lot of them in Newark where you are unable to give those GPS coordinates, for example, if you're in World Trade Center, not possible because you don't run everybody blasting those GPS coordinates, you will not be able to run standard power. You can only do like low power indoor. It's very interesting. It's super cool. That is super cool. Now that is really cool. That is really cool. I am that that's just you Wi-Fi people. You do cool things. You do cool things. And then Greg kind of concludes this for us here by saying that this as a Hollywood's just saying this is where GPS comes in. Standard power is six of your Hertz APs need a GPS receiver or another FCC approved method of establishing precise location so that they can report their exact accurate coordinates to the AFC system. Without it, you can't get approval. You're stuck at low power. Again, thank you Greg. That's great stuff. And oh yeah, we got to do a dedicated, you know, find some Wi-Fi 7 nerds

34:12and you don't get them on. David Coleman over extreme or some of the other folks at Juniper or there's all kinds of awesome Wi-Fi people that we could pull in and get in on some of this stuff. Keith on our very own Pack of Purchase Podcast network would be great. He runs the The Heavy Wireless Podcast. He's forgotten more about wireless than I ever learned. So we again, we know people. I was going to say especially around Wi-Fi, those I made a lot of friends. So that would be also, I mean, just reading that follow up, I think there's so much cool stuff that you don't know until you really dive really deep into the topic. Like I obviously glazed over it from a sales engineering perspective, but I never got deep into it from a network engineering perspective. And there's just so much more cool stuff and it just makes me so excited and so nerdy. Will you want to take a stab at the last one from Jeff? Sure, I'll take a stab at some of it. So this came in, I think yesterday,

35:13or over the weekend, on episode 63 on Link Layer Discovery Protocol. And Jeff said, for this will actually, he's not an expert and had to do some looking to find this information. But the destination MAC address used by LLDP seems to be defined as a sort of scoping mechanism, particularly around the idea of provider bridging. Now Jeff, we really appreciate all this information that you shared with us because you did mention that you didn't get to fully read this PDF because you are on a road trip and on the side of the road to ride this follow up. So we love to hear it. So Jeff, Jeff sent us this PDF and I popped it open. I looked at it too. Thankfully, it's not one of these, it's, I don't know if you had a chance to look at it, Holly, it's more like slides from a deck for someone giving a talk as opposed to endless paragraphs of

36:14words. It wasn't one of those kind of things, but he did find some good information there. This is where we were talking about the different MAC addresses that are used in an LLDP frame. And you and I were like, it could end in 0, 0 or 0, 3 or 0E that MAC address, but we couldn't know why. Why would there be a variation? Wouldn't it be a standard? And this is the thing that Jeff uncovered for us, that was buried in this document from the IEEE. And by scoping mechanism, he means, depending on what that MAC address ends with, whether it's 0, 0, 3 or 0E, it means different things to the bridges, to the switches that the LLDP frame is passing through. So if it ends in 0, the provider bridge is going to forward the frame, and it will be received and filtered by other customer bridges. So what's the thing here between customer bridges and provider bridges? By bridges, we mean, we just think of it as a switch,

37:14that's all we're talking about here. Do you get the differences making and why that would matter, Holly, between customer bridges and provider bridges? Maybe, maybe not. Then we recalled this episode a while ago. We did. It was a minute before we, the summer vacations and various things happened. So here's the thing. If I am a customer using a service provider's network, they're the glue in the middle. I don't want to see them. I don't want to see their network and interact with it. I want them to transparently connect my stuff in this part of the world to my stuff in this other part of the world. I don't want them to get in the middle of any of my traffic. What's the thing about LLDP frames? They're supposed to go to the neighboring switch, and that's it. They don't get transferred any further. Well, if there's a provider in the middle, a service provider in the middle between my stuff and my other stuff, and I send an LLDP frame,

38:15how does the provider know to push that LLDP frame through to my switch in the other location? So that my two switches that happen to be connected by the provider in the middle can see each other with an LLDP frame because you've ended the frame with 0, 0. So the provider bridge is going to look at that and go, oh, I'm a provider bridge. So I'm going to send that through. I'm not going to do what normally you would do with an LLDP frame, which is take it yourself and do something with it and act on it. Instead, it's going to pass through. So according to what Jeff found here, if it ends in 0, 3, it's going to be received and filtered by both bridges except for two port Mac relay, which Jeff speculates is referring to in the TPM R bridge as an old school two port bridge like way back in the day when that's what you had. You had a, again, history, but the ethernet didn't have switches way, way back, right? I think

39:18we talked about this in some very early episodes. We had hubs, which we basically just electrical signal repeaters. There wasn't any intelligence by them behind them. And ethernets could get too big. You'd have too many, too many clients on the wire, too many hosts on the wire trying to talk to each other. And they'd be too separated by too many different ethernet devices. And so the way you can make an ethernet network bigger was to stick a bridge in the middle and say, okay, all you folks on this side of the bridge are one ethernet and all you folks on this other side of the bridge are a different ethernet network. And only if you guys need to talk to each other, will you see each other's traffic and so on. And this bridge in the middle is going to take care of making those decisions. And they were just two ports way back in the day. A switch is a multi port bridge where that decision is being made all the time. And so not everybody sees everybody else's traffic. It's quite limited. Where you're only seeing broadcasts or multi casts of that everybody sees. Other than that, you only see your own traffic and whoever you're talking to

40:22on a port. So that sounds like the 0-3 maybe is a bit of history. And then the 0-E, Jeff thinks is received and filtered by all of the above classifications of bridges. So customer bridges, provider bridges and to port Mac relay like the like if Jeff's right. And I think I know what he says is the original bridge. Again, going back decades. Some of these documents covered history. And since that is the behavior that we expect from LLDP received and filtered all the way typically, we're going to see 0-E address for the destination Mac and LLDP frames typically. Okay. And then Jeff Caviats, I did not fully read and I just that pete. If you're on the side of the road with nothing to do, Jeff, I don't know why you didn't read the whole thing. But I mean, fine. Okay. That's why I may not have this exactly right.

41:22Jeff, dude, that is deep. That's a deep cut, man. You went you went hard to find that one. I tend to ignore the IEEE docs because not all of them are public. And so and and they're usually so incredibly dense that I struggle to find what it is I'm looking for in there as opposed to an RFC, which those could be dense too. But I usually know what I'm looking for anyway. So okay, good episode, Holly. We got lots of feedback here. I'm glad that that Jeff came back with that because I'm pretty sure on the episode we were like, eh, probably like doesn't really matter. But like, it matters, you know, everything, everything matters. And I think if you're assuming that it's random or you know, it's just there because who knows? Like there's a document somewhere where some network engineer who helped create these standards has decided on these specific numbers for a reason. And if you look hard enough, you could find it. Now sometimes the reason aged out where

42:24this mattered 15 years ago and maybe it doesn't matter to date because technology change. I'm just speaking generally, generically here, that that can be true. But the history is often interesting. And you're right, we may gloss over a detail, but there was someone thoughtful and a discussion that was had before that document was written and standardized that solved some particular problem or address some specific situation is always a reason. Even if the reason doesn't happen to be relevant in the modern era, that's that's a great point. So again, Jeff, thanks, Matt. And that our podcast meets someone pullover and nerd out for a minute is freaking me out a little bit. I got to be honest. Oh, I love it. I'm like, that's that's where we want to be. It's, you know, some people are walking their dogs and going the lawns and some people are like, wait, I got to pull over for this one. It's awesome. It's it's just so so exciting that we've made such an impact. Yes, yes, indeed. And we have a lot more shows coming up. We've been talking about them. There's no

43:29we have no plans to end this show anytime soon. This is going to be going on for a very, very long time. And and and keep them coming. You keep asking for specific episodes. We'll try to cater to you. We're also trying to build episodes that we need to get on record because other episodes, we want to do build on those episodes. So like BGP, like we don't want to get into EVP and until we have these foundational episodes on BGP first, for example, you know, things like that are on our minds. Well, all right, Holly, let's wrap this up. Everyone, thank you for listening to NSF Networking today. If you'd like to share your thoughts, comments, show requests or your well actually is like all these folks did on today's episode. Maybe you'd like to be a guest on NSF Networking because you're a deep subject matter expert. You're a super nerd about some particular topic. And you're like, Oh, I'm really good with this thing. And I want to come on and talk about it. Yeah, hit us up. Hit us up. Go to packet pushers.net slash follow up and let us know. And maybe you don't want to use a web for them. Okay, join our community slack group packet pushers.net slash community. You can connect with Holly and me there. Or LinkedIn would be the third way. Holly

44:32pod billak and Ethan banks. You can connect with us follow us and you can talk to us there. Send us DMs and we'll do our best to chat with you and and so on. Thank you for listening, everybody. Again, thank you for chatting with us. I think I said this at the top of show. I'm going to repeat myself here, but I have been writing, teaching, podcasting and public speaking to network engineers about network engineering topics for over 20 years now. And this series that Holly and I have been recording and it's for networking. It has by far received the most appreciation interaction. So again, please keep it up for everyone. We really do appreciate it. We're going to be back in a couple of weeks to help you learn subnetting. We've got a sub a special guest coming up for that. My friend Tony Matt Kate and we are as we said, lining up more BGP episodes coming and until then just remember that networking isn't hard. Other people figured it out so you can too.