Here we go again with more IOS tips. Although the examples are shown on routers, they also work on IOS-based switches.
To get a router to begin using the new IOS after an upgrade, you either have to power-cycle it or execute the privileged mode “reload” (software restart) command:
Let’s imagine that we’ve established a Telnet (or SSH) session to a router for some remote-control configuration. What if we make a mistake that not only terminates our session, but also prevents us from reconnecting, such as a misconfigured access list? The result could be a CLE (Career-Limiting Event).
To prevent this, we connect to the router, instruct it to perform a reload in five or ten minutes, then make the changes to the config. Assuming that all goes well, we save the config, and cancel the reload. If, on the other hand, all does not go well (and we cut ourselves off), the scheduled reload will occur. After the router reboots, it will come up with the old config, allowing us to reconnect and try again.
You can schedule reloads for the future by using the in option. For example, to reload five minutes from now:
- Router#reload in 5
You can also reload at a certain time and date with the at option. For example, to reload on August 31 at 1:00 am:
- Router#reload at 1:00 31 august
To display a reload scheduled via the in or at options:
- Router>show reload (“s rel”)
When there is one minute remaining before the scheduled shutdown, the system will display messages to all active lines (console, aux and vty). The system will also display a message just prior to the reload, but at that point it’s too late to stop the reload from occurring.
To cancel a scheduled reload:
- Router#reload cancel (“rel can”)
You should see a message confirming that the shutdown was aborted. Make sure that you see this message, because if you mistyped the “cancel” command, the reload clock is still running. Note that you can view a scheduled reload from user mode, but you must be in privileged mode to schedule or cancel a reload.
I realize that every programmer thinks that his or her way of doing things is the best way, but I often wish that they would make a little more effort to be consistent. A case in point is the “Traceroute” command, which exploits the TTL field in the IP header to determine the routers traversed on the way to a specified destination. Like UNIX, the Cisco IOS implementation of “Traceroute” uses UDP with high port numbers, whereas Microsoft’s implementation uses ICMP Echo Requests (“Pings”). The result of this is that a trace from a Cisco machine may make it through firewalls and router access lists, while a trace from a Microsoft machine may not, or vice-versa.
Another difference is that Cisco’s command is traceroute (which can be shortcut as trace or even tr) and Microsoft’s command is tracert, which can’t be shortcut at all. What makes this really annoying is that Cisco’s traceroute (or trace or tr) and the like don’t work on a Microsoft machine, and Microsoft’s tracert doesn’t work on Cisco. This means that if you work in a mixed Cisco/Microsoft environment (as lots of us do), you have to think about which machine you’re on every time you do a trace.
Cisco has given us a way around this, though … the “alias”. What we can do is set up an alias on the Cisco, so that typing the Microsoft tracert command on a Cisco machine will invoke the Cisco traceroute. First, create the alias:
- Router(config)#alias exec tracert traceroute
Now, whenever the router (or switch) sees the string tracert from an Exec prompt (that is, user or privileged mode), it substitutes the string traceroute in its place. You can now execute the tracert from user or privileged mode:
- Router>tracert 220.127.116.11
From privileged mode you can also invoke the extended tracert, which like extended ping, will prompt you for additional information. Granted, we’ve just “dumbed-down” Cisco IOS to the Microsoft level with regard to trace, but at least now tracert will work on both platforms. The other option, as mentioned before, is to just use tra on a Cisco and tracert with Windows.
By the way, if you work in a Microsoft environment, don’t forget about the Windows pathping command which is similar to Cisco’s extended trace, but using ICMP echoes, of course. Try this on a Windows machine:
- C:\WinXP>pathping /?
The alias feature of IOS can be used for other things. For example, if you make frequent use of the show ip ospf neighbor detail command, you might have discovered that you can shortcut it, like this:
- Router#s ip o n de
Or, you could set up an alias, such as siond, from global config mode:
- Router(config)#alias exec siond show ip ospf neighbor detail
Now you can use siond (or whatever you set up) in place of the full-blown command, including any options, such as:
- Router#siond fa0/0
To display what a particular alias represents:
- Router#siond? (with no space between the alias and the question mark)
To display all existing aliases:
- Router#s alias
And, of course, to delete an alias, precede it with “no” in global config mode:
- Router(config)#no alias exec siond show ip ospf neighbor detail
Author: Al Friebe