From: John Matus (jmatus@pacbell.net)
Date: Sat Sep 03 2005 - 01:36:28 GMT-3
cisco press lab manual uses this cofig for lab 1 -3. you can use ip
default-gateway as an option to reach the rest of the network.
Regards,
John D. Matus
MCSE, CCNP
Office: 818-782-2061
Cell: 818-430-8372
jmatus@pacbell.net
----- Original Message -----
From: "Dillon Yang" <dillony@gmail.com>
To: "Gustavo Novais" <gustavo.novais@novabase.pt>
Cc: "ccie2be" <ccie2be@nyc.rr.com>; "Cisco certification"
<ccielab@groupstudy.com>
Sent: Friday, September 02, 2005 8:35 PM
Subject: Re: Went yesterday to Brussels (How I overcame my weaknesses)
> <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
>
> _______________________________________________________________________
> 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