Are you the best network troubleshooter in your store? Maybe you're the person to turn to to solve problems when the network collapses. Maybe you know who that person is, and you know you need them to be part of the team. But in most stores, people know who to turn to when things really fall apart. Today, I'm going to see how network engineers can solve the kinds of problems in the TSHOOT exam, and ask you to evaluate: how do you think your favorite problem solvers would approach questions about problems with TSHOOT?
I have always found it interesting that the problem solving aspect of networking works a bit like a competition. Maybe it's a way to show that you know your stuff. It seems to be the fastest runner, or have the best disadvantage of golf, or know the best new computer tools, be the best in the last game of iPhone, and so on. With problem solving, there is time pressure, greater reward, but a notable disadvantage if it fails. Maybe that's it, more than most of the other job functions for network engineers, it's a place where the competitive nature of each person 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 good job of bringing that competition closer together, much more than the more traditional types of questions. But should you address these TT questions in the same way you would with almost any problem in your own network? Should I study how the engineers in your shop solve network problems? What should you do specifically? Today I will begin to unfold these questions by examining these TT questions and categorizing some general methods. I will include a survey at the end to see what they think is better 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 wording of the scenario implies that "the configuration has changed", it is not always true in real networks, but it is clearly true in TT, because the answer of question 3 of MC always lists the configuration that solves 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 within each TT, it reveals all possible answers, but it is a potentially large number. Figure 6 possible devices that can be configured, 6 technologies per device (MC question 2), 6 different configuration 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 that's what you can see in the demo, there are other things you can guess about the exam, but Cisco does not tell us much about that. So, here is another list of assumptions you could make. They may not all be true, but they have 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. The topology of each TT may be the same, but the initial work configuration may differ. For example, show run in R1 shows different results in 2 different TT, but it can be 100% good in both cases.
The topology of each TT may be the same, but the initial work configuration may differ. For example, show run in R1 shows different results in 2 different TT, but it can 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 see all the settings. Why not? There is a reasonable logic to this approach. The third MC question lists specific configuration commands to add that resolve the problem. Why not start at the last question and show run everywhere? Could you read all the possibly related settings on 6 devices and find the proverbial needle in the haystack, in 8 minutes? If so, this could be for you.
Traffic path (forward): In this approach, start with the source host and verify everything between that device and the next one. Then, between the second and third devices, then the next pair, and so on. For example, in the demo, start with Client1 on the first switch (ASW1), then from ASW1 to DSW1, etc. You do not have to follow this blindly, for example, if the client1 can ping your default gateway, you can forgo the checks on the access layer change and move at least to the distribution switch (a layer 3 switch). ). But you discipline your thinking by taking things one device at a time, from source to destination.
Traffic Path (Reverse): Same as the previous one, but it starts at the target device (from the perspective of the wording in the question). For example, all demonstration TTs say: "Client 1 can not ping 209.65.200.241." In this case, it would start as close as possible to host 209.65.200.241 and return to client 1.
Trace route forward: this approach starts with trace route (on routers) or tracert on the client. If the client does, the trace route will fail or not. If the tracert does not fail, you have reduced the problem in a very short time. If it fails, the output shows the IP address of the last router. Then, go to that router's CLI and start verifying the forward path: the route to the host pinged the original problem statement. Essentially, this uses the route plot to find the most remote router on the forward route for which we believe the forward route is working.
Trace route reverse: this approach focuses on tracert / traceroute, but once the initial commands are executed, the problem resolution focuses on the reverse route (the route from 209.6.5200.241 to the clients).
Intuition and experience: in this, you observe the scenario, do some quick commands and let your intuition activate. Does the tracert show R3 as the last device? You look at the topology, the notes about the routing protocols, keep in mind that R3 is an ABR, and you decide to rummage through OSPF in R3 and R2. Less structure, but it can take you to the correct answer more quickly if you are a good problem solver.
No comments:
Post a Comment