TSHOOT Journey & Preparation

I'll sit the TSHOOT exam this friday and i built a list of the common problems i could face in the exam and based on the Boson ticketing system, i will share my experience and what strategy i plan to use for the exam.

Layer 1 (down/down)

sh ip int br (Check for UP/*)
sh int X/X (Check for errdisable)
sh port-s or sh port s
sh run int X/X
Check the other side state
1. (For frame-relay, compare PVC's VS Interface)

Layer 2 (up/down)

sh vlan br
1. Access VLAN's in right slot
2. Trunk interfaces transparent
sh int trunk
1. Allowed, pruned, active
sh run int X/X
1. Port Security
2. PACL (Mac access-lists)
3. Encapsulation & Switchport mode
4. Frame-relay
sh ether br & sh run
1. Check for etherchannel configuration
2. Check for negotiation and interface assignment

Layer 3 (up/up)

Combination of PING/Traceroute
sh ip route
Check VLAN access-map and ip access-lists
Check ip routing is enabled for L3 switches

Routing problems (EIGRP)

sh ip eigrp neigh
sh run int X/X
1. Check for weird summary
2. Check for Authentication parameters
sh run | inc router
1. Check for AS number
2. Check for auto-summary
3. Check for all networks
4. Check for redistribute static
5. Check for metric weights
6. Check if default-metric is present if redistributing OSPF

Routing problems (OSPFv2)

sh ip ospf neigh
sh run int X/X
1. Check for weird hello interval
2. Check for Authentication parameters
sh run | inc router
1. Check for areas number
2. Check for area type mismatch
3. Check for all networks
4. Check for default inf orig always
5. Check for "subnets" keyword if redistributing EIGRP

Routing problems (BGP)

Check neighbor IP and remote-as
Check network statement match an existing route in the routing table

Routing problems (OSPFv3)

Check ipv6 unicast-routing is enabled
Check ipv6 interface declarations of both sides

Redistribution

Check EIGRP default-metric statement
Check OSPF subnets keyword
Check route-map name
Check match statement for correct ACL
Check ACL statements
Implicit permit statement of a route-map isn't important

HSRP

Check standby group & ip
Check priority VS higher IP address (default 100)
Check prempt
Check track decrement (default 10)

NAT

Check ip nat inside/outside for correct interfaces
Check ip nat pool
Check nat access-list
Check for overload missing

GRE Tunnel

Default mode is gre ip
Check tunnel source match egress ipv4 interface
Check tunnel dest match ipv4 neighbor
Check neighbor tunnel mode
Check for ipv6 ip address applied to tunnel interface

DHCP

Check SVI's or Routed ports helper-address
Check excluded-address pool
Check network and default-router params

The hint i found to memorize the logging severity

Logging messages shortcut from low-to-high severity (DIN-WECA-E)
1. Emergencies
2. Alerts
3. Critical
4. Errors
5. Warnings
6. Notifications
7. Informational
8. Debugging

I hope i'm not missing much and maybe this could be helpful for someone else. If you have something i could add to this pattern, please post it !
I wonder if i can abort the tickets in the exam ?
So when stuck, i guess it is a bit helpful to verify what you suspect being the problem from another ticket configuration.

If so, i think i will take this approach mixed to bottom-up method from client pc to L3 Switches and divide-and-conquer from L3 Switches through server.

Cheers

Find more posts tagged with

Comments

Chris_

You can abort the tickets in the exam. Kevin Wallace was talking about it ina web cast. So, once you narrow it down to a device and think you know the problem, you can abort, then check the 'good' config on another ticket. Cisco have allowed this as they see checking baseline configs as a valid troueshooting method.
I see google as a valid Troubleshooting method, wonder if it's allowed

Akiii

I'm taking the exam tomorrow, check out this

TSHOOT Demo Item

stuh84

You may be overthinking it a bit to be honest.

My strategy was simple, if the question says "the user can't reach the web server", just ping from each device starting at the web server, and when the pings dont work, then its either that device or the device upstream that is causing the problem.

If you've got the knowledge from the routing and switching exams and labbed them up enough, the TSHOOT should be a piece of cake.

chmorin

Still, it is nice to see a collection of basic steps to further narrow down the problem. It's not like he can bring this in with him during the test, he was just writing down for a reference. I think that is a good thing to do and have.

stuh84

This is true. I just worry a lot of people look at the TSHOOT as if its going to be this massive mountain to climb, only to find they either spent weeks/months preparing for it when it can really be done very soon after doing the other two CCNP exams, or overcomplicating it to the point were simple methods to check get missed.

chmorin

stuh84 wrote: »

This is true. I just worry a lot of people look at the TSHOOT as if its going to be this massive mountain to climb, only to find they either spent weeks/months preparing for it when it can really be done very soon after doing the other two CCNP exams, or overcomplicating it to the point were simple methods to check get missed.

That is a great point to get out there. If you go into these exams expecting all worse-case complex scenarios then you are likely to miss the simple issue that could of been fixed and found in minutes.

kryolla

just to clarify for layer 2 you can have an up/up state and still have issues, I would also add spanning tree issues for layer 2 check

tomaifauchai

thanks for the comments, i've built it mainly to do some review before the exam since it is easy to forget about details and i'm the kinda guy who love to have a structured approach before doing something because i'm easily distracted :P

@Kryolla
For the Layer 2 up/up, are you referring at a working connectivity but problems at upper layers or something i couldn't know about the blueprint? I'm thinking about things like duplex mismatch or native vlan mismatch
It could be nice if you have some examples and thanks for the spanning-tree

nicklauscombs

whats nice is if you study the topology before going in its pretty easy to narrow down what they possibly could ask you and where the problem lies.

good luck!

Ryan82

Pretty much echoing what Stuh84 said, but one small thing that I did first was on the PC client I would do an ipconfig to ensure it has received an IP address from the DHCP server and if so then start pings to the distant end and stepping it back. If not, you know you need to hone in on something between your client pc and the dhcp server.

Remember this exam is about paying attention to the details.

If you can't figure out a ticket in 10 minutes move on to the next one and come back when you have knocked out the easy ones.

Good luck

okplaya

Good luck today! Although I have no Cisco certifications yet, I do "TSHOOT" every day at work. I think you have a pretty good foundation and should be able to discover most issues with your approach. My only advice, while probably too late, is to remember the basics. Too often I find myself delving way too deep on tickets without checking the basics.

tomaifauchai

CCNP Certified !
642-832 -> PASS!!

The exam was a very good experience overall but there was a bug on 1 ticket. Without disclosing what was it, i can say you can find a way to "bypass" this bug by checking if the options needed are elsewhere on the topology.

I'd like to thank all the TE community for the great infos and great people in the forums. I'm currently from 1 exam away to start my CCIE quest and it's fun to write and read here everydays!

billyr

kryolla wrote: »

just to clarify for layer 2 you can have an up/up state and still have issues, I would also add spanning tree issues for layer 2 check

Good point. For layer 1 a fast ethernet port will also show as UP/Down even when no cable is connected as long as you have the no shut command on the interface.

hermeszdata

tomaifauchai wrote: »

CCNP Certified !
642-832 -> PASS!!

The exam was a very good experience overall but there was a bug on 1 ticket. Without disclosing what was it, i can say you can find a way to "bypass" this bug by checking if the options needed are elsewhere on the topology.

I'd like to thank all the TE community for the great infos and great people in the forums. I'm currently from 1 exam to start my CCIE quest and it's fun to write and read here everydays!

Congrats on the pass!

I know I am a bit late chiming in on the original content, but I would like to offer this general troubleshooting tip. Having spent many years as a electronics technicial/engineer doing bench repairs and prototyping of circuits, I adopted a Divide and Conquer approach to troubleshooting. I have found this approach the fastest way to a solution. as applied to network troubleshooting the steps are as follows:

Check the source host config to insure correct.
Ping Destination IP.
If Ping Fails , tracert from source to destination to get indication of point of failure.
Ping path midpoint IP halfway between source and destination.
This is where we branch:
- If pass, ping ip address between midpoint and destination and repeat as necessary.
- If fail, ping ip address betwen source and midpoint IP and repeat as necessary.

Basically, the idea is to start by cutting the topology in half to try to isolate which half is the source of the problem. Then cutting the halves in half and repeating until we narrow down the device causing the problem.
Pings/tracert are cheap from a time cost standpoint, and there is always the possibility that the problem is on the first connected device, i.e. a switch vlan/trunk config issue. However, from a real world standpoint, trouble tickets arise as a result of a failure of a formally functional network.

mikej412

tomaifauchai wrote: »

PASS!!

Congratulations on the PASS!!

Congratulations on the CCNP!!

*BB*

Congrats!!

tomaifauchai

hermeszdata wrote: »

Congrats on the pass!
This is where we branch:
If pass, ping ip address between midpoint and destination and repeat as necessary.

If fail, ping ip address betwen source and midpoint IP and repeat as necessary.

Basically, the idea is to start by cutting the topology in half to try to isolate which half is the source of the problem.

Quality! So this is a full Divide-and-conquer method.
When i get into a newer device, i always ping the neighbor device facing the cloud direction so then i'm sure layer 3 is working. I go then directly to sh ip route!
I will bring your method in my handbag!

NOC-Ninja

tomaifauchai wrote: »

CCNP Certified !
642-832 -> PASS!!

The exam was a very good experience overall but there was a bug on 1 ticket. Without disclosing what was it, i can say you can find a way to "bypass" this bug by checking if the options needed are elsewhere on the topology.

I'd like to thank all the TE community for the great infos and great people in the forums. I'm currently from 1 exam away to start my CCIE quest and it's fun to write and read here everydays!

How long did it took you to study
ROUTE?
SWITCH?
and
TSHOOT?

tomaifauchai

I took 2 months to study & lab ROUTE
1 month for switch
2 weeks for tshoot (Skipped most of the book)

But i am a full time student with plenty of time and i can pass around 15 to 20 hours per week studying Cisco. ( Starting MPLS now!! )
I usually take 1 month per exam (70-85 hours) and for the whole CCNP i would say i've spent 200 hours of study without any doubts

Quick Links

All Categories
Recent Posts
Activity
Unanswered
Groups
Best Of