From: Farrukh Haroon (farrukhharoon@gmail.com)
Date: Sat Sep 03 2005 - 00:47:08 GMT-3
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
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:13 GMT-3