5 Day INE CCIE Troubleshooting Bootcamp Day 1

For the next 5 days I will be attending the INE 5 Day CCIE Troubleshooting Bootcamp with Brian Dennis in London.
I am going to blog here my experience of this class, mainly for my own reference but also to help out anybody thinking of taking this class in the future.

Although as any of you you who know Brian Dennis or have done a ccie bootcamp before, any time in a class with Brian is invaluable time and money well spent on your CCIE Lab Exam preparations.

Morning

The course is being held at the Charing Cross hotel in London which is actually defined as the centre of London – more info here.

The room is very spacious and there are 4 projector screens showing 2 copies of the console window and the diagrams etc. A typical day starts at 9am and is scheduled to run 10-12 hours.

This is not a power point course, Brian talks and labs the entire time giving you first hand experience of how to tackle every aspect of the troubleshooting section of the CCIE lab exam.

This week there are 20 students (all male) 5 of us have already made one attempt at the exam and the rest are planning on making their first attempt sometime this year. The most popular slot is December when then the CCIE Mobile Lab is in London.

Once the introductions are out of the way we are straight into an introduction to the troubleshooting section and a walk through the restrictions.

The next writing is going to be some basic notes, of the basic troubleshooting concepts and this afternoon we are going to configure a 30 router topology in preparation for the first troubleshooting tickets this evening – If you can’t build a network how are you going to troubleshoot it?

Brian says the majority of engineers who go on to pass the troubleshooting and the lab exam are the ones that are very comfortable with configuring a network from scratch. If you can’t build it, how can you troubleshoot it?

Tip #1

Load up a Vol II topology with the basic config (IP address and VLANS) then spend the next few hours by just looking at the diagram configuring the network. By laying in the BGP / OSPF / Redistribution etc you can see how things are built instead of just tackling an already configured network.

This is certainly one thing I am going to start doing as soon as I get home!

Tip #2

First thing to do when you drop onto a router
ping 255.255.255.255 re 2
See what replies – do the devices that reply match your diagram?
This will emlimate any layer 2 connectivity issues

sh ip protocol summary

See what routing protocols are running

Default Route / sh ip cef

Beware of the default route which can send you off in the wrong direction. If you have a problem that e.g R11 cannot telnet to R15 – the first thing you would do is check the route from R11 to the IP address on R15 if you get the following:

[stextbox id=”black”]R11#sh ip route 15.1.1.1
% Network not in table
R11#[/stextbox]

You might assume that R11 does not have a route to 15.1.1.1
There may not be a route in the routing table but there could be a default route in place which is taking the traffic in the right direction. You can verify this with sh ip cef 15.1.1.1 – this will tell you exactly what direction the traffic is going to take.

[stextbox id=”black”]R11#sh ip cef 15.1.1.1
0.0.0.0/0, version 12, epoch 0, cached adjacency 10.0.5.100
0 packets, 0 bytes
via 10.0.5.100, 0 dependencies, recursive
next hop 10.0.5.100, FastEthernet0/0 via 10.0.5.100/32
valid cached adjacency
R11#[/stextbox]s

By doing a sh ip cef you can verify which way the traffic is going to route and will will show you if it’s taking a default path, whereas the sh ip route command can through you off when you see % Subnet not in table

Basic Troubleshooting Concepts

Brian is very keen to explain the value of showing the results of  the ticket. You need to know the debugs and show commands that will isolate the problem quickly. Try to avoid using show run on every router as with the size of the topology it is going to take a lot longer to do a show run on every device than it is to locate the source of the problem by seeing the results.

If you can’t build it you can’t troubleshoot it!

2pm in the afternoon and we start the building of the 30 router topology. The topology that we start with has all the IP addresses and vlans configured but we have to put on all the routing protocols, redistribution and build any frame switching. This is in preparation for 5pm when we start with the first ccie troubleshooting tickets.

5pm has come and gone and I am about 3/4 of the way through configuring the topology. It really goes to show that you need to fully understand how everything hangs together to be able to really troubleshoot it later on. Brian recommends to do this exercise over many times until you can configure the entire topology without even thinking about it. When you are fully comfortable configuring everything when you come to troubleshoot it any routing problems should be a lot more obvious to you.

CCIE Troubleshooting begins

6pm We start the going through the troubleshooting tickets from Lab 1. The idea of the troubleshooting labs is to explore every possibility of what the problem could be and not to just do a sh run on every device to find the problem in the config.

You are only cheating yourself by just doing a sh run on every router, the key to mastering ccie troubleshooting is to understand why the fault exists and to know the show commands to discover that quickly.

9pm and most people have gone home now, there are 5 of us left here going through the tickets. There are a few things I need to brush up on tonight after dinner and then we will get a full review of the Lab 1 tickets from Brian in the morning.  The plan for the day is to spend about an hour on each ticket to really go through every possible way of solving a ticket and to fully understand the technologies and how to break them.

Final thoughts for day 1

This has been an awesome day so far and is just what I needed at this point in my preparations.
By the end of the week I am sure to be a lot closer to nailing the troubleshooting section of the ccie lab exam.