CCIE Pursuit Blog

March 31, 2008

Internetwork Expert: Mock Lab I Review

Mock Lab: 1
Difficulty Level: 6
Date Completed: 26 March, 2008
Final Score: 89

NOTE: I will be discussing very few details about the actual tasks on this lab.  If you are planning on taking this Mock Lab then you can read this post as will have few (if any) “spoilers”.   :-) 

I purchased 4 of Internetwork Expert’s Graded Mock labs back in December when they were on sale for $99.  The current cost is $129.  I completed the first of my 4 labs last Wednesday.

On your IE member page you’ll see a section for Graded Mock Labs (emphasis mine):

Your mock lab number will be locked in 1 hour prior to your session start. Once your session has started, a “Start” button will appear. Click the “Start” button to receive your lab, topology, physical topology, and configs.

If you do not click the “Start” button within 1 hour of the start of your session, it will automatically be started for you. Once your mock lab has started, you have 8.5 hours to complete it, and a timer will appear telling you how much time you have left. You will be automatically kicked off your rack at the end of the 8.5-hour lab.

Your mock lab will be graded by 9 PM PDT on the second business day.

Click “View” to open a pop-up window displaying your graded mock lab. Click “Overdue” to automatically send a support ticket about not receiving your graded mock lab.

NOTE: The password to open password-protected PDFs is your e-mail address.

My lab was scheduled for 10 am PDT (noon for me).  Sure enough, once noon rolled around there appeared a button to start the lab.  Once you click this button you will be presented with links for the PDF files for the lab, the topology, and the physical topology (cabling).  Anyone who has done the IE Volume II (or Volume III labs) will be familiar with the documentation.  You’ll get a logical Layer 3 document as well as a routing protocol map.  Although I did not need to provide a password, if you are prompted for a password for any of the PDFs, use the email address that you have registered with you IE account.

One thing to note is that the instructions on how to access your rack is located in a different part of your IE membership page.  It’s in the “My Current and Future Rack Rental Sessions” section.  You’ll probably want to familiarize yourself with the rack documentation.  I’ve rented IE racks before so I was familiar with the process.  Although I didn’t do it (only because I didn’t think about it), it’s probably a good idea to log into your rack and open your reverse telnet session before you click the button to get your documents.

One thing to be aware of is that as soon as you click the button to begin the lab the clock will start ticking.  You’re given 8.5 hours to complete the lab.  There is a cool countdown widget on your IE member page that will run through your lab so you can easily see how much time has elapsed and how much time you have left.

Mock Lab 1 Timer

As soon as you click the “start lab” button the clock starts counting down.  I didn’t think about printing the lab until after the lab had started.  Since I was at home I had to load drivers on my laptop before I could print to my ancient Canon printer.  By the time I had printed all of the documentation and logged into each of the devices I had already lost 15 minutes.  As I mentioned above, it’s a good idea to log into your rack before starting your lab.

One of the resources that becomes available once you start the lab is a zip file of the initial configurations.  I had already lost 15 minutes printing and logging in to the rack.  I was a little pissed that I would need to apply the initial configurations.  The initial configurations are already loaded on your rack so you don’t need to worry about that.  The intial configurations are provided so you can redo the lab later (or rebuild your rack if you really fuck up).  Whew!!!

So I was up and running with 8 hours and 15 minutes to go.  The IE documentation states that after 8.5 hours you will automatically be kicked off of your rack.  I’ll spare you the task of reading the rest of this post and just tell you that this did not happen in my case.  When the timer finally hit zero I was not kicked off of the rack. I didn’t make any changes at that point and the initial grading script ran within 1 hour of my time elapsing.  [I can't remember when it ran, it may have run right after time expired, but the score was on my member page less than an hour later]  Your experience my not be the same, so I would just assume that your going to be booted off. 

As I posted earlier the grading script will run and give you an initial grade.  Don’t get too depressed about your initial score from the script as it is likely that you will get more points once a proctor reviews your lab. 

Initial Scoresheet Graded By Script

Within two business days a proctor will manually grade your lab and you’ll be able to see a web page with your final grade along with the proctor’s comments and feedback. 

Proctor Feedback

I read the complete lab and made notes before I started configuring anything.  Reading the lab and creating a simple layer 2 diagram took 22 minutes.  After that I kept track of the when I completed each task as well as how confident I was that I had earned the points.  I had completed IGP redistribution and basic BGP peering just before I took “lunch”.  Lunch turned out to be the 20 minutes I spent picking up my son from school.  :-)

I had finished all of the tasks that I felt I could complete with about 30 minutes left.  I ended up not attempting 3 tasks. I spent quite a bit of time troubleshooting an issue that was probably due to an IOS bug, but I had plenty of time to complete the lab.  I did start getting mentally fatigued about 6 hours into the lab.  If I could have stayed a little more focused I could have finish about 30 minutes earlier.  When I finished, I felt pretty good about meeting my goal of getting 80 points.

When your time expires you’ll see a new link to the solution guide.  I didn’t have the energy or inclination to look through it at the time.  I looked at it briefly this weekend.  There are no breakdowns like in the Volume II labs, only the correct configuration as well as some good verification commands.  The Graded Mock Labs are supposed to include a Class On Demand breakdown of the lab.  I haven’t received a link to that yet.  That will probably include the task breakdowns.

I’m not going to go into details about the lab itself other than to say that it was fairly easy.  The lab has a difficulty level of 6 which is easier than the actual lab.  After spending most of the prior 10 days getting my ass handed to me on level 8 labs, this lab seemed pretty easy by comparison.

On Sunday I got the email saying that my lab had been graded by the proctor.  I was very happy (and a little shocked) to find that I had scored an 89.  Since I had skipped 9 points, so I only failed one of the tasks that I attempted.  I missed it due to a stupid mistake in an ACL, but I’m not complaining because there were at least 3 tasks that I got full credit on which I was unsure about my solution. 

Proctor Graded Scoresheet

Random Thoughts:

Finishing with 30 minutes to spare is nice, but I didn’t have time to go back over my tasks to catch stupid mistakes.  I still need to increase my speed.  As I stated earlier, there was a period about 6 hours in where I lost my edge.  I was making silly mistakes and I would end up reading and rereading tasks as well as configuring things twice (because I forgot I had just configured it) as well as forgetting what device I was on.  Nothing major, but in a more difficult lab this could have been a big problem.  As it was, I think that I probably lost 20 – 30 minutes during that stretch just to lack of focus.

I need to limit myself to items that will only be available in the lab as well as curb practices that will not be allowed in the actual lab.  I’m still using Tera Term as my telnet client.  It’s not hugely different from SecureCRT, but I need to make sure that I am more familiar with SecureCRT, especially the cut and paste hot-keys/options.  I also need to stop writing notes on the lab and lab diagrams.  This is not allowed in the actual lab.  I also need to start getting used to using notepad without saving or closing the notepad instances.  Finally, I keep the lab topology open on my laptop so that it’s visible in the background while I’m working.  This is not allowed in that lab, so I need to nix that habit as well.

I was lucky.  I done over 60 hours of IE labs over the 9 days prior to my mock lab so I had more practice with some technologies that I am normally weak on.  I also watched the IEATC session on setting up a logging server and configuring NTP the night before the lab.  Normally, I would have spent much more time using the DOC CD for those topics and I probably would not have received any of the points for NTP because I totally misunderstood key aspects of that technology until literally the night before the mock lab.  Multicast was very simple.  This is the first time that I’ve ever received all of the points for Multicast so you know it was dead easy.  :-)

I knew which technology to use for each task I attempted as well as how to implement it with minimal need of the DOC CD.  I’m not saying this to brag.  I’m saying it because I still finished with only 30 minutes left.  A more difficult lab would have meant more time mining the DOC CD and therefore more time to complete the lab.  I also completely skipped three tasks.  I somehow need to pick up my speed.

Anyhoo….I’m pretty pleased with my score, but I still realize that I have a LONG ways to go before I am ready for the actual lab.

March 28, 2008

ATTACK BY PROCTOR!!!

Every few months on GroupStudy there will be a story about a CCIE candidate going to lunch and coming back to find out that the proctor has messed with their configuration.  I always figured that this was just an urban legend, but then I experienced an ATTACK BY PROCTOR firsthand.

On Wednesday I took one of Internetwork Expert’s Graded Mock Labs.  I had successfully completed IGP redistribution  and had verified that I had end-to-end connectivity via TCL scripts.  I hurried up and applied the basic BGP peerings.  Then I consoled into each device and wrote the configuration.  Just before I went to lunch (actually just a 20 minute break to pick up my son) I reloaded all of the devices. 

When I got back I ran my TCL script again and noticed that my connectivity was broken.  Between IGP redistribution and basic BGP peering my network somehow “broke”.  I figured that I must have really messed something up with my BGP configuration since everything was fine after IGP redistribution.  I went back and verified my BGP configuration and peering on each device.  Maybe I lost some configuration when I reloaded – even though I was careful to make sure that I wrote each device before reloading.  All of my BGP configuration was there so I obviously wrote each device as that was the last configuration I had completed.  All of the BGP peerings were up and I was seeing routes coming in on the peerings (the ones that should be sending routes at least).  WTF?

I didn’t want to waste a ton of time troubleshooting this mess, so I soldiered on with the exam and made a note to run the TCL scripts again later.  When I did eventually run the scripts again, my network was still broken.

I finally started to look at the individual routes that were missing.  My issue seemed to be between the hub and spokes on one of the Frame Relay networks.  I still could not find an issue with BGP.  I took a look at my OSPF neighbors and I found that my OSPF adjacencies from my hub to my spokes were gone.  I still had some routes coming in via a virtual link between my hub and one of my spokes.  How the hell did that happen?

I looked at my OSPF configuration on my hub and found that my neighbor statements to the spokes were missing.  I added them back into the configuration and then ran my TCL scripts again.  Hallelujah!!!  I had full connectivity once again.  Although I had written my configurations after each task I must have somehow not written r5′s configuration after I finished my first OSPF task?  I continued on with the lab as I only had about 20 minutes left at that point.  I did not reload the routers again before finishing the test.  I did make sure that I wrote my configurations on each device and saved out my configurations to textfiles on my desktop.  I probably verified that those neighbor statements were still on r5 about 10 times before the lab ended.  :-)

Thinking back about this issue later I realized that since my BGP configuration was still on r5 I had definitely written the configuration on that device.  The neighbor statements must have been removed when I reloaded that router.  Somehow those devious bastards at IE must have removed my configuration.  They probably have a script that somehow removes those two lines of configuration whenever r5 is reloaded.  I had experienced the dread ATTACK BY PROCTOR!!!

Or not…. :-)

I went to ccie-in-3-months to see if Tassos had experienced any similar issues with his mock lab and found this:

…I decided to reload all routers! What was even more disastrous, was the fact that i reloaded them all at the same time and i didn’t look at their logs while booting.

The result? After the reload, something wasn’t working as expected. After a quick search I found one router which seemed not to be running OSPF. I checked its configuration (thank god I had saved all my session locally) and I found that there were two “neighbor” commands missing! I added them and reloaded again. This time I watched the logs and there was an error message saying that this particular command is not supported on this kind of topologies (a bug? command is accepted while configuring, but it’s rejected after reloading). So i saved my configuration and warned (through email) the proctor about this behavior.

Here’s his post on the Internetwork Expert Mock Lab 1 forum:

Task 4.1

After reload:

Cisco 3640 (R4700) processor (revision 0×00) with 111616K/19456K bytes of memory.
Processor board ID 13831044
R4700 CPU at 100MHz, Implementation 33, Rev 1.0
2 Ethernet interfaces
2 Serial interfaces
DRAM configuration is 64 bits wide with parity disabled.
125K bytes of NVRAM.
32768K bytes of processor board System flash (Read/Write)

OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks
OSPF: Neighbor command is allowed only on NBMA and point-to-multipoint networks

Press RETURN to get started!

Like I said, I didn’t reload the router a second time.  I also would not have thought to watch the reload output.  So the good news is that it was not ATTACK BY PROCTOR but I was the victim of a bug.  [My network type on the hub and spoke was NBMA per the task].

This was actually a good experience as I got to do some troubleshooting under pressure.  I did fuck up my troubleshooting as I assumed that the issue was with BGP and did not troubleshoot outside of BGP until much later.  This was also a potentially disastrous experience as I would have lost an untold number of points due to not having end-to-end connectivity.  I am a bit disappointed that IE had not addressed this bug.

Oh, and the ATTACK BY PROCTOR rumor?  It’s exactly that – a rumor:

Hi Maruilio,

Thanks for the reply!!!

Could you please give a clarity on proctor’s behaviour during the Lab exam? I’ve heard that proctor’s occasionally changes the configuration while the exam is on eg- erase passwords, erase configurations, shutting down the interface, changing the IP addreses, etc. I am not sure if that’s all true? If it is, is that justified? I’ve also heard that you should not be too fast even if you know are pretty confident of your configurations because proctor’s probability of changing the configurations increases. Is that also true?

If the above is true, I also want to know to what extent are proctor’s authorised to play with the configurations during the exam?

My second query is – when the lab starts do we get all the devices with zero configurations or we have to first erase all the pre-configured inappropriate configuration on the devices?

My third query is out of curiosity – what method does proctor’s use for checking the lab created by the student?
Regards,
Saurabh Garg

Hi Saurabh,

These are all rumors and do not reflect the CCIE Lab environment.

Proctors do not touch any of the candidate’s devices during the exam.The only exception will be if a candidate thinks that something is not working because a possible failure on your rack the Proctor will ver[if]y it, but the candidate will be aware of it. Proctors do not touch or play with candidate’s configuration during or after the exam.

When you start the exam your routers and switches will have an initial configuration such IP addresses, hostnames, passwords. Depending of the exam you may have more pre-configuration. The ‘General Guidelines’ of the exam will state what you can change and what not can be changed.

We do have a process to development each question of the exam and it is based on results. By the end of the exam Proctors use an automatic tool to save the candidate’s configuration into our database and to verify some questions and do some connectivity tests like pings, verify routing tables, and so on. Then Proctors will manually verify the results and all remaining questions to come up with the final score.

Regards,
Maurilio

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 109 other followers