CCIE RS v4.0 Lab Strategy by Darby Weaver 2/13/2010 (Friday the 13th Edition)
Darby's Woodshed : Darby Weaver
1. You know you have to deal with the Open Ended Questions. Some say they are easy and others say they they are so easy but somehow missed them - too much or not enough, etc.
- Let's start with what can we expect from Open Ended questions in the first place. They are generally probably not going to be spell out the words of an acronym. They are probably not going to be values for items like Admin Distance or various metrics, and they are probably never going to be an RFC, at least not directly. This much we pretty much can be sure of.
- So what should we expect then?
- We should expect that if it is fundamental and has to do with the fundamental operations of any given topic, topology, neighbor relationship, function, operation, topology, or basically anything that we know we've seen everyday while studying, reading, sitting classes, attending lectures, watching videos, taking notes, or just watching basic adjacencys form from a simple relationship for example... that might be the very basis of an Open Ended question. Hell you really might want to brush up the output of most of the show commands you might use from day to day. Remember they can be straight-forward but are probably going to be subtle. No one ever comes out saying they got something they never ever really "saw" before and when they did... they were not looking in the right places or paying proper attention and I don't care how many CCIE's the person might have. Beauty is in the Eye of the Beholder. OEQ's are Beautiful.
- You have 30 minutes to contend with 4 questions. You can probably answer all 4 of them in less than 10 minutes and that includes a rest room break, a trip to the coffee machine, and making a cup of coffee if you need to... But that would be a mistake. And you would fail based on just 4 tiny questions that you enjoyed a cup of coffee over and took a restroom break to think about.
- Don't do that. Instead. Read the questions. Write down everything you think you know about the questions. Do this for each question. Now maybe take a quick break if you need to or take a stretch. Then look at them again and ask yourself the again what you think they are asking. I don't recall having access to the DOC CD during this time. It's just you and the OEQ. Take your time. Your whole trip rides on these minor 30 minutes and 4 little questions.
- Now if you are confident you've thought of everything and wrote it down. Consider the questions again and now and only now write your questions and save them as you exit the app.
Moving on...
2. Troubleshooting. You have 2 hours to get through this section. You need at least 75% but shoot for better.
- A few things to keep in mind here.
- Know yourself. You are an "engineer". You will tend to go into "head down" mode when working on a problem. You will ignore the world around and when the 2 hours are over you will just feel like it was a couple of minutes and if you are not careful you will have succeeded in failing the lab. You may not even have enough time to complete all the questions either. That is a bad thing.
- Keep this in mind ~12 questions and 2 hours = 10 minutes a question. Most of the questions are probably not designed to cost you a full 10 minutes. Statistically they just can't be designed in this fashion. So they probably are not.
- Remember you are going to be looking at a fairly large topology of about 30 devices. That's a lot of devices. However, your problem is probably going to be on no more tan 2-5 devices per problem. My guess is most of the time only 2 or 3 devices. Lucky guess.
- While you are in this section you need to be thinking about strategy. Look at what is configured and what is not. Solve the problems based on the tickets presented. Also, if time permits and you see configs that you know you are weak on... yep... write them down and take a little note... you are in the lab and every little bit helps. Think of this as the only part of the lab that is open-book and they may well give you some answers to later tasks. Who knows?
- Don't dwell. Solve the problem. Take the low-hanging fruit first. You need to ask yourself: If you were studying with a study buddy and you wanted to insert a fault, what would you do? You are the expert now. Do it and carry on smartly.
- Common troubleshooting techniques will always prevail. If you make a change and it does not fix the problem, put it back. No sense creating extra mayhem in this little world of chaos you have entered upon.
Moving on along...
3. You have survived 2.5 hours of pure stress and now comes the main course: The Hands-On Lab Tasks.
- First thing is first, be thankful that there are only 5 routers and not 6 to contend with.
- Second thing, be thankful that you only have to deal with one series of Cisco Catalyst Switch - the 3560.
- Now that you have finished your prayers and taken any breaks you should be fired up and ready to go, kick ass and take some names.
- Don't look for the proctor and don't expect the DOC CD to work properly. Sorry just don't. The proctor will usually tell you to read it again and the DOC CD will probably be slower than molasses with arthritus. Don't bother looking for too much help. You should not be here if you left home thinking any section could just be skipped. None can be. You need every miniscule point and you are going to get them or die trying.
- Time is critical and you no longer have the notepad. That can be tricky. I'm not certain that SecureCRT is still guaranteed to be available moving forward. Let's assume it is. Let's be ready with using Putty if it is not.
- Let the games begin.
- Look we are not novices when we step into the Gladiator's Chamber. We are not. We are here to prove expertise. Take off the shackles and do your thing, this is what you came to the party for... It's now time to dance!
- I've noted being "6 times faster" working on my configs, if and when, I take the time to draw a diagram (getting familiar with the lay of the land) and then configuring as many tasks as possible on a per router basis. Look I know everyone else says do it one router at a time, verify, and then move on. I've done it this way 6 times at these labs and I'm pretty confident that what I configure most of the time works properly... and then if I get distracted by one little piece and do not finish something... the whole world tends to just fall apart.
- Let's not do that. While performing a graded lab at Cisco Live this year in a similar "virtual environment" as the current labs. I had the great fortune of losing all my configs about 2.5 hours into the lab. All of them and they were just gone. Luckily, when I got my pod fixed I picked myself up and used notepad and got back to where I was in under 30 minutes or less (about 25 minutes). Yep! I was a happy camper but and all my L1-L3 just came up like no one's business and I was all the way to Multicast, just like that. Imagine had I used that technique the first time... Yep! TIME-SAVER!!! (It used to be store on the corner in Louisiana's West Bank when I was a kid.)...
- Kewl. Now we kick that lab's ass. See If we work smartly then we can verify the configs step by step. Chances are there will be work done for us and if there is, the same process applies. Use the lab diagram and notepad to be your beacon. If it is on the routers and switches it may be a pre-set trap or may just be a typo. Your dime. work it out. The diagram will usually win. Check with your proctor. I have been given the wrong workbook in the past too. Everything devours your time like a bag of "Cheetos"!
Some techie tricks I use to save time:
1. Timers for protocols like say BGP... learn how to optimize this one. It's a life-saver!
2. Use notepad for authentication strings and watch the spaces.
3. Use statics to "sanity check" if things are not doing what you need them too.
4. Know how to configure any access-list and route-map possible.
5. Take your time and learn to love Multicast and QoS. If you still hate them... get a new date to take the lab. Simple as that.
6. Remember that MPLS is not that bad really.
7. Frame Relay and OSPF is a classic and you have no excuses why not to know it by now.
8. Know all your optimization and summarization features. Yes, redistribution is still a classic.
9. NAT and Tunnels - timeless classics.
10. The world is racing towards IPv6 do don't get left behind.
11. Understand how to use logging and debugging tools. If you can tell time it will help too.
12. SSH and AAA are good enough for the real world and they are probably just dandy in the lab too.
13. Learn to verify everything.
I'll probably update this a bit as I get more in the mood for it.
Later
Darby Weaver