Ethan Banks Not writing about IT.

Bad Assumptions Make Labs Harder Than They Need To Be

B

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?”

4 comments

  • Again, the detail with which you write is just incredible. Those examples, particularly the first, were great. As a fellow CCIE candidate, I can sympathize. Your preparation level looks great. You’re way ahead of me, but I’m following you!

  • I agree with markman 100%, the way how you described your experience is a great asset for every one working in this painfull process…remember my first try to the lab, fully understanding the basic is a key facto to pass the lab….keep it up with your studies and comments that will help you and others as well….we are right behind you……

  • Thanks for this posting. I can identify with all three of those patterns. It’s sometimes difficult to know how to avoid them, except that I know I have good days and I have bad days.

    My worst “bad assumption” behavior is not to read the global constraints carefully enough. All too often I assume that “ip default-network” is not allowed, when it actually is. That can make me go down long and winding roads needlessly. Maybe I need to cheat a bit : if I am expecting a global constraint and it turns out not to be there, maybe I should ask myself “OK, where could I usefully put an “ip default-network”?”

  • Great point! In addition reading each task a couple times, I found it helpful to read the whole lab through once.

    As I read each task, I made notes on the scratch paper that I was given. I noted my initial thoughts about the task and any caveats that came to mind.

    Later, when I got to that task in the test, I re-read it and compared my second take on it to the notes I had made during the first read through.

    I think this helped me gain a good picture of the lab as a whole and it forced me to carefully read and re-read each question.

By Ethan Banks
Ethan Banks Not writing about IT.

You probably know Ethan Banks because he writes & podcasts about IT. This site is his, but covers other stuff.

Get the details on his about page.