From: John Matus (jmatus@pacbell.net)
Date: Sat Sep 03 2005 - 00:22:13 GMT-3
hehe......sorry scott, merely a continuation of our NDA and isdn switch-type
discussion :)
what was the original question btw?? i'm was responding to tim's suggestion
that ip mobile was "not" on the exam. i don't believe that cisco has stated
anywhere that it is "not" fair game for the exam, much the same way is i can
say that voip is not on the R&S exam.
Regards,
John D. Matus
MCSE, CCNP
Office: 818-782-2061
Cell: 818-430-8372
jmatus@pacbell.net
----- Original Message -----
From: "Scott Morris" <swm@emanon.com>
To: "'John Matus'" <jmatus@pacbell.net>; "'ccie2be'" <ccie2be@nyc.rr.com>;
"'John Matus'" <john_matus@hotmail.com>; <ccielab@groupstudy.com>
Sent: Friday, September 02, 2005 7:50 PM
Subject: RE: Top Reasons Me & people with enough skill fail the lab
> Why am I being sucked into this? Am I somehow the NDA Nazi? (No offense
> to
> Nazis, of course)
>
> I won't feel bad letting everyone know that I had X.25 and Decnet on my
> exam. While likely an NDA violation, it falls into that concept of "BFD"
> kinda like "IP" being on your exam. However, the original question was
> specific. In fact a bit TOO specific which is (I believe) how we got
> where
> we are now.
>
> *shrug* I'm going back to kicking someone's ass at Internet Reversi. ;)
>
> Scott
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> John
> Matus
> Sent: Friday, September 02, 2005 10:43 PM
> To: ccie2be; 'John Matus'; ccielab@groupstudy.com
> Subject: Re: Top Reasons Me & people with enough skill fail the lab
>
> 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
>
> _______________________________________________________________________
> 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