CCIE Pursuit Blog

December 7, 2007

Initial Faults – When And How To Find Them

Here’s a thread on GroupStudy concerning intial faults in the CCIE Lab (errors that are placed in the pre-loaded configurations) and methods used to discover them.  The Internetwork Expert labs (Volume II and III) have these types of errors in their initial configurations.  I have struggled with how long I should be spending hunting them down and whether I should sniff them out before I start the lab or just correct them as I discover them in the lab.  This post has some good strategies concerning this.

Implicit in this discussion and the fact that IE includes these faults in their labs (I can’t speak for the other vendors, but due to Scott Morris’ responses I would assume that IPexpert does as well) is that there is a very good chance that the actual lab contains these types of errors.  I think that coming out and verifying this would break the NDA, but I would fully expect to see some errors in the initial configurations.

I have posted the original question along with some interesting responces:

Hi All,
From what I have heard aboutt the lab, there are a few initial mistakes that you have to correct to get a couple of marks (IP Addresses, Mask etc). Tried to see if there is a pattern or flow that I could induct in my lab practise to find these, but no avail. Just a beginner in the CCIE World so don’t have much idea abt lab strategy right now.

Please suggest if there are any Tips or Tricks that i can use to find these initial glitches. And most importantly when should I start looking for them..

Thanks in advance.

With Regards,
Rakesh Menon


When I practice with the IE labs and I usually find the mistakes while doing the actual lab. And I generally figure the problems when I am working through the switching tasks.

You could have a quick look through the initial configs and match them with the diagram. Try working through the switching section and see if you can see where the mistakes are.


That always depends on the evils of the lab…  🙂

“sh ip int br | exc una” is a good place to get your IP addresses.
“sh run | in interface|ip address” is a good place to get your interface, IP and MASK information.
“sh int | in is up|Internet” is a good place for interfaces that are really up, plus IP and VLSM information.

Tweak things around for whatever you are searching for!  But each lab may be different in terms of how much is or is not preconfigured for you!

[note: I combined two of Scott Morris’ responses.  The text below actually comes from another of his posts.]

I would read the lab and look at HOW MANY faults I was supposed to find.  If there was something major that made me paranoid about changing it, I’d go ask the proctor “did you really do this?”
I would strongly recommend reading through the whole lab (twice!) BEFORE you do any troubleshooting or touch your keyboard!!!  That way you have a good solid picture in your head of what is supposed to be there.

Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE-M
#153, JNCIS-ER, CISSP, et al.
VP – Technical Training – IPexpert, Inc.
IPexpert Sr. Technical Instructor


Something I found useful was to take a snapshot of all the configs prior to making any configuration changes.

This way I had a snapshot of what I had been given to begin with and should I accidentally delete/change/modify something I wasn’t supposed to I could refer back to the snapshot and recover what I had been given.



Dear Rakesh,

I don’t think you should waste too much time trying to find the initial errors because you have no idea what you are looking for. Trust me, I wasted a good 30  minutes which i could have used for my final verification.

These mistakes that have been introduced will definitely interfere with the completion of a task (it wouldn’t be a mistake otherwise). So the key is to verify after you finish each task and you will find the mistakes as you go along.

The best strategy to start off would be to draw out the IP Topology  presented to you (On a separate Sheet) and write out the IP addresses/mask from the live system. Take no more that 15 minutes for this. This will give you a good idea of your Topology and will help you weed out any mistakes in IP Assignments. I think what Spathas said is a very good idea – to take a snapshot of the config before you start.


Ranjith Samuel.


The approach that worked for me best was:

1) Log on to all devices and to see if you were given a pre-configuration in sync with the scenario.  The reason to do this was to discover possible issues with the lab early.  Takes 5 minutes. One time I was given the wrong setup.
2) Read the scenario and do your homework
3) Fix the issues as you complete the Layer 2 tasks, then check basic connectivity again.  “sh run” is great at discovering “typos” and the like.  However, not all issues appear in sh run (I am thinking of VTP, system MTU, SDM and other goodies).  Do not forget to check if console logging is on.




1 Comment »

  1. On my first lab attempt, the first time I entered config mode, I accidentally hit the up-arrow key. The switch kindly presented a ‘monitor session’ command. Apparently the proctor put in the command after the initial config was loaded and didn’t reload.

    Comment by Josh — July 10, 2008 @ 10:26 am | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at

%d bloggers like this: