CCIE instructors see the question time and time again – are we penalized for “over-configuration” in the CCIE lab exam? The answer – “not typically”. 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 “over-configure” 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:
Versus:
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 “good measure” 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…”yes, it can cause point loss because I am wasting so much time!”
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.
First of all, I encourage students to ask two questions when they are about to “over-configure” 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 “good measure” 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…”yes, it can cause point loss because I am wasting so much time!”
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.
