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 lab.
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 lab.
Below is the script that loads random configurations with errors in the lab.
#!/bin/bash # 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: ASW1 #5: R4 #6: R4 #7: R2 #8: R1 #9: R1 #10: R1 #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