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


2 Responses to “Anti-lockout best practice”

  1. Mircea Says:

    Yes, it’s a good idea the reload in command, but imho when you are dealing with production routers it is better to lock yourself out than having zounds of users complaining they were disconnected from their applications.
    In my opinion there are like 3 viable solutions:
    1. be careful!
    2. use a EEM applet that would issue a “no ip access-list” or reset the acl config to a template-based one, say after 10 minutes, if no “wr mem” is issued.
    3. use Juniper ( :P ), that has the “commit” command

    PS: anyway, I’m just being picky, I actually used “reload in” many times..but never on backbone equipments

  2. bogd Says:

    The “reload in” command should be a last resort – in 99% of the cases, you will not lock yourself out, so you can issue a “reload cancel”.

    I agree that it’s a completely different story when dealing with production routers serving “zounds of users”, but then again… you _really_ shouldn’t be making potentially disruptive changes (or any kind of changes!) on such routers outside of a maintenance window. :)

    And to answer the Juniper part – I really do love the “commit” feature, but… if you commit a non-working config, you’re just as scre^H^H^H^H much in trouble :) .

Leave a Reply