From: ccie2be (ccie2be@nyc.rr.com)
Date: Fri Sep 02 2005 - 19:20:19 GMT-3
Chris,
re: ospf loopback.
I might have mis-spoke twice.
How does a /24 loopback appear in the route table when it's redist into
osfp?
As a /32 or a /24?
I don't even remember anymore. But, I think it appears as /24 and that
makes 3 ways to advertise a loopback into ospf with it's native mask.
-----Original Message-----
From: Chris Lewis (chrlewis) [mailto:chrlewis@cisco.com]
Sent: Friday, September 02, 2005 11:56 AM
To: ccie2be
Subject: RE: Went yesterday to Brussels (How I overcame my weaknesses)
Tim,
What are the three ways to assign an IP or IPv6 address you are thinking
of? Are they manual configuration, DHCP and address negotiated on PPP?
Regarding the OSPF /24, are you thinking ip ospf network, area range and
what else?
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gustavo Novais
Sent: Friday, September 02, 2005 9:44 AM
To: ccie2be; Cisco certification
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
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:13 GMT-3