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

A Fair Shot – Time To Execute

832 Words. Plan about 5 minute(s) to read this.

I’m about done looking at labs, workbooks, the Doc CD, my notes, CLIs, PDFs, blogs, books, and three-ring binders. For now, at least. I need to do a quick look back at Catalyst QoS which I haven’t done much of for a while. That’s plane reading. Other than that, I’m as ready as I’m going to be for my first lab attempt. I have a fair shot at passing.

Mentally, I feel good. I am absolutely convinced that I am capable of passing this exam. If I don’t pass it this time around, I’ll take the lab again – simple as that. I feel confident, but not cocky. I’ll be surprised if I fail due to technical ignorance. If I fail, I suspect that it will be for some combination of the following weaknesses: poor time management; insufficient verification; breaking an earlier task with a later task; and/or leaving out a task requirement.

To address time management, I completed the IEWB Vol.3 workbook series. IEWB Vol.3 is a series of 10 half-labs that connect the core, add IGPs, perform redistribution and reachability checks, and finally BGP. Generally, I was completing those within 3 – 4 hours. 3 hours and change is about right for most of those labs, so I was within IE’s scope. Those labs helped automate some common tasks for me such as setting appropriate OSPF network types, IRB, summarization, IGP authentication, and PPP authentication. I don’t have to look any of that stuff up now. Aside from that, I have to make sure I’m not spending too much time on any one task.

Insufficient verification has bitten me before, where I’ll miss an ACE, forget a catch-all at the bottom of a route-map, transpose a digit, etc. I’ve even been guilty of looking at CLI “show” output, and deciding my solution was probably okay even though the router was telling me otherwise. (Can you believe that?) I’m sweating the details when I verify my solutions now. Doing labs and labs and labs will get you to that point, I guess.

I am developing a sixth sense about when I might have broken an earlier task with a later task. I wish I was better in this area. For anything my internal warning bell doesn’t sound off about, I hope that a careful run-through in the last hour will reveal the problem.

Leaving out task requirements has killed me in mock labs. I have a huge problem with not reading the task entirely, therefore missing requirements. This is not a terribly hard problem for me to deal with – I just have to read more slowly. I read FAST. I motor through sentences and paragraphs. As a kid, I won the local library reading contest one summer by reading and reporting on more books than any of the other kids. The contest wasn’t close. I was probably 7 or 8, and I decimated the competition. Fast-forward almost 30 years, and my habit of fast reading is killing me on CCIE tasks.

I have failed tasks because of things like ignoring “all traffic must be tagged” and therefore leaving off “vlan dot1q tag native” when building a trunk. Stuff like that is an inexcusable throw-away of often easy points.  I am forcing myself to slow down, read the task one word, then one sentence, then one paragraph at a time. Then I re-read it. Then I usually code the task in a text editor. Then I re-read the task a third time, and compare my code with the task requirements. That helps me with this particular problem, although I still could stand to do better. I hope I’m not so amped-up that I miss task requirements just because of anxiety.

Technically, I guess my only “weak” area is multicast, and I only say that because there’s a lot of detail you can get into with multicast that I did not focus on in my studies. There are a LOT of lengthy Doc CD guides about multicast. I understand the mechanics of PIM sparse, sparse-dense and dense mode. I understand IGMP. I can deal with static RP, auto-RP, and BSR. I could cough up an MSDP anycast config if I had to. I can read the mroute table to diagnose RPF issues, and resolve RPF with static mroutes easily enough. I know what PIM nbma mode is for. I think that’s probably enough for the lab. We’ll see.

I guess I said that all that to say that I feel ready for this thing. No promises that I’ll pass on the first go. My mock labs have not been that good, which worry me a bit. The last mock lab I did was especially disappointing, because I gave away so many points due to dumb mistakes. At the same time, that lab was a confidence booster because it showed me that I understand the problems and the proper solutions. I just have to execute properly.

I guess that’s really it, isn’t it? Execution. It’s time to execute.