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.

Recenty, a lot of people were looking for information on the sl_def_acl access list. Here's the whole story: if you've configured IOS login enhancements on your router, the router generates an access list named sl_def_acl (unless you specify your own with the login quiet-mode access-class command) the first time it has to enter the quiet mode. This access-list is then applied to the VTY lines whenever the router enters the quiet mode and removed from the after the quiet period is over. The access list itself is left in the running configuration.

Marko asked a very interesting question: What is the default class policy in a firewall policy-map (policy-map type inspect)? Or, using his original wording, "is it mandatory to use class class-default/drop" at the end of every policy map?

As it turns out, the default action for any class (unless you specify otherwise) is drop. By default, packets not matched by any traffic class are therefore dropped (unless you specify a different action in the class-default), similar to well-known ip access-list behavior.

In the security advisory detailing the Crafted IP Option Vulnerability (a nasty bug that allows an intruder to reset your router with a ping packet), the authors forgot to mention a great tool available in IOS release 12.3(4)T (and integrated in 12.4): the ability to filter packets with IP options in an access-list.

I've tried to be a "good citizen" in one of my Embedded Eveng Manager (EEM) applications and used the action 1.1 cli command "copy running-config startup-config" instead of the (supposedly obsolete) action 1.1 cli command "write memory" command. However, as the copy command generates console prompts (unless you turn them off with the file prompt quiet command), it immediately hung my EEM applet.

Moral of the story: use write memory :)

IOS has (yet another) nice "underdocumented" feature - if you don't have an enable password/secret configured on your router, you can access IOS HTTP(S) server (assuming it's enabled with the ip http server command) without any authentication whatsoever. Of course you'd never do that in a production environment, but it's nice to know you can always configure the router from a web browser if needed (see also the discussion on default passwords with Cisco SDM).