Justin, I definitely see your point but it might be hard to generalize that all CF chips fail at 10000 writes. Unless you know that Cisco uses a specific type of flash and the MTBF of that chip is 10000 writes. Some CF chips are rated much higher than that. Regardless it is good that Cisco has fixed the coredump feature in 8.2 code. Nick
-----Original Message----- From: Justin Shore [mailto:jus...@justinshore.com] Sent: Friday, September 25, 2009 11:56 AM To: Nicholas Maio Cc: amsoa...@netcabo.pt; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASA5520 which image should I use? nm...@guesswho.com wrote: > Justin, > I believe I saw your posts on the RANCID list and although the 8.2 coredump > problem can be a pain you can modify your rancid script to ignore the > coredump file when rancid does a show flash. I do this for dhcp snooping > since the db is small enough that I can keep it in flash. (Yes I know about > the warning that they give when you configure like this) Every time a lease > expires or a new lease is distributed the file is updated which would make > rancid grab the change. Nick, I could have modified a copy of the RANCID scripts to just use to work around the problem but that only addresses the RANCID problem. I kicked it around and ultimately decided to just slow down the rate that RANCID checked that device while I worked with Cisco on a solution. Modifying the RANCID scripts doesn't help address the bigger picture. The DE who programmed that feature to rewrite the file on disk with the exact same information each and every time the running-config was generated made a beginner programming mistake. CF has a lifecycle of approximately 10,000 writes. Running RANCID hourly (everybody picks their own times but we run hourly) results in CF module failure in about 14 months. It's hard to believe that something as simple as polling a router for some info can cause it have a hardware failure but in this case that's how the cookie crumbles. The fix on Cisco's end was very simple and they had the bug addressed and rolled into an interim release in about 3 weeks (far exceeding my expectations so kudos to Cisco on that). I will definitely keep in mind that possibly modifying the scripts if I ever have to write to flash regularly. Hopefully I can avoid it though. Justin _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/