It's a bit embarrassing: I've posted a hint on how to execute commands after a router reload and Aamer figured out something I've wanted to have for years: the ability to automatically start debugging after the router reload.

The easiest way to remove all settings from an interface is to use the default interface configuration command. For example, if you've configured Frame Relay interface with subinterfaces ...

interface Serial0/0/0
 no ip address
 encapsulation frame-relay
 load-interval 60
!
interface Serial0/0/0.100 point-to-point
 bandwidth 2000
 ip address 172.16.1.1 255.255.255.252
 ip load-sharing per-packet
 ip ospf cost 50
 frame-relay interface-dlci 100

... and have erase all interface-specific configuration, the ...

rtr(config)#default interface serial 0/0/0
Building configuration...

Interface Serial0/0/0 set to default configuration

... gets you there. As you can see, after the configuration change, the main interface has no IP address and the subinterface is deleted.

A while ago a reader has asked me whether you could modify an IP access-list when the interface IP address changes. While that's definitely doable with Tcl and Embedded Event Manager, it's not a trivial task, so I've tried to understand why he would need such a functionality.

The answer was quite interesting: he's running NTP on his firewall router and thus needs to accept incoming NTP responses from an external NTP server. While that could be easily achieved with the following configuration (only the relevant bits-and-pieces are shown), he didn't want to make the access-list too generic (allowing NTP from the external server to any IP address).

It makes perfect sense in hindsight, but I was nonetheless pleasantly surprised: when the router acting as a DHCP client (configured with the ip address dhcp interface configuration command) receives the DHCP reply packet containing the default gateway option (option #3), it installs a static default route toward that next-hop.

Even better, the default route is installed with the administrative distance 254 (floating static route), making sure that the default route you’ve configured manually or the default route received via a routing protocol are not overwritten.

The IOS documentation claims that the quiet mode the router enters after a series of login failures blocks all telnet (or ssh) sessions as well as HTTP requests. Unfortunately the latter is wrong; you can execute any HTTP request on the router during the quiet mode.

If you want to block HTTP requests during the quiet mode, you can use EEM applets to change the HTTP server configuration when the quiet mode is started and completed.

If you use UDP-based syslog servers, you might have noticed that they miss a message or two generated during a router reload (particularly when the syslog server is on a directly connected LAN). The reason is simple - when the first message is sent to the syslog server, its MAC address is not yet in the router's ARP cache and the message is dropped. To prevent the message loss, you can use the logging server-arp configuration command (introduced in IOS release 12.3T), making sure that the router sends ARP request to the configured syslog server(s) before generating the first syslog messages.

With the introduction of DNS views in IOS release 12.4(9)T, a number of additional DNS-related configuration commands were introduced. As IOS still supports all the older configuration commands (and the DHCP-acquired DNS servers), the results are not as obvious as one would hope. The IOS documentation is pretty explicit (a nice surprise :), but I still had a bit of a headache figuring it all out, so you might be in the same position.

After you've configured the Warm Reload, you can also perform warm IOS upgrade/downgrade (assuming that you already run at least the IOS release 12.3(11)T or 12.4). The Warm Upgrade functionality loads the new IOS image into the main memory, decompresses it and starts it, significantly reducing the downtime (in my case, a 2800 router reloaded in 62 seconds as compared to 415 seconds it took to load the image from a locally-attached server).

Apart from the downtime reduction, the warm upgrade (requested with the reload warm file url command) has a number of other benefits:

• The new image does not have to be stored in flash
• You don't have to change the boot image with the boot system command
• If the new image crashes, the router will revert to the original IOS image stored in flash

Testing Embedded Event Manager (EEM) Tcl policies is a convoluted process:

• Source file is usually edited on a general-purpose workstation.
• The file has to be downloaded to router's local storage (EEM does not register non-local policies).
• The new version of the EEM policy has to be registered with EEM with event manager policy configuration command
• After all these steps, the new policy can be tested.

While you can use EEM applet to automate this process, slightly more flexible approach (you can specify the policy name to be replaced) can be implemented with Tcl script:

In one of my previous posts I've been writing about the problems I had when the DHCP client on Cisco IOS was messing up the DNS name-servers I've configured manually with the ip name-server configuration command. As is quite usual in Cisco IOS, there's one more know to turn to fix this - the Configurable DHCP Client feature introduced in IOS release 12.3(8)T.

To stop the router's DHCP client from overwriting the static name-server settings, use the no ip dhcp client request dns-nameserver interface configuration command (you can also exclude a few other DHCP options).