This morning I got my lab results and it looks like I’m not quite there yet. I failed the exam. It was close, but it wasn’t good enough. In this post, I will be going over my first CCIE R&S lab experience and what led to my failure.
Sunday morning I traveled to Toronto for my first lab attempt. My hotel was right in front of the Cisco testing center so I wasn’t too worried about getting there late the next morning. From the moment I stepped in that hotel, I knew something was shady. A bunch of people were smoking in front of the “Prohibited to smoke within 9 meters” sign, the elevator was half broken and my rooms phone wouldn’t dial-out. Oh well, I guess it was good enough for the money I paid. I went to bed pretty late that night as I wanted to be able to sleep without waking up from nerves. I set up my alarm for 7:45AM. Unfortunately, I was awoken at 6:15 AM by the hotels fire alarm. I woke up in panic and started getting dressed. By the time I was out the door, the alarm stopped. Needless to say, I didn’t go back to sleep after that.
I arrived at the testing center 30 minutes before the starting time. There was already another candidate there. He was also going for the CCIE R&S. There was only 4 CCIE candidates that day at the testing center. Three of them were R&S and one was SP. The proctor explained the rules and said we would start in 10 minutes. I was pretty annoyed as my chair wouldn’t stay in the upwards position. I know this sounds stupid but sitting for 8 hours in an uncomfortable chair makes a big difference.
I encountered my first problem before the exam even started. I turned on the screen at the Proctor’s signal and I was greeted with the message “Windows is now shutting down…”. The same happened to one of the other CCIE candidate beside me. Once the computer started, the screen resolution was set to 800X600. It took the proctor 7 minutes to fix it, restart my computer and get me logged in. This is when I started the TSHOOT section.
The TSHOOT section had many 2 pointers questions and only a couple of 4 pointers. The first question was really easy but for some reason the switch wasn’t behaving as expected. I knew what the problem might be from the symptoms I was getting but the interface where the problem should have been at was not showing any signs of misconfiguration like the other show commands were telling me. I spent around 10 minutes on this ticket and decided to reload the switch and come back to it later. When I came back to this problem later on I noticed that the “show run interface x/x” had a different output than the global “show run” command. Very weird… I entered the proper configuration commands at the interface level and verified with the “show run” instead of “show run interface x/x”. I could now establish reachability as requested by the ticket.
The rest of TSHOOT was fairly hard, several faults and the topology was complex and misleading at times. I will be honest, I probably spent half of my time trying to understand the topology and how all the technologies interacted with each other. At the end of the TSHOOT, I had fixed all faults but because of lack of time I didn’t fix it the way Cisco wanted me to. Let me explain. There are several ways you can fix a problem in TSHOOT but not all of them are the right one. For example, if there’s an ACL blocking a certain protocol you can either:
- Remove the access-group on interface
- Add a “Permit any any” on the ACL
- Modify the ACL to make the protocol and its dependencies work
Obviously the way Cisco wants you to fix it is to ” Modify the ACL to make the protocol and its dependencies work”. Due to lack of time, I couldn’t fix the tickets like Cisco wanted me to. At the time, I thought the way I did it would be good enough but now I know it wasn’t.
Diagnostic was pretty easy. There was a lot to read but as soon as I had finished reading the trouble tickets I had a good idea of what the problem was. I have nothing else to say about this section, I passed it and any CCNP should be able to do the same.
The configuration section was very long and the topology was very large. I understood all the core stuff but it became clear that I might run out of time if I didn’t go fast. We stopped for lunch and at that point I had completed half of the L3 connectivity parts. For lunch we had 2 slices of Pizza. I wasn’t really hungry but damn that was the most expensive 2 slices of Pizza I’ve ever had.
After lunch, I finished all the other parts of CONFIG except for one. I couldn’t understand what was the problem for the entire exam. I probably spent 30-45 minutes on this problem trying to figure it out. This part was critical as it was breaking 3 other sections of the exam. Now that I got my lab results, I know I failed because of this. I will have to lab it up to reproduce the problem but at this point I’m thinking there was a bug with the SP device that I didn’t have control over and it probably needed to be reloaded.
I believe I encountered several bugs during the exam (probably due to IOU memory problems) and had to reload the devices to fix them. Also, access to devices was very slow. I had to click and wait up to 15 seconds for the console to pop up. The DOC-CD was slow and sent me to “This page cannot be found” several times.
My overall impression of this exam was that the topologies were complex and sometimes misleading, the devices were buggy and the access was slow. I also think that the combination of all the events that happened to me that day made the exam harder than it actually was.
Next attempt will be in February/March at RTP I think… I will have to check but I’m taking a break for the next few days to re-focus on what I have to work on. I am really grateful for everyone that encouraged me and sent me hopeful wishes.
Thanks again to all my followers for your support, I will be posting new technology blogs soon and a review on all the material I’ve gone through.