Cisco ASA 9.0 Cluster – Fundamentos, Arquiteturas e Configuração - Webcast FAQ

    Com o especialista Pedro Ivo Santos Mauri.

P: Hoje existe um problema com o velho cabo cross um morreu o outro asa entende que morreu tambem isto teve alguma melhora nesta versão ? 

Especificamente quanto a questão do cabo, isso pode ser um cenário bem específico para se dizer, mas a questão é que nessa funcionalidade, qualquer falha do cluster control link, ou de acordo com a customização da minha configuração, falhas na interface de dados, interface que recebe e encaminha pacotes, o ASA é imediatamente retirado do cluster, para não restar dúvida de que aquele ASA possa ainda processar de maneira erronea um pacote. Ou seja, qualquer falha, seja da interface ou do cabo que conecta este ASA ao restante do cluster, ao menor sinal de falha, ele é removido do cluster e passa por uma série de tentativas, sendo então removido definitivamente do cluster ao final das tentativas.

 

P:  O comando Failover era utilizado para promover ou rebaixar um membro pra Ativo ou Standby .. o que estou entendendo que isto esta automatizado tem como fazer isto manualmente  ? 

Sim, hoje esta automatizado. Nós temos o master, que é a primeira caixa que entra no cluster, é assim que sempre será, e os slaves. Se eu quiser forçar a saída de um master do cluster ou de um slave, eu quero fazer uma manutenção ou eu quero trocar por alguma razão, eu posso sim interferir manualmente, remover um master do cluster, despromove-lo,  promover uma outra caixa para master, isso tudo é possível manualmente sim. Isso é menos recomendado, porque o cluster tem inteligência para, na ausência do master, promover automaticamente, o membro de menor ID, mas é possível fazer de maneira manual utilizando comandos similares ao que era conhecido como failover, porém hoje com nova nomeclatura.

P:  Pretendo criar um Cluster entre dois DataCenters geograficamente distantes. Quais os requisitos para criar um Cluster ASA? Podemos usar MPLS, OTM, latências minimas? 

Sim é possível você ter o cluster disperso geograficamente, por exemplo, você tem dois DC, e você ira criar 2 ASAs no DC "a" e 2 no DC "b", e você vai formar um cluster com 4 ASAs. O requisito que você tem é, você precisa de um ethernet mpls, você precisa de uma extensão layer 2 entre os ASAs, lembrem-se que o que mantém o cluster é cluster control link, por onde o master se comunica com os slaves e por onde os pacotes são redirecionados para manter a simetria de processamento, então contanto que você garanta que uma interface de ASA que é cluster control interface, consiga falar no mesmo domínio layer 2 com a interface do outro lado, você pode sim ter um cluster geografico, isso ja foi testado. Lembrando que você precisa manter a latencia sobre controle, pensando no seu trafego de dados.

P:  Qual vai ser o criterio por mac addr ou por conexoes ativas que ele vai escolher quando falha um owner ? 

O owner vai ser escolhido entre os ASAs do cluster que perguntar ao director quem é o owner daquela conexão, porque isto, já que o algoritimo de balanciamento naturalmente mandou o tráfego para aquela ou aquelas caixas, ida e volta, faz sentido que uma delas seja owner, para evitar ao máximo possível de assimetria. O owner vai ser escolhido a partir delas, entre estas caixas, normalmente o owner vai ser o primeiro que perguntar, a primeira que pegar o primeiro pacote que bater, o director ja atribui ela como owner. No caso, quando há varias caixas perguntando o director, quem pegar o próximo pacote, na conexão UDP, vai se tornar o owner daquela conexão. 

P:  Pinholes pode ser um furo de segurança entro com um pacote FTP e encaminho um exploit junto um exemplo uma vez que sei que ele aceita por comportamento natural  isso deveria entao ser tratado por um IPS antes ? 

O pinholes não é considerado uma falha de segurança inerente do cluster de ASA. Pinhole é um mecanismo para permitir a comunicação que usam estes protocolos que inerentemente abrem conexões secundárias como parte do serviço.

P: Uma pergunta posterior como o ASA vai trabalhar com inspeção quando chegar no L7?

Contando que o protocolo seja suportado pelo cluster, esse  processamento da inspeção vai ser extamente como costuma acontecer, a unidade que é owner, a caixa vai trabalhar com todas as inspeções que precisam ser feitas no pacote, o que chamamos de processamento do pacote, o que o cluster esta fazendo é garantirque um pacote que foi processado uma vez por um owner, sera processado novamente por aquele owner, e lembrando que o master controla todas a configuração de todos os slaves, então nos temos uma configuração de inspeção sempre consistente, ou seja qualquer caixa que seja transformada em owner, irá aplicar a mesma politica de inspeção. 

P: Se uma das Interfaces entrar em DOWN este ASA vai ser desconsiderado do cluster?

Pode ser. Existe um help monitoring que é feito, e a interface é considerada evidentemente um pacto para que aquela caixa não quebre e não seja considerada owner de minhas conexões se eu não posso enviar nada a ela, então, isso é configurável, se você quiser configurar para que assim que uma interface do meu ASA cair, ele saia do cluster , isso pode ser configurado.

P:Quando trocar o owner não existe o risco de termos problemas com ARP?

Não. Não corre o risco, porque este processo normalmente é seguido de gratuital dark para forçar atualizações de tabela.

 

  

 

Histórico de versão
Revisão #
1 de 1
Última actualização:
‎02-26-2015 09:09 AM
Actualizado por:
 
Etiquetas (1)
Marcas (1)