CCIE R/S Versus CCNA/CCNP Troubleshooting

Breadth Matters More as You Go Higher in the Cert Pyramid

It's a long story, but I started out planning to blog about a book I used to prep for the CCIE R/S lab troubleshooting section. However, I think there's a broader topic that grows out of what I experienced in the lab. Today I'd like to offer a few thoughts that crystallized around this theme: the CCIE R/S Troubleshooting tasks require such a broad view of everything in the lab blueprint that it may require a different approach than the CCNA and CCNP t'shooting questions. As a result, your preparation, and the tools you use, may need to be a little different. Today I'll describe this one book that I tested when taking the CCIE R/S lab, and discuss why I think this new section requires a little different plan of attack than do the CCNA and CCNP t'shooting topics. At the end, I'll offer a survey to see how you think you'd approach the t'shooting topics on lab day.

So, first, the background. If you missed the last two posts (here and here), I took the CCIE R/S lab Beta a few weeks back. I knew that I didn't have time to prep, other than maybe 2 hours of time in airports and on the plane. So, rather than just go and kick the tires in the lab, I decided to test a theory that had been percolating ever since I heard they were adding specific troubleshooting section back to the lab.  I've been a fan of the book "Troubleshooting IP Routing Protocols" from Cisco Press for a while, but I only used it in small intervals. My theory was that it was the perfect book from which to do final prep for the routing protocol topics in the lab's troubleshooting section. I wanted to test the book's use as a final prep tool, hoping it would help me confirm what I knew, brush up on what I'd forgotten, and learn stuff I'd never come across - and do so relatively quickly as a tool used the last week before the test.

To be fair to the authors, I don't think that this book is billed as a "cram" or fill-in-the-holes book for CCIE lab study, but basically, that's how I used it. I already thought it was an excellent book for explaining lots of issues that arise with routing protocols.

The short version is that the book was fantastic for my purposes. First, the Table of Contents (TOC) is detailed. It lists problems - lots of problems - including the symptom and the root cause, right there in the TOC. With enough info in the TOC, I could read and quickly know which I already knew, which I thought there might be some small point to learn, and which might be completely new (or forgotten). Then I could flip over to read more about the one that were interesting, and solidify my skills. And I did learn some new stuff!

As a brief aside, here's one I didn't know: that in an NSSA area, only one ABR (the one with the highest RID) will convert the Type 7 LSA to a Type 5. The book showed that fact, and a scenario that then results in the intended area 0 routers not learning about the external routes injected into the NSSA area. As you can see from this PDF of one of the TOC pages, I thought the scenario was pretty cool.

So what? It's a good book, hoorah. Next, consider what happens on CCIE lab day. Let's say you're taking the CCIE R/S lab. You start the troubleshooting section, and you spend the first 10 minutes looking at the diagrams, reading all the troubleshooting tickets. With 110 minutes left, you begin the first of 11 tickets, figuring 10 minutes each. Do you start with a show run? Start with ping/traceroute? Do several show commands? Just one or two show commands, and then dive into show run? How do you get from general idea, to your mental list of related things to check, to finding all the missing/busted config, fixing it, and verifying that the problem is solved, in 10 minutes or less?

Next page over, I'll comment a bit on that game, both for this scenario with CCIE, and for CCNA/CCNP.

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