TS - General way to fix an issue

Hi all,


DUring some labs, I always got the feeling that I fix the issue, but in fact not in the way it was expected...

I have two examples here, and I would like to know how it is expected to fix them :


1. Eigrp adjacency between 2 routers, on ethernet link, but one of them as a hello-intervall set to 40s on the interface, making the adjacency flapping.

Solution: well, removing the command is apparently during TS lab not so welcome.... So I add it also on the other router. Problem... ethernet link have hold-time set to 15s per default... so should we also set the hold-timer to 120s on both devices ???

Setting the intervall timer to 5s (default value) is in fact the same as removing the command...soooo, what to do ?


2. lmi.... what a nice stuff... What if one device has for example an lmi type ansi, but the facing FRSW has nothing and expect default value...we can modify the lmi type on FRSW or on the router, or we can remove it, so it will automatically choose the default ?

Here is a question of point of view... which configuration is wrong ? :D FRSW or Router ?

In 2 hours, decisions have to be taken fast... so what would you do in such case ? not removing but adapting everything around ? or removing it because it is faster?

Any advice is welcome,

Thanks ,




  • Hi Olivier,

    I haven't attempted the exam yet so this is just my own understanding of how you are being evaluated. They are supposed to be concerned with the outcome of your work, not the exact method. If you met the requirements that are stated then you have fixed the problem. They will likely prefer to look at show commands in the grading script rather than parse the running configurations.

    So I would think for your example #1 if EIGRP neighborship is up (show ip eigrp neigh) and the adjacency is no longer flapping.. and you haven't broken any general rules.. then your solution would be correct.

    For #2 I would say if the link is up and you see the DLCI's you're expecting? In this case I would personally treat the FRSW as a "BB" router, leave it alone, and make my changes on the other devices. But I think if the rules do not say you can't modify FRSW then it must be a viable solution.

    Some of the advice I've seen is to look at the question and think about what show commands would verify a working solution, and then make your configuration to match that. 

  • Olivier,


    I agree with ealeatherman.  I watched Brian Dennis troubleshooting lab seminar and found it to be very useful:


    The biggest thing I found from this is when you start studying for the TS section to take your time with the TS practice labs and think of multiple ways to fix an issue and try those out, even in they do break the rules.  After that focus on speed and accuracy. 

    My understanding of the TS section is try not to remove or add but change configuration when possible.  Also use fewest commands possible to resolve the issue.   So in your case if you "change" lmi on either side that should be suitable in my opinion.  The thing with EIGRP is I see either solution as valid since you are changing the hello/hold timers.  These are all changes even though the config does not appear due to it being default.   I would prob change these two back to defualt unless there was something in the question that eludes me not to.

    just my 2c..

  • peetypeety ✭✭✭

    My standard statement still applies as it has for the past two years:

    Assume that you're a consultant, and company XYZ brought in a quintuple-CCIE a few years ago to build their network.  Once the network was optional, the IT Director saw no need for the high-dollar 5xCCIE and sent her packing.  Sometime later, the IT Director hired a CCNA-wannabe for pennies on the CCIE dollar and cut them loose on the network.  Over time, little errors have crept in, and now things have gotten out of hand, so you've been brought in to fix it.  One caveat: you have to fix at least 80% of the items listed, or you don't get paid.  Oh, and by the way, you have to actually fix them.

    In other words, the design of the network is in front of you, and it's your job to fix it.  In item 1, if duplicating the hello timer on the other neighbors is sufficient to restore stability, assume the CCNA deleted that command and replace it.  If it takes a lot more work to provide stability, assume the CCNA dropped in the hold-timer 40s, and remove it.  In item 2, since the carrier operates the FRSW and you have no access, assume either the carrier changed something without telling you (you know, "problem cleared while testing" type of lie from the telco) or the CCNA dropped in the lmi-type command so you should remove it.  Remember that you're going to have an LMI of one form or another...perhaps just living with the default is the right way to go.

    I realize my scenario is not actually spelled out in the TS docs, but I find that it's a perfect mindset to carry into the room, as it will guide you forward through the section quite well IMHO.

  • JoeMJoeM ✭✭✭

    Hi Olivier,

    Have you looked at Workbook-4 yet?   I stumbled on it this week, and I really liked the experience.   I got my butt totally kicked.  No way I was getting it done in 2 hours, but the experience helped me to review my approach and understanding of some technologies.

    Every ticket solution is spelled out in great detail.  But of course, every situation is different.

    Here is an excerpt from the workbook introduction:

    Our ultimate goal is not only prepare you for passing the Troubleshooting section of the CCIE R&S lab exam, but also to teach you a structured troubleshooting approach.

    As opposed to simple guessing and peeking at the routers running configurations you should learn using the debugging commands and interpreting various show commands output. For every ticket, we are going to follow the same  structured  procedure to resolve the issue. Here is an outline of this procedure:
             Copyright © 2013 INE, Inc.  www.INE.com

    CCIE R&S VOL4 Adv. Troubleshooting Lab Workbook for CCIEv4.0  Intro

    1.  Build and Analyze the Baseline
    2.  Analyze the Symptoms (propose hypothesis)
    3.  Isolate the issue (gather more symptoms)
    4.  Fix the Issue (by comparing to the Baseline)

    We are now going to discuss all these steps in details to give you the basic understanding of the fundamental procedure.


  • Hi,


    Thanks for your input. Last exemple where I have some trouble with SG...

    You have an interface with ACL in input like:

    10 deny udp host x.x.x.x any

    20 permit ip any any


    Lots of people would configure:

    no 10 deny udp host x.x.x.x any

    10 permit udp host x.x.x.x any


    But then you have an ACL like

    10 permit udp host x.x.x.x any

    20 permit ip any any


    Doesn't it look stupid ??? I mean if statement #10 would have log option or time-range or whatever, I would understand, but otherwise, who in real world would configure such ACL ?? Why can't we simply remove statement #10 ? Or... can we ???





  • WB Vol4 is really good, but I am at the moment in the thinking 'time is points' for the lab and if I have to think about a politic way to fix the issue, I lose time :(

    Lots of people wrote that they fixed all issues, but in the way CIsco is expecting, that scares me... I mean, if we don't violate the rules, if you don't introduce new issues and if it works, why it wouldn't be a valid solution ?

    Lost in Cisco Cloud :)


    Anyway... great forum here, great people, really helpfull, thanks again to everybody !!!



  • Olivier,

    I would say you could just remove statement #10 and it would also probably fulfill the requirement. Just my 2 cents.

    I think we probably need to take the solution guide with a grain of salt.. it's going to show one possible solution but probably won't go into every possible solution.


Sign In or Register to comment.