Troubleshooting queries in JNCIE-M Lab

darry9502darry9502 Member Posts: 12 ■□□□□□□□□□
Hi to all mates that had taken the JNCIE-M lab,

I appreciate if anyone can answer some queries with regard to the troubleshooting requirements,

1) If we find something wrong with the network, like default route not present, do we fix them first or do we check with the proctor? The case study in JNCIE-M seem to indicate that we need to check with the proctor.
2) Do they have a requirement like all loopback address of the routers must be reachable? Or that we must see all the routes to Transit, Peer and Customers devices?
3) Very often, there is more than one way to solve an issue. Do the lab indicate any specific requirement that we can only solve an issue using a particular method
4) Do we need to test routers or links failure by deactivate an interface or protocol? Take for example the JNCIE book, if we shutdown R3, we will need to do extra redistribution at R5 and R4 in order for the network to maintain full reachability.
5) Is there a recommended time for the troubleshooting section? I am wondering how much percentage does troubleshooting section consist of the overall JNCIE-M lab? Is it just 10% or there is no way to quantify such issues? (well, some people may just take 30 mins to solve it, while others may take 2 hours). But comparing the whole lab, does this section take up a signiificant amount of time and effort of the whole lab?


Thanks in advance for any responses

Cheers
darry

Comments

  • hoogen82hoogen82 Member Posts: 272
    Answers to your questions...

    1. If the task states you to fix the issue yeah you should do it... You don't need to ask the proctor every time.... But your question is tricky... def route / static routes aren't mean't to be used until specifically allowing you to use them....

    2. That would be based on the requirement... They may or may not say that.

    3. I would say if there is a second way to do it.. You could do it...

    4. If they say for example bringing R3 down shouldn't result in loss of service.. Then yes you need to do the extra things to ensure everything works..

    5. Hmm... I am not sure I can answer that... That dwells into NDA....
    IS-IS Sleeps.
    BGP peers are quiet.
    Something must be wrong.
  • darry9502darry9502 Member Posts: 12 ■□□□□□□□□□
    Thanks hoogen,

    I am clearer now. Basically, we just look at the questions and respond according to the requirements.

    I am asking these because the JNCIE-M book chapter 1 does not really have much troubleshooting issues. And the case study 1 is unlike the rest of the case studies, which come with specific requirements.

    During my JNCIP lab, the proctor told me that a lot of candidates actually failed the troubleshooting and cant find time to finish the lab. Anyway, I am going to review the JNCIP topics once again in order to refresh the IGP concepts.

    Cheers
    darry
  • hoogen82hoogen82 Member Posts: 272
    That would actually be true.. And your assessment of going over the JNCIP topics again is really good...
    IS-IS Sleeps.
    BGP peers are quiet.
    Something must be wrong.
  • zrchengzrcheng Member Posts: 44 ■■□□□□□□□□
    troubleshooting sometimes can be hidden. the good way is just leave some time in the end to go over the requirment one by one.
  • darry9502darry9502 Member Posts: 12 ■□□□□□□□□□
    Thanks zrcheng,

    Indeed, checking, testing and verification of our config is important. Sometimes, due to FAT finger or stress, we unknowingly create some typo errors, which resulted in marks lost.

    That's why I think allocation of time and space for each topics in the lab is very important, which prompt me to raise the concern on the troubleshooting section.

    I still remember about 9 years ago when i do my ccie, the most basic question to ask is :" What problem are you trying to solve?" . If we can't even figure out the cause of the problem, then there is no way to find the solution.
Sign In or Register to comment.