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

NMC DOiT Vol.2 Scenario 3 Day 4

572 Words. Plan about 3 minute(s) to read this.

This was not a good day, overall.  I’m feeling a little depressed right now.  The route redistribution part of the scenario was tedious.  I got through it okay, but I handled some of the specific requirements differently than the answer key.  Part of that was due to my ignorance of how to select certain routes for redistribution.  I didn’t know you could flag internal EIGRP and OSPF routes specifically, which would have made my process a whole lot easier.  So I ended up ripping out everything I had done, which was mostly working, and redid everything like the book had it.

I got to tell you, that redistribution was not easy, and was actually kind of intimidating.  I want and need the challenge, but man – will the actual lab have redistribution so complex?  I guess it could.  If you miss one little thing, you could get bogged down for way too long trying to debug the problem.  The whole need for speed thing is daunting.  I am just not even close to being able to finish one of these scenarios in 8 hours.  I guess I want too much, too fast.

Then I worked on the BGP scenario.  That wasn’t too bad.  The core challenge was to make traffic flow through specific routers from one end of the BGP domain to the other.  I did okay with that, too, but I spent a lot of time staring at the BGP tables, trying to make sense of why BGP was making some of the decisions that it was making, with several moments of “Oh yeah! Well, of course that’s why!”

I did a quick little section on IOS HTTP server security that was a no-brainer, but then got mired down in “lock and key” dynamic access lists, which I had never run into before.  Although not suprising, it’s a little depressing to see just how much IOS stuff I haven’t been exposed to yet.  I put a lot of time into prep for the written exam, with the express purpose of grounding myself in what I’d need to know.  I wasn’t anticipating quite as many new things to learn from scratch.  It’s frustrating in the sense of trying to gauge how likely it is I might see this or that strange little feature on the actual lab exam.  I keep telling myself that’s there’s only so many things I could be reasonably asked to do in an 8 hour lab.  And you know what the core tasks are going to be because of the blueprint.  But there’s so many little other things that could get thrown in there and lose valuable points.

I still have IPv6, QoS, Catalyst Specialties, Address Administration and Multicast yet to go on this scenario.  I was really hoping to be done today, but I don’t see that happening.  At the level of knowledge I have at this point in the lab prep roadmap (ergo, not close to enough), there’s roughly 6 more hours of work to do.

As another little side project, I am listening to some of the on-demand class lectures from InternetworkExpert.com.  As I have a chance to listen, I’ll let you know what I think.  I started the lecture on multicast, and liked it so far…but I’m only 20 minutes into it.

Okay, ranting for tonight is over…I’m going to get some dinner, and maybe crash on this some more in a couple of hours.