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
Best Answer
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 :
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:
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.