CCIE Troubleshooting Lab Tips

Troubleshooting lab is designed for a CCIE candidate to fix an issues of a pre-configured network.  Tickets are very well defined as well as the expected behavior.  There are about 10 tickets presented, some are worth 2 points and some 3 points.  The troubleshooting lab has an automatic cutoff time after 120 minutes.  All devices are virtualized using Cisco’s IOU (IOS on Unix).

The way I approached the troubleshooting section is by reading all of the tickets first.  Yes, that will eat up about 10 minutes of your allocated 120 minutes, but it is well worth it.  During the initial read, I created a table which tracked:

 

Ticket	Points	Bullet Point	Restrictions	Comments
1	2	O O O
2	3	O O O
…	…	….

 

* Ticket – The ticket number number.

* Points –  I circuited the 3 pointers, as you have to get at least one to pass the troubleshooting lab.

* Bullet Point – If a ticket has 5 bullet points that described the ticket, I would draw 5 circles and check them after completing each point to verify that I didn’t miss anything.

* Restrictions – Any major ticket restrictions, if there are too many, I didn’t write them all just used the task list and noted the major ones.

* Comments -Used for any of my own observation and possible solutions.

I did not draw the topology for the troubleshooting section since there are about 20-30 devices and I didn’t really need to waste time on that.  Reading over each task, I took  notice of any dependencies for each ticket, for example do I need to have Layer 2 working for this Layer 3 ticket to be solved?  Are there any tickets that have no dependency?  Do any of them relate only to one device?  Which tickets are worth 3 points (circle those)?

After reading all trouble ticket, I tried to solve the easier ones first.  If I couldn’t get a ticket in 5 minutes, I moved on and returned to it after trying all others.  What I noticed is that it took me a lot of the time to solve the first few tickets.  I had to skip around and come back.  On the second try, they seemed to get a lot easier. Once I attempted all of the tickets, I had a very good idea of what the topology looked like and what the root of the problem could be.  After completing each ticket I reread the task requirement and verified that my solution didn’t violate any of the restrictions and that I didn’t miss anything (this is where I would use the bullet points column to check off each bullet point).  Verification is a crucial step that is easy to forget but at the same time very important to get the hard earned points.  I made sure to leave plenty of time for the 3 pointers, since these have potentially more than 1 issue to fix.

One other thing that I did to help me, was copy and paste any commands/changes I make to for each ticket into notepad.  Keeping track of all changes, I was able to revert back in case one of the solutions broke something, some commands were not necessary to fix the ticket or my solution violated the requirements.

The other major challenge was not to remove any features already configured. For example if I would have an ACL that denied something which should be permitted, I didn’t just remove the ACL, but inserted the permit statement.