From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

Lost Power + No Internet

216 Words. Plan about 1 minute(s) to read this.

A thunderstorm rolled through and took out my Internet connection (where this blog lives).  During the storm, we had a really close lightning strike that blew a GFI outlet in my house, taking out the rest of the outlets downstream from it.  Those outlets included the ones that power my workstation and my wife’s workstation.  Took me a while to figure out that it was a GFI outlet that blew, since it was in the wet bar that we never use.  I assumed a circuit breaker.

The Internet rack is in a different part of the house on a different circuit with a decent-sized UPS, so the mail server, web server, firewall, switch and so on stayed up. Of course, my network staying up means almost nothing if my ISP can’t keep the little IP packets flowing to my house.  Being offline sucks.

The lousy part is that I was just sorting through the Custom Queueing part of NMC scenario 1, which is so arcane of a queueing method that I’m surprised it showed up.  So I was reading on cisco.com/univercd about how to set up custom queueing, and trying write IOS code that complied with the unclear instructions in the scenario.  Then kablooey!  Lightning strike…

Ah, well.  We live to fight another day, right?