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

The Prairie Dog Peeks Out

593 Words. Plan about 4 minute(s) to read this.

Just popping my head out of the hole for a minute before heading back down.  Since last Friday, I’ve completed IEWB Vol.2 labs 6, 7, and 8 + IEWB Vol.3 labs 8, 9, and 10 + IE mock lab #5.  I am DREAMING about lab scenarios at this point.  I am taking 15 – 30 minutes breaks here and there to eat and think about things that aren’t lab-related.  At night when I can’t handle any more lab work (I run out of gas around hour 12), I watch a little TV, then go to bed.

The IEWB Vol.2 labs have been good reviews.  Mostly reviews, I should say.  For example, IE seems to go into more detail on multicast than I remember from NMC, and more detail than Narbik Kocharians’ workbooks.  To be fair to NMC, maybe they do get into the same detail, but it just didn’t stick in my brain.  With multicast, I’ve focused on understanding dense mode, sparse mode, sparse-dense mode, static RP, auto-RP, BSR, mapping agents, controlling which RP will deal with which groups, resolving RPF problems, and that’s about it.  If I get something stranger than that on the actual lab, I’ll hit the Doc CD.

The IEWB Vol. 2 6 – 11 labs have been great for reviewing ALL the fundamentals of switching and routing.  Lab 7 was a little scary, as one of my fellow bootcampers warned me, just because it seemed to go on forever.

With all of this work, I am seeing some good habit changes.  My brain seems to automatically tell me to go back and check if a current task broke a previous one.  This is key with redistribution.  If a certain route has to appear in a router in a specific way, you need to be careful that your redistribution doesn’t break that.  You also have to be careful that you don’t “redistribute connected” for routes that aren’t allowed to appear in the routing table.  Also key are access-lists.  Security and filtering tasks tend to come later in the labs.  If an access-list is added to an interface, are you permitting everything that needs to be permitted to allow previous tasks to continue working?  Also key for me – did I add a route-map “permit” catch-all at the bottom if appropriate?

Mostly, I’ve been zoomed in on fundamentals.  I have not been spending excessive time on what I consider to be “the weird stuff”.  Getting my switching and WAN up and working is first on my list.  Then I bring up all the IGPs, verifying that the expected routes appear where expected (helps to catch that I’m advertising all the routes I’m supposed to, easy to forget a network statement).  I verify all neighbor adjacencies (easy to overlook authentication, a network type, or neighbor statement).  I deal with summarization and filtering.  Then redistribution.  Then reachability check.  Then make sure all previous requirements are still met.  Then on to BGP.  I’ve been getting a lot of bestpath-related problems with BGP, and how to resolve those issues is flowing reasonably well.  I forced myself to memorize “N WLLA OMNI” from the Odom book, and can write it down at will now.

Task interpretation is coming faster.  Most of the time, a long paragraph boils down a single, simple task they want you to do.  Reading through the rhetoric to come up with the technical requirement is straightforward 9 times out of 10.  “Oh, they want FRTS and precedence-based random-detection in a map-class.” Or, “Ah-ha.  I just need to apply no ip proxy-arp to the ethernet interface of the router and that’s it.”

On to IEWB Vol.2 lab 9 after some lunch.