The Dumb Question

I was today years old when I finally understood the real reason we need Spanning Tree Protocol.

That sentence is embarrassing to type. I have a CCNA. I work at NetworkChuck Academy. I am around networking content and networking people every day. And yet, until recently, I did not actually understand why STP exists. I knew what it does. I knew the textbook answer. I could recite it in my sleep:

"Because broadcast storms are dangerous."

And that's not wrong. But it's not the answer either. It's the symptom dressed up as the cause, and I went years—years—without questioning the distinction.

Here's what happened. I was watching one of Jeremy's livestreams just chillin' the way you do when someone who actually knows the material is talking you through it in real time. A very passive review sesh. And then Jeremy got into some of the details around STP. Nothing earth-shattering, just the kind of under-the-hood specifics that I had internalized a long time ago. And somewhere in the middle of it, maybe because of my familiarity with the topic, my mind started to wander. A question started forming that I almost dismissed because it felt too basic, the kind of thing you're supposed to already know by the time you've got letters after your name: Why doesn't Ethernet just use a TTL like IP does?

That's it. That was the dumb question. And it nagged at me enough after the stream that I went and looked it up.

IP packets have a TTL—a hop count that decrements every time the packet crosses a router. When it hits zero, the packet dies. Elegant, simple, self-correcting. Even if something loops at Layer 3, the loop is self-terminating. The packet has a built-in death mechanism.

Ethernet frames don't have that. No hop count. No expiration. No built-in way to die. And—this is the part that wrecked my understanding—that was intentional. Early Ethernet was designed to be as simple and lightweight as possible because the hardware running it could barely keep up as it was. Adding a TTL field would have meant more processing per frame, more complexity in the header, more overhead on devices already operating at their limits. The engineers who designed Ethernet looked at the trade-off and chose simplicity: keep the frame lean instead of reinventing the Ethernet standard from scratch.

I imagine that if Ethernet were developed in 2026, where the computational power found in the smartphone you are probably reading this on eats the lunches of supercomputers of even 20 years ago, instead of the 1970s, we would have come up with some other way of handling loops in the switched environment.

That "some other way" turned out to be Spanning Tree Protocol. Instead of giving frames a way to die, we prevented loops from forming in the first place. Block redundant paths. Elect a root bridge. Build a loop-free topology and just hope nobody plugs in a cable where they shouldn't. It's clever, and it works, but it's not solving the root problem. It's routing around it. [pun... intended, I think]

And then the history gets genuinely interesting, at least to me, and if you've read this far I'm going to assume you're at least mildly curious.

TRILL and SPB came along and essentially asked: What if Layer 2 worked more like Layer 3? What if frames could take multiple paths, handle redundancy natively, not require a protocol whose entire job is preventing the network from eating itself? Good questions. Reasonable architecture.

But before either could gain real traction, VXLAN and EVPN leapfrogged both of them. Different approach entirely: instead of making Layer 2 smarter, just encapsulate it inside Layer 3. Let the routed IP fabric handle the hard stuff. Move the problem up the stack. Let routing—which already has TTLs, already knows how to deal with loops—do what it's always been good at.

We spent decades trying to scale Ethernet's flat-switching model. Then we decided maybe routing was the answer all along.

I could wrap this up here with a clean technical summary and that would be a perfectly fine post. But the thing that keeps nagging at me isn't really about Ethernet.

It's about the question I almost didn't ask.

Why doesn't Ethernet have a TTL? is not a complicated question. It's basic. Almost embarrassingly simple. And I nearly didn't ask it because I felt like I should already know the answer. I have the cert. I work in this space. Asking something that fundamental felt like admitting the foundation wasn't as solid as the credentials implied, like pulling on a thread that might unravel something I'd rather leave looking tidy.

But the question was the thing. Everything I learned about STP's real purpose, about Ethernet's deliberate design trade-offs, about the historical arc from spanning tree to TRILL to VXLAN—all of it was sitting behind a door I almost didn't knock on because ...reasons.

I think about how much of what I "know" might actually be because this is the way things are. Getting it on a how level is fundamentally different from getting it on a why level. How many other textbook answers I'm carrying around that are technically correct but fundamentally incomplete. The honest answer is probably more than I'd like to admit, and that's, I don't know, both humbling and weirdly energizing? Because it means there's still territory. The map isn't as filled in as I thought it was, and the blank spaces aren't gaps in my ability. They're just places I haven't asked the right question yet.

"There are no dumb questions" is something I've spent most of my career filing under things teachers say to be kind. I'm starting to think it might be more like a technical specification. The dumb question is the one that gets past the surface. It's the one that sounds too obvious to bother with until you realize nobody around you can answer it cleanly either, and then suddenly it's the most important question in the room.

Route where you can. Switch where you must. And ask the dumb question.