Cisco has released security response acknowledging that the IPS software does not properly handle a rarely used Unicode encoding. Reading the security notice you might be left wondering what's going on. Here's the whole story.

Within an URI (web address), the ASCII characters can be encoded in one of three ways:

• Unless they are reserved, they can be included in the URI directly (for example, you can always use the letter a in an URI).
• You can always escape a character using its hexadecimal value. Letter a can thus be written as %61.
• Unicode character set includes full-width form of ASCII characters, where letter a can be encoded as a two-byte value 0xFF61 (or %ff%61 in an URI)

The IPS software (standalone or integrated in Cisco IOS) does not recognize the sequence %ff%61 as letter a. It's thus possible to evade some IPS triggers by replacing ASCII characters with their full-width Unicode encoding.

The vulnerability by itself does not open new attack routes, unless you use the IPS as the only means of protection of a vulnerable system (which is a bad practice anyway).

The Split DNS functionality introduced in IOS release 12.4(9)T has survived a single maintenance cycle before being broken. While you can still configure the DNS views in 12.4(11)T2 (and they still work), the view names are missing from the router-generated configuration (show running, for example), making the configuration syntactically incorrect. The router will thus reboot without DNS views after you've saved the running configuration to NVRAM.

One of my readers asked an interesting question: „why do the commands executed within a EEM Tcl policy fail with Command authorization fails message?“ The short answer is simple: If you use AAA command authorization (which you can only do if you're using a TACACS+ server), you have to specify the username under which the EEM will execute its CLI commands with the event manager session cli username user configuration command.

In a previous post, I've described how you could generate a (almost) continuous ping from a router using the extended ping command. While that approach is extremely simple to implement, it ties up a line (and if you're working from the console, it's highly impractical). You could get the same results (as Tom has already pointed out) using IP SLA feature of Cisco IOS. Configure the ping request with commands similar to these:

ip sla 100
  icmp-echo 172.16.1.2
  timeout 500
  frequency 3

To start the ping, use the ip sla schedule 100 life forever start-time now configuration command, to stop it, no ip sla schedule 100 command. When using IP SLA ping, you can trigger Embedded Event Manager applets to report ping failure (similar to the technique described in this post) or read the ping results from SLA MIB with SNMP.

Note: In IOS release 12.3(14)T, the ip sla command replaced the rtr command. To use this technique in IOS release 12.3 or lower, use the rtr configuration command.

Whenever a router running CEF switching has LAN interfaces (or any other multi-access interfaces), you'll find cached adjacencies for active directly attached IP neighbors in its CEF table. These adjacencies ensure the smooth traffic flow toward the LAN-attached next-hops (preventing the initial packet drop symptom once the next-hop becomes active).

One of my readers made an interesting observation when faced with configuring zone-based firewall on Cisco IOS: „My main issue is a confusion between when to use self and when to use in/outside.“

The rules are simple:

• Whenever you filter traffic transiting the router, you control it with a zone-pair specifying an inside and an ouside zone.
• The self zone controls traffic sent to the router itself or originated by the router.
• Unless you specify a zone-pair combining self zone with another zone, all traffic from that zone sent to the router itself is allowed (the router is not protected)
• To control traffic that the router can send into a zone use a zone-pair from self to another zone. Use inspect in the service-policy to allow the return traffic.
• To filter the traffic that the router can accept, use a zone-pair from another zone to self. Only the packets accepted by this zone-pair's service-policy will be accepted by the router.

More information about the self zone (as well as other aspects of zone-based firewall configuration) can be found in my digital book Deploying Zone-Based Firewalls published by Cisco Press.

During network troubleshooting or proof-of-concept testing, I often change the state of a loopback interface (to insert or remove IP prefix from the routing protocols) or flap it to test the impact on network stability. The traditional approach to this procedure should be known to everyone:

• Enter configuration mode;
• Select the appropriate interface with the interface loopback x command;
• Try to remember whether you need to disable or enable it;
• Issue the shutdown or no shutdown command;
• Exit the configuration mode and continue your debugging/testing process.

After a particularly boring testing session I decided to write a Tcl script to automate the job. To use it, download it and store it into ifchange.tcl. Download the Tcl file to your router (Flash or NVRAM) and define an alias: alias exec ifchange tclsh flash:ifchange.tcl. Now you can use the new ifchange command to change interface status.

Before trying to write Tcl procedures to be executed by Cisco IOS tclsh command, read the following articles:

• Running Tcl procedures from IOS command line
• Tclsh command line parameters
• Where does Tcl output go
• Executing IOS commands from Tcl shell
• IOS scripting with Tcl (IOS 12.3T documentation)
• TCL'ing your Cisco router

And last but not least, if you want to store Tcl procedures on your router and don't want to write into the router's Flash memory (I hate that the router prompts me whether I want to erase the flash every time I store something into it), you can store them in NVRAM.

Cisco IOS allows you to configure the ip default-gateway, but most often it looks like this setting is ignored. In fact, the default gateway is only used when an IOS device does not perform IP routing (acts like an IP host), for example, when you configure a Catalyst switch for layer-2 switching ... or when you disable IP routing on a router with no ip routing configuration command. In both cases, the show ip route command (or show ip redirects on some Catalyst switches) displays the default gateway and any ICMP redirects received from directly attached routers:

b2#show ip route
Default gateway is 192.168.0.5

Host      Gateway         Last Use    Total Uses  Interface
1.2.3.4   192.168.0.10        0:00            13  FastEthernet0/0

Disabling IP routing on a router makes perfect sense if you use it as a (reverse) terminal server or telnet-to-X.25 gateway.

In his latest Q&A post, Scott Morris mentioned an excellent Cisco article that describes routing tricks needed to implement sinkholes and remote blackholes in great details. Highly recommended reading.

IOS release 12.2(13)T (integrated in IOS release 12.3) has added the capability to redirect output of an IOS show command to a file. This feature uses Unix-style pipes (similar to the include, exclude and section keywords) and adds append, redirect and tee (redirect + print) keywords.

The show output can be redirected to a local filename (in flash, on usb token or even in NVRAM) or sent to a remote server (currently only FTP and TFTP servers are supported). For example, the show ip interface brief | redirect ftp://student:[email protected]/ifstatus command will store the current interface status to an FTP server.

Note: the append (or tee /append) operation only works on destinations that support the file append operation: class-C flash file systems, local disks, USB tokens and NVRAM.

I've always wanted a short summary display of DLCIs configured on my Frame Relay boxes (or whatever your favorite WAN technology is), but the only printout I would get from the router would be the lengthy show frame pvc printout. Fortunately, a judicious use of output filters can get you a summary printout from almost anything Cisco IOS produces.

Sometimes, parts of router configuration get lost during the reload process: although the configuration commands are saved in NVRAM, they are not processed after the reload and thus do not appear in the running configuration. Re-entering these commands manually solves the problem ... but it's obviously not a reliable solution.

Embedded Event Manager (EEM) solves this issue as well. You just configure an applet that triggers on syslog message SYS-5-RESTART and reapplies the necessary configuration commands.

TACACS+ protocol introduced with the IOS AAA architecture had great provisions for customizing the whole login process (user-defined banners, prompts ...). Unfortunately, it never really took off and most AAA solutions deployed today rely on RADIUS servers that cannot control the login process itself (the RADIUS server can only check the username/password pair for validity).

To change the login prompts when using RADIUS servers, use the aaa authentication [banner|fail-message|password-prompt|username-prompt] text configuration command.

Early EIGRP implementation treated changes in EIGRP summary address configuration (configured with the ip summary-address eigrp interface configuration command) very disruptively: all EIGRP sessions across the affected interface were cleared, sometimes resulting in a large number of routes entering active state, potentially leading to a stuck-in-active condition.