The Transcender Team Weblog

Troy’s TSHOOT study plan: Topic 1

Topic 1 in our TSHOOT series: Get a Game Plan!

As was reported earlier, both here and in many other places on the Internet (though I don’t know why you would ever look anywhere else on the Internet, because everything you need to know is here on our blog, by the way), the new Cisco TSHOOT exam is not the same test from years past. Yes, there will be a token number of multiple-choice questions to answer, but the bulk of the exam will be presented to you as “trouble tickets”. This post is the first in a series where I will cover some of the topics that you may see on this exam, and — the important part — how you need to approach these topics in your study plan.

On the exam, you will be presented with a set of diagrams representing the network for which the problem tickets are based. Just like in the real world, your job is to find where the problem lies within this thicket of devices, and then to decide how to fix it. As we explained in our previous post on TSHOOT, you will have to answer three questions on each ticket:

• Which device is causing the problem?
• What is the nature of the problem?
• What command would fix the problem?

In every scenario, there is a user at one end of the network trying to communicate with a device at the other end. That means that the problem could be located at 5 or 6 different links along the way.  Some of the devices are routers, some are switches, and some are Layer 3 switches.

(If you’re not getting a good picture of what I mean, then this would be a good time to go and look at Cisco’s online demo for the TSHOOT, http://www.cisco.com/web/learning/le3/le2/le37/le10/tshoot_tutorial.html, and then return to this post.)

Before you even start working the first ticket, you should adopt a plan of attack. Don’t take a scattershot approach. Be organized. Let’s look at the tried and true approaches to this type of troubleshooting. You have two issues to consider as you work:

1. Where is the problem (on which device)?

2. At what  layer of the OSI model is the problem located?

Where is the problem?

Let’s start with the possible approaches for the first issue.

Tactic 1: Start at the source

With this approach, you would start with the user device and attempt to ping the IP address of the next device on the path to the destination device. If that works, then ping from the second device to the third, and so on. At some point in the process, a ping will fail, and now you know which connection has a problem. So make sure you know how to determine the IP address of an interface and how to ping an interface.

Tactic 2: Start at the destination

With this approach, you ping from the source device to the destination. Of course, it will fail (otherwise there would not be a trouble ticket, right?). Then you work back toward the source, pinging next from the source to the next closest device in the path. When your ping is successful, the problem will then be identified as residing on the last connection that failed before the one that worked.

Tactic 3: Start in the middle

Are you a gambler? Then you would understand that the odds of finding the problem the quickest are best with this approach. Here, you ping to the middle of the path, and if that works, continue to ping toward the destination. If pinging to the middle of the path doesn’t work, start to ping back toward the source. Mathematically speaking (please do not ask me to explain it, ask George, he went to Georgia Tech with the rest of the smart kids), this will find the problem the quickest.

PING tips

Realize that when a device is connected to a Layer 2 switch there is no need to ping the IP address of the switch. It does not come into play in the switching or routing process. If it’s a Layer 3 switch, then that’s different, but even then you will be concerned with the router part of the Layer 3 switch and not the switch side. So that means you should ping from the device to the next router interface in the path, and skip the switch.

What type of problem is it?

Now that you have determined where the problem is, you must determine the type of problem it is. There are three approaches to this.

Tactic 1: Top down

This approach starts by troubleshooting application issues (Layer 7), and then working down the OSI model to the transport and network layers, and from there to the physical layer (Layer 1). I would not recommend this approach since the problem is connectivity, which is most likely to be a lower layer.  Application issues usually result in performance issues, not connectivity issues.

Tactic 2: Bottom up

With this approach, you start with the physical layer (cabling), then proceed to Layer 2, which would encompass VLAN issues and DLCIs. If the problem is not discovered, you would move to Layer 3 to investigate routing protocol issues, DHCP problems, and NAT. This is a better approach than top down for this scenario, and one I recommend.

Tactic 3: Divide and Conquer

This approach plays the odds and starts in the middle of the OSI model, at the network layer, and then proceeds up or down based on the results of your investigation. For example, if you see no routing protocol issues, NAT issues, or DHCP issues, then move down to Layer 2.

Whatever approach you adopt, you should stick with it for the duration of the ticket. Be methodical and keep working until you find the problem. You have plenty of time to finish if you know your commands, although you should do some quick math from time to time and ensure you don’t spend too much time on one ticket. If there are 16 tickets and you spent 20 minutes on the multiple-choice questions (let’s say there are about 10), then you have 115 minutes left for 16 tickets. That’s 7 minutes per ticket. Keep that in mind and if you find yourself crunched for time, don’t skip any answers, but make a guess and move on.

I’ll go into more depth on specific issues, such as issues with BGP, DHCP, IPV6, EIGRP, and HSRP in my next post.

Stay tuned!

–Troy McMillan