I was sitting in a livestream today with Chuck, Jeremy, Anthony, and Zach. Chuck said something about getting his CCNP if 1,000 people earned their CCNA. The crowd went nuts. And somewhere in that noise, I made a decision I've been circling for a long time.

I'm going for my CCNP.

Not because my job requires it. It doesn't. Not because 1,000 people hit some milestone—I'm not waiting for that. Because I've had the book. I've watched the videos. I've had the subscriptions. I've done everything around this thing without actually doing the thing.

My wife and daughter are in Korea visiting family right now. I have an abundance of time that deserves better than what I've been giving it.

So here's the public version: I'm buckling down. I don't know exactly when I'll take the exam. I don't know if I'll pass on the first attempt. But I know I'm going to sit the exam, and if the first time doesn't go my way, there'll be a second.

Anthony said doing hard things is worth doing. He's right. Sometimes you just need to stretch. Not later, not when conditions are perfect, but now.

If you're ready, I'm ready. Here we go.

My home network is not a lab. It's the network my wife and daughter use every day, which means the unspoken design constraint is that Netflix must never go down. Korean dramas do not pause themselves, and my wife's tolerance for "I'm just going to reconfigure something real quick" has been calibrated over the years.

But she and my daughter are visiting my in-laws for the summer. Which means the network is mine. Ich habe Sturmfrei!

I'd been wanting to enable OSPF for a while. The topology had the right pieces—a pair of Juniper EX3300s handling Layer 2 switching, a UDM tackling router on a stick and the WAN (replacing a pair of EdgeRouter Xs I had set up as a VRRP group because why wouldn't I?). Only problem… the UDM couldn't actually speak OSPF when I got it. I'd picked it up on Craigslist about a month earlier for $70. A UDM from 2020, purchased in 2026, which is a sentence that probably says a lot about me. It also didn't support OSPF. That made it the third Craigslist find I'd spent money on before realizing it couldn't do the one thing I wanted. The first two were the Junipers.

Then UniFi OS 10.4 dropped, and the UDM finally got OSPF support. Between that and working so closely with the Summer of CCNA—which had me excited about hands-on labs again, real hardware, real cables, real mistakes—the timing was right.

The goal was specific: get OSPF running so routes between the EdgeRouter Xs and the UDM would propagate dynamically. No static routes. And ideally without killing Netflix from seven thousand miles away, though with the house empty the stakes were mostly academic.

Before any of this, though, I had to get into the EdgeRouters.

I'd factory-reset them both—clean slate, no lingering config from before. The problem with a factory-reset EdgeRouter X is that it came back with no IP address. I must have held the reset button too long or something. The web interface was gone. SSH, gone. Both devices powered on and blinking and completely unreachable from my Mac.

The last resort was serial console. I've done it before. I even have a short post and video of how to do that here. Open the case, find the UART pads on the circuit board, connect an FTDI USB-to-serial adapter, and talk to the thing directly. As far as electronics are concerned, it's child's play; in terms of the OSI model, this is less than Layer 1. This is unfurling useless umbrellas under hurricane conditions.

The first EdgeRouter X cooperated. Four male pins already soldered to the pads on the board (I vaguely remember doing that while still in Seoul), female Dupont jumper wires connected straight to the FTDI adapter—TX, RX, GND—and a terminal window open at 115200 baud, because that's what the internet said was correct. What I got was a screen full of gibberish. Fast-scrolling garbage characters that eventually stopped, leaving a cursor blinking on nonsense. It looked like the device was frozen mid-boot, or stuck in a loop, or just dead.

It wasn't. 115200 is the baud rate the kernel uses after it's already booted. During the initial boot sequence, the serial console runs at 57600. So the gibberish was real output at the wrong speed, and the silence was a login prompt I couldn't read. Switching to 57600 gave me clean output, a console prompt, and a way to assign an IP address and get back to the web interface.

The second EdgeRouter X was not as cooperative.

Somebody had already attempted to solder male pin headers onto those UART pads—and bridged the holes. The solder filled the gaps instead of making clean connections, leaving nothing for my jumper wires to attach to. So I got out the soldering iron. Desoldered the bridges, reflowed new headers, in a room whose smell was starting to give me a headache (seriously...proper PPE while soldering. And open a window)—all to assign an IP address to a router sitting three feet from my keyboard.

I went from soldering circuit board pads to running OSPF in a couple of hours, working off and on. The range of a single afternoon on this project. What else was I going to do? I had already spent enough time outside riding up Mt. St. Francis on my bike. A little time away from the sun's anger to battle network gremlins was a welcome change.

Now you might be thinking: isn't that Juniper EX3300 a Layer 3 switch? Capable of OSPF? Why wouldn't you invite it to the party? And the answer is that this particular Juniper was sold to me lacking any configuration whatsoever—including the advanced support license that would unlock what the EX3300 is actually capable of in software. Namely, OSPF. So the Juniper stays at Layer 2. It's a switch. Its job is to provide connectivity between the devices that are running OSPF. The UDM and the EdgeRouter X are the speakers. The Juniper is the room they're speaking in.

Which meant ge-0/0/3 on the Juniper became an access port on a new VLAN. VLAN 85. A dedicated transit VLAN for the OSPF adjacency, because putting routing protocol traffic on the management VLAN felt like the kind of shortcut that works until it doesn't. IYKYK. The trunk on ge-0/0/0 to the UDM got VLAN 85 added to its member list. Two ports, same VLAN, pure L2. The Juniper doesn't care what the routers are doing above Layer 2, and that's exactly the point.

The adjacency didn't come up.

The first EdgeRouter X had OSPF configured—router ID, hello timers, redistribute connected—all set through the web GUI, which is happy to let you configure everything around the protocol. What the GUI doesn't expose is the one thing that actually turns it on: the area 0 network statement. That lives in the CLI. And of course I hadn't set it—I was in the web interface, where as far as I could tell OSPF was fully configured. One line, typed into the command line:

set protocols ospf area 0 network 10.85.0.0/24

The adjacency came up immediately. Full state. The UDM and the first EdgeRouter X could see each other, exchange routes, the whole deal. But my Mac still couldn't reach the second EdgeRouter X at 10.85.1.1.

Troubleshooting this part was methodical in the way that networking forces you to be. My Mac could ping 10.85.0.1—the first EdgeRouter X on the transit link. So the forward path from my Mac through the UDM to the first EdgeRouter X was fine. The first EdgeRouter X could ping 10.85.1.1 from its switch0 interface at 10.85.1.2. So the link between the two EdgeRouters was fine. But when I sourced the ping from 10.85.0.1—the eth0 address on the transit side—10.85.1.1 went silent.

That narrowed it down. The second EdgeRouter X had no route back to my Mac's subnet. It only knew about its directly connected networks—traffic could arrive, but the replies had nowhere to go.

The clean fix: run OSPF between the two EdgeRouters so the second one would learn routes dynamically. I configured OSPF on the second EdgeRouter X, added the 10.85.1.0/24 network to area 0, set up the adjacency on the link between them. The adjacency came up Full. The LSDB was fully populated—I could see every LSA from every router in the topology.

And still no routes.

The second EdgeRouter X had a Full OSPF adjacency, a complete link-state database, and was installing zero learned routes. Just its own connected networks, sitting there like nothing had happened. The adjacency was a formality—handshake completed, information exchanged, and then apparently filed away and ignored.

This is the part where I stared at the screen for a while.

The second EdgeRouter X had a switch0 interface configured at 10.85.0.2/24. That address—I'd set it myself, over the serial console I'd spent an afternoon soldering my way into. I was so relieved to finally have access that I punched in an IP and moved on without checking what else on the network already owned it. The UDM owned it. On the OSPF transit VLAN, on a completely different physical segment—also 10.85.0.2. Same IP. Different networks. Both advertising themselves to OSPF.

This is what happens when you configure a network by the seat of your pants. A diagram—an actual diagram, with addresses written down—would have caught this before I ever typed the command. But I was working from memory and momentum, and momentum doesn't check for duplicates.

When OSPF ran Dijkstra's algorithm on the second EdgeRouter X, it saw a network LSA for 10.85.0.2—the UDM's designated router address on the transit link. But the second EdgeRouter X also had 10.85.0.2 on its own switch0. So the algorithm looked at that network, looked at its own interface, and concluded it could reach the transit network directly through switch0. Which it couldn't, because switch0 was on an entirely different Layer 2 segment. The path computation was poisoned. Every route that depended on traversing the transit network—which was all of them—computed to an invalid next hop and got discarded.

The fix was removing the 10.85.0.2 address from the second EdgeRouter X's switch0. The moment it was gone, the SPF calculation found valid paths, and every route flooded in at once. Default route from the UDM. All the VLAN subnets. The transit link. Everything. One IP conflict, hiding in plain sight, breaking the entire routing table without generating a single error message.

I keep coming back to how quiet this failure was. The adjacency was Full. The LSDB was complete. Every piece of OSPF was doing its job correctly—exchanging LSAs, maintaining neighbor state, running the SPF algorithm on schedule. And the SPF algorithm was running correctly, given the information it had. It computed the shortest paths using its link-state database and its local interfaces, and it arrived at a perfectly logical conclusion that happened to be wrong because the local interface was lying about what it could reach.

There was no error. No warning. No "hey, you've got two devices claiming the same IP on different segments." OSPF doesn't know about Layer 2 topology. It trusts that if you have an interface on a subnet, you can reach other devices on that subnet. And normally that's a safe assumption. Until it isn't.

It's the same lesson as the overlapping subnets problem I helped Michael with a while back, just wearing different clothes. Two things with the same address, both technically correct in isolation, both completely broken in combination. The symptom presents as nothing works and the cause hides behind the fact that everything looks configured. You don't find it by checking if things are up. You find it by asking which 10.85.0.2 are we talking about.

The topology works now. Three OSPF speakers—UDM, first EdgeRouter X, second EdgeRouter X—all in area 0, all exchanging routes dynamically through a Juniper switch that has no idea OSPF exists. The Juniper provides the room. The routers have the conversation. And somewhere in the middle of all of it, I learned that the hardest bugs aren't the ones where something is broken. They're the ones where everything is working exactly as designed, and the design has a contradiction you haven't noticed yet.

I should have been annoyed. But I wasn't.

It was one of those days where the work just flows. Small projects stacking up and getting knocked down one at a time, the kind of momentum you don't want to interrupt because once it's gone you spend the rest of the afternoon trying to remember what you were doing. I was starving like a hostage and seriously considering whether the tortilla chips in the back of the pantry still counted as food or if they had crossed over into the realm of building material. The phone rang, snapping me in an instant out of the I wonder if shoe leather actually has nutritional value discussion that was percolating through my brain. The smart move would have been to let it go to voicemail.

It was Michael. I picked up.

Michael is a retired teacher—a former colleague from a different life—who now lives in an RV and tours the country picking up odd jobs because he retired too young to sit still. He's had a GL.iNet travel router in his rig for years now, running on its factory defaults: SIM card for cellular, Wi-Fi repeater for campground networks. The only thing I ever touched on that box was configuring his Starlink dish as a policy route for when he's off-grid. The rest of it, the LAN settings, the DHCP range, the default gateway, was whatever the router shipped with out of the box. Nine years on the road and it never mattered.

"I'm not sure what witchcraft is going on," he said, "but I can't get on the campground Wi-Fi. All I've got is cell." But from the speedtest we ran, the signal was weak enough that you might consider it barely usable.

I had him share his screen. macOS has a screen sharing app baked right in, and once I could see the GL.iNet admin panel we were looking at the same picture. Internet sources on the left, router in the middle, LAN to the right. Everything looked connected. The Wi-Fi repeater showed a link to the campground's network. But traffic wasn't moving.

The first clue was the DNS.

The resolver address coming back was... wrong. Not wrong in a this is broken way. Wrong in a this doesn't belong to us way. A quick WHOIS lookup confirmed it: the DNS was resolving to a local ISP in Michigan. Which is exactly where Michael happened to be parked. That DNS had no business showing up on his LAN unless something upstream was leaking into his network in a way it shouldn't be.

A few more things that didn't add up. And then it clicked.

The GL.iNet router ships with a default LAN of 192.168.8.0/24. That's fine. Millions of these things run on that address space without issue. Until you connect one to an upstream network that's also using 192.168.8.0/24. Which is apparently what the campground's ISP had configured on their equipment.

Two networks. Same address space. One router with an arm in each, unable to tell them apart.

This is where it got interesting, not for me, but for Michael. Because once I could see the problem, I had to explain the problem. And that's the true test of your knowledge on a subject. "If you can't explain it simply, you don't understand it well enough." Michael was just about to have that aha moment, and I was going to be there for it. Well worth the price of admission, even if it meant my stomach was attempting to join the conversation with all the noise it was making.

"Look at the diagram," I said. "Your router has one interface facing the campground and one interface facing your LAN. Both networks are 192.168.8.0/24. Both have a gateway at 192.168.8.1. So when a device on your network says I need to reach the internet, where's the exit?—it gets two answers. Your GL.iNet says I'm the gateway, send it to me. And the campground's router says No, I'm the gateway, send it here. Same address. Both claiming to be the door."

You could hear it on his voice over the screen share as it landed. That moment where the abstract becomes concrete.

"So it's not that the connection is broken," he said. "It's that nothing knows where to go."

Exactly. And it gets worse. It's not just the gateways competing, it's the DHCP servers too. Both networks are advertising the same address range to any device that asks for one. A device connecting to Michael's LAN could receive its IP assignment from the campground's DHCP server instead of his router's, or vice versa. At that point you've got devices with addresses that technically belong to both networks, default routes pointing at ambiguous gateways, and ARP tables full of conflicting entries because multiple devices across both networks may share the same IP. Nothing is broken in the sense that an interface is down or a cable is unplugged. Everything is configured. Everything is live. And nothing works, because the addressing that's supposed to tell traffic where to go is pointing in two directions at once. It's actually kinda surprising Michael's router wasn't causing conflicts for neighboring RVers.

The only reason Michael still had any internet was the SIM card. That connection routes through the cell tower on a completely separate interface. It never touches the campground network, so it never encounters the overlap.

The fix was almost comically simple.

We changed the LAN subnet from 192.168.8.0/24 to 192.168.9.0/24. One digit. The moment we applied it, traffic started flowing through the campground Wi-Fi like nothing had ever been wrong.

There was a brief moment of panic when the admin page disappeared—because of course it did, the router's address had just changed from 192.168.8.1 to 192.168.9.1—and Michael had to dig out his little notebook of passwords of important things and reassociate with the Wi-Fi at the new gateway. But once he was back in, everything worked. Load balancing, policy routing, all of it. One digit was the difference between a functioning multi-WAN setup and a router arguing with a campground over who gets to be the exit.

Nine years. Michael has been on the road for nine years. Not the entire time with that router mind you... but the router has been on its factory defaults the entire time he's had it, connecting to campground Wi-Fi in every state, and this was the first time he ever hit an overlap. That's how rare it is. But rare doesn't mean impossible, and the fact that it took nine years to surface is exactly what makes default configurations dangerous. You start to trust them because they've always worked, and then one afternoon in Michigan they don't, and you're on the phone with a guy who skipped lunch trying to explain why two networks can't both be 192.168.8.0/24.

I have a hunch about what happened on the campground's end. The GL.iNet's default subnet is 192.168.8.0/24, and that's not a common range for consumer ISP equipment. Most home routers ship with 192.168.0.1 or 192.168.1.1. The fact that the campground's network was using the exact same /24 makes me wonder if their ISP, or whoever manages the park's network, is running GL.iNet hardware too. I can't confirm it. I'll never know what's sitting in that campground office. But the overlap is suspicious enough that I'd put money on it being the same brand, same factory defaults, same it works, so why change it reasoning on both ends.

Which brings me to the only real takeaway here: change your defaults! It takes thirty seconds. Pick a subnet that isn't whatever the manufacturer chose for you. 192.168.47.0/24. 10.0.99.0/24. Anything. Because the default exists for the convenience of the factory, not for the uniqueness of your network, and the one time in nine years that it matters, it really matters.

I hung up and realized I'd completely forgotten I was hungry.

That was supposed to be a lunch break. It was the highlight of my day.

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.

There's this thing people say now: that the tools are changing us. That we're losing something. That the person who used to sit down and think through a problem is being slowly replaced by the person who asks a machine to think for them, and honestly, I get why that lands. It's not an unreasonable fear.

But I want to push back on it for a second. Not because I think it's entirely wrong, but because I think the framing is off.

When you pick up a new skill—really pick it up, not just skim a tutorial—the person you were before that skill starts to fade. That's not loss. That's refinement. The old version of you doesn't get destroyed so much as it gets polished down into something that can do more, see more, hold more weight without cracking.

I think about carpentry sometimes. Not because I'm any good at it [No, dear, I cannot make that mid-century Asian-inspired credenza you've been eyeballing and not-so-subtly hintdropping about.], but because the metaphor holds up. There's a guy who's never touched a jointer plane, never attempted a dovetail joint, never really understood why wood moves the way it does. And then one day he learns. He picks up the plane, figures out the angle, starts producing joints that actually fit. The old version of him—the one who would've just grabbed a nail gun and called it done, that guy is gone. And nobody mourns him, because the new version is better. Not better in some abstract motivational-poster way, but functionally, practically, observably more capable.

That's what tools do when they work right. They don't replace you. They refine you.

There's a line I keep coming back to—and I'm not going to dress it up with attribution because either it lands for you or it doesn't—about putting away childish things. When I was a child, I spoke as a child, I reasoned as a child. But at some point you set those things down. Not because they were bad, but because you outgrew them. You don't want milk anymore; you want a steak.

And I think that's closer to what's actually happening with AI tools than the narrative we keep hearing. The narrative says erosion—as though something is being worn away against our will, ground down by a force we didn't invite. But what if it's formation? What if the discomfort people feel isn't loss at all but the growing pains of becoming someone who can operate at a higher level—someone who's been shaped by the tools they chose to pick up?

That reframing matters to me. Because erosion is passive. It happens to you. Formation is something you participate in. You show up. You do the work. You let the process change you because you trust that the person on the other side of it will be more than the person who went in.

I'm not naïve about the counterpoint. And the counterpoint is real.

When you stop doing the thinking yourself, when you just accept the output and move on, no critical evaluation, no "wait, is this actually right," you're not being sharpened. You're going dull. The edge that made you useful, the part of you that could sit with a hard problem and reason through it, that atrophies if you never use it. And the thing about atrophy is that it's quiet. You don't notice it happening until one day you reach for a capacity that used to be there and it's just...not.

The light slowly goes out.

So the question isn't whether to use the tools. That cheese has long since been eaten, and I'm on it—I'm literally using an AI tool to help me write this, which is either ironic or perfectly appropriate depending on how generous you're feeling. The question is whether the tools are shaping you or just doing things for you. Because those are not the same thing. [And no, using AI to proofread is not the only thing I've done for this piece...it was getting a bit rambly, so I used it to trim things while retaining my voice. It was...helpful.]

A tool that shapes you leaves you sharper than it found you. A tool you lean on so hard that you forget how to stand isn't a tool anymore. That's called a crutch. And crutches are fine when you're healing, but nobody wants to use one forever.

I don't have a clean answer here. I don't think there is one. But my instinct—and it's just that, an instinct—is that the safeguard isn't in the tool itself. It's in the question you ask after the tool gives you its answer:

Is this reasonable?

Three words. That's it. If you can still ask that question and mean it, if you can look at what the machine produced and bring your own judgment to bear on whether it's actually good, then you're still in the game. You're still being formed. The tool is doing what tools are supposed to do.

But the moment you stop asking, the moment the output just flows through you, frictionless, that's when the old fear earns its keep.

I'd rather be refined than eroded. I think most people would. The difference is just whether you're paying attention.

I am, by every measurable standard, more capable than I was a year ago. That's not nothing. The AI tools I've folded into my workflow, largely Claude Code and OpenAI, have genuinely expanded what I can accomplish — whole categories of work that I could not have dreamed of asking the first questions of research about, let alone executing, now get done. I find it useful not to inflate this: it's not really me doing the work. It's me prompting something that does the work. But the output lands in my name, on my desk, and I've learned to navigate that distinction without too much philosophical hand-wringing about it. After all, I mean I am the one formulating the informed-enough questions to get the ball rolling; the project wouldn't progress without me.

What I Did Not Anticipate Was the Accounting.

The thing about becoming more capable is that people notice. And when people do notice, they load you up accordingly. I may be five times more productive than I was twelve months ago — and I am, without question, five times busier. That's the kind of math that does not sum to any total in your favor. Somewhere between the tool and the output and the organizing of the input and output files I'm generating, the day disappears. Keeping track of what the AI has helped me produce is, on some days, a full enough job by itself, leaving little time to muse or ideate. It can be an endless loop of iteration, making the next newer version of a thing that wasn't needed until someone had the capability to do it. kinda a Jurassic Park thing — so consumed with whether we could do whatever, we never stopped to consider if we should [ or however the quote is supposed to go...positive Kevin will correct it ;) ]

So Stay Put the Boulders

It's easier to move pebbles. Low-hanging fruit, quick wins, the small tasks that give you the brief satisfaction of checking something off — yes, each one inches you a step closer to a goal. But I've lost sight of the goal because I'm head-down in the pebbles. The bigger items, the ones that require sitting with a question long enough for something useful to happen, get deferred to some later time when things quiet down. Things don't quiet down.

I used to be able to sit in a restaurant or a café — the steam off a coffee cup, the smell of roasting garlic, the sound of passing cars blurring into white noise — and find my way into something like a flow state. Reflective. A little slow. The kind of thinking where the bigger picture starts to arrange itself. I wrote during that time, and the writing helped. It has always helped me find clarity on the things I actually care about moving.

I Haven't Written Anything Outside of Work in Over a Year.

There's something worth naming in that irony. The tools that were supposed to free me up to have more time to cogitate and muse have kept me busier with smaller things. Whether that's a feature of the tools or a bug of how I've let myself use them — I genuinely don't know. I haven't had time to figure it out.

I have pressing deadlines today, as it happens. This thought will have to wait.

Which is, I realize, exactly the problem.

Ready to elevate your coffee game? While the "best" cup of coffee is a matter of personal taste, there are a few brewing methods that consistently stand out for their ability to produce a delicious and satisfying cup. Let's count down to the best as we explore the top three brewing methods that every coffee lover should know.

3. The AeroPress: For a Quick and Versatile Cup

The AeroPress is the new kid on the block, but it has quickly become a favorite among coffee lovers for its speed, portability, and versatility. This unique brewer uses a combination of immersion and pressure to create a smooth, rich, and low-acidity cup of coffee in about a minute.

What You'll Need:

• AeroPress
• AeroPress filters
• Finely ground coffee
• Hot water (185°F/85°C)
• Digital scale
• Timer
• Mug

How to Brew:

1. Prepare Your AeroPress: Place a filter in the filter cap and twist it onto the AeroPress chamber. Place the chamber on top of your mug.
2. Add Coffee and Water: Add 17 grams of finely ground coffee to the chamber, then add 220 grams of hot water.
3. Stir and Plunge: Stir the coffee and water for 10 seconds, then insert the plunger and press down gently for about 30 seconds.
4. Enjoy: You'll have a concentrated shot of coffee that you can drink as is or add hot water to for an Americano-style drink.

Whether you prefer the control of the pour-over, the richness of the French press, or the speed of the AeroPress, there's a brewing method out there for you. So go ahead, experiment, and find your perfect cup.

2. The French Press: For a Rich and Full-Bodied Brew

The French press is a classic for a reason. This immersion-style brewer steeps the coffee grounds directly in water, resulting in a rich, full-bodied, and robust cup of coffee. It's a simple and forgiving method that's perfect for those who enjoy a bold and flavorful brew.

What You'll Need:

• French press
• Coarsely ground coffee
• Hot water (200°F/93°C)
• Digital scale
• Timer

How to Brew:

1. Preheat Your Press: Fill your French press with hot water to preheat it, then discard the water.
2. Add Coffee and Water: Add 56 grams of coarsely ground coffee to the press, then add 900 grams of hot water.
3. Steep: Let the coffee steep for 4 minutes.
4. Plunge: Slowly and evenly press the plunger all the way down.
5. Serve: Serve the coffee immediately to prevent it from becoming bitter.

1. The Pour-Over: For the Coffee Connoisseur

The pour-over method is the go-to for coffee aficionados who want complete control over their brew. By manually pouring water over the coffee grounds, you can control the water temperature, flow rate, and extraction time, resulting in a clean, nuanced, and flavorful cup that highlights the unique characteristics of your beans.

What You'll Need:

• Pour-over brewer (like a Hario V60 or Kalita Wave)
• Paper filter
• Gooseneck kettle
• Digital scale
• Burr grinder
• Your favorite whole bean coffee
• Mug or carafe

How to Brew:

1. Heat Your Water: Heat your filtered water to 200°F (93°C).
2. Rinse the Filter: Place the filter in your pour-over brewer and rinse it with hot water to remove any paper taste and preheat the brewer. Discard the rinse water.
3. Measure and Grind: Measure out 20 grams of coffee and grind it to a medium-fine consistency.
4. The Bloom: Add the coffee to the filter, place it on your mug and scale, and pour 60 grams of water over the grounds. Let it "bloom" for 45 seconds to release CO2.
5. The Pour: Continue pouring the water in a slow, circular motion until you reach a total of 340 grams of water. The entire process should take about 3 minutes.
6. Enjoy: Let the coffee drain, and then enjoy your perfectly crafted cup.

Now for a Little Explainer

From this point forward, 'tis I who write (/ dictate) and not some crummy Ai.

Why did I do it? you may never fully know. Just kidding. It is a proof of concept. I wanted to to see if i could get Ai running in the terminal and able to access the file structure of my computer to do its work.

The cool part is that it works (as you plainly see witthhe post above).

The not-so-cool part is that Ai robs us of the opportunity to create. Because this blog post was nothing more than just a proof of concept I didn't really care necessarily that it should have anything of personality baked into the methods presented.

I can understand the allure of something seen as a time saver but at the end of the day just like there is absolutely no life present in the blog post above. I can't get behind anybody using AI to completely take control of the writing process.

That said, I don't think the output was terrible, but there's just really no humanity in it whatsoever. Tell me if you think otherwise.

It may sound a bit meta at this point of development in regard to this website (after all, it started as a way to share my current learning in the tech field), but I think this is a useful stratagem in enabling others to do the same. My aim is to pull back the curtain and show how the sausage is made, so to say. We will focus on the method and format I try to use when writing here such that you may be able to do the same.

What are we doing?

In theory, in taking pen to paper, or in this case, keyboard to screen, we are passing a torch, conveying a skill gained to a learner come behind us. Keeping in mind that acquiring a singular skill (learning) plays part of a grander mosaic called mastery, we the teachers all too often overdo it when imparting what should be a nugget-sized soundbite. We (myself very much so included) forget that education is i+1, not plus everything-all-at-once.

The curse of knowledge erases our collective memories of the burden learning places on students. We bite off too much for them to chew, swallow, and digest.

What should we be doing?

Well, if you have known me for any time at all, you know that I have a propensity to be a touch (possibly understated for effect) verbose in my output. We need to keep it concise.

Concise does not mean shallow. It means cutting the fluff, giving one idea room to breathe before introducing the next. Think of it like serving a tasting menu instead of dumping the entire pantry on the table. Each dish has a purpose, a sequence, and a chance to be appreciated before the next one arrives.

That’s where writing to teach shines. When we write with the learner in mind, we are forced to distill, to prioritize, to make trade-offs. It is an act of empathy as much as it is an act of explanation. And the funny thing? You end up learning more yourself. The act of teaching locks in the lesson for the teacher better than almost anything else.

So, what do we do with this?

We write like someone will actually try to follow our steps (because they might).
We trim the fat, we break things down, and we accept that we will never say everything there is to say in a single post—nor should we.

Writing to teach is not just about sharing what we know. It’s about making the path a little clearer for whoever comes next. And if we do it right, we leave them just enough light to take one more step. No more, no less.

If you’ve learned something recently, try writing it down—not for yourself, but for the version of you who didn’t know it yet. Then hit publish. Someone out there is just one well-written paragraph away from their own aha moment. Who knows, you might be the one holding the torch.

I'm one of the lucky ones. This may not come as a surprise to you, but in the face of the statistics pointing to an ever-decreasing demand to attend and complete a bachelor's course, somehow I managed to pass that milestone, land a job in my incredibly niche chosen field (teaching German), and still somehow move on.

A quick search shows the following statistics:

• Only 46% of college graduates work in jobs related to their field of study.
• 52% of college graduates are underemployed, meaning they work in jobs that typically do not require a bachelor's degree.

Crazy to think that I could be the lead administrator for any online technology education platform, let alone the NetworkChuck Academy. Let me unpack that for just second. The skills I cultivated while building this very website enabled me to meet the meet the challenges (I'll save you the details) of my current position head on. I work for and alongside the guy whose YouTube videos got me interested in technology in the first place. None of the training / learning path went to waste; my tool pouch is full, and I use every one of my tools to accomplish my day's work.

While puttering with my fledgling website back in (maybe early) 2020 while working for DYB in Seoul, I would never have dreamed that I would someday be in the position I currently occupy. It's not without difficulty that I trace back the steps that lead to this moment. I can't help but remember back to the nostalgic refrains echoed by my old boss / supervisor, Michael Meyers (no, not that one—the other one you didn't know from the movies), quoting the opening lines from that old Talking Heads song.

I ask myself, "How did I get so lucky?" I may not be teaching German any more, but once the shine wore off that apple I found something else that tickled and got trained up in it. Somehow, despite the odds, that second education also ended up being put to use.

Keep us brewing!

Nothing good in IT ever happened without coffee.Thanks for your support!

Buy us a coffee

If there is one takeaway for me, it's to never stop learning—it won't be in vain (edited; credit goes to Kevin Kim for catching my sloppiness). You may not land where you had envisioned your future self to be 10 years from now, but in pursuing what you love, you'll be in the right ballpark. Maybe it sounds a bit hedonistic, but if learning something pleases you to, you should probably do it. You never know where it might take you or when you will look back wondering how you got where you are.

There's been so much to occupy my time and thoughts since arriving in Colorado, but occasionally I have a moment to look back at photos of daily life in Seoul. This is the view from across the Han at night. I may have shot many dozens of similar photos but they never came out as good as this--likely owing to sweat smudges smeared across an iPhone lens as I huffed homeward.

I can't help missing it although it seems like a lifetime has passed. They say the passage of time heals, but my heart hungers for the frenetic pace and bustling traditional market where we used to get 떡볶이 and 순대 간. Life is good here--good but very, very different.

It came as a shock having landed how easily overheard and understood chatter of passersby floated into the background consciousness; the strain to grasp at a potential third of Korean speech directed at me just hours before still stands in stark contrast.

Seoul never really belonged to me nor I to Seoul, but it was home. On rare rainy days such as this, I remember.

Well, if you’ve been wondering where I’ve gone or why I haven’t been updating the site since back in August, this post is for you.

It‘s no secret that I usually have a lot to say, and maybe because of that, I have found it much easier to say nothing than to stay tight-lipped and risk accidentally alluding to something that may as well be the same as spilling the beans.

Here is The Update…

I have been working with a company called The Network Chuck Academy .

For anyone out there unfamiliar with that particular website I linked above, that’s ok. This is an up-and-coming online training platform focused on just about anything tech related. I have been assigned the CCNA portion and have been having a blast making study materials for the course. I never would have thought that my training as a curriculum writer in Korea would have such direct intersection with anything remotely related to network engineering, but here we are.

There isn‘t much more that I can really say at this point, but I really wanted to break the silence.

I plan to be coming back here with more updates and material in the coming months, now that I know I am not stepping on any toes by keeping this website while also working for a company that could otherwise take the work I do here as direct competition or undermining of their mission.

Last Thoughts

I wish only that I had had while in Korea exposure to the writing and versioning tools I am using now at NCA. If you’re curious, go check out Notion and Clickup. I don’t love Clickup, but it is super helpful in tracking the progress of jobs; Notion is awesome for anyone who uses markdown. And if you don‘t yet, what are you waiting for? It’s far easier than clicking through a billion dropdowns in Microsoft Word with the added bonus of being essentially plain text that your designer will love you for using.

If you are anything at all like me, and I bet you are, because it's kinda human to be as lazy as possible conserve energy for more cognitively demanding tasks, you likely will benefit from removing any friction that slows you down from starting anything involving lab work on your server. Don't feel bad, the smartest people I know sometimes have the hardest time getting started. But once you get moving, you start to fly.

Today, I will show you how I automate the startup process of my EVE-NG server.

First, a little as to why I bothered to set this up. I recently migrated my EVE-NG server out of Google's Cloud in favor of an on-prem server. I managed to pick up a retired Dell R720 for a reasonable price. But whatever it saved me in upfront costs would be eclipsed by the electric bill soon enough if I just let it run around the clock. Therefore, I find it much more practical to start up the lab and load startup configurations before doing my lab work.

So, What's the Problem?

Server-grade hardware goes through way more system checks before loading the operating system. The short version is that it takes anywhere between ten and twenty minutes conservatively before I can even begin my studies. Those 20 minutes are not completely unattended, thus I kinda have to babysit the server and make sure everything loads and we are ready to rock.

Wouldn't it be great is there were a way to set a schedule such that the server basically had its own alarm clock? I could wake up and brew my favorite coffee, and by the time I was half-way through the first cup, EVE-NG would be ready and waiting for me. Speaking of...

Keep us brewing!

Nothing good in IT ever happened without coffee.Thanks for your support!

Buy us a coffee

Now with that out of the way...

There is a short list of things that we will need to accomplish. Before getting started, this video assumes you have a server that runs 24/7 to function as the "alarm clock" for your (much-more-expensive-to-operate) EVE-NG server. You could use a Raspberry Pi, but I will use my Proxmox server.

The 4-Part Secret Sauce

• SSH keys — for password-less authentication
• An alias 
• A Powerup script
• A cronjob

If that doesn't make sense, watch this walkthrough. I also have my scripts available on my GitHub. Feel free to modify them as you see fit, and let me know how you get on with it.

Cheers!

#automateallthethings

Hi. Today I was running some Ethernet cable when it dawned on me that there may be someone out there who finds use in a brief tutorial on this mundane task. I'm going to show you how to terminate RJ45 connectors.

Unfortunately, I didn't have a decent tripod to hand, so please excuse the awkward angle. Also, I left out the dragging of the cable through the crawlspace, as there really isn't enough light down there to make decent content; you will just have to use your imagination, I guess.

Why Cat6a?

On the end of the cable that I demonstrate, you will see a passthrough style RJ45 connector crimped to a Cat6a cable. A million, million years ago when I did my first-ever Ethernet cable run (I believe I was in 6th grade and fastEthernet at 100mpbs wasn't even a thing yet). That was Cat5e and is surprisingly still very capable for short runs. But as with all things tech, eventually every specification meets its end. If this house had had existing Cat5e, there may have been a bit more to deliberate, however, as there was no wired infrastructure when I moved in here, the choice to use Cat6a was a no-brainer.

Not only does Cat6a support higher bandwidth (10Gbps up to 100 m), it also allows for higher voltages for power over Ethernet (PoE) devices, such as CCTV cameras and even monitors—there is even a way to use the Ethernet cabling to provide power to a laptop or PC.

In a word, deploying Cat6a future-proofs my home network for whatever comes down the line. I can rest well, knowing that this will likely be the last set of Ethernet cables this house will need in my lifetime. Whether or not I ever take full advantage will tell in time. But you may not have access to the same quality of cable at the low price I found it. Really when it came to cable selection, the extra $6 was worth the cost for me.

The Demo

That said, here is a video of the crimping process. It's pretty straightforward. But keep in mind there are two different wiring standards. I use T568B. You can use whatever you like, but the standard must match on both ends of the cable.

If you made it this far and like what you see

• please consider supporting us
• share this content wherever appropriate and applicable
• jump in the comments and give us a shout out
• and subscribe for more

Keep us brewing!

Nothing good in IT ever happened without coffee.Thanks for your support!

Buy us a coffee

The Tools

The Other Side

I apologize for the lack of video for this one, but the background noise was pretty bad. Perhaps, if there is enough interest in the future, I will make a quick tutorial on crimping keystone jacks—although that's pretty straightforward.

The Final

Here's how it looks, now that it's all finished up.

And now that everything is done, and the pain has been touched up, I hope you have a better idea of how to terminate Ethernet cabling in your own home.

I've been holding off on this post for a while. Mostly I needed get my house in order. There has been a lot of change in the past week or so and yet a lot has stayed the same; I'm still learning and growing in my pursuit of network engineering; I'm still looking forward to making my my mark on the world of networking; I'm still waiting on the TS clearance before starting my new position.

Everything has happened at the exact time it was meant to

This journey has been one of setting one foot down before knowing where it was going to land and praying there would be solid foundation to plant myself on before pushing off onto the next footfall. If it feels as though I am being vague, I am merely sparing you the details. I know that things are working out--even if it is slower than the timeframe I have been hoping for.

In the meantime, I am just glad to be surrounded with the beauty of nature and the closeness of friends. I leave you with a mild photo-dump. I will omit thechallanges and include just the good bits:

I may be a place I’m not necessarily supposed to be. More to follow; stay tuned…

Here's the Rest...so...EDITED

If you've ever looked up to the skyline here in Seoul, you've no doubt seen loads of items similar to the one pictured in my rooftop photoshop as the image for this post. Maybe you've seen them and not thought much about them, or perhaps you have seen them and not really noticed them.

It's also possible you notice them no matter how poorly disguised as pine trees they tend to be. Whatever the camouflage used to blend these objects into their surroundings, my eyes cannot help giving them extra attention.

So, what are they?

What you are looking at there is a classic example of cellular antennas. The technology behind them is not terribly dissimilar from your WiFi at home or in the café you are sitting in sipping your cup of Joe right now. The main difference is that these big boys tend to use a different means of transmission.

Microwaves...not just for Hot Pockets

It is helpful to think of the energy emitted from and received by (not just) these cellular antennas as part of the electromagnetic spectrum—because that's what it is. I've heard it explained as infra-infrared light. But where I am not a physicist, nor will I attempt to explain it that way, I will say that framing in radio waves with comparison to the energy of light is somewhat helpful for me.

As you can see, microwaves are just below the infrared portion of the spectrum, followed by radio waves with slightly less energy. That means the cellular data is beamed from one tower to the next with waves at only a slightly higher frequency than those used to send music to your FM receiver—it's high-power radio!

Fear Not

If you are worried about the emissions from these antennas, let me put your mind at ease. There isn't enough wattage available to the antennas to do much damage to your leftovers. There are differences from country to country and carrier to carrier, but these are some of the estimates I've come across:

20 Watt for GSM 900 and LTE 800
10 Watt for GSM 1800 & UMTS
6 Watt for WLAN & LTE

Compare that with the common household popcorn burner at 1200w, and you will see why I am not really concerned to get so close for the photo opp. Furthermore, cellular data is not broadcast transmission and, as a result, ramps up and down its wattage requirement based on load.

So why am I telling you all this?

I'll tell you after this coffee break...

Keep us brewing!

Nothing good in IT ever happened without coffee.Thanks for your support!

Buy us a coffee

Glad you're back. I hope your brew was fulfilling. Mine was a locally roasted Kenyan blend from a roastery by the name of Sanchez. I'll see if I can get a photo of the shop the next time I pass by on my bike. Now back to the story.

There is just something to be said about the appreciation of the hard work that has been done in connecting us all. Something of a sense of pride as a network engineer wells up within me when I see the hardware that represents the planning and deployment that makes our modern mobile connections possible.

It blows my mind to know how rigorous the certification for CCNA is (after having passed it over a year ago), and yet how little the certification concerns itself with wireless technologies. As a matter of fact, there is a whole CCNP (Cisco Certified Network Professional) specialization that scratches the surface—Designing Cisco Enterprise Wireless Networks (300-425 ENWLSD)—if you are interested.

There is still a lot about wireless technology out there for me to learn, but the more and more I dive down this rabbit hole, the more and more intriguing I find it. I am not pledging to certify in wireless design, but this post is mostly my way of announcing that I am focusing on wireless design for the foreseeable future.

If you see someone on a rooftop taking pictures of wireless equipment installed by your local ISP, don't be shocked to find me behind the camera. And keep your eyes open for more of these towers of connection; once you start to recognize cellular radios and antennas, you start noticing them everywhere.