I ran the cvtnrlog utility with the -d option to clean out the database of two months worth of alarms. The cvtnrlog utility ran for a full 24 hours. Once it was completed I was unable to enter the database event viewer now. I get the following error messages:
Unfortunately, it appears that you have corruption in your database. There are two options that you should consider at this point. In both cases, you must have a copy of your Topology (.cpm file) to recover your configuration. If you do not, you will have to add your sensor(s) back in.
The first option is to us the 'Troubleshooting Toolkit'. Close CSPM and go to "Start>Programs>Cisco Secure Policy Manager>Troubleshooting Toolkit". Go to the Restore policy database tab. Select Restore to orginal and then hit the Restore button. This may take a few minutes, and as the process is completed, you will see check marks fill in the boxes. Once this is complete, close the toolkit and reboot the server. (not require, but a good idea).
Bring CSPM back up and select File>Import from file. Point this at your .cpm file. Then do a File>Save and Update.
If this does not work, then as a last resort, you must reinstall. There is no other way to repair corruption, than the two methods above.
If sounds like you had quite a few alarms in your database, if it ran for 24 hours. I would suggest that you run this more frequently. Don't let the database get above 59k alarms in it if possible. This value is not documented, just a suggestion based on my experience. There are other factors that influence the number of alarms that can be in the database, but this is a pretty good rule of thumb.
One of the above methods should resolve your issue, but if for some reason it does not, or you have further questions, the don't hesitate to contact the TAC for assistance.
I also experienced database corruption on or about the 2 month period. After speaking with the DE, the work-around that I use today is to only perform maintenance with the default administrator profile that was used to install. This has allowed me to keep the database for 6 months(and still going). The installation has many registry keys that tie to the profile that installed the program. I was unable to gather from TAC the effects of editing the registry, and requirements to keep this database for trending purposes has binded me to use the administrator profile.
Do you have an export of the configuration .CPM file? If so, open the Troubleshooting Toolkit from the CSPM Program Menu and find the appropriate tab to restore the database to the original form. This will also wipe away your config, hence, the need to the export prior to the restore. You will also have to take CSPM back to the correct signature and version level.
CSPM does have issues with database size, so I would recommend backing up the database on a regular basis and then restoring to original to start fresh. If you need the data, you can always restore from a backup.
Jason, I run v2.3.3i on NT4 SP6a (IE 5.5) and have always experienced what I consider to be a significant problem with the "cvtnrlog function"...that is, its inability to convert the database to log format "cvtnrlog" successfully even after what I consider to be relatively few events. For instance, even after a week the ability to cut a log file stopped and I only have 2 sensors. I've used the support tool but have found it easier to reinstall from scratch after exporting the topology, etc. I've opened a TAC case on this to no avail. I don't get the same error you do but the effect is the same. Unfortunately, I don't trust this functionality of the system and even more unfortunately, that means I convert the DB to log format every 3 days! Worse yet, there isn't an obvious way I've found to combine all the log files for history analysis/correlation. I've had no problem with opening a database of 20MB which represented about 3-4 months worth of events...just a problem cleaning out/archiving the DB (cvtnrlog) after an indeterminate amount of time...consequently, I clean out DB before it gets very big. Basically, I'm cleaning out about 1000-1500 events every 3 days resulting in a logfile of about 220k.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...