OK, so you have a Cisco Firewall Service Module installed in a 6509 or 6513, whatev, and it's setup in multi context mode. It's running, it's got multiple contexts configured, it's passing production traffic and everything is honky dory.
Well, you decide to futz around in a new context and lock yourself out when you try to update the AAA config or some such thing… there are tons of ways you could do this… trust me… been there, done that. Now, if it weren't for all those production contexts running, you can just reload the blade and get back to your last known good config. But how can you recover without reloading the whole dag-blamed thing?
Well, assuming that you did not lock yourself out of the SYSTEM context and the ADMIN context still has IP connectivity to a TFTP server, then you can try to force feed some corrective commands into the context.
First, create a config file (e.g., BROKENCONTEXTNAME-restore.cfg) on your TFTP server that has the commands needed to correct the problem… I sure hope you know what they are… you do know what you did to screw it up and how to fix it right?
Then, once that's done, TFTP the restoration config file up to the FWSM:
host-FWSM# copy tftp://192.168.1.1/restore.cfg disk:/BROKENCONTEXTNAME-restore.cfg
Now, just cram that file down the context's throat… (This assumes that the context's regular and working start-config is saved in BROKENCONTEXTNAME.cfg):
host-FWSM# conf t
host-FWSM# context BROKENCONTEXTNAME
host-FWSM# config-url disk:/BROKENCONTEXTNAME-restore.cfg
host-FWSM# config-url disk:/BROKENCONTEXTNAME.cfg
host-FWSM# delete disk:/BROKENCONTEXTNAME-restore.cfg
At this point, all should be well. Go ahead, try it. If it didn't work, well, you screwed it up worse than you thought. You might just need to reload the blade… to hell with the production traffic.
