4 Replies Latest reply: May 1, 2010 8:56 AM by mwhisen RSS

    Interpret Troubleshoot tickets

    Richard Gosen

      Hi all,


      Last week I took the R&S exam and failed my first attempt. When I was done with the Troubleshooting section I thought that this was a 10/10 score.

      The next day I received my score report and I have failed this section.


      Maybe someone can give some clarification about how to interpret these tickets.




      router_x cannot reach router_y


      In the transit path from R_x to R_y there could be an access-list that is blocking some traffic. When you delete this access-list there is connectivity between these routers. So There is reach ability. This sounds ok, but is this the way Cisco wanted you to resolve this question?


      So the questions do not tell you, what you can do. (delete, modify, or add in the existing configuration)


      Kind regard,


      Richard Gosen

        • 1. Re: Interpret Troubleshoot tickets
          Scott Morris - CCDE/4xCCIE/2xJNCIE

          I suppose that would depend on what "reach" was.  Pings?  Traceroute?  HTTP?  Telnet?


          I'd look at:


          1. Ask the proctor

          2.  Ping first (fastest) and then look at traceroute and telnet/ssh as additional tests (UDP and TCP respectively)


          That will help you if there were MULTIPLE things wrong.



          • 2. Re: Interpret Troubleshoot tickets
            Richard Gosen

            Hello Scott, thanks for the reply.


            What I meant to ask is: what are you allowed to do to solve an issue?

            E.g. remove a blocking access-list completely or leave the access-list as-is and somehow find a way to get the traffic across?

            Or another example is: the ticket is to solve an ospf neighborship. Is it enough to get the ospf neighbors to talk to each other or do you have to look for the implications that the ospf neighborship might have for the rest to the network? Redistribute the newly learned routes e.g.

            • 3. Re: Interpret Troubleshoot tickets
              Scott Morris - CCDE/4xCCIE/2xJNCIE

              Well, in theory, you should be able to do ANYTHING to fix it.  Just don't break another task...  e.g. there may be a later ticket that talks abotu blocking SMTP traffic or something like that, so completely removing the ACL would be unhelpful.


              Otherwise, sure...  it's fair game as far as I'm concerned.  Asking the proctor is always the best bet, but I'd think they'd tell you that as long as you don't break any defined rule or other ticket's expectation then you are good to go.


              As for redistribution and things like that, I'd go for reachability.  Did the ticket say there's something wrong with OSPF and R1 can't reach R10?  It may be getting a neighbor AND redistributing/network command to get reachability...  So you'll have to read the whole scenario to guess how far.


              I wouldn't not OVER-solve though...



              • 4. Re: Interpret Troubleshoot tickets



                Caution on any specifics on the exams. However, one should be able to apply foundational problem analysis to the scenerio.  For theoritical examples, lets say that you have a Frame network, I could think of a condition that could have a couple items incorrect that could lead to a number of reach issues...


                First the frame is on physical interfaces, non-broadcast and they want to have a DR election using Unicast neighbor statements. However, if you do a show ip ospf neighor on the hub, you would see a say a FULL/DR and FULL/DROTHER. to get full routes, one may have to set the interface ip ospf priority to 0 on the spokes so that both neighbors become FULL/DROTHER... (I know I have personally gotten bit on this in my studies)


                Or they may have this worked out, but one of the OSPF spokes has a loopback that is not in the routing table, so looking and OOps, one forgot to add no auto summary on the OSPF on that one spoke... presto again...


                Now I have not yet done all the troubleshooting studies that I plan, but I think that the approach that Scott lays out is a good one. I would look at all the trouble shotting questions and see what all the examples were. Likely I would see a number of potential routing issues. So then one could use TCLSH and log into each router and get the output of the show ip alias (CTRL+select) and then create a script that can easily be run on the routers to check full reachability (again at least for ping)...


                It could be an ACL or it could be some policy based routing, etc... The objective I think is to resolve that specific problem, without making one of the next troubleshotting questions even more complicated and complex. Always take the time to read the entire scenerio. Action you take in STEP 1, which may be resolvalbe in more than 1 way, can cause issues later that makes step 7 so complicated that you can not resolve thta one.


                Sorry to hear that you did not achieve the desired results. I know that there are some assessments with mentor guide and answer keys on the 360 program and several excellent sources of training material  by what I call the big 4. I doubt anyone is better or worse than the other, they all have successful results, so it goes to the cost, support, ability to interact, etc that may make your selection.


                The one component that has helped me the most if to take a step back and not attempt to resolve the issues in a serial manner. Rather to look at the whole and attempt to Spot the issue, what happens when I do X. Just like at the end it talks about redistribute the newly learned routes... Careful, what could happen? Well if you redistribut routes, is there another location in the topology where routes get redistributes back to the point one could create a loop, or a blackhole? You may have to place unique conditions on the route, or make sure that route while redistriute on Rx is not on Ry, else it breaks Rz reach.


                I find the troublshooting more inticing than just plain configuration... but I also know that in the plain configuration that they intentionally introduce trouble shooting if you take the simplistic approach... It is never what it seems. But it is what it is...