From: ccie2be (ccie2be@nyc.rr.com)
Date: Fri Sep 02 2005 - 20:46:47 GMT-3
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
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:13 GMT-3