From: CCIEin2006 (ciscocciein2006@gmail.com)
Date: Tue Nov 15 2005 - 15:38:30 GMT-3
Great post Tim!
Regarding multiple ways to accomplish a task, I noticed from the practice
labs I have taken (specifically CCIE Practice Labs by Martin Duggan,
Maurilio Gorito) the easiest way to accomplish a task was the correct way.
For instance one of the labs tells you to aggregate a route but to maintain
its attributes. I went down the rat hole of configuring a route map to
change the origin, as path, and metric back to the pre-aggregate values
without knowing a simple keyword "as-set" was all I needed.
A corollary to the KISS rule would be that if it takes you more than 30
minutes to find the solution to a problem, you're probably doing it wrong.
Do you agree?
On 11/15/05, Tim <ccie2be@nyc.rr.com> wrote:
>
> This is a repost of an earlier with a different subject line.
>
> T.J. Mitchell,
>
> Having failed the lab many times myself, I can sincerely say I feel your
> pain (Actually, until Tuesday I could honestly say I've been feeling your
> pain for the past 2 years).
>
> So, what I'm about to say is for those people like yourself, who have
> enough
> knowledge and skill to pass the lab but still fail anyway.
>
> Personally, I believe there are 4 primary reasons people who should pass
> the
> lab don't.
>
> 1. Task mis-interpretation
>
> 2. Insufficient organization during the lab
>
> 3. Not seeing the implied requirement
>
> 4. Insufficient checking and verification
>
>
> Here are the some of the things I did to overcome the first problem.
>
> I think there are 3 reasons people mis-interpret the task requirements:
>
> 1. Cisco, by design and with malice of intent, often writes the tasks in a
> vague or misleading way.
>
> For example, if you've been following GS posts over the past couple of
> weeks, you may have noticed questions regarding Mobile IP. However, Mobile
> IP is not on the lab. This was a response to a question re: forwarding
> Mobile IP registration broadcasts.
>
> "Ip forward protocol with IP helper is what I would use...you can forward
> mobile-ip registrations which are udp...I'm not sure about your
> configuration but that's what it appears to me what you are trying to
> do.."
>
> Reading between the lines, it seems to me that a task could be written
> with
> the words Mobile IP in it where the solution has nothing to do with
> configuring Mobile IP. Now, I can't speak for anyone but myself but I know
> that if I read a task with the words Mobile IP in it, I would
> AUTOMATICALLY
> think about having to configure Home Agents or Foreign Agents or something
> related to that. Not in a million years would it occur to me that the
> solution was really calling for the ip forward udp command.
>
> Could it possibly be that the proctors who write these labs would be so
> wicked? I think the answer is definitely YES.
>
> On the other hand, there are ways to combat this wickedness. First of all,
> DON'T ALLOW YOURSELF TO BE SUCKED INTO THE BLACK HOLE OF WASTED TIME.
> Losing the points of one or two non-layer connectivity tasks won't
> automatically cause you to fail the lab. I had at least 2 tasks on my lab
> which I didn't even attempt to answer and I still passed.
>
> 2. Reading the task too quickly (or not carefully enough)
>
> To combat the scourge of task mis-interpretation, slow down. Yes, I said
> it. Slow down. Read the complete set of bulleted sub-tasks slowly and
> multiple times. Here's what often happens when you don't slow down. You
> read the task too quickly and realize you know how to do that and you
> configure the task using the most common method or the way you're most
> familiar with - and you're wrong. You make the assumption that just
> because
> you know A way to fulfill the task requirements, you are fulfilling the
> task
> in THE correct way. Of course, it doesn't appear that you're wrong because
> you verify reachability and you have reachability but you didn't fulfill
> all
> the conditions of the task. Bingo !!! At least another 2 or 3 points lost.
> (You might also lose points for subsequent tasks because of dependencies.)
>
> Here's another example. "Allow pings to bring up the isdn link" which is
> not exactly equal to "Allow icmp traffic to bring up the isdn link".
>
> Consider this. Does "Allow pings..." mean "Allow ONLY pings..."?
>
> If your acl is like this: access-list 100 icmp permit any any
>
> This acl does in fact "Allow pings..." to bring up the link but it also
> allows other traffic as well. What should you do? Will the acl above cause
> points to be lost? I don't know for sure but I suspect that it's better to
> be as specific as the task allows.
>
>
> This brings me to next KEY reason people mis-interpret the task:
>
> 3. Not knowing every way to accomplish a given task.
>
> Of course, the best to deal with this problem is easily said but not that
> easily done.
>
> KNOW EVERY WAY TO ACCOMPLISH A GIVEN TASK.
>
> The lab is FAMOUS for restricting your choices for how something is done.
> For example, there are 3 ways to advertise a loopback in OSPF without a 32
> bit mask. There are 3 ways to advertise the ip address assigned to an
> interface in IS-IS. There are multiple ways (at least 3 that I know of) to
> assign an ip or ipv6 address to an interface. There are a gazillion ways
> to
> configure isdn to back up lost connectivity somewhere else in the network.
> There are multiple ways to overcome reachability problems.
>
> Here's my list:
>
> 1. Redistribution
> 2. NAT
> 3. Default network
> 4. Static route
> 5. Tunnel
> 6. Policy based Routing
> 7. Summary Addressing
> 8. Virtual-links
>
> When you don't know every way to accomplish a given task, it's easy to be
> faced with the dilemma of thinking, "They must mean ...". So, then you
> configure something that seems to be pretty close to what they were asking
> for but not 100% exactly what they were asking for. Bingo !!! Another 2 or
> 3
> points down the drain.
>
>
> Now, I'll talk about the 2nd reason I think people fail the lab.
>
> Insufficient organization during the lab
>
> This could also be referred to as STUPID MISTAKES.
>
> We all make them and I suspect I do much more than most people. For
> example, let's say early in the lab (in the section on bridging and
> switching), you have to configure f/r end-to-end keepalives. So, that's
> what you do. You check it. It works. You go on your merry way. Later on,
> you're working on the QoS sections and you have to configure FRTS. So,
> that's what you do. You check it. It works. You go on your merry way. But,
> if you're anything like me, you didn't notice that the interface you
> applied
> the FRTS to were the same ones already configured for FREEK. Whoops !!!
>
> Another 2 or 3 down the drain.
>
> You can probably think of hundreds of examples like this where you do
> something early in the lab only to do something later in the lab that
> breaks
> your earlier configurations.
>
> To address this problem which probably caused me to fail multiple times, I
> started getting in the habit of making lists during the lab. If I have to
> create an acl or map-class, I write it down on the scratch paper they hand
> out at the beginning of the lab. Then, if at any later point in the lab, I
> need to create another acl or map-class, I first check to see if I've
> already had to create one before and on which interface. I also used to
> create a list of every loopback interface and make a note of which IGP
> it's
> in. When I'm done with the IGP section I check to see if I've advertised
> every loopback. I don't do that anymore. Now, I use a tcl script to check
> that. But, the list method worked fairly well before I was comfortable
> with
> using TCL scripts.
>
> Reason # 3 people fail: MISSING THE IMPLIED TASKS
>
> Let's assume for a moment you take the lab and only do what they
> explicitly
> tell you. If they didn't EXPLICITLY tell you to do something, you didn't
> do
> it. How many points would you lose? My guess is at least 6 to 9 points. Of
> course, they did tell you full reachability was required at all times
> perhaps in the general directions but not in any of the numbered sections
> of
> the lab. Hmmm. How do you combat this challenge?
>
> The way I tried to address this challenge was by making lists. For
> example,
> I have a short list of things to check for ospf and bgp. Before leaving
> the
> IGP section, I looked at my IGP diagram and looked for any potential
> virtual-link or gre tunnel requirement. Not only do I look for the obvious
> v-link requirement but also a potential requirement if the frame relay
> cloud
> went down. It's amazing how often a v-link or gre tunnel becomes required
> when the f/r link goes down. For another example, with BGP, I always used
> to forget configuring the neighbor ... next-hop-self command. Before
> moving
> from BGP, I always check, do I need to configure next-hop-self.
>
> As my last example, if there's any task that has anything to do with time,
> I
> automatically think "SET CLOCK". This includes acl's with time-ranges,
> logging, ntp, etc. Now, I know there's been extensive discussion her on GS
> about whether or not it necessary to set the clock if the routers are
> rebooted anyway at the end of the lab and those routers without hardware
> clocks will reset the clock to the default after a reboot. But, if I see
> any task that relates to time in any way, I make a beeline to the proctor.
>
>
> And, of course, look for tunnel and NAT requirements. Refer to the
> reachability list shown earlier. So, make your list of potential implied
> requirements and look for them. Let this list be your mental trigger.
>
> TOP REASON # 4 people fail the lab: Insufficient checking and verification
>
> I used to assume that if I knew how to do something and then did it, I did
> it correctly. Experience has painfully and expensively taught me that's
> the
> wrong assumption. I now assume when it comes to configuring routers and
> switches that anything I've configured IS in some way large or small,
> WRONG.
>
> In other words, I nominate myself as the world's number one ccie most
> likely
> to make configuration mistakes. Maybe I'm a bit dyslexic. Maybe it's
> because
> I hate configuring routers and switches. Maybe it's because my mental
> wiring
> just isn't configured properly for configuring routers and switches.
> Whatever the reason, I suck at configuring routers and switches and make
> loads of mistakes while doing so. But, yet on Wednesday I became a ccie.
>
> Having a deep awareness of my weakness in this area and yet being
> determined
> and convinced of my ability to join the club, I had to figure out a way to
> overcome this handicap. It wasn't easy. But, here's what I did.
>
> I practiced finding mistakes by using various show and debug commands. For
> example, I would misconfigured a dlci or ip address in a frame relay map
> and
> then study how that would affect the output of the show fram map command.
> I
> did the same for every technology covered by the lab. Slowly, painfully,
> tortuously, I got reasonably competent at finding my mistakes reasonably
> quickly. I still don't consider myself very good at troubleshooting but,
> what the hell, I'm still a ccie.
>
> So, my final words of advice to anyone wanting to be a ccie is this. Ask
> yourself, "What is your level of determination to become a ccie?" If your
> answer is, "I am 100% committed to this.", then figure out what your
> weaknesses are and how you're going to overcome them.
>
> If I can do this, so can you.
>
> Tim
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> tj.mitchell@verizon.net
> Sent: Monday, October 31, 2005 11:51 AM
> To: ccielab@groupstudy.com
> Subject:
>
> Guys ?
>
> I took the lab on Friday, got my results and didn?t pass but I?m doing a
> re-read of the test. My question is this, you practice and practice
> everything you can think of, you do the practice exams and do really well
> on
> those in the 90 ? 95% range, then come test time you get subjects that you
> know like the back of your hand and have configured time and time again in
> labs and real life. You configure the tasks the way they ask, you get the
> results and the section is marked extremely low. I don?t understand what I
> did wrong, I configured the devices as the requirements have asked and I
> still get the sections wrong. Everything works according to the show
> commands, nothing is failing and I still get the sections wrong. Now from
> what I understand on certain sections there are multiple ways of
> configuring
> the devices to get the required result, but other sections you need to
> configure the section and they tell you how to configure it. If you
> configure the device and it meets the re!
> quirement doesn?t violate the rules it should be valid, even though it
> might not be the desired configuration they are looking for it should
> still
> be right, right?
>
> Scott I have heard about you but never talked with you before, does any of
> this make sense to you? I know you teach a course and might have a little
> in-site that will help.
>
> If anyone might have a suggestion I'm open to it, I have taken the test
> more
> times that I would like to state, but I would like to finish off my
> certification and call it done. (basically I don't give up easily, other
> people can pass it, so can I :) )
>
> Thanks for all the help you have provided in the past.
>
> T.J. Mitchell
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:06 GMT-3