Introdução

Este documento descreve alguns dos problemas comuns com o cluster entre sites do modo transparente do EtherChannel estendido.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Firewall ASA (Adaptive Security Appliance)
• Clustering ASA

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

A partir do ASA versão 9.2, o clustering entre locais é suportado, em que as unidades ASA podem estar localizadas em diferentes data centers e o Cluster Control Link (CCL) é conectado por uma interconexão de data center (DCI). Os possíveis cenários de implantação são:

•  Cluster entre sites de interface individual
•  Cluster entre sites do modo transparente do EtherChannel estendido
•  Cluster entre sites do modo roteado do EtherChannel estendido (suportado a partir da versão 9.5)

Notificações MAC MOVE

Quando um endereço MAC na tabela Content Addressable Memory (CAM) muda de porta, uma notificação MAC MOVE é gerada. No entanto, uma notificação MAC MOVE não é gerada quando o endereço MAC é adicionado ou removido da tabela CAM. Suponha que um endereço MAC X seja aprendido através da interface GigabitEthernet0/1 na VLAN10 e depois de algum tempo o mesmo MAC seja visto através da GigabitEthernet0/2 na VLAN 10, então uma notificação MAC MOVE é gerada.

Syslog do Switch:

NEXUS7K %L2FM-4-L2FM_MAC_MOVE: Mac 000c.8142.2600 in vlan 10 has moved from GigabitEthernet0/1 to GigabitEthernet0/2

Syslog do ASA:

ASA-4-412001: MAC 003a.7b58.24c5 moved from DMZ to INSIDE

Diagrama de Rede

Implantação de cluster entre sites em que os ASAs são configurados no modo transparente, fazendo a ponte entre a VLAN 1535 e a VLAN 35. A VLAN 35 interna é estendida sobre a virtualização de transporte de sobreposição (OTV), enquanto a VLAN 1535 externa não é estendida sobre o OTV, como mostrado na imagem

Notificações de Movimentação de MAC no Switch

Cenário 1

Tráfego destinado a um endereço MAC cuja entrada não está presente na tabela MAC do ASA, como mostrado na imagem:

Em um ASA transparente, se o endereço MAC de destino do pacote que chega ao ASA não estiver na tabela de endereços MAC, ele envia uma solicitação de Address Resolution Protocol (ARP) para esse destino (se estiver na mesma sub-rede que o BVI) ou uma solicitação de Internet Control Message Protocol (ICMP) com Time To Live 1(TTL 1) com o MAC de origem como o endereço MAC de Bridge Virtual Interface (BVI) e o endereço MAC de destino como Destination Media Access Controller (DMAC) está perdido.

No caso anterior, você tem estes fluxos de tráfego:

1. O roteador do ISP no data center 1 encaminha o tráfego para um destino específico que está atrás do ASA.
2. Qualquer um dos ASAs pode receber o tráfego e, nesse caso, o endereço MAC destino do tráfego não é conhecido pelo ASA.
3. Agora, o IP de destino do tráfego está na mesma sub-rede do BVI e, como mencionado anteriormente, o ASA agora gera uma solicitação ARP para o IP de destino.
4. O Switch 1 recebe o tráfego e, como a solicitação é um broadcast, ele encaminha o tráfego para o Centro de dados 2, bem como através do link OTV.
5. Quando o Switch 2 vê a solicitação ARP do ASA no link OTV, ele registra uma notificação MAC MOVE porque anteriormente o endereço MAC do ASA foi aprendido por meio da interface diretamente conectada e agora está sendo aprendido por meio do link OTV.

Recomendações

É um cenário de canto. As tabelas MAC são sincronizadas em clusters, portanto é menos provável que um membro não tenha uma entrada para um host específico. Uma movimentação ocasional de MAC para o MAC BVI de propriedade do cluster é considerada aceitável.

Cenário 2

Processamento de fluxo centralizado pelo ASA, como mostrado na imagem:

O tráfego baseado em inspeção em um cluster ASA é classificado em três tipos:

• Centralizado
• Distribuído
• SemiDistribuído

No caso da inspeção centralizada, todo o tráfego que precisa ser inspecionado é redirecionado para a unidade primária do cluster ASA. Se uma unidade secundária do cluster ASA receber o tráfego, ele será encaminhado para o primário por meio da CCL.

Na imagem anterior, você trabalha com o tráfego SQL, que é um Protocolo de Inspeção Centralizada (CIP - Centralized Inspection Protocol) e o comportamento descrito aqui é aplicável a qualquer CIP.

Você recebe o tráfego no Centro de dados 2, onde você tem apenas unidades secundárias do cluster ASA, a unidade primária está localizada no Centro de dados 1, que é o ASA 1.

1. O roteador 2 do ISP no data center 2 recebe o tráfego e o encaminha para os ASAs em seu local.
2. Qualquer um dos ASAs pode receber esse tráfego e, uma vez determinado que esse tráfego precisa ser inspecionado e, como o protocolo é centralizado, ele encaminha o tráfego para a unidade primária através do CCL.
3. O ASA 1 recebe o fluxo de tráfego por meio do CCL, processa o tráfego e o envia downstream para o SQL Server.
4. Agora, quando o ASA 1 encaminha o tráfego para downstream, ele retém o endereço mac origem do roteador 2 do ISP, que está localizado no data center 2 e o envia para downstream.
5. Quando o Switch 1 recebe esse tráfego específico, ele registra uma notificação MAC MOVE porque vê originalmente o endereço MAC do Roteador 2 do ISP através do link OTV que está conectado ao Centro de dados 2 e agora vê o tráfego que vem das interfaces conectadas ao ASA 1.

Recomendações

Recomenda-se rotear conexões centralizadas para qualquer site que hospede o principal (com base nas prioridades), como mostrado na imagem:

Cenário 3

Para uma comunicação entre controladores de domínio (DC) no modo transparente, esse fluxo de tráfego específico não é coberto ou documentado, mas esse fluxo de tráfego específico funciona do ponto de vista do processamento de fluxo do ASA. No entanto, isso pode resultar em notificações de movimentação de MAC no switch. 

1. O Host 1 na VLAN 35 tenta se comunicar com o Host 2 que está presente no outro Centro de dados.
2. O Host 1 tem um gateway padrão, que é o Roteador 1, e o Roteador 1 tem um caminho para acessar o Host 2, por poder se comunicar com o Roteador 2 diretamente através de um link alternativo e, nesse caso, presumimos o Multiprotocol Label Switching (MPLS) e não através do cluster ASA.
3. O roteador 2 recebe o tráfego de entrada e o roteia para o host 2.
4. Agora, quando o Host 2 responde, o Roteador 2 recebe o tráfego de retorno e encontra uma rota diretamente conectada através dos ASAs em vez do tráfego enviado através do MPLS. 
5. Nesse estágio, o tráfego que sai do Roteador 2 tem o MAC de origem da interface de saída do Roteador 2.
6. Os ASAs no Centro de dados 2 recebem o tráfego de retorno e encontram uma conexão que existe e é feita pelos ASAs no Centro de dados 1.
7. Os ASAs no Centro de dados 2 enviam o tráfego de retorno sobre CCL de volta para os ASAs no Centro de dados 1.
8. Nesse estágio, os ASAs no Centro de dados 1 processam o tráfego de retorno e o enviam para o Switch 1. O pacote ainda tem o mesmo MAC de origem que a interface de saída do Roteador 2.
9. Agora, quando o Switch 1 recebe o pacote, ele registra uma notificação de movimentação de MAC porque inicialmente aprendeu o endereço MAC do Roteador 2 através da interface que está conectada ao link OTV, no entanto, nesse estágio ele começa a aprender o endereço MAC da interface conectada aos ASAs.
   
   

Cenário 4

Tráfego gerado pelo ASA, como mostrado na imagem:

Esse caso específico será observado para qualquer tráfego gerado pelo próprio ASA. Aqui, duas situações possíveis são consideradas, em que o ASA tenta acessar um Network Time Protocol (NTP) ou um servidor Syslog, que estão na mesma sub-rede que a sua interface BVI.No entanto, não se limita apenas a essas duas condições, essa situação pode acontecer sempre que o tráfego é gerado pelo ASA para qualquer endereço IP que esteja diretamente conectado aos endereços IP BVI.

1. Se o ASA não tiver as informações ARP do servidor NTP/Servidor Syslog, o ASA gerará uma solicitação ARP para esse servidor.
2. Como a solicitação ARP é um pacote de broadcast, o Switch 1 receberá esse pacote de sua interface conectada do ASA e o enviará por todas as interfaces na VLAN específica, incluindo o local remoto através do OTV.
3. O Switch de local remoto 2 receberá essa solicitação ARP do link OTV e, devido ao MAC de origem do ASA, ele gerará uma notificação de oscilação MAC, já que o mesmo endereço MAC é aprendido no OTV por meio de suas interfaces locais diretamente conectadas ao ASA.

Cenário 5

 Tráfego destinado ao endereço IP BVI do ASA de um host conectado diretamente, como mostrado na imagem:

Um MAC MOVE também pode ser observado em momentos em que o tráfego é destinado ao endereço IP BVI do ASA. 

No cenário, temos uma máquina host em uma rede diretamente conectada do ASA e estamos tentando conectar-se ao ASA.

1. O host não tem o ARP do ASA e aciona uma solicitação ARP.
2. O Nexus recebe o tráfego e, novamente, como é um tráfego de broadcast, ele envia o tráfego através do OTV para o outro site também. 
3. O ASA no data center remoto 2 pode responder à solicitação ARP e envia o tráfego de volta pelo mesmo caminho que é o Switch 2 no lado remoto, OTV, Switch 1 no lado local e, em seguida, o host final.
4. Quando a resposta ARP é vista no Switch 1 do lado local, ela aciona uma notificação de movimentação MAC ao ver o endereço MAC do ASA que vem do link OTV.

Cenário 6

ASA configurado para negar o tráfego, junto com o qual ele envia um RST para o host, como mostrado na imagem:

Nesse caso, temos um host 1 na VLAN 35, ele tenta se comunicar com o host 2 na mesma VLAN de camada 3, no entanto, o host 2 está na VLAN 1535 do data center 2.

1. O endereço MAC do host 2 seria visto no Switch 2 através da interface conectada aos ASAs.
2. O Switch 1 veria o endereço MAC do Host 2 através do link OTV.
3. O host 1 envia tráfego para o host 2 e isso segue o caminho do switch 1, OTV, switch 2, ASAs no data center 2.
4. Esse específico é negado pelo ASA e, como o ASA está configurado para enviar de volta um RST ao Host 1, o pacote RST volta com o endereço MAC origem do ASA.
5. Quando esse pacote volta para o Switch 1 através do OTV, o Switch 1 registra uma notificação MAC MOVE para o endereço MAC do ASA porque agora ele vê o endereço MAC através do OTV, onde antes de ver o endereço de sua interface diretamente conectada.

Verificar

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshooting

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Informações Relacionadas

• Guia de configuração da CLI do Cisco ASA Series
• Suporte Técnico e Documentação - Cisco Systems