[email protected] 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 [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
