My CCIE Story – Part 3

In Part 1 of my CCIE Story I talked about taking the Cisco CCIE Routing & Switching Written Exam. In Part 2 I discussed some of my approach to studying for the lab.

As you join me for Part 3, I am flying to Brussels to take the CCIE Lab Exam for the first time.

My CCIE Story Moves to Brussels

Interestingly, while I can remember a fair amount about the lab exam itself, I recall very little about the flight to Brussels, the Hotel (other than I had to walk through some of a business park and some large parking lots to get to Cisco), or indeed anything else. When people ask me if I have been to Belgium, I say no because I honestly forget where I was for the lab. My focus was very clearly in one place: the CCIE lab I was about to take. I arrived the afternoon before, checked into my hotel, and began running through some study areas where I knew I needed a little last-minute refresher.

Lab Format

In January 2001, the CCIE lab was a two-day exam. The waiting list for the lab was over 4 months when I booked (unless you managed to grab a cancellation), and Cisco’s own (employee) CCIE candidates were a large part of the reason the waiting list was so big. In October 2001 Cisco changed the CCIE lab to a 1-day format, in part I’m sure to help reduce those waiting lists (and I’m sure it reduced their own administrative costs too). They also, as I recall, started offering Saturday lab dates for Cisco employees only – to clear out the weekday slots for customers. That’s quite thoughtful really!

So I was going to be there for two days, I hoped. I knew that Troubleshooting – if you qualified to continue to that section – was on Day 2, but I had not fully understood before I arrived that it was possible to be sent home at the end of Day 1 too. The high level schedule was:

Day 1 All Day — Configuration tasks. 3.5 hours in the morning, 30 minutes for lunch, then 3.5 hours in the afternoon. Grading review at the end of Day 1, with the option to send you home if you weren’t doing well enough.

Day 2 Morning — Configuration tasks. Grading review before lunch, with the option to send you home if you weren’t doing well enough.

Day 2 Afternoon — Troubleshooting. If you made it this far, it was make or break time. Once you were finished, your exam was graded and you would find out your final grade.

Day 1 Arrival

The next morning, I grabbed breakfast at the Hotel and headed through the business park towards the Cisco testing location. After signing in I was taken through to a break room right opposite the lab room, where we could grab a beverage and relax as best we could before the exam began. After a short while we were all invited to come to the exam room. The room was long and narrow, and was set up with desks on each side of the room. Each desk had a computer, and some of the desks had Cisco IP Phones on them. The proctor called our names out and told us which of the numbered desks we should go to. From what I can tell, Cisco ran two exams at the same time. It was well known that there was more than one exam type for R&S – for example one might have VoIP, another might not – and it was luck of the draw which you got. The room was laid out something like this (there may have been more desks, but it’s close enough):

Desks 1, 4 and 5 had IP Phones; desks 2, 3 and 6 did not. Depending on which desk/pod you were allocated, you’d either get an exam that included VoIP or you’d get one that didn’t. The layout of the desks meant that nobody had somebody directly in front of them doing the same lab exam, so nobody could shoulder surf between the rows. I was in Pod 3 I think, and managed – I believe – to dodge a bullet by that allocation. At that point in time, I could configure VoIP but I was certainly not confident about it in the same way I was about more general routing and switching. Note that the lab equipment was in the room next door to the exam room – this is important when you have a problem you suspect is cabling or equipment-related.

Day 1 – The Exam Begins

I sat down at my desk and started reading the exam paper. The paper explained the architecture that I was working with, the ‘Cisco’ devices on the edge that I would have to peer with so they could inject routes, and the requirements for IP addressing, before going  into the actual questions, which were usually multi-part and showed the points available for each specific instruction.

What stuck out more than anything was the confirmation of my previous experience that being able to configure ‘basic’ protocols cold was critical. For example, configuring IP, BGP, OSPF and IPX per the diagram took a lot of configuration lines and validation, but was worth just 5 points, or thereabouts. It was key not to spend unnecessary time on things that had a low point value, because there was a lot to get to in the exam. Other questions had points split between the sub-questions, and I remember seeing quite a few of the questions following this kind of point allocation:

5. Configure <protocol_or_feature>
   a) Configure <protocol_or_feature> between R5 and R3  (2 points)
   b) Do something simple but clever with it             (3 points)

The effort (just in time terms) to execute question 5a was usually significantly higher than that to execute 5b, but because 5a was considered something you should be able to do anyway, it was worth fewer points than 5b which was usually something a little tricky. Often the second part of the question was something you either knew or you didn’t, and while you had access to documentation, it might not always be obvious, or easy to find. I’d like to give you a specific example, but I don’t want to risk naming something that’s still in an exam somewhere.

Thankfully, I knew pretty much all of the tricks that were presented to me, so I was not too phased by most of the questions. There was one question though that had stumped me. It asked me to do something, but specifically said that I was not allowed to use a particular command to do it. As with many of the questions, it was necessary to get the functionality working in order to get the right results later on in the lab, and I ended up with an interesting solution where I used a different command, and IOS itself inserted the command I wasn’t allowed to use. Pedantic yes, but I was willing to make the argument that I had not used the command, IOS had. It was all I had, because I could not figure out any other solution. Apart from that, I just worked through the questions, documenting as I went along, and apart from a somewhat disappointing 30 minute lunch break, I felt pretty good as the afternoon session came to a close.

Day 1 – Grading

I knew before I arrived that you had to get at least 55 out of 75 points in order to be allowed to continue to the Troubleshooting section on day 2. The pass mark for the whole exam was 80 points, and troubleshooting was worth 25. Therefore, if you didn’t have 55 points before going into Troubleshooting, there would be no way you could achieve a final grade of 80 points, so they would send you home without even trying. I had not realized though, until I saw somebody else being sent home, that they also had a checkpoint at the end of Day 1. With a similar logic, Day 1 was worth 45 points so you had to have scored at least 25 out of 45 in order to come back for Day 2.

Grading in 2001 was performed by the Proctor – the Cisco person who sat in the room for both days supervising the exam and answering questions if necessary. I understand these days it’s all computer graded and you find out the next day, but this was immediate. This was probably to my advantage, because at the end of the day I was called in and the Proctor sat down with me to go through the first day’s results. It was great to be able to have interaction with the Proctor because when he came to the question where I had done my little pedantic semantic workaround (avoiding typing the command) I had a chance to explain what I had done, and why, and he had a chance to school me on the proper solution. It turned out that on one other question, I had made a bozo mistake. As he said “Now, for question 3b…” and brought up the configuration I had typed on the screen, I immediately spotted the stupidity and couldn’t help but cry out “Oh for heaven’s sake… please tell me I didn’t forget to <x>.”. “Yep,” he said, “you sure did.” I don’t know for sure, but I like to think that these two events counted in my favor and I didn’t lose all the points for those questions as a result.

My grade at the end of the first day was 42 out of 45 points. That was a cushion of 17 points over the minimum required score, and I knew this would take a lot of the stress off the testing on the morning of Day 2 – I would only have to get 13 out of 30 to make it to Troubleshooting!

Day 1 – Evening

I went back to the hotel in a bit of a daze, unable to believe I had scored that well, and annoyed about the bozo error which must have lost me at least one extra mark of my safety margin. I had dinner, which involved a saddening lack of alcohol, and then went to bed where I slept somewhat fitfully, wondering what on earth Day 2 would hold.

 

I’ll pick up on Lab Day 2 in Part 4 of my CCIE story!