ASA 5550 – Reboot Worthwhile

cisco-asa

I've got an ASA 5550 that is performing loads and loads of operations (AnyConnect, NAT, ACL, RADIUS, etc, etc). It isn't particularly overloaded in terms of CPU & Memory, but it has an uptime of over 3.5 years.

Lately I have been attempting to deploy another IPSEC tunnel (via cryptomap) along with a NAT Exempt rule, but the ASA is exhibiting very strange behaviour. Sometimes when I add ACE's a mass of text pops up from nowhere in the description field. No matter what I do, my tests with the on-box PacketTracer tool do not yield the results I expect (for example – I see the packet hitting the Any/Any rule at the bottom of the ACL, even though there is a specifically configured ACE at the top of said ACL).

Anyway, the question is this: Has anyone ever actually solved anything by rebooting an ASA? It isn't my favourite option, but with the very strange behaviours I am seeing troubleshooting is becoming fruitless.

Best Answer

Short answer: Yes.

Longer answer: :-) There are bugs in every piece of software. The longer it runs, the more likely one is going to setup shop in your network. But more to the point, the longer it's gone without a reboot, the more little bits of "old" configuration and/or status will be left lingering. In IOS, no interface foo will emit a warning that it's not completely destroyed and configuration elements may reappear if you recreate the interface -- shouldn't happen in an ASA but in rare cases, it does. I've also seen phantom NAT entries after deleting them from the config. (that one actually is a bug)

When dealing with IPSec/crypto, I've found a whole lot of crazy can be cleared up by a reload. In one case (pix 6.3.5) it wouldn't re-establish a VPN tunnel until I did.

[edit] A word on reboots in general: I tend to reboot things just to make sure they will. All too often I've had various systems (routers, firewalls, servers) running for extended periods -- constantly being modified, and when something ends up restarting them (usually a power outage, but "oops, wrong machine" happens too) they rarely come back up exactly as they were before... someone forgot to make X start at boot, or some odd interaction of parts makes something not startup as expected. I admit, it's less of a concern for more static parts of one's infrastructure.