Ethan Banks Not writing about IT.

A Script for the “Troubleshooting” Section?

A

The lab exam might have a troubleshooting section. NMC DOiT labs did not cover troubleshooting, so I never developed a habit for quickly identifying issues. The IEWB Vol.3 series features troubleshooting sections. I’m trying to nail down a simple script that I can run against the rack to find common problems quickly. Here’s a summary of the “troubleshooting” problems I recall seeing thus far:

  • Incorrect IP address.
  • Incorrect subnet mask.
  • Rouge secondary IP address.
  • Incorrect SVI vlan number.
  • Rogue routing protocol.

A simple command set to ferret these out could be this:

show run | include interface|ip address
!
show ip protocols summary

You might have to do one command at a time, if the device has a lot of interfaces. The output will show you the interface with assigned IP addresses and masks. A “show ip interface brief” won’t show you secondary IPs or masks. Let’s focus on Fa0/0.13 in this example.

Rack1R1#conf t
Rack1R1(config)#interf fa0/0.13
Rack1R1(config-subif)#ip address 1.2.3.4 255.0.0.0 secondary

Rack1R1(config-subif)#^Z
Rack1R1#show ip interface brief | e unassigned
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0.13 204.12.1.1 YES manual up up
FastEthernet0/0.16 145.1.16.1 YES manual up up
FastEthernet0/0.136 145.1.136.1 YES manual up up
Loopback0 150.1.1.1 YES manual up up
Rack1R1#show run | include interface|ip address
interface Loopback0
ip address 150.1.1.1 255.255.255.0
interface FastEthernet0/0
no ip address
interface FastEthernet0/0.13
ip address 1.2.3.4 255.0.0.0 secondary <== There’s the rogue IP address…
ip address 204.12.1.1 255.255.255.0

interface FastEthernet0/0.16
ip address 145.1.16.1 255.255.255.0
interface FastEthernet0/0.136
ip address 145.1.136.1 255.255.255.0
interface FastEthernet0/1
no ip address

You’ll also get a breakdown of routing protocols running on the router. If there are no rogue routing protocols enabled, your output should look similar to the following:

Rack1R1#show ip protocols summary
Index Process Name
0 connected
1 static
Rack1R1#

To compare, see the output when I enable some routing protocols:

Rack1R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R1(config)#router rip
Rack1R1(config-router)#exi
Rack1R1(config)#router ospf 1
Rack1R1(config-router)#exi
Rack1R1(config)#router eigrp 1
Rack1R1(config-router)#exi
Rack1R1(config)#router bgp 1
Rack1R1(config-router)#exi
Rack1R1(config)#exi
Rack1R1#show ip protocols summary
Index Process Name
0 connected
1 static
2 rip
3 ospf 1
4 eigrp 1
5 bgp 1

Rack1R1#

What else could you add to my little script from your dealings with troubleshooting sections?

9 comments

  • Ethan..if I can make an observation I believe you are overcooking things. You will never come up with a script that will cover everything so just don’t bother. In the lab your best friend is time management! You already know a great deal..certainly enough to give you a shot at passing. Spend your remaining time working on the basics and increasing your speed there..and the rest of the time on DocCD awareness to look up cryptic things. There are many easy marks in the real lab which you can miss out if you overcook preparation…it will overcook your approach on the day! So far as ‘troubleshooting’ goes..just spend some time reflecting on the lab you have been handed on the day and try to spot the issues.

    Good luck!

  • You make a good point. I’ve found that most of the problems like addressing or bogus VLAN assignments reveal themselves anyway. A link doesn’t work, you dig in to find the problem, and spot the issue.

    I need all the luck I can get right now. How I think I’m going to do on the lab goes through cycles of up and down. I’m definitely in a “down” cycle. Like I keep hitting my head against a wall that won’t give.

  • Interesting post. I do have a question though. When you say “Troubleshooting” section do you mean that the lab before you even get started has “mistakes” configured such as secondary ip addresses, rogue routing processes, incorrect subnet masks etc. or are these the mistakes that the CCIE canidate makes while configuring and then must troubleshoot later on.

    I had never read anything on the lab including mistakes up front so I would assume the latter, but I just wanted to double check because that would certainly make it harder.

  • My understanding from both InternetworkExpert.com workbooks and Narbik Kocharians bootcamp is that the rack you get at the actual lab might have a few misconfigurations you’re supposed to find. If so, this will be identified by a “Troubleshooting” section that is worth a point or two. So no, we’re not talking about mistakes that you or I might make, but rather problems Cisco inserted into the lab on purpose.

    And I don’t mean that this magically happens during the lunch hour! If there is a problem, it’s in the initial configuration only, and there’s a section in your lab exam that tells you there are issues for you to discover. No surprises or secrets, all very “up and up”.

  • Wow, didn’t know that. Would you suppose that the mistakes that are in the lab would affect many of the tasks that you must complete so that if you do not find them you not only lose the points for your troubleshooting section but also for countless other tasks that depeneded on those mistakes being found?

    btw, I took your reccomendation on the soup to nuts workbook. Haven’t gotten it yet, but I am anxiously awaiting its arrival.

  • I’m impartial to “sh ip int | i lin|/[0-9]” for viewing sub-ints.
    You can tack on “|ena” to see what kind of madness the interface is capable of.

    This one doesn’t seem to get a whole lot of press but I find it invaluable when working with OSPF: sh ip ospf int br

    I heard that the lab could have partial configs that you need to deal with. (I think the source was Scott Morris at IPExpert.) That would certainly take things to a higher level — and yet it really is the most likely situation a newly minted CCIE would experience in the real world.

  • that second command should be: sh ip ospf 1 int br
    (1 being the OSPF process ID)

    one other thought… in the early days we were taught not to look at the config too much. If at all possible, try to find a show command that confirms what’s in the config. Troubleshooting epistemology… first focus on what’s happening not on what you want to have happen.

  • Ethan
    Instead of running a script on every router, i found that easy method of troubleshooting is problems as you go.
    For instance, before any task we do on the router we can check

    sh runn | inc ip subnet | ip classless | ip routing
    sh ver | inc Config (For config register)

    to see if any defaults are changed or not.
    IP addressing is never going to be a problem as such, because say configuring a FR network on int s1/0, the first thing we can do is to
    sh runn int s1/0
    to see what is configured before proceeding. It wont take more than a second and sometimes if something is pre configured correctly, might save us some time anyway:) It’d resolve ID addressing and sub addressing problems.
    And cant say about you but during a lab, I at least issue sh runn | b router a dozen times, any rogue protocols can be detected and cleared easily as we go further.
    Infact the most trouble I ever had troubleshooting was because initial config turned ip routing off on a router and I just couldn’r understand why my FR ping is not working when mapping and everything else was fine. Even debug fram packet in that case isnt much helpful:)

    Basically I believe that worst initial config problem can be changing a default value.
    Addressing etc will never be a problem as these things will be checked a thousand times anyway for each route, for each L2 circuit etc.

  • just a tip barooq… try “sh run | s router” and “sh run | s int” to see just the right stuff.

    I like your idea for checking the config-reg…. nothing like the feeling of staring at the boot prompt after a reload. Ugh.

By Ethan Banks
Ethan Banks Not writing about IT.

You probably know Ethan Banks because he writes & podcasts about IT. This site is his, but covers other stuff.

Get the details on his about page.