Someone has recently asked an interesting question - can you disable the reload command? Although I would strongly discourage you from doing that (after all, every router I've ever worked on since a venerable MGS running IOS 10.0 had to be reloaded every now and then), here's what you can do:

• define an alias for the reload command that does something else. For example, alias exec reload show ip interface brief. While this would remind a careless operator, it would still not prevent someone using an abbreviation like relo to reload the device.
• Use TACACS+ command accounting and disable the reload command on the TACACS+ server. The benefit of this approach is that you can do it on user-by-user basis ... but of course you need TACACS+ server, RADIUS will not do.
• Disable the reload command with the Embedded Event Manager applet.

Cisco IOS long had the ability to define local users that could be used to authenticate incoming telnet sessions or dial-up connections (using PAP or CHAP). Until IOS release 12.3, the passwords assigned to local usernames were encrypted using the weak (type 7) reversible encryption. With crack tools widely available on the Internet, there's obviously almost no protection offered by this encryption type.

With IOS release 12.3, Cisco introduced enhanced password security and the new username user secret password command which uses strong (type 5) encryption, making local user passwords secure. Of course, such usernames cannot be used in scenarios where you need access to cleartext password (for example, CHAP authentication).

Every introductory Cisco course tells you that you can stop any IOS command (for example, ping or traceroute) with the Ctrl/^ (also written as ^^ or Ctrl-Shift-6) escape character. What they usually forget to tell you is how to do that on non-US-ASCII keyboards or with telnet programs that do not want to recognize weird control characters.

The trick is simple - if you cannot generate ^^ (ASCII code 30), change the escape character. You can change it for the current session with the terminal escape-character char exec-level command or permanently with the escape-character char line configuration command. For example, to set the escape character for the current session to ctrl-C, use terminal escape-character 3 command.

Note: this article is part of You've asked for it series.

In certificate-based IPSec deployments, the router has to establish an approximately valid date and time before it can use a certificate to establish IPSec session (as most certificates were issued after March 1st 2002, which is the default initial value, they are not valid until the router has acquired an approximately correct date-and-time).

This requirement is not a problem for most router models, as they have battery-backed hardware clock that continues running even when a router is reloaded or powered down. The low-end models, though, have a problem, as they always start with the default date/time after the reload. These devices have to get their time from an NTP/SNTP server before being able to establish the IPSec session. If the (S)NTP server is only accessible across the VPN, you have a nice chicken-and-egg problem.

I've got an interesting question a while ago: Do new Cisco routers still use CBAC?

Of course they do, it's just been renamed. The marketing department has decided that Context Based Access Control (CBAC) does not sound nearly so nice as the Cisco IOS Firewall. Even the command structure hasn't changed, you still use the ip inspect commands to configure it, unless, of course, you have IOS release 12.4(6)T or newer, where you can use zone-based policy firewall configuration.

This article is part of You've asked for it series.

Developing Embedded Event Manager (EEM) Tcl policies is "a bit" tedious task. Usually you would edit the source file on an external workstation, then you have to download it into the router (IOS will not read EEM policy from an external source), re-register it with EEM (when you register a policy it gets copied from the source file into system:lib/tcl/eem_registered_scripts directory) and test it. To automate this process, I've written a small EEM applet that does the tedious steps automatically.

With IOS file system (IFS) introduced in IOS release 11.3AA (integrated in 12.0), IOS got the more command that displays any local or remote file that you could specify with IFS. The obvious use of the more command would be display of startup configuration (more nvram:startup-config), but you could also display built-in Tcl EEM policies (for example, more system:lib/tcl/http.tcl) or remote router configurations (for example, more tftp://host/cfg-file). But that's not all, you could even troubleshoot web servers and display HTML generated by the web server (for example, more http://192.168.0.2/index.html).

Note: IOS documentation claims that the show running command is obsolete and that you should use more system:running-config. This is not true, as the show running command has a number of interesting options that are not implemented with the more command.

The IOS command line interface has long included unix-style pipes that you could use to limit the output generated by the show commmands. Initially, the only available filters were begin (include everything after the first regular expression match), end (stop the output at the RE match) or include (include only matching lines).

IOS release 12.3(2)T (integrated in 12.4) brought us a few new filters, among them the section filter that includes or excludes whole sections (start of section being defined by a line with no leading space). You can use this filter to focus on parts of your router configuration. For example, to display only the routing protocols configuration, use show running | section include router command.

Of course, you can go a step further and define an alias, for example alias exec events show running | include ^event manager configuration command defines the exec-mode events command that lists all EEM applets.

Embedded Event Manager is a bit picky about the location of the EEM Tcl policies: although they are loaded into RAM when registered, they have to reside on the router itself. If you have a low-end router with no flash disk (I'm using 2800-series routers) or USB flash and you don't want to mess with your flash: device (to prevent accidental erasure), the only other place left is NVRAM:. Surprisingly, it works.

If you need interface counters on subinterfaces or virtual interfaces, you can emulate them with an empty policy-map, for example:

policy-map Count
 class class-default
!
interface Serial0/0/0.100 point-to-point
 service-policy input Count
 service-policy output Count

The service policy counters are then inspected with the show policy-map interface name command:

a1#show policy-map interface Serial 0/0/0.100

 Serial0/0/0.100

  Service-policy input: Count

    Class-map: class-default (match-any)
      10 packets, 840 bytes
      1 minute offered rate 0 bps, drop rate 0 bps
      Match: any

  Service-policy output: Count

    Class-map: class-default (match-any)
      61 packets, 7084 bytes
      1 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Recently I had to investigate whether Cisco Router and Security Device Manager (SDM) uses a default username/password, so I was forced to figure out how exactly the SDM works. The minimum functionality needed on an SDM-enabled router is preconfigured Ethernet interface, HTTP server and (optionally) DHCP pool.

In his excellent question, Matt reminded me of (almost prehistoric) days when static routes pointing to a connected interface (not IP next-hop) had administrative distance zero. I also remembered that we've had interesting routing problems as those static routes actually behaved like connected routes (and were redistributed into routing protocols with redistribute connected command).

IOS release 12.3T introduced an interesting concept: static routes that are used only if an object a router is tracking (for example, next-hop router) is available. Named reliable static routing, this feature allows you to constantly ping next-hop router (or any other IP address) and use the static routes only if the tested destination is reachable.

While the reliable static routes are easy to understand and configure, a careless implementation can lead to interesting routing loops or other instability problems. You'll find the needed in-depth design and implementation guidelines in my IP Corner article Small Site Multi-homing (which is one of the prime applications for reliable static routing) in sections Not-so-Very-Static-Routes and End-to-End Connectivity Test.

You can find a variety of sample EEM scripts on Cisco forums. Quite a few of them are really interesting, illustrating various aspects of using TCL to program EEM (as well as what can be done with EEM to make your life simpler).

Cisco IOS supported Frame Relay switching (emulation of a Frame Relay switch) for a very long time. First they've implemented local switching, then remote switching over a GRE tunnel. With the introduction of generic Layer 2 transport across a layer-3 backbone (L2TPv3 or AToM), Frame Relay switching got integrated into the new infrastructure, but never implemented completely ... that is, until release 12.0(27)S and 12.4(11)T which finally supports local switching in the new architecture. We've also got a few extra goodies: now you can do DTE-to-DTE switching (interconnecting two Frame Relay switches with a router) or same-port switching (switching two DLCIs terminating on the same router port).