I own a chainsaw—well, I live in the country, and for a bit of light relief from networking, I chop logs and cut (small) trees down for our stove. I have never yet cut a branch off a tree while sitting on that branch on the wrong side of the cut. Well, you wouldn’t, would you? It is so obvious that that would be a silly (and painful) thing to do. But how many of us would have to admit that we’ve done something similar when it comes to configuring remote bits of network kit? You’re logged into a router, changing an access list, and next thing you know, you’re frantically hitting the keyboard and nothing is happening. Why do we do this to ourselves? I’ve found that a lot of the time, the problem isn’t that the ACL is wrong; it’s that we’ve not thought through the process of how it works. You create an ACL, apply it to an interface, and it starts to take effect. Assuming you’ve got all your IP addresses right and not done anything daft with subnet masks, everything is fine. It’s when you want to change that ACL that the problems seem to occur. You copy the ACL into Notepad, make the changes to add the new lines or whatever you need to do. So far so good. I’m talking Cisco devices here, by the way, but I’m not having a dig at them particularly (that will come later no doubt). So then you log in to your device, erase the ACL and start to paste the new one instead. And that’s when it all goes horribly wrong. As soon as the first line of that replacement ACL hits your router config, you’re locked out--unless you are very lucky indeed. Remember that in an ACL, there’s an implicit deny at the end. We know that. So when you enter the first line, the ACL contains that that first line followed by a deny. Unfortunately the line that allows your management access is the second line. Which you never get to type because you’ve already locked yourself out. All because you forgot to remove the reference to that access list from the interface over which you’re logging in to the router. It didn’t matter when the access list didn’t exist—but as soon as it reappeared in the config it started taking effect before you could finish it. It sounds basic, but so many times it’s caught folk out who have started editing the list without taking it off the interfaces first. What you should really do is create a new access list and then reference it in your interface config instead of the old one when you’re happy with it, and then remove the old one (or use named access lists which you can edit), but if it’s just a minor change, to be honest, most of us don’t bother. And there’s nothing more embarrassing than having to start phoning round in the middle of the night to get someone onsite to reload the router, because most of us don’t have proper out of band access (which of course we should do, and if we were connecting via that, we wouldn’t have this problem in the first place). So, even when you are confident you know what you’re doing (ACLs aren’t rocket science, after all), remember the “reload in x” command which will reload the router in x minutes and bring it back to the working state it was in before you started messing about with it, unless you type “reload cancel” when you know your config’s okay. It’s not just for when you’re doing ACL changes of course—anything that might give you an inaccessible device could benefit from this safety net, and if all goes well, you just cancel the command and it doesn’t do anything. It means you may bounce the router, but if you’ve locked yourself out, all you have to do is wait a few minutes and it’ll be back to normal and you won’t have to call anyone up to go and fix it for you. After all, you can always blame a dodgy power supply.