From: Dillon Yang (dillony@gmail.com)
Date: Sat Sep 03 2005 - 00:35:18 GMT-3
<quote>Was I stupid for even asking?</quote>
Yes! :)
The switch without routing protocol is just a stub terminal.
Can you connect two PCs separated by 6 routers?
Yes, you can, but the interfaces of the PCs are not taking part in any
routing protocol!!!
HTH
dillon
----- Original Message -----
From: "Gustavo Novais" <gustavo.novais@novabase.pt>
To: "ccie2be" <ccie2be@nyc.rr.com>; "Cisco certification"
<ccielab@groupstudy.com>
Sent: Friday, September 02, 2005 10:44 PM
Subject: RE: Went yesterday to Brussels (How I overcame my weaknesses)
> Reading your email makes me think a lot... There was a loopback on a
> switch which was not covered by any routing protocol, yet at the
> beginning they say that you should have reachability to all configured
> interfaces. Of course I asked the proctor, is it OK to not have this
> loopback advertised to the network... And he said YES! Was I tricked?
> Was I stupid for even asking?
>
> The thing is that the implicit configuration often enters the field of
> "I am not being asked to do something".
>
> It's like I heard someone saying... If there are 2 ways of doing
> something you have to know all 3 to the cisco lab.
>
> You are right about not sufficient verification... I was worried about
> finishing the lab on time, that I was a bit careless on checking
> backwards connectivity... I only can say that I THINK that I had
> everything working, but not for sure...
> I agree with you when they say allow traffic or a routes from
> somewhere... You must be specific... (ping example was great! I'd do
> permit icmp directly... And feel happy about it!)
>
> You know, at first I thought that people on this list should be
> masochists for going to an exam and fail over and over, don't they have
> an idea if they are prepared or not? The lesson I learned today is that
> most of people are technology wise prepared... BUT that's only the FIRST
> step of becoming CCIE... Next step is forget everything and relearn it
> properly until you are not just prepared, but you are able to SLAY the
> beast!!
>
> Thanks for your words... I was feeling a bit down :(
>
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: sexta-feira, 2 de Setembro de 2005 15:24
> To: Gustavo Novais; 'Cisco certification'
> Subject: RE:Went yesterday to Brussels (How I overcame my weaknesses)
>
> 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
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Gustavo Novais
> Sent: Friday, September 02, 2005 5:59 AM
> To: Cisco certification
> Subject: Went yesterday to Brussels
>
> Hi,
> I went yesterday to brussels, and did the RS exam. All went well, I did
> all the exam with the exception of a 2 point question, everything was
> fine, I thought I got all the tricks, I was all excited on the plane
> back home, nevertheless I've failed. :(
>
> I kept thinking about the exame and I think I would do everything the
> same way, I kept annoying the proctor with questions on which I had
> doubts interpreting, just to not let anything pass unseen.
>
> I am at the stage where I think that studying one more month would not
> do any difference on that exam, the difference is on how the decisions
> are made, and whether or not it will cost you points.
>
> So, I'd like to share with you some errors that I did that I think that
> costed me points.
>
> - Do not do anything that they didn't specifically told you to ---
> example: a preempt on a HSRP group active router. You may think of it as
> a best practice (if we want it to be active as much time as possible,
> but if not said in the lab...)
> - Be as specific as possible when allowing/changing policies on your
> network --- example: Even if no other BGP peer, do not just set weight
> to the peer indiscriminately if not specifically told so. Even in QoS,
> beware match any.
> - ISDN can be ambiguous in wording - try to get as much information from
> the proctor as possible.
> - KISS - Keep It Simple and Stupid - DO NOT GET FANCY
>
>
>
> I'd like to ask for your opinions on that, and complete the list, just
> to see if we can once and for all dominate the Cisco way of doing things
>
> Thank you
>
> Gustavo
>
> _______________________________________________________________________
> 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