06-16-2015 11:48 AM
Troubleshooting with Speed and Confidence
Starting June 23 through - July 3rd.
During the live event, Routing and Switching, subject matter expert, Kevin Wallace, will cover a number of advanced topics on troubleshooting best practices. Troubleshooting is not only a fact of life for network engineers it consumes a significant percentage of their time. Also, many troubleshooting efforts are accompanied by the urgency of getting a production system back on-line, resulting in an emotionally packed episode. To help you more effectively deal with the inevitable troubleshooting scenarios you’ll encounter, this webcast equips you with a 7-step troubleshooting model that allows you to confidently approach and deal with any troubleshooting situation. You’ll also be equipped with efficiency tips for using Cisco IOS “show” commands, and the webcast concludes with a group exercise where you’ll help troubleshoot an issue being experienced on live gear.
Featured Speaker
Kevin Wallace CCIEx2 No. 7945 (Route/Switch and Collaboration), is a Certified Cisco Systems Instructor (CCSI #20061), and he also holds multiple Cisco professional and associate-level certifications in the Route/Switch, Collaboration, Security, Design, and Data Center tracks. With Cisco experience dating back to 1989, Kevin has been a network design specialist for the Walt Disney World Resort, an instructor of Cisco courses for Skillsoft, and a network manager for Eastern Kentucky University. Currently, Kevin produces video courses and writes books for Cisco Press/Pearson IT Certification (http://kwtrain.com/books). Also, he owns and operates Kevin Wallace Training, LLC (http://kwtrain.com), a provider of self-paced training materials that simplify computer networking. Kevin holds a Bachelor of Science degree in electrical engineering from the University of Kentucky, and he lives in central Kentucky with his wife (Vivian) and two daughters (Sabrina and Stacie).
Need more information? Have more questions? Find more experts and topics by visiting https://supportforums.cisco.com/expert-corner/events ">https://supportforums.cisco.com/expert-corner/events.
**Ratings Encourage Participation! **
Please be sure to rate the Answers to Questions
06-24-2015 03:28 AM
Someone asked yesterday if it'd be possible to include and exclude strings in show commands.
I tried some regex I pulled from SO like the following to no avail
http://stackoverflow.com/a/1880637/
http://stackoverflow.com/a/5313996/
http://stackoverflow.com/a/23944384/
I always get this message
% ?+* follows nothing
% Failed to compile regular expression.
Could you provide some insight?
06-25-2015 06:55 AM
It seems that the only way to use regular expressions with show commands is by piping the output of the show command to an output modifier that uses a regular expression. Here are a couple of examples.
Example #1:
A router has three loopback interfaces:
Loopback0 192.168.1.1 YES manual up up
Loopback1 192.168.2.1 YES manual up up
Loopback3 192.168.3.1 YES manual up up
I want to issue a show command that will show the ip address commands where the first two octets are 192.168 and the third octet contains either a 1 or a 2. To do that, we can use the bracket regular expression.
R1#show run | i ip address 192.168.[12].
ip address 192.168.1.1 255.255.255.255
ip address 192.168.2.1 255.255.255.255
Notice that the output from this commands does not show the ip address 192.168.3.1 255.255.255.255 command.
Example #2:
Let's say I want to see all subcommands (i.e. commands given in a non-global configuration mode) that begin with the command no. If I give the command show run | i no, we get both global commands and subcommands that begin with no, and any other command containing the string of no.
R1#show run | i no
no aaa new-model
no ip domain lookup
no ipv6 cef
no ip address
no ip address
no ip address
no ip address
no ip address
no ip address
no ip http server
no ip http secure-server
logging synchronous
However, using the ^ regular expression, we can say only show lines beginning with a space and then the word no.
R1#show run | i ^ no
no ip address
no ip address
no ip address
no ip address
no ip address
no ip address
I hope that helps!
06-25-2015 07:06 AM
Thanks, but do you have any idea why more complex regex aren't allowed?
06-25-2015 07:15 AM
No. I haven't personally run into that situation. Could you please provide a sample show command you issued that resulted in an error.
Thanks!
06-25-2015 09:05 AM
I was trying with `show ip interface brief` filtering addresses and excluding down interfaces. You can try any of the approaches in the stackoverflow links above. It seems regex lookarounds are not support by IOS (or I'm wrongly writing the regex, although the message refers a compilation error, which again could be me or the IOS). I used it in IOSv and IOL with same result, don't know if they have this feature crippled though.
06-25-2015 10:25 AM
Ah, I see what you mean. It does appear that compound regular expressions, like those in the examples you provided, do not work following an output modifier.
While this does appear to be a limitation, I guess the good news is, we usually use output modifiers as shortcuts to help us find information quicker. So, it would be rare (at least it would be rare for me) to use a complex regular expression with an output modifier.
Great observation though! I've taught this content for many years, and no one has ever mentioned that issue.
06-25-2015 01:45 PM
I was trying with `show ip interface brief` filtering addresses and excluding down interfaces
Hope Kevin doesn't mind me adding to this thread.
The regexes used in those links are not supported as far as I know because IOS only supports a subset of regexes but it doesn't necessarily mean you can't do an include and an exclude because you may be able to express it as a regex that IOS does understand.
A somewhat contrived example would be you have the following interface IPs on your router together with their interface state -
10.10.10.1 up
172.16.5.1 up
192.168.3.1 up
192.168.7.1 down
192.168.8.1 up
you want to include any interfaces with a 172.16 or a 192.168. IP and then exclude from that list any interface that is down -
"sh ip int brief | include (172.16|192.168).*up"
should show 172.16.5.1, 192.168.3.1 and 192.168.8.1 only.
You can make them more complex as IOS does, as I mentioned, support a limited set of regexes and the above is only really an example which may or may not be the sort of thing you are trying to do.
Edit - if it says failed to compile it's usually because you used a regex IOS doesn't understand.
You generally need to experiment to see what it will and won't accept :-)
Jon
06-25-2015 01:45 PM
Thanks Jon!
That's awesome information. I tried it out, and it does indeed work to include specific IP addresses for interfaces in the "up" state. Thanks for contributing!
HQ#show ip int brief
Interface IP-Address OK? Method Status Protocol
Embedded-Service-Engine0/0 unassigned YES NVRAM administratively down down
GigabitEthernet0/0 unassigned YES NVRAM up up
GigabitEthernet0/0.100 192.168.1.77 YES NVRAM up up
GigabitEthernet0/0.200 10.10.120.1 YES NVRAM up up
GigabitEthernet0/0.300 10.10.130.1 YES NVRAM up up
GigabitEthernet0/1 unassigned YES NVRAM administratively down down
GigabitEthernet0/2 unassigned YES NVRAM administratively down down
Serial0/1/0 unassigned YES NVRAM up up
Serial0/1/0.1 10.10.33.1 YES NVRAM up up
Serial0/1/0.2 10.10.33.129 YES NVRAM up up
Loopback0 10.10.32.1 YES NVRAM up up
HQ#show ip int brief | include (10.10.32|10.10.33).*up
Serial0/1/0.1 10.10.33.1 YES NVRAM up up
Serial0/1/0.2 10.10.33.129 YES NVRAM up up
Loopback0 10.10.32.1 YES NVRAM up up
06-25-2015 02:11 PM
Thanks Jon, more than excluding/including your approach with regular expressions is refining the output through multiple-character patterns, multipliers and alternation to achieve the same output. Maybe basic regex filtering will do in most cases, even though trickier.
06-25-2015 10:52 AM
As of 15.0(1)M the `show parser dump` command has been removed. Is there any non-documented replacement you know of? :)
06-25-2015 11:01 AM
While that was a handy command, I've heard that during the commands "parsing," it would sometimes get into an infinite loop, causing high CPU utilization. My guess is that Cisco removed it for that reason. Unfortunately, I'm not aware of an alternate command.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide