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

Unequal load-sharing with static routes is almost impossible as there is no configuration command to assign non-default traffic share count to a static route. For example, if you configure two default routes, one pointing to a low-speed interface and another one pointing to a high-speed interface, there is no mechanism to force majority of the traffic onto the high-speed link (IOS ignores interface bandwidth when calculating load sharing ratios).

You can, howerer, use a workaround: if you configure multiple routes for the same prefix pointing to the same interface, that interface will attract proportionally more outbound traffic.

The IP Service Level Agreement (SLA) measurement feature of Cisco IOS is extremely SNMP-oriented. For example, there is no easy way to generate a logging message when an SLA operation fails (or exceeds the threshold). However, Embedded Event Manager reading SNMP variables can help you get there.

Have you ever wanted to be notified when your router loses a specific route (for example, the default route toward the Internet)? In IOS release 12.4T you can do it with a combination of Enhanced Object Tracking and Embedded Event Manager 2.2.

One of the most commonly asked load-sharing-related questions is “can I load-share traffic across unequal-cost links?”. In general, the answer is no. In order to load-share the traffic, you need more than one path to the destination and the only way to get multiple routes toward a destination in the IP routing table is to make them equal-cost (the only notable exception being EIGRP that supports unequal-cost load-sharing with the variance parameter).

There are, however, two cases where you can force unequal traffic split across equal-cost paths toward a destination: when using inter-AS BGP with the link bandwidth parameter, and when using unequal-bandwidth traffic-engineering tunnels.

Someone managed to scramble the VTY numbers displayed with the show users and show line commands in IOS release 12.4. The VTY numbers in the show printouts no longer correspond to the numbers in the router configuration.