No doubt about it, IOS cannot be classified as an operating system that’s easy to master. However, those who have been using it for years have learned to appreciate its flexibility and the immense speed of its configuration and code execution. Please see previous article here.
CCNA Training – Resources (Intense)
In this article, I would like to present another set of IOS tips. Learning them is going to make you feel more confident with IOS and bring you one step closer to becoming an expert. Here are the tips I will cover:
- Disabling domain lookup.
- Preventing syslog messages from interrupting your typing.
- Faster way of saving your configuration in NVRAM.
- Creating command aliases.
- Using ‘debugs’ the way experts do.
Courtesy of /u/JoeBirds ‘s suggestion, here is the next tip:
Disabling domain lookup
Designers of IOS enabled domain name lookup by default. The command responsible for the name to IP address resolution is configured in the global configuration mode: ‘ip domain-lookup‘.
If you are a frequent IOS user, this feature can quickly become very annoying. In order to understand how it affects your workflow, let me show you a practical example. In the picture below, I have purposely mistyped the command. Look at the result:
Pic.1 – Domain-lookup (default).
Notice what happened. Mistyped commands are an invitation to open telnet sessions using the name you have provided that was not an actual command (simple typo). In order to do so, IP address must be learned via ip domain-lookup which means finding the DNS server and asking it about the address that represents your mistyped command. This happens if your switch or router has at least one IP address configured and the interface is active. It only works this way in the user exec mode (prompt: ‘>’) or privileged exec mode (prompt: ‘#’).
In my example, the router did not have the name-server’s address configured. Therefore, it tried to find any DNS server and resolved ‘showrun’ on the IP address using broadcast. After a few unsuccessful attempts it finally gave up and told me that the command was unknown and it could not resolve it to IP address. Here’s the worst part: this froze my console for more than 40 seconds!
If you are under time pressure (i. e. your boss is breathing at your neck) and you are in the middle of doing some troubleshooting in order to bring the network up, losing console/telnet or SSH access for more than five seconds seems like eternity, never mind forty or more seconds.
A quick solution to this problem, at least temporarily, is to disable this domain lookup. After you have finished diagnostics, you can always turn it back on. In order to disable it, type the following command in the global configuration mode: no ip domain-lookup. With this command in place, IOS is going to return access to your console immediately if you mistype the command in the user or privileged exec mode.
If you want to restore to factory default, just re-enable it by issuing: ip domain-lookup.
Below is another tip proposed by /u/CaptainIceman :
Preventing syslog messages from interrupting your typing.
Another feature a lot of users find a bit unfortunate is the fact that, by default, IOS sends all the messages to the console and displays them in the current line of the cursor. System messages, also known as ‘syslog’ messages, are not sent to VTY line (your telnet/ssh connections). If you want to see them on virtual terminal lines, you must issue terminal monitor command in the privileged mode like shown below:
Notice that the command is not used in the global configuration mode as you may expect. Sending these unsolicited messages to the line of the cursor more often than not interferes with your typing. Let me illustrate this below in picture 2. I have left the global configuration by using CTRL-Z (other options: exit or end). Then, I immediately started typing the command: show run. However, this has been interspersed with the system message.
Pic. 2 – Logging Synchronous disabled.
In such situations, you can repeat what you have already typed by pressing CTRL-R (press CTRL and still holding it, press the letter ‘r’). Alternatively, you can press TAB to have the system auto-complete the command.
There is a better solution still. You can instruct IOS to keep its unsolicited messages separate from the line where the cursor is currently located. This command works on both IOS enabled switches and routers. In the picture below you will find the configuration on the console and VTY lines.
Pic. 3– Logging Synchronous.
The second iteration of the command (on VTY 0 4 lines) in the above picture is only needed when you are remotely accessing your device through telnet or SSH and want to see the messages sent to the console by default (terminal monitor).
Another tip comes from /u/Detective_Colephelps :
Faster way of saving your configuration in NVRAM.
IOS command designers have changed the syntax of certain commands. One such command was introduced in IOS to save the running configuration kept in RAM memory into Non-Volatile RAM (NVRAM). This configuration is activated after the device is rebooted and is referred to as ‘startup-config’.
The command that saves the currently executed configuration into NVRAM looks like this:
router#copy running-config startup-config
There is another way of accomplishing the same goal:
I rarely use the latter option though. A much faster way of doing it is simply typing this:
The ‘wr‘ shortcut is an abbreviation of the older command that predates the famous ‘copy run start‘. Originally, we used the ‘write memory‘ command to achieve the same result. The simplest form of using this command is just ‘wr’. Notice that if you use it, IOS does not ask you if you want to name the file in NVRAM (the name must be ‘startup-config’). It names it startup-config by default.
/u/Justinsaccount proposed another useful IOS feature:
Creating command aliases.
This is one of my favorite features in IOS. Creating your own short names for some particularly long commands can be a huge time saver. Consider the following commands that most use very often:
router(config)# do show ip interface brief
router(config)#do show ipospf interface brief
Depending what IOS features you have enabled on your switch or router, you may deal with plenty of such commands. Consider two more examples which almost all network admins use very often:
router#show processes cpu sorted 5sec | exclude 0.00% 0.00% 0.00%
router#show archive config differences nvram:startup-configsystem:running-config | section exclude certificate
The first one shows all the processes affecting the CPU, which is similar to the ‘top’ command used on Unix/Linux platforms. The second compares configurations between RAM and NVRAM. If there are discrepancies between them, for example, if the admin did not save them, they will be reported.
Instead of typing all these keywords which is a time consuming and error-prone task, you can replace them with your own short aliases. First, I recommend that you check what aliases IOS uses by default so you do not change them accidentally:
Pic. 4 – IOS Default Command Aliases.
Now that we know which keywords to avoid (left hand side column), we can create our own. For instance, I would like to have the following aliases for the commands we have already used; of course, you can use completely different aliases than mine below. On the left are the commands, and on the right my proposed aliases:
showip interface brief | excluded unassigned = sib
showipospf interface brief = soi
show processes cpu sorted 5sec | exclude 0.00% 0.00% 0.00% = top
show archive config differences nvram:startup-configsystem:running-config | section exclude certificate = dif
You can configure them as shown below (global config mode):
R1(config)#alias exec sib show ip interface brief | exclude unassigned
R1(config)#alias exec soi show ipospfint brief
R1(config)#alias exec top show processes cpu sort 5sec | ex 0.00% 0.00% 0.00%
You are by no means limited to these commands. You can replace any long command this way. Look how some of my aliases work now:
Pic. 5 – Alias: Top.
Pic. 6 – Alias: Sib.
If you are excited by this feature, try not to overdo it by creating too many aliases. They could become hard to remember and may start to defeat their purpose.
And the last one in this article is from yours truly:
Using ‘debugs’ the way experts do.
There are two major diagnostic commands: show and debug. The former is safe to use in any situation, except for ‘show tech-support‘ which should be used after office hours. The latter can require extra power from the CPU. In other words, debug commands can be quite dangerous on production devices. However, some of them can be extremely useful, especially when your network or a part of it is down and you must bring it back up as soon as possible.
In order to use debugs in these rare situations, it is imperative that you learn these commands in the lab first. You must see what kind of output they produce and how to interpret it. Also, you must pay attention to how much information they send to the console. Some of them can be really lengthy. If you decide to use them, you should follow the method used by the majority of Cisco experts and professionals.
The general recommendation is that a debug command should not be logged to the console. The console is a high priority IOS process and sending a large output to it can impair the operation of the device. In addition to this, the output can amount to hundreds of lines sent every second and disabling debug may require an extra telnet or SSH session. Remember: the messages are not sent to VTY lines by default.
Here’s the list of steps before debug should be used:
– Check the utilization of CPU. If highly utilized, do not use debug commands.
– Disable logging to the console. Log the debug messages to the RAM memory (buffer).
– After collecting information, disable the debug. You can use the shortest available alias: u all, which stands for undebug all.
Let me illustrate the idea in practice. Suppose I want to collect information about an RIP operation on my router. After checking the utilization of CPU, which is not high (mine was 5% in the last five minutes), I can do the following to safely obtain information from the debug:
Pic. 7 – Disabling Logging to the Console.
Pic. 8 – Logging to the Buffer.
Pic. 9 – Enable Debug/Collect Info/Disable Debug.
Pic. 10 – Display the debug.
While logging debug messages to the buffer, make sure you let it run for some time. Some technologies will log information immediately and running it for just few seconds will do. Others may require a bit more time to collect the required information. For instance, RIP protocol sends and receives updates every 30 seconds. Once you think enough information has been logged, disable the debug and bring the previous configuration.
R1(config)# no logging buffered
The above command is going to flush the information stored previously.
R1(config)# logging console
This will resume logging messages to the console 0 port as per default.
I hope you find these tips useful and they will contribute to your better understanding of IOS. In the next article I will address more propositions and suggestions from around the internet.