Bad Assumptions Make Labs Harder Than They Need To Be


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

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.


  • 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.


Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.