Re: Top Reasons Me & people with enough skill fail the lab

From: John Matus (jmatus@pacbell.net)
Date: Fri Sep 02 2005 - 23:42:51 GMT-3


is it an NDA to discuss "topics areas" that appear on the exam? for
instance, can i say that "IP" may appear on the exam?....what about being so
bold as to say "yes, i had IP on my exam". probably the later is a
violation but not the former. scott? whaddaya think?
if one says that IP "may" appear on the lab, can another candidate logically
infer that IP does and will appear on the test? that is probably inductive
rather than deductive and probably hence no a violation, unless cisco's NDA
covers inductive references or other matter of relative truth.

"when asked if ip mobile would be on the exam, the buddhist master knocked
twice on the table"

"if ip mobile might appear on the exam...don't knock twice on the table!"

Regards,

John D. Matus
MCSE, CCNP
Office: 818-782-2061
Cell: 818-430-8372
jmatus@pacbell.net
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "'John Matus'" <john_matus@hotmail.com>; <ccielab@groupstudy.com>
Sent: Friday, September 02, 2005 4:46 PM
Subject: RE: Top Reasons Me & people with enough skill fail the lab

> John,
>
> This was posted on Group Study not that long ago and I also saw it
> somewhere
> on Cisco's web site but can't find it now.
>
> Did you do a search for mobile ip in the GS archives?
>
> Tim
>
> -----Original Message-----
> From: John Matus [mailto:john_matus@hotmail.com]
> Sent: Friday, September 02, 2005 6:00 PM
> To: ccie2be@nyc.rr.com; ccielab@groupstudy.com
> Subject: RE: Top Reasons Me & people with enough skill fail the lab
>
> tim,
> what leads you to believe that mobile IP is NOT on the lab. (i'm not sure
> that it would be a violation of the NDA to say what might lead me to
> believe
>
> that is IS on the lab)
>
> john
>
>
>>From: "ccie2be" <ccie2be@nyc.rr.com>
>>Reply-To: "ccie2be" <ccie2be@nyc.rr.com>
>>To: "Group Study" <ccielab@groupstudy.com>
>>Subject: Top Reasons Me & people with enough skill fail the lab
>>Date: Fri, 2 Sep 2005 12:12:18 -0400
>>
>>This is a repost of an earlier with a different subject line.
>>
>>Gustavo,
>>
>>Having failed the lab many times, 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 gzillion 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
>
> _________________________________________________________________
> Is your PC infected? Get a FREE online computer virus scan from McAfeeR
> Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:13 GMT-3