In IOS release 12.3(1.4), Cisco has added Goodbye message to EIGRP protocol. Previously, whenever the router would need to tear down EIGRP adjacency (for example, due to changed summary addresses), it would simply erase the neighbor from its EIGRP neighbor table and pretend the it’s just encountered a new neighbor on the next hello message. As the adjacent device does not participate in this charade, it becomes confused resulting in delayed adjacency establishment. The whole process is described in details in my EIGRP book, which is unfortunately out-of-print and is available only as an on-line book on Safari.

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.

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.

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).

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.

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.