CCIE instructors see the question time and time again - are we penalized for bover-configurationb in the CCIE lab exam? The answer - bnot typicallyb. Let us walk through some examples to see exactly what we are talking about here.
First of all, I encourage students to ask two questions when they are about to bover-configureb something. Question 1 - can this additional configuration I am about to make actually gain me points (might Cisco be grading for it)? Question 2 - can this additional configuration I am about to make actually hurt me (cause point loss)? If the answers are a resounding YES and NO, then it is definitely a configuration you should consider making.
A simple example would be setting a Layer 2 switch port for a VLAN with:
switchport access vlan 100
Versus:
switchport mode access
switchport access vlan 100
Might Cisco be grading for the specific configuration of DTP mode OFF on the port, perhaps. So the answer to the first question is YES. Notice, on the other hand, this configuration should not cost us points in any way, so the answer to the second question is NO. We see that these questions lead us to the conclusion...if it can only help us and not hurt us - GO FOR IT!
While many times we are not penalized for over-configuration, remember that we are always looking for the simple, time-saving, straightforward solution to the task at hand. I have seen ridiculous amounts of silly over-configuration from students that do not understand this principle. One example that comes to mind is the student that is asked to iBGP peer between R1, R2, and R3 using AS 100. The student then takes it upon himself to configure peer groups, loopback peerings, and router-IDs. All of this is for bgood measureb and absolutely none of it was required and gained the student any points! In fact, when asking the second question about the over-configuration causing point-loss, the answer here might be...byes, it can cause point loss because I am wasting so much time!b
Let us also remember that the key to solving the CCIE lab exam comes down to reading very carefully and following explicit instructions versus implicit instructions that exist in the task. Often times we discover additional configuration steps that we should take due to implied requirements.
I discuss this issue in greater detail in the following blog post:
http://blog.ine.com/2008/11/12/the-lab-made-me-do-it-%E2%80%93-implicit-versus-explicit/b(
________________________________________
From: nobody_at_groupstudy.com [nobody_at_groupstudy.com] On Behalf Of Sergey Matashuk [matashuk_at_gmail.com]
Sent: Wednesday, October 20, 2010 5:26 PM
To: Cisco certification
Subject: keeping configuration lines minimal
What guys are you thinking about keeping configuration lines minimal
on a real CCIE lab exam?
I`ve did INE`s mock lab exam some time ago, and i`ve noticed I`ve loos
the points for one of the tasks due to one more route-map entry. The
route-map were used for redistribution tagging, and my solution was to
add explicit permit clause. All the task requirement were solved, just
the route-map MAY had one entry less.
So, I`m wandering will such approach ends loosing points in real lab
exam? Following keeping conf lines minimum principle we can end up for
example "summarizing" network statements at routing protocol config
mode (to permit two or more interfaces by noe network statement), but
I never heard about loosing points for explicitly permiting every
interface running routing protocol with network statement. And I
personaly prefering to add interface to routing protocol with 0.0.0.0
wildcard, just to have more granular control. We can have interfaces
added (eg tunnels) on later tasks, and I don`t want end up
troubleshhoting routing at the end of exam.
Where is a reasonable border betweeing keeping configuration as small
as possible and having some "freedom" to configure things? Should we
been paranoid on configuration lines? Let`s discuss all of your
thoughts.
Blogs and organic groups at http://www.ccie.net
Received on Wed Oct 20 2010 - 17:53:31 ART
This archive was generated by hypermail 2.2.0 : Mon Nov 01 2010 - 06:42:06 ART