From: Andrew Moriarty (amgroupstudy@hotmail.com)
Date: Mon Nov 10 2003 - 12:54:04 GMT-3
Alec:
As far as redistribution goes, and with a lot of things on the lab, there
appears to be two schools of thought:
1. "Lock everything down and leave nothing to chance, otherwise you will
lose points"
2. "Don't add any extra commands unless explicitly requested, or you will
lose points"
This discussion has been going on for at least a year; I know this for sure,
because in the run up to my lab attempts, I read every single group study
post from Nov 1, 2002, to August 14, 2003. There were over 20,000+ and this
reappears every few months or so.
I believe the best answer is to look at the question for clues. In frame
relay, for example, it is widely understood that you should lock down DLCI's
with map statements, because most frame relay questions in (Practice) labs
specify that you should not activate extra DLCI's. Therefor, you must
prevent not only current problems, but future problems as well. This falls
under the "lock down everything" method.
On the other hand, in redistribution, my personal thought is that their is
no need for all this extra effort. As you have pointed out, with OSPF and
EIGRP redistribution, the problem almost solves itself. What's the benefit
of the extra configuration? Nothing in that scenario that I can see.
During my studies, I spent a lot of time working on different practice labs.
One of the errors that I commonly made when I "Locked down" route
redistribution, was that later questions would inject additional routes into
the IGP's, say from BGP, and I would have to redifine access lists, or
prefix lists, and I would inevitably mess something up. Even when I didn't
mess something up, revisiting an access list/route map you created three
hours ago, requires precious time to reacquaint yourself with exactly what
you did. Time is at a premium on the exam.
Currently my personal view is
1. Don't lock down redistribution between protocols unless absolutely
necessary. I define absolutely necessary as a permanent routing loop
occuring, or a specific note in the question about it.
2. Lock down redistribution of connected routes to the exact network. I do
this because these questions in the practice labs inevitably use words like
"ONLY, JUST, etc".
On the real lab, pay close attention to exactly what the question says, read
the whole lab from start to finish before you start answering any questions,
cause you never know what is lurking later, and when you think you
understand the question, before you start to answer it, go to the poctor
with very specific qestions that s/he can answer with a yes or a no. Ex "Can
I use a distribute list? If a temporary routing loop is formed her for 4
minutes, is that ok? If this design produces non-optimal, but still working
connectivty, is that ok?" etc
As far as the marking goes, here is my understanding, after speaking to
several procters and interpreting my test results. (Somewhat of a black art
that. Best results received by sacrificing a chicken) Note that this is my
UNDERSTANDING, I have no proof of this, its just what I feel.
1. Initial grading is done by an automated script. If you get a requirement
wrong, its wrong, no matter why or what broke it. For xample, if a question
says X must be able to ping Y, and it can't, you get no points for that
question, even if it was configured correctly, and some other part of the
test broke it.
2. If the script says its OK, its still not ok. A procter then goes and
looks at your test to see if you got it correct in on of the allowed ways. (
No static routes, for example)
3. This often results in you getting a lower score than you thought you
should get. If you ask for a rescore, you score in one area usually goes up,
but I've never heard of anyone actually passing. If you get a test result
that says you totally screwed up your IGP routing, you may not have totally
screwed up IGP, but instead put a totally wrong access list in on a security
part. As a result, the security doesn't work, but neither does IGP. So no
points for either, even if you IGP configuration was perfect. Problem is,
you don't know which it is.
Good luck!
am
>From: "Pun, Alec CL" <Alec.CL.Pun@pccw.com>
>Reply-To: "Pun, Alec CL" <Alec.CL.Pun@pccw.com>
>To: "'CCIE Study Group'" <ccielab@groupstudy.com>
>Subject: [HELP] Rules for redistribution and marking scheme Date: Mon, 10
>Nov 2003 00:59:02 +0800
>
>Hi group,
>
>Just want to get a clear and simple answer to multiple redistribution
>points
>scenarios that have come across from time to time :
>
>1) When there are multiple redistribution points in the topology, I always
>see answer keys that make use of cubersome distance with ACL, tagging or
>route-maps to prevent route-loop. While in some case it is absolutely
>necessary, especially for protocols that can not differentiate external and
>internal routes, i.e. RIP. But for mutual redistribution such as EIGRP <>
>OSPF / ISIS, I can't see the reason why those configurations were in place
>'coz EIGRP has external ADMIN distance which is already large enough. For
>working with OSPF, isn't a simple command "distance ospf external <AD>"
>already sufficient ? Just want to find the simplest way to get the work
>done...
>
>2) The 2nd question is about the lab marking scheme.
>Redistribution between IGP is so easy to get errors, maybe due to missing
>routes or route-loops. If so happened after redistribution, some of the IP
>connectivity can not be fulfilled, will I get marks for individual IGP
>section ? (assume connectivity within each IGP domain is okay)
>
>Appreciate if anyone can share their view. Many thanks.
>
>regards,
>alec
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Dec 12 2003 - 12:29:10 GMT-3