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

I get a lot of hits via Google from people searching for a default username on Cisco router. It's ages-old news, but there is no default username. Period. If you have to get access to a router and cannot remember the password(s), the only thing left is the password recovery mechanism ... although even that can be disabled with the no service password-recovery configuration command.

There are, however, a few things you can do if you want to relax the access to your router in a lab environment (never do it in a production network):

In my discussion of per-packet versus per-destination load sharing, I've relied on the "accepted wisdom" that out-of-order TCP packets reduce session performance (as a side note, out-of-order UDP packets are a true performance killer; just try running NFS with out-of-order packets).

Today I've discovered another huge show-stopper: stateful firewalls (read: almost everything in use today) might just drop out-of-order packets, resulting in TCP timeouts and retransmissions (and repeated timeouts will totally wreck the session throughput). Here's how Cisco devices handle this problem:

You could limit terminal access to a router with an access-class in line configuration command for a very long time (since, at least, IOS release 10.0). However, the access-class command only accepted standard access-lists, allowing you to restrict access solely based on source IP addresses. In the meantime, this feature quietly got upgraded to support extended access lists. In the IOS release 12.4, the command even accepts (undocumented !) named access lists.

These new features give you the ability to implement interesting policies, for example:

If you want to disable the Cisco IOS more ... prompt (for example, when listing router's configuration with the show running command), set the terminal screen length to zero with the terminal length 0 exec-mode command. To change the terminal lenght permanently, use the length lines line configuration command, for example:

line console
 length 0
line vty 0 4
 length 0

Cisco has in IOS release 12.3(4)T (integrated into 12.4) finally introduced features (long available in Unix and Windows) that slow down dictionary attacks on a router. On top of logging of login failures, you can also slow down the login process by delaying the router response after a login failure with the login delay seconds command.

On top of that, the you can configure the router to enter quiet mode after several login failures have been detected in specified timeframe with the login block-for seconds attempts tries within seconds configuration command.

The packets that cannot be CEF-switched in a box with CEF switching enabled are punted to the next switching level (fast switching or process switching). The incoming packets can be punted for a number of reasons, for example:

• If the destination is reachable over an interface that cannot use CEF-switching due to a feature not supported by CEF (for example, X.25 link), the packet has to be fast- or process-switched.

These destinations are easily discovered by inspecting the punt adjacencies.

In "border cases" you might find interesting CEF adjacencies in your CEF adjacency table (displayed with show ip cef adjacency). Most common one is the glean adjacency used for directly connected routes (this adjacency type is a placeholder that indicates the router it should perform the ARP table lookup and send the packet to directly connected neighbor). Discard, Drop, Noroute and Null adjacencies are obvious, the "weird" one is the Punt adjacency, which indicates that the router cannot CEF-switch the packet toward the destination (due to a feature being used that is not yet supported by CEF), thus the packet is punted to the next switching method (fast switching and ultimately process switching).