Best Troubleshooting Approach to TSHOOT Exam

Are you the best network troubleshooter in your shop? Maybe you’re the go-to person to fix problems when the network falls apart. Maybe you know who that person is, and you know you need them to come through for the team. But in most shops, folks know who’ll be called on when things really fall apart. Today, I’ll take a look at how network engineers might troubleshoot the types of problems on the TSHOOT exam, and ask you to weigh in: how do you think your favorite troubleshooters would approach the TSHOOT trouble ticket questions?

It’s always been interesting to me that the troubleshooting aspect of networking jobs seem to be a little like a competition. Maybe it’s a way to prove you know your stuff. It seems more like being the fastest runner, or having the best golf handicap, or knowing the coolest new computer tools, being best at the latest IPhone game, and so on. With Troubleshooting, there’s time pressure, increased reward, but a noticeable downside if there’s failure. Maybe it’s that, more so than most other job functions for network engineers, it’s a place where each person’s competitive nature can take over.

(I’d be curious if any of you see such tendencies, and have opinions why that might be the case. It has little to do with the TSHOOT exam, but I’d still be curious.)

The TSHOOT Trouble Ticket (TT) questions do a nice job of approximating that competition, much more so than the more traditional types of questions. But should you approach these TT questions the same way you would most any problem in your own network? Should you study how the go-to engineers in your shop troubleshoot network problems? What specifically should you do? Today I’ll start unwrapping these questions by examining these TT questions, and categorize some general methods. I’ll include a poll at the end to see what all of you think is best as well.

Next post, I’ll dive into details of how I’d approach TSHOOT.

First, let me make some observations about these new TT questions. I’ll base these on the Demo, but it was corroborated when taking the TSHOOT Beta:

1. The 4 Demo TT questions reduce to simply “Client 1 can’t ping IP address 209.65.200.241”.
2. The scenario wording implies that “the config has changed” – not always true in real networks, but clearly true in TT’s, because the answer of MC question 3 always lists the config that fixes the problem.
3. Host Client 1’s user interface is accessible, and supports ping and tracert.
4. The destination host’s user interface, at least in the 4 Demo questions, is not accessible, nor is the closest router to that host. (The host, and it’s nearest router, are in the Internet.)
5. The routers support traceroute, with extended options – but only through prompts (i.e., no way to put all options on one CLI command.)
6. Router traceroute only supports destination address for host B (actually 209.65.200.241), at least in the demo version.
7. All routers and switches, except those in the Internet portion of the topology, were accessible, and supported “show run”.
8. The simulated CLI does not support all commands and command parameters.
9. Looking at the three MC questions inside each TT does reveal all possible answers, but it’s a potentially large number. Figure 6 possible devices that can be configured, 6 technologies per device (MC question 2), 6 different config options per device, for 216 possible combinations.
10. The simulator/GUI for the test was fast enough so I wasn’t waiting on the output to display.
11. The demo topology has 6 CLI devices accessible (2 switches, 4 routers), but there’s no layer 2 or layer 3 redundancy in the demo topology.

While those are things you can see in the Demo, there are other things that you can guess about the exam, but for which Cisco doesn’t tell us much. So, here’s another list of assumptions you could make. They may not all be true, but they bear consideration:

1. Cisco says there are 53 questions, in 120 minutes. That’d be incredibly unreasonable is the mix was 53 TT questions.
2. A more likely mix would be some multichoice, some TT questions, and 1 TT = 3 questions, since each TT has 3 MC questions imbedded.
3. For the sake of discussion, assume you’ll have an average of 8 minutes per TT. You may have more or less.
4. There’s no guarantee that a single TT question has only 1 config problem introduced, but if I had to bet, I’d expect that there’s a single problem in each TT.
5. There’s no specific guarantee that the cabling actually matches the topology map.
6. Each TT’s topology may be the same, but the initial working configuration may well differ. EG, show run on R1 shows different output on 2 different TTs, but it may be 100% good in both cases.

The biggest key is that many questions, and certainly the 4 demo questions, are “ping no workie” scenarios. As such, there’s no need to look above layer 3. And while the problem could well be a layer 1 or layer 2 problem, we know that the technologies included in route are mostly layer 2 and 3 technologies.

So, what’s the best way to find these answers, and find them quickly? Let me describe some options, and ask for your comments, and get you to answer a poll this week.

Which of the following most closely matches what you would do for the first few minutes of each TT question?

Show run everywhere: Well, you can look at all the config. Why not? There’s some reasonable logic to this approach. The third MC question lists specific config commands to add that fix the problem. Why not start at the last question, and do show run everywhere? Could you read all the possibly related config in 6 devices, and find the proverbial needle in the haystack, in 8 minutes? If so, this might be for you.

Traffic Path (forward): In this approach, you start with the source host, and check out everything between that device and the next. Then, between the 2^nd and 3^rd device, then the next pair, and so on. For example, in the Demo, start with Client1 to the first switch (ASW1), then from ASW1 to DSW1, etc. You don’t have to follow this blindly – e.g., if client1 can ping its default gateway, maybe you can forego the checks to the access layer switch and move on to at least the distribution switch (a layer 3 switch). But you discipline your thinking by taking things a device at a time, source to destination.

Traffic Path (Reverse): Same as the previous, but start at the destination device (from the perspective of the wording in the question.) For example, the Demo TTs all say, “Client 1 cannot ping 209.65.200.241”. In this case, you’d start as close to host 209.65.200.241 as possible, and work back towards Client 1.

Traceroute forward: This approach begins with traceroute (on routers) or tracert on the client. If done from the client, either the traceroute will fail, or not. If the tracert doesn’t fail, you’ve narrowed down the problem quite a bit in very short order. If it fails, the output lists the last router’s IP address. Then, go to that router’s CLI, and start checking the forward route: the route towards the host pinged in the original problem statement. Essentially, this uses the traceroute to find the furthest away router in the forward route for which we think the forward route is working.

Traceroute reverse: This approach focuses on tracert/traceroute, but once the initial such commands are done, the troubleshooting focuses on the reverse route (the route from 209.6.5200.241 towards the clients).

Intuition and Experience: In this one, you look at the scenario, do a few quick commands, and let your intuition kick in. The tracert shows R3 as the last device? You look at the topology, the notes about routing protocols, note that R3 is an ABR, and decide to go poking around OSPF on R3 and R2. Less structure, but it may get you to the right answer more quickly if you are a good troubleshooter.

Other: Is your approach so different that it really doesn’t match any of these? Tell us!

So, weigh in with the poll, give your comments, and maybe you can influence what I’ll write up as Wendell’s personal approach to TSHOOT TT questions. Thanks!