Jul 23

Anti-lockout best practice

Posted by Alex Juncu

ACL are usually configured for firewall configurations, for traffic filtering. When configuring ACLs, careful planing should be made so that in the moment when you are applying an ACL, things get filtered exactly the way you want it. In a lab environment tests can be made and if somethings doesn’t work right, you can start over. But in a live network router, filtering the wrong traffic could cause network outages.

If you are connected to the router via telnet or ssh (most likely in productions routers) it is very easy to lock yourself out of the router by denying the telnet or ssh traffic on an interface between you to that router. This is mostly because how IOS works. Any commands given in IOS are instantly commited to the live configuration. And, for example, if you make a configuration with an ACL and you forget about the implicit deny any (any) and you also forget to permit the telnet/ssh traffic, you might find yourself with the router not responding to any input after you apply the rules. It might take a while to figure out that you can’t access the router anymore and need to get physically to its location and either reload it orĀ  use the console port to remove the ACL from the running-config.

One way of avoiding this is to schedule an automated reload in 10-15 minutes, while you are configuring, From enable mode issue the command:

#reload in MINUTES

This will reload the router after the specified number of minutes. It will ensure that if you lock yourself out, the router will revert back to the working startup-config. If the configuration was applied successfully, you can cancel the scheduled reload with the command

#reload cancel

http://www.youtube.com/watch?v=SMWi7CLoZ2Q
Aug 19

Like most CCIE Lab stories, this one starts with a way to access the consoles remotely – a terminal server. In my case, a Cisco 2811 with a NM-16A module (and a CAB-OCTAL-ASYNC breakout cable for connecting 8 routers).

I have had the opportunity to work with terminal servers many times before (including the actual CCIE lab) – but they were always configured by other people. This time, I had to configure the TS myself. No problem, I say…

TS(config)#int lo0
TS(config-if)#ip add 192.168.1.1 255.255.255.255

!--- line numbers may vary depending on module
!--- use "show line" to determine the numbers in use
TS(config-if)#line 66 81
TS(config-line)#transport input all

!--- Optional
TS(config-line)#flowcontrol hardware

!--- Optional, but it makes accessing the devices easier
TS(config)#ip host r1 2066 192.168.1.1
TS(config)#ip host r2 2067 192.168.1.1
TS(config)#ip host r3 2068 192.168.1.1
TS(config)#ip host r4 2069 192.168.1.1
TS(config)#ip host r5 2070 192.168.1.1
TS(config)#ip host r6 2071 192.168.1.1
TS(config)#ip host r7 2072 192.168.1.1
TS(config)#ip host r8 2073 192.168.1.1

Looks good, and I can now access the devices by telnetting to the various ports on 192.168.1.1. Yet something is wrong… The lines become busy at random intervals, which makes the terminal server refuse connections. A “clear line” solves the problem, but only for a very short time – just seconds later, the line becomes active again.

TS#sh line
   Tty Line Typ     Tx/Rx    A Modem  Roty AccO AccI  Uses  Noise Overruns  Int

*   1/6   72 TTY   9600/9600  -    -      -    -    -     3   1448  447/1343   -
*   1/7   73 TTY   9600/9600  -    -      -    -    -     5    129   62/188    -

TS#r1
Translating "r7"
Trying r7 (192.168.1.1, 2072)...
% Connection refused by remote host

After several hours of frustration (clearing lines just to have them become busy again almost immediately), I realize what I forgot:

TS(config-if)#line 66 81
TS(config-line)#no exec

The explanation? Any kind of noise on the wire was interpreted by the TS as an incoming character. As a result, the TS would activate the line, opening an exec session. A “clear line” would close the session, only to have it opened again by the noise.

As somebody else put it – “‘No exec’ isn’t mandatory, but it will help you keep your sanity!”