cisco asa reloading

Question

After having both memory and code upgrades, we have a significant number of our asa 5520's (in active/standby pairs) develop problems. The problem manifests itself as losing connectivity to the other 1/2 of the pair on the failover interface, and is usually accompanied by a reload of the standby device. Since both the memory and code have been touched, we are trying to look @ both as the source of the problem. Code is being back leveled where appropriate, but thats not always feasible. Is there a way to test the memory (like a memtest) while the devices are up and running?

5520's running 8.2(3) w/ 2gb ram.

05:05:36 %ASA-1-105005: (Secondary) Lost Failover communications with mate on interface outside
05:05:36 %ASA-1-105005: (Secondary) Lost Failover communications with mate on interface inside
05:05:36 %ASA-1-105008: (Secondary) Testing Interface outside
05:05:36 %ASA-1-105008: (Secondary) Testing Interface inside
05:05:37 %ASA-1-105009: (Secondary) Testing on interface inside Passed
05:05:38 %ASA-1-105009: (Secondary) Testing on interface outside Passed
05:11:39 %ASA-1-105003: (Primary) Monitoring on interface outside waiting
05:11:39 %ASA-1-105003: (Primary) Monitoring on interface inside waiting
05:11:39 %ASA-1-105006: (Primary) Link status 'Up' on interface outside
05:11:39 %ASA-1-105006: (Primary) Link status 'Up' on interface inside
05:11:41 %ASA-1-105003: (Secondary) Monitoring on interface outside waiting
05:11:41 %ASA-1-105003: (Secondary) Monitoring on interface inside waiting
05:11:56 %ASA-1-105004: (Secondary) Monitoring on interface outside normal
05:11:56 %ASA-1-105004: (Secondary) Monitoring on interface inside normal
05:11:59 %ASA-1-105004: (Primary) Monitoring on interface outside normal
05:11:59 %ASA-1-105004: (Primary) Monitoring on interface inside normal
05:12:31 %ASA-1-105005: (Secondary) Lost Failover communications with mate on interface outside
05:12:31 %ASA-1-105005: (Secondary) Lost Failover communications with mate on interface inside
05:12:31 %ASA-1-105008: (Secondary) Testing Interface outside
05:12:31 %ASA-1-105008: (Secondary) Testing Interface inside
05:12:32 %ASA-1-105009: (Secondary) Testing on interface outside Passed
05:12:32 %ASA-1-105009: (Secondary) Testing on interface inside Passed
05:18:50 %ASA-1-105006: (Primary) Link status 'Up' on interface outside
05:18:50 %ASA-1-105006: (Primary) Link status 'Up' on interface inside
05:18:51 %ASA-1-105003: (Secondary) Monitoring on interface outside waiting
05:18:51 %ASA-1-105003: (Secondary) Monitoring on interface inside waiting
05:18:52 %ASA-1-105003: (Primary) Monitoring on interface outside waiting
05:18:52 %ASA-1-105003: (Primary) Monitoring on interface inside waiting
05:19:07 %ASA-1-105004: (Primary) Monitoring on interface outside normal
05:19:07 %ASA-1-105004: (Primary) Monitoring on interface inside normal
05:19:11 %ASA-1-105004: (Secondary) Monitoring on interface outside normal
05:19:11 %ASA-1-105004: (Secondary) Monitoring on interface inside normal

Answer 1

Ok I'm not going to pretend I have de facto answer, but have you considered...

Are you using a dedicated interface for failover such as the Management port, as other traffic may delay 'hello' packets triggering a failover condition?

Have you tried adjusting the hold-down timer like so :

hostname(config)# failover polltime interface [msec] time [holdtime time]

Maybe extending the timer may yield different results, if it does you know the code/memory isn't solely resposible for the reload.

You could also try the command:

show failover history

To try and establish why the failover occurred. However it does look like the interface or link is going down, from your output, so I'm unsure this is a memory issue, although code is a distinct possibility.