cisco asa recarregando

4

Depois de ter atualizações de memória e de código, temos um número significativo de nossos 5520s (em pares ativos / em espera) para desenvolver problemas. O problema se manifesta como perda de conectividade com o outro 1/2 do par na interface de failover e é geralmente acompanhado por um recarregamento do dispositivo em espera. Como tanto a memória quanto o código foram tocados, estamos tentando parecer tanto a origem do problema quanto o problema. O código está sendo novamente nivelado quando apropriado, mas isso nem sempre é viável. Existe uma maneira de testar a memória (como um memtest) enquanto os dispositivos estão funcionando?

5520 está executando 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
    
por Starsky 21.10.2011 / 20:27

1 resposta

1

Ok, eu não vou fingir que tenho uma resposta de fato, mas você já considerou ...

Você está usando uma interface dedicada para failover, como a porta de Gerenciamento, já que outro tráfego pode atrasar pacotes 'hello' que acionam uma condição de failover?

Já tentou ajustar o temporizador de espera assim:

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

Talvez a extensão do temporizador possa produzir resultados diferentes, se você souber que o código / memória não é exclusivamente responsável pelo recarregamento.

Você também pode tentar o comando:

show failover history

Para tentar estabelecer por que o failover ocorreu. No entanto, parece que a interface ou link está diminuindo, a partir da sua saída, então não tenho certeza se isso é um problema de memória, embora o código seja uma possibilidade distinta.

    
por 02.03.2018 / 15:08