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

Bad Assumptions Make Labs Harder Than They Need To Be

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

Part of the mystique of the CCIE lab is the difficulty people have in passing it. As I understand it, the vast majority of candidates take the lab exam more than once before passing. One statistic indicates an OVERALL (not first time) lab pass rate of only 26%. Certainly then, it IS a difficult exam. But I have discovered in my practice labs, I am making certain tasks harder than they need to be.

I don’t claim to be perfect in all CCIE technical areas, but I don’t think a lack of technical competence is my greatest barrier to passing the lab exam. Rather, this issue of over-engineering solutions is my greatest enemy. I have developed a habit of assuming that a complicated task must have an equally complicated solution.

Here’s some examples from some recent labs I’ve done, mock or otherwise.

  • I was told to address a PPP link without using the “ip address” interface command. Without considering other possibilities, I decided that the task must be referring to some auto-configuration function of PPP, where the backbone router on the other side of the link would serve up an address to my side of the link, if I only used the right commands. I began reflecting back on the good ol’ days of supporting several hundred dial-in PPP users on an AS5301, having to run “debug ppp authentication” and “debug ppp negotiation” regularly for troubleshooting. After the moment of nostalgia passed, I started digging through the PPP dial-in commands on the Doc CD, hoping to find the magic bullet. I was over-thinking the problem. The answer was to create a loopback with the IP I needed and use “ip unnumbered” on the PPP interface. A simple, routine task that I’ve performed dozens of times. Yet in the context of PPP, I was thrown off track.
  • I needed to summarize some addresses. I can do this. I know how to summarize in multiple ways for all the IGPs and BGP. Yet, I somehow managed to screw up both the RIP and EIGRP summarization tasks on a particular lab. Why? Again, over-thinking. On the EIGRP task, I was given a /23 route in the task, and told to make a certain /24 route appear instead like that /23 route in the routing table. I didn’t read the route listed in the task closely enough for the “/23” to register, and started thinking the task must refer to some strange NAT task with which I was not previously acquainted. Once I started going down that road of “it’s a weird task I’ve never done before”, I never came back. Re-reading the task more carefully would have easily resolved this.
  • After configuring layer 2 on a switch for a couple of router interfaces, I was unable to ping between the routers. One of the routers was a backbone router. The other router was pre-addressed via the lab initial config script. I burned at least 10 minutes checking my switchport configs, looking at CDP output to verify connectivity, etc. I was working hard, but not finding any explanation. I remember asking myself, “Have you checked ALL the basics?”, answering “No”, and then finally doing a “show run interf fa0/0” on the pre-addressed router. There it was – wrong subnet mask. Fixed it. Problem solved. 10 minutes was far too long to solve that particular problem. I checked layer 1 and 2 repeatedly before I checked the layer 3. That wasn’t over-engineering as much as it was assuming there was some problem more insidious than there really was because a backbone router was involved.

Going forward, I’m going to practice this thought process when challenged by a lab task. “Did I understand the task? Read the task again (slowly) to be sure. Is the obvious answer allowed by the scenario? If not, what are the other options?”

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks