[c-nsp] ASA5520 which image should I use?

NMaio at guesswho.com NMaio at guesswho.com
Fri Sep 25 12:19:59 EDT 2009


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:justin at justinshore.com] 
Sent: Friday, September 25, 2009 11:56 AM
To: Nicholas Maio
Cc: amsoares at netcabo.pt; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA5520 which image should I use?

NMaio at 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



More information about the cisco-nsp mailing list