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 got physically to it’s 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
Leave a Reply