CCNP Troubleshooting and Maintaining Cisco IP Networks (TSHOOT v2.0) Exam Guide
TSHOOT v2.0 validated the ability to troubleshoot and maintain complex Cisco routed and switched enterprise networks, using both technology-specific commands and a systematic troubleshooting process. It was designed for candidates pursuing the former CCNP Routing and Switching path and for network professionals building structured diagnostic skills. The most important decision today is whether you need historical TSHOOT knowledge for an existing certification or should prepare for a current Cisco credential instead, because Cisco has retired both the exam and its associated certification track.
Check whether TSHOOT is still an available exam
TSHOOT 300-135J is retired and is no longer available for certification or recertification. Cisco lists CCNP Routing and Switching as retired on February 23, 2020. Existing certifications based on retired programs remain active only until their individual expiration dates; Cisco does not issue new certifications or provide recertification for a retired certification. Verify your status on Cisco’s current retired-certifications pages before buying training or planning a test appointment.
For a candidate researching an old transcript, this distinction matters. Studying the TSHOOT blueprint can help explain a historical CCNP Routing and Switching result, support internal skills development, or provide a structured troubleshooting curriculum. It cannot create a new CCNP Routing and Switching certification today. If your objective is a current Cisco credential, use the retired exam information as background and compare it with Cisco’s current certification requirements rather than assuming that TSHOOT can be scheduled.
Cisco’s exam-retirement information is the controlling source for availability. The exam page is at https://www.cisco.com/site/us/en/learn/training-certifications/exams/retired.html, and the certification-retirement page is at https://www.cisco.com/site/us/en/learn/training-certifications/certifications/retired.html.
What the exam was designed to validate
The exam focused on planning and performing routine maintenance on complex routed and switched enterprise networks, then isolating faults and applying appropriate fixes. Its objectives required more than recognition of protocol definitions: candidates had to diagnose root causes, design and implement effective solutions, and validate and monitor the resolution. That combination made TSHOOT a practical troubleshooting assessment rather than a narrow command-recall test.
Cisco also described a technology-based and systematic ITIL-compliant approach. In practical terms, a strong candidate would first define the symptom and scope, gather evidence, form a testable hypothesis, change the smallest relevant variable, and confirm that the result solved the reported problem without introducing another one.
The official blueprint identifies the exam as “Troubleshooting and Maintaining Cisco IP Networks v2,” with exam code 300-135J. Cisco also states that passing TSHOOT 300-135J was required for the former CCNP Routing and Switching certification. The blueprint is available at https://www.cisco.com/c/dam/global/ja_jp/assets/learning/exams/docs/300-135-tshoot.pdf.
Who benefits from studying the TSHOOT blueprint
TSHOOT study is most useful for network engineers who need a disciplined method for diagnosing Cisco IOS routing and switching faults, especially in environments where symptoms cross several layers. It is also relevant to candidates reviewing the former CCNP Routing and Switching structure, instructors maintaining legacy course material, and teams that want scenario-based practice without treating a retired exam as a current certification target.
The blueprint suits learners who already understand basic networking and need to connect that knowledge to fault isolation. Someone who cannot yet explain VLAN membership, trunk negotiation, routing-table selection, adjacency formation, or first-hop behavior should build those foundations before attempting complex tickets. Troubleshooting practice exposes missing fundamentals quickly; it does not replace them.
For current-career planning, separate two goals. If the goal is operational ability, the TSHOOT objectives remain a useful checklist of technologies and diagnostic habits. If the goal is certification, stop before scheduling research and identify a current Cisco pathway. Cisco’s later material explains that the old ROUTE, SWITCH, and TSHOOT structure was replaced when Cisco retired the old CCNP Routing and Switching program and introduced CCNP Enterprise with ENCOR and ENARSI.
Read the blueprint as a study-priority map
The published blueprint assigns the largest stated study areas to Layer 2 technologies and Layer 3 technologies, with network fundamentals occupying a smaller stated area. Do not treat those percentages as a complete description of every possible task; use the named domains to decide where your lab time and review effort should go.
Network fundamentals accounted for 5% of the published exam blueprint. Layer 2 technologies accounted for 40% of the published exam blueprint. Layer 3 technologies accounted for 40% of the published exam blueprint. Each percentage should remain attached to its official domain label: network fundamentals, Layer 2 technologies, or Layer 3 technologies.
The blueprint also contains troubleshooting-methodology objectives. Because the stated domain percentages do not by themselves describe every reasoning step, reserve study time for evidence collection, root-cause analysis, solution selection, validation, and monitoring. A candidate who memorizes protocol outputs but cannot explain why one observation rules out a hypothesis is underprepared for the skill the exam was intended to measure.
Turn the weights into a weekly allocation
A practical recommendation is to give the two 40% domains the greatest share of technical lab work, then revisit the 5% network-fundamentals domain as a command and verification toolkit. This is a preparation choice, not an official Cisco schedule. Keep methodology present in every session instead of isolating it as a final reading topic.
For each lab ticket, record the symptom, affected scope, evidence collected, likely fault domain, command or change selected, and validation result. This simple record prevents a common mistake: making several changes at once and then being unable to identify which change restored service.
Do not use the percentages to ignore a technology merely because it appears in a smaller study category. A fundamental tool such as ping, trace, or a conditional debug can determine whether a Layer 2 or Layer 3 hypothesis is worth pursuing.
Build the command-and-evidence foundation
Start with a compact diagnostic toolkit and learn what each command can prove, what it cannot prove, and what observation should follow it. The network-fundamentals objectives specifically included debug, conditional debug, ping, and trace or traceroute, while the broader blueprint required systematic diagnosis rather than indiscriminate command execution.
For reachability problems, define the test source and destination before interpreting the result. A successful ping from a router does not prove that an end host has the same path, source address, policy, or return route. A failed trace does not automatically identify the failed hop because filtering and control-plane behavior can affect displayed results.
Treat debug output as evidence with operational risk. Use conditions where appropriate, establish how the output will be stopped, and capture only information relevant to the hypothesis. In a study lab, practice moving from a broad observation to a narrowly targeted command instead of enabling multiple debugs and searching the resulting noise.
A useful evidence sheet has four columns: observation, implication, next test, and decision. For example, an absent neighbor relationship may justify checking interfaces, addressing, timers, authentication, or filtering, but it does not by itself identify which item is wrong. The next test should distinguish among those possibilities.
Separate symptoms from causes
A user’s inability to reach a server is a symptom, not a diagnosis. Check whether the issue affects one host, one VLAN, one path, or multiple destinations; then test progressively closer dependencies. This prevents a default-route change from being proposed when the actual fault is an access port, trunk, DHCP, or local gateway problem.
Write the suspected fault in one sentence before changing configuration. “The access switch is not forwarding the user VLAN across the trunk” is testable. “The network is broken” is not. After the change, repeat the original test and at least one adjacent test so that the fix is validated rather than assumed.
Master the Layer 2 troubleshooting sequence
Layer 2 work should progress from physical and management visibility to forwarding behavior. The published objectives covered switch management, CDP and LLDP, UDLD, VLANs, trunking, EtherChannel, spanning tree, SPAN or RSPAN, and StackWise. Study these as connected failure domains, because a single end-host symptom can arise from several of them.
Begin by confirming the affected interface, link state, speed or duplex information where relevant, and the identity of connected devices. Use CDP or LLDP evidence to test whether the expected neighbor is present. Then verify VLAN existence and assignment, trunk membership and allowed VLAN behavior, and whether the path is blocked by spanning tree or affected by an EtherChannel inconsistency.
For a VLAN-specific ticket, compare the intended design with the actual path. Ask whether the endpoint is in the expected VLAN, whether that VLAN is carried on every required trunk, and whether the forwarding topology selects the expected links. Avoid changing spanning-tree priorities or trunk settings merely because a topology looks unusual; first establish the intended outcome and the exact discrepancy.
Include maintenance-oriented exercises. Practice identifying stale or unexpected neighbors, investigating an unidirectional-link symptom with UDLD concepts, checking EtherChannel consistency, and using SPAN or RSPAN as an observation technique. StackWise should be studied as a platform and forwarding-behavior topic, not as a memorization list detached from the reported symptom.
Cisco’s TSHOOT Learning Labs page lists practice areas including maintenance and monitoring, troubleshooting tools, switch-based features, and complex environments. It is available at https://www.cisco.com/E-Learning/bulk/public/cln/store/topologies/tshoot/TSHOOT_Lab.html.
Layer 2 mistakes that waste study time
The most common preparation error is checking only the access port. A host may have a correct access assignment while the VLAN is absent from a trunk, filtered by an allowed-list change, blocked by an unexpected spanning-tree result, or disrupted by a port-channel mismatch. Build diagrams that show the entire forwarding path and annotate the expected VLAN at each hop.
Another mistake is treating every down interface as a physical fault. Administrative state, err-disabled conditions, negotiation, port-security behavior, and upstream configuration can produce different evidence. The goal is not to collect every possible command; it is to choose the smallest set that distinguishes the likely causes.
Work through the Layer 3 fault domains
Layer 3 technologies accounted for 40% of the published exam blueprint, and the objectives covered a broad range of routing and forwarding conditions. Build study cases around addressing, route selection, control-plane relationships, policy, and redistribution rather than studying each protocol in isolation.
The named Layer 3 objectives included IPv4 and IPv6 addressing, DHCP, static and default routing, VRF Lite, filtering, redistribution, policy-based routing, RIP, EIGRP, OSPF, and BGP troubleshooting. For each topic, identify the expected local state, the expected learned or configured state, and the forwarding result that should follow.
For addressing and DHCP cases, verify the endpoint’s address, mask or prefix, default gateway, and relevant lease or relay path before investigating dynamic routing. For static and default-route cases, distinguish absence of a route from selection of an unexpected route. A route can be present yet unusable because the next hop, interface, recursion, or return path is wrong.
For EIGRP, OSPF, RIP, and BGP, practice a layered sequence: interface and address, neighbor or session state, learned information, route installation, and packet forwarding. Do not stop when a protocol adjacency is established. A healthy relationship does not prove that the desired prefix is being advertised, accepted, installed, or used.
VRF Lite, filtering, policy-based routing, and redistribution deserve dedicated scenarios because they can make a locally correct view misleading. Confirm the routing context, inspect the relevant policy or filter, and follow the route from source information through selection to forwarding. Redistribution exercises should include identifying where a prefix enters the wrong protocol or loses the attributes needed for the intended path.
Use IPv4 and IPv6 as separate hypotheses
A dual-stack symptom should not be reduced to “the network works” or “the network fails.” Test IPv4 and IPv6 independently, record their paths, and check whether the reported application prefers one family. A correct IPv4 route does not establish that IPv6 addressing, neighbor behavior, routing, filtering, or return traffic is correct.
When a route appears absent, first confirm that you are inspecting the correct device and routing table. VRF Lite and policy-based routing can make two commands from the same physical router produce different answers depending on context and traffic classification. This is why topology awareness must accompany command knowledge.
Practice methodology, not just protocols
A reliable TSHOOT-style workflow is: clarify the ticket, define scope, collect non-destructive evidence, localize the fault, test one hypothesis, apply the smallest effective correction, and validate both the original service and the surrounding network. This sequence directly reflects the objectives for root-cause diagnosis, solution implementation, and validation and monitoring.
Start each scenario by restating the expected behavior in concrete terms: source, destination, protocol or service, direction, and time or scope if known. Identify what still works. A user unable to reach one server is a different problem from an entire VLAN losing all destinations, even if both reports say “no access.”
Use the OSI model as a navigation aid, not as a rigid ritual. A Layer 3-looking failure may be caused by a missing VLAN, while an apparent routing problem may be a filtering or policy issue. Move between layers when evidence requires it, but document why you moved.
After a fix, repeat the failed test, test a nearby control path, and check for unintended effects. Monitoring is part of resolution: a configuration that restores one ping but causes a routing loop, asymmetric path, or broader outage is not an effective solution. In a lab, record the expected post-change state so validation has a clear standard.
A ticket template for every lab
Use a repeatable ticket form with these fields: reported symptom, affected source and destination, scope, baseline behavior, topology segment, evidence, hypothesis, change, validation, and rollback. The form turns troubleshooting into a sequence of decisions and makes it easier to review whether you guessed, tested, or actually demonstrated the cause.
Add a confidence note after each major observation. For example, “the route is present” is high-confidence evidence about the inspected table, but it is not evidence that the packet uses that route. This distinction trains you to avoid conclusions that exceed the command’s scope.
Create a lab that forces end-to-end reasoning
Use a topology containing access switching, trunks, a routed core, multiple routing protocols, and at least one policy or routing-context boundary. Introduce one fault at a time initially, then combine faults only after you can isolate single-domain issues. The purpose is to reproduce the reasoning pattern, not to imitate secret or live exam content.
Cisco publicly described TSHOOT practice as involving complex network topologies and trouble tickets. Its Learning Labs page lists maintenance and monitoring, troubleshooting tools, switch-based features, Layer 3 switching and first-hop redundancy, EIGRP, OSPF, route redistribution, BGP, network security, and complex environments as practice areas. Use those categories to diversify cases rather than repeating simple ping failures.
Design each ticket with an expected answer path but do not make the fault obvious from the ticket wording. Examples include a user VLAN missing from one trunk, an EtherChannel member with inconsistent configuration, an OSPF relationship that forms but does not provide the required route, a redistribution policy that rejects a prefix, or a VRF mismatch that sends a lookup to the wrong table. These are lab-design recommendations, not claims about current exam items.
Keep a clean baseline configuration. Before introducing a fault, save the intended state and write down the expected neighbors, VLAN path, routing entries, and test results. After the exercise, restore the baseline and explain the failure in plain language. A lab that cannot be reset encourages accidental workarounds instead of repeatable diagnosis.
The official TSHOOT lab resource is https://www.cisco.com/E-Learning/bulk/public/cln/store/topologies/tshoot/TSHOOT_Lab.html. Cisco’s later troubleshooting article also describes scenario-based trouble-ticket practice and a complex IPv4 and IPv6 network, which can help you think in terms of cases rather than disconnected command drills.
A practical four-stage study roadmap
Study in stages: establish foundations, isolate Layer 2 faults, isolate Layer 3 faults, then combine technologies in timed ticket sessions. Move forward only when you can explain the evidence and validation for a fix. Because TSHOOT is retired, adapt the final stage to your real objective: historical knowledge and lab competence, or preparation for a current Cisco certification.
Stage one: map the blueprint. Create a checklist for network fundamentals, troubleshooting methodology, Layer 2 technologies, Layer 3 technologies, maintenance, and monitoring. Review interface behavior, VLANs, trunking, routing tables, protocol adjacencies, and basic verification commands. Produce a small baseline topology and document normal output before introducing faults.
Stage two: work through Layer 2 cases. Start with switch visibility and neighbor discovery, then progress through VLANs, trunks, EtherChannel, spanning tree, UDLD, SPAN or RSPAN, and StackWise-related concepts. Keep the source and destination visible in every case so that you connect a control-plane observation to an end-to-end forwarding result.
Stage three: work through Layer 3 cases. Separate addressing and DHCP from static and default routing, then add dynamic routing. After that, introduce VRF Lite, filtering, policy-based routing, redistribution, and BGP. For every scenario, inspect not only whether a protocol is active but also whether the intended prefix reaches the forwarding decision.
Stage four: combine faults and review decisions. Use a ticket queue, set a personal time budget, and record the first hypothesis, the evidence that supported or rejected it, and the validation result. Do not measure readiness by how quickly you remember a command. Measure it by whether you can localize a fault without making unrelated changes and explain why the correction is safe.
At the end of each stage, revisit errors by category: misunderstood symptom, incomplete topology, wrong command context, incorrect protocol interpretation, unsafe change, or incomplete validation. This classification tells you what to fix in your study method. Re-reading a routing chapter will not solve a recurring failure to check the return path.
Understand the historical exam delivery facts
The official blueprint specified 15–25 questions and a 120-minute time limit for 300-135J. Those details describe the published exam version, not a currently schedulable test. Since Cisco identifies the exam as retired, do not use the old format as evidence that a testing provider can deliver it now.
The available Cisco blueprint is the right source for historical scope and format. It should not be treated as a substitute for a current exam page, current registration instructions, or current delivery policy. For any present-day certification decision, consult Cisco’s live certification and exam information and confirm that the exam is active before purchasing preparation resources.
Avoid inferring unverified details about price, delivery location, languages, scoring, prerequisites, or question behavior. The supplied official research does not establish current values for those items, and the retirement status makes historical assumptions especially risky. Concentrate your planning on the skills and on the credential that is actually available to you.
Avoid preparation traps that create false confidence
The biggest trap is preparing to memorize answers for a retired exam. TSHOOT was built around troubleshooting and maintenance objectives, so the durable value lies in interpreting evidence, locating a fault, implementing a controlled fix, and validating service. Practice materials should support those behaviors rather than replace them.
Do not treat a single successful ping as proof of end-to-end health. Define the source, destination, path, protocol family, and direction. Check the return path and any policy or routing-context difference before closing the ticket.
Do not enable every debug at once. Excess output hides the signal and can distract from the actual scope of the problem. Choose a command because it will confirm or reject a specific hypothesis, and know how to stop or limit diagnostic output.
Do not change several devices before testing the first change. Multiple simultaneous edits destroy causality and make rollback difficult. Keep a change log, save the pre-change state, and validate after each controlled adjustment.
Do not confuse an established neighbor with a usable route. Check whether the prefix is advertised, accepted, installed, selected, and forwarded as expected. The same discipline applies to VLANs: a trunk being up does not prove that the required VLAN crosses it.
Do not use blueprint percentages as a reason to skip methodology. Network fundamentals accounted for 5% of the published exam blueprint, Layer 2 technologies accounted for 40% of the published exam blueprint, and Layer 3 technologies accounted for 40% of the published exam blueprint; none of those labels removes the need to reason through a ticket systematically.
Finally, do not confuse a legacy study guide with a current certification plan. Confirm retirement status first, then decide whether the TSHOOT material serves a skills goal, a historical review, or a transition into current Cisco Enterprise preparation.
Choose your next action
Begin by checking whether you need a historical understanding of TSHOOT or a current Cisco certification. If TSHOOT is a skills objective, download the official blueprint, build a baseline lab, and start a ticket log. If certification is the objective, stop researching TSHOOT scheduling and identify the current Cisco exam that matches your role and target credential.
For a skills-focused plan, spend the first session inventorying the blueprint topics and the second creating normal-state evidence for your lab. Then introduce one Layer 2 fault, one Layer 3 fault, and one methodology exercise. Review not only whether the service was restored but whether your evidence justified the change.
For a transition plan, use the TSHOOT domains to identify gaps in routing, switching, and structured diagnosis, then compare those gaps against the current Cisco exam blueprint. Cisco’s blog notes that ENARSI includes multiple troubleshooting tasks while also serving as the replacement for ROUTE, so do not assume that one legacy exam maps perfectly to one current exam.
Use Cisco’s official pages for the final availability decision and the official TSHOOT PDF for historical objectives. The useful outcome of this guide is not an unsupported promise of passing; it is a clear choice between legacy skills practice and preparation for a currently available certification.
Conclusion
TSHOOT v2.0 remains a valuable model for learning how to investigate Cisco routing and switching failures, but it is not a current certification exam. Its published objectives emphasize evidence, root-cause analysis, controlled remediation, and validation across substantial Layer 2 and Layer 3 domains. Confirm retirement status before scheduling anything, then use the blueprint deliberately: build a baseline, practice complete ticket investigations, document every decision, and select a current Cisco certification separately when a credential is required.
