From: simon hart (simon@harttel.com)
Date: Sat Sep 03 2005 - 03:37:39 GMT-3
And I bought the bloody book!!
Still may come in useful?
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
John Matus
Sent: 03 September 2005 05:35
To: Farrukh Haroon; Scott Morris
Cc: ccielab@groupstudy.com
Subject: Re: Top Reasons Me & people with enough skill fail the lab
oh, wow..........actual documentation from cisco. it would be nice if they
would have posted this on their site. IE actaully included ip mobile in
their volume 2 manual..........oh well :) that's good enuf for me
Regards,
John D. Matus
MCSE, CCNP
Office: 818-782-2061
Cell: 818-430-8372
jmatus@pacbell.net
----- Original Message -----
From: "Farrukh Haroon" <farrukhharoon@gmail.com>
To: "Scott Morris" <swm@emanon.com>
Cc: <ccielab@groupstudy.com>
Sent: Friday, September 02, 2005 8:47 PM
Subject: Re: Top Reasons Me & people with enough skill fail the lab
> here is the link from the archive
> http://www.groupstudy.com/archives/ccielab/200508/msg00730.html
>
> mobile ip is no more a topic for the lab.
>
> On 9/3/05, Scott Morris <swm@emanon.com> wrote:
>> It quietly disappeared from the BluePrint. So one has to wonder whether
>> it
>> was a typo (and IS still on) or a quiet way of saying "Just Kidding" (and
>> it
>> shouldn't have ever been on).
>>
>> *shrug* Can't hurt to be vaguely familiar with it and know where to look
>> it
>> up JUST IN CASE!
>>
>> :)
>>
>> -----Original Message-----
>> From: John Matus [mailto:jmatus@pacbell.net]
>> Sent: Friday, September 02, 2005 11:22 PM
>> To: swm@emanon.com; 'ccie2be'; 'John Matus'; ccielab@groupstudy.com
>> Subject: Re: Top Reasons Me & people with enough skill fail the lab
>>
>> 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
>>
>> _______________________________________________________________________
>> 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