CCIE R/S Lab Troubleshooting: Initially Shocked, but Wasn't Too Bad

2 hours; 10-12 trouble tickets; but 30-40ish devices – Yikes!

So I'm sitting at the CCIE R/S lab Beta, and beginning the part I was sooooo looking forward to - the new 2-hour troubleshooting section. 2 minutes into that section, I was completely bummed. It seemed too much to even attempt. 40-ish routers and switches... 10-12 trouble tickets... 2 hours... plus a new user interface. But by the end of the process, I had completely reversed my opinion - I thought it was completely reasonable. Today, I'll describe the process and draw a few conclusions about the t'shooting section.

First, a little context is in order. The day began with a brief talk w/ the proctor, and a look around the parts of the user interface you could see before starting the timer. Then, it was time to start a timer and then answer the open-ended questions. Cisco didn't require that the Beta candidates pass that part - they wanted the labs, process, interface, etc tested - so then it was time to click start to crank up the t'shooting part of the lab.

(I'm assuming you read my last post, which talks about the GUI; if not, go here.)

There was no physical lab book, but there was a window that you could display that lists the various t'shooting tasks that I would refer to as trouble tickets. Each task or ticket describes a problem, eg, PC1 can't ping PC2, intervening routers should be set up to do x, y, z, make it work, that kind of thing. I can't say how many I had, but I did get permission to say 10-12 tickets is typical. Just my opinion, but that number may change over time, particularly as they build more, some of which may take longer or shorter time.

The GUI actually worked pretty well for reading the tickets. The t'shooting tasks could be easily scrolled from the window that displays the tasks. So if I looked at my list, thought about doing numbers 3, 5, or 7 next, it was quick and easy to review each briefly. Because the tickets did not seem to be dependent on each other, it seemed a good strategy to do the easiest for me first, ignore those for which I had no current knowledge of the config, and get the tweeners in between. (Your tickets might be interdependent - they just weren't in my case.) Regardless, the GUI made it easy to navigate to the trouble ticket I wanted to tackle next.

The shock in the first few minutes was the unveiling of the topology figure. 30-to-40 or so routers/switches interconnected, lots of redundancy. Yikes! On top of that, I came to the lab with the typical strategy for doing the config section, planning to get a good handle on the topology before doing any of the exercises. However, a 4X bigger topology than a typical config topology made that difficult. Plus, the information in the figure was a bit sparser than the typical multiple view figures for the config section. So, going in with my "understand the topology" strategy was not good, particularly in light of the time constraints.

An interesting aside: the config section continues to be performed on real gear, sitting in a rack somewhere else (I think San Jose, not sure, but it wasn't next to us in Raleigh). But the big t'shooting topology was on a "virtual environment", to use the approved description. So they don't have tons of 30-to-40-device pods waiting on you. I don't know where those instances were hosted, but the response time was better on the t'shooting labs than in the config labs.

The individual tickets were clear and fair. Plus, they were not long - after reading through them all at once, on the 2^nd time through, it took maybe 10 seconds to re-read, and it was time to get into the consoles. So, there was only a little time consumed to understand each issue.

• Careers
• Cisco
• CCIE
• CCIE lab
• CCNP
• Cisco Press
• Troubleshooting
• Wendell Odom