I took and did not pass my TSHOOT exam last week. Bummer. I had not studied specifically for the test very hard. In my mind I had already started thinking about the CCIE written and even started doing the “easy” CCIE labs. I have a long way to go as the best I could do was a 2 hour CCIE lab in 5 hours. That was the best. There were a few that took a couple of days to complete. So when I went to take my test I felt I had a good chance at passing but was by no means assured of a passing grade.
Without breaking the NDA here are some of my thoughts.
How I prepared for the last test:
I went and reviewed this blog. Reading my own writing and doing the commands on the lab routers refreshed some of the old memories.
I configured the TSHOOT topology from scratch again. Then I had my coworker go through and randomly break things. He would log in and break it, give me a hint and then I would go in and fix the configuration. This was easy, possibly too easy, and it was slow. We would only do this once a day and I wouldn’t worry if it took 15 or 20 minutes, I was just playing around in the lab before I went home. That all changed during the test. Because I had configured my lab I knew the configs cold, I had configured it all and I could spot typos or simple errors quickly by just viewing the running configuration. That is not the case during the test.
How I am preparing now:
I am not concerned about theory. I have been studying TCP/IP Volume I with the CCIE written in mind and am on the last chapter.
Over the weekend I made 15 different configurations with errors. I don’t even remember what each ticket does, just that it creates an error somewhere in the lab. I saved them to the flash of each switch or router and wrote the following script. It randomly selects a trouble ticket to load, then calls the testlab update expect script, tlue, and loads the bad configuration on the device.
At this point I am not concerned with the actual error. I did not have a process to follow last week during the test and was not consistent in my troubleshooting process. By being able to load a number of errors in quick succession I will be able to troubleshoot a number of errors using a consistent process. My goal is to bombard myself with random errors like I saw in the test and get my troubleshooting process down pat.
The other key here is to rely on mastering a few commands that tell me the most about the situation on a router or switch and not on reading router configurations to troubleshoot. I feel that was my weakness in my previous studies and became my weakness during the test.
Below is the script that loads random configurations with errors in the lab.
# 2010-11-15 Jud Bishop
# tl-ticket
# This script randomly picks a ticket and loads the configuration from flash.
I=$((RANDOM%15+1))
#1: DSW1
#2: ASW1
#3: ASW1
#4: DSW2
#5: R3
#6: R4
#7: R2
#8: R1
#9: R1
#10: R2
#11: R2 -- IPv6
#12: DSW1
#13: R4
#14: R4 -- IPv6
#15: R4
case $I in
1 )
tlue DSW1 replace ticket1.cfg
;;
2 )
tlue ASW1 replace ticket2.cfg
;;
3 )
tlue ASW1 replace ticket3.cfg
;;
4 )
tlue DSW2 replace ticket4.cfg
;;
5 )
tlue R3 replace ticket5.cfg
;;
6 )
tlue R4 replace ticket6.cfg
;;
7 )
tlue R2 replace ticket7.cfg
;;
8 )
tlue R1 replace ticket8.cfg
;;
9 )
tlue R1 replace ticket9.cfg
;;
10 )
tlue R2 replace ticket10.cfg
;;
11 )
tlue R2 replace ticket11.cfg
;;
12 )
tlue DSW1 replace ticket12.cfg
;;
13 )
tlue R4 replace ticket13.cfg
;;
14 )
tlue R4 replace ticket14.cfg
;;
15 )
tlue R4 replace ticket15.cfg
;;
esac