Full Scale Troubleshooting Lab 1

Hello,

I just started with Full scale troubleshooting Lab 1 and just found out how difficult it can be especially finsihing it under two hours.

I jsut wanted to ask anyone for tips if there are ways to identify the issue if it is related to control-plane policing and EEM?  The troubleshooting Lab1  used a lot of this and it took me awhile to identify it, actually I found it by reading the full config which is very time consuming.

So I was wondering if there are debug commands for this?  Or you just make in part of the routine in your troubleshooting?

 

 

Thanks,

Jason

Comments

  • You could do something like this:

    show run | sec access-list|route-map|policy-map|class-map|event|access-class|drop|max

    This will let you if quickly if there is something that may be configured on the box on purpose to break a scenario. This is a double edged sword though, because there are many occasions where config like this is left on devices throughout the network to trip people up who only look at "show run" instead of doing actual troubleshooting. Troubleshooting Lab 1 is a prime example, there is config in places that does not affect any ticket. 

    I would only use something like this on a controlled set of devices, where I've already narrowed where I think the issue may be.

    The "tell tale" sign in Troubleshooting Lab 1 that there is somethign messing with the control-plane is that adjacencies bounce at a set interval. 

  • Thanks both, the approach seems good. 

    Since its time pressured i guess it really needs a structure approach.  I was just thrown off with the weird issues.

    On 22 Jun 2015 1:56 pm, "Martinl" <[email protected]> wrote:

    imageplucena24:

    You could do something like this:

    show run | sec access-list|route-map|policy-map|class-map|event|access-class|drop|max

    I would replace access-list with access-group , how about that?




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • <!DOCTYPE html>




    I do the same, but with a bit different command. I will include "event" and "drop" and "max" on my command now on.

     

    show run | sec -list|-map

     

    * -list  includes prefix-list also

    * -map includes all type of maps.

     

     

    Also, I turn logging on on console and buffer. Another tip is to check for variable names typos. Stuff like "default" versus "defaut". 

     

    show run | inc VARIABLE

     

    Paulo

    --


     

    Em Sáb 20 jun. 2015, às 10:11, plucena24 escreveu:

    You could do something like this:

    show run | sec access-list|route-map|policy-map|class-map|event|access-class|drop|max

    This will let you if quickly if there is something that may be configured on the box on purpose to break a scenario. This is a double edged sword though, because there are many occasions where config like this is left on devices throughout the network to trip people up who only look at "show run" instead of doing actual troubleshooting. Troubleshooting Lab 1 is a prime example, there is config in places that does not affect any ticket. 

    I would only use something like this on a controlled set of devices, where I've already narrowed where I think the issue may be.

    The "tell tale" sign in Troubleshooting Lab 1 that there is somethign messing with the control-plane is that adjacencies bounce at a set interval. 

     

     

     



    INE - The Industry Leader in CCIE Preparation


     


    Subscription information may be found at:


     


Sign In or Register to comment.