Wendell's Approach to Attacking TSHOOT Exam Trouble Tickets

Part of a Series on how to Approach the TSHOOT Exam

Time for me to come clean about the TSHOOT Beta exam. It kinda ticked me off. Today I'm going to talk about why it made me mad, but more importantly, I'll describe what I intend to use as my strategy when I go back to take it again, and beat the exam. And I welcome any and all comments about how to improve the process.

As I mentioned a few weeks ago, I didn't finish all the tickets when I took the TSHOOT Beta, for the wide variety of reasons, including several reasons that won't apply to anyone whose sole goal is passing the test. However, if I had shown up with a goal of passing, ignoring all other goals, it would still have been a challenge to finish on time, while also being confident of my answers. I did not expect to have that much trouble, so it felt like TSHOOT 1, Wendell 0. And it made me mad, and I want to beat this exam, and beat it badly, next time around!

First, here's a rundown of what surprised me that had some impact on how well and how quickly I could do the TT questions.

I didn't trust myself. Why? Lack of reps actually troubleshooting a problem, and a tricky first TT question. EG, I often started with a traceroute, and then immediately went to the last router listed in that output - pretty easy. Unfortunately, my first TT was a bit of a corner case, where the trace wasn't that helpful. Result? I repeated commands, went around in a circle a few times, got frustrated, moved on to another question. Then I started doubting the process, and just looking at what popped to mind at the time.

Some commands I use frequently were not supported by the Exam's simulator. Result? It took me a little more time to choose how to proceed, either by scrolling a lot, looking at the config, thinking of other show command options. Admittedly, I chose to not worry about finishing the exam, instead focusing on learning about this new exam. I even spent time just looking to see what commands were not supported. Some samples: show ip route address (shows the route this route matches for the address), show ip arp, show frame-relay map, (switch) show portchannel, (switch) show int status, no piping, show ipv6 int brief.

I relied on intuition a little too much. Why was that a problem? Well, it's been a long tine since I actually did troubleshooting regularly in a real network. So, while my intuition sometimes led to the right answer, it wasn't as quick as I thought it needed to be. Intuition worked much better for topics I knew best. (So maybe that's not really intuition, but real insight?)

I didn't trust the Sim to be 100% accurate. That was my mistake, in retrospect. I think you have to assume the output you see is correct. I'm as sure as I can be, without having it confirmed by Cisco, that they did these questions exactly as shown on real gear, and that they generate the output in the TT questions based on such tests. If I had been trying to finish on time, I wouldn't have spent so much time looking for inconsistencies. (For those who don't recall, when I took the Beta, I thought my exam was badly busted, and spent almost an hour just plying with the interface. It was not busted, by the way.). But I will make a conscious choice to trust the output, but maybe verify some facts two ways instead of one.

The choice of when to go config trolling threw me off a little. When did I stop doing show commands other than show run, and when to jump to show run? I looked at many configs on devices that were configured perfectly. It was clear I needed to think beforehand about how far to isolate the problem before staring at configs.

Those are some of the problems I encountered with the exam. So, how to improve, do better, and be ready to do well next time? Next page over, I'll describe my plan for next time around:

Here's my plan philosophy, before exam tasks, and exam-day tasks:


Isolate the problem by isolating the problem to a subset of devices, and subset of technologies, and then go config trolling.

Before the Exam:

1)    pre-determine the technologies you want to isolate before show run

2)    Script the first 2-4 commands that make you think that's the technology with the problem

3)    Double check all commands you use when practicing versus the commands that the Cisco demo TT questions support

4)    As an exercise, when practicing config, unconfig something, and think about what the show commands should look like now, before doing the show commands.

Exam day:

Follow the script, note the technology and possible problematic devices after doing the scripted commands, and then alternately examine configs and other show commands.

The general idea is a compromise. It's too much to read to simply do show run and every device and look at the whole config. You might figure out the answer, but it'll probably take too long. But once you narrow the problem down to 2-3 devices, and 1 technology topic, so you can concentrate on certain parts of the config, then I think the missing/errant config will jump out at you.

For instance, say there's a missing missing route, so you know there's some control plane issue with IPv4, and the route is missing on router R3, and the route would point to R2, and then to R1. So, you've got IPv4 control plane, 3 devices, so look at the configs. But, I wouldn't abandon all other show commands immediately, but it saves you looking at everything in the config. And more obviously, isolating to a small number of devices means that there are fewer configs to review.

Practically speaking, here's my working list of technology topics.

  1. Control plane for destination (forward route)
  2. Control plane for source (reverse route)
  3. Data plane (undecided on whether I'd care about route direction here)
  4. IPv6
  5. DHCP
  6. Default Gateway connectivity (layer 3)
  7. Layer 1 and 2 LAN connectivity
  8. Layer 1 and 2 WAN

For the script, take this as a sample for TTs where the problem says "client1 can't ping". I'd go with:

  1. Client1: tracert
  2. If at least 1 router is listed, go to last router in output: show ip route, look for matching route for
    1. If no routes match the destination, a control plane problem exists, and it exists on the current router, or a router closer to the destination. So, you've isolated to a subset of routers, and that it's a control plane problem, for a specific destination ( in this case).
    2. Else if a matching route exists, go to next router in the forward route, and check reverse route (back to client1)
      1. If no route exists, a control plane problem exists for the reverse route. Check configs on this router, and all other routers nearer to client1. And you've isolated the problem to one or a few routers, again control plane, again for a specific destination (client1 in this case).
      2. If a route exists, then pursue as a data plane forwarding problem. Be suspicious of false negatives (things that cause a tracert failure, but not a ping failure from client1 to If you get to this part of the script, you have isolated problem as likely existing on the two routers examined in the last few steps, but not 100% for sure.

So, the idea is that I'd plan to use this script, practice it, and do it on automatic. It's kinda like an NFL team that scripts the first so many plays in the game, no matter what the earlier plays did for them. Once completed, I wouldn't be so worried about a script, but I'd alternate between configs and other show commands.

For instance, if the script ended up implying a control plane problem, I'd probably start with a quick show run, but also I'd check neighbors and topology tables, eg, show ip eigrp neighbors and show ip eigrp topo prefix/length. If a neighbor is missing, there's a short list of things to check. If the neighbor's there, but no topo table entry for the route, then the downstream neighbor is not advertising it. If the topo table entry is there, but it's already been determined as not in the routing table, then check the small set of things that prevent the route from getting into the routing table.

I'd need to expand my script to be complete. The script above handles cases of IPv4, with at least one router listed in the tracert output. That implies that the VLAN works, because there's connectivity from client1 to its default gateway, and back. IPv6 problems will be relatively obvious from the problem statement. It might be worth developing a few steps in a script for IPv6. But the trickier part is how to isolate problems in the 2nd half of my list of technologies. We can work a script collectively on that branch for those who are interested. If the tracert on client1 lists no routers, how would you isolate the problem further? How to determine if its DHCP failure or not? How to tell if it's a connectivity problem to the DHCP server, or specific to DHCP? How to tell if its layer 3 to the default gateway, particularly with HSRP/VRRP/GLBP configured? Or whether its one of many layer 2 issues on the LAN?

So, tell me what you think. Would you bother scripting the first few commands? What holes do you see in my layer 3 script? Will you practice a script before taking the exam? If you like some of these ideas, how would you refine? What steps would you take when the tracert doesn't even list the default router? Fire away!

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT