Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Configurar

Fundamentos do cluster

Arquitetura de NGFW

Capturas de cluster

Mensagens do Link de Controle de Cluster (CCL)

Mensagens do Ponto de Controle de Cluster (CCP)

Mecanismo de verificação de integridade do cluster (HC)

Cenários de falha de HC de cluster

Estabelecimento de Conexão do Plano de Dados do Cluster

Troubleshoot

Problemas do plano de dados do cluster

Problemas comuns de NAT/PAT

Manuseio de Fragmentos

Problemas com a ACI

Problemas do plano de controle de cluster

Unidade não pode ingressar no cluster

Problema de interface de canal de porta/dados

Problemas de estabilidade do cluster

Modo simplificado

Informações Relacionadas

Introduction

Este documento descreve a solução de problemas de uma configuração de cluster no Firepower Next-Generation Firewall (NGFW). A maioria dos itens abordados neste documento também é totalmente aplicável à solução de problemas de cluster do Adaptive Security Appliance (ASA).

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento desses tópicos (consulte a seção Informações Relacionadas para obter links):

- Arquitetura da plataforma Firepower

- Configuração e operação do cluster Firepower

- Familiaridade com o FTD e o FXOS CLI

- NGFW/registros do plano de dados

- NGFW/data plane packet-tracer

- Capturas de plano de dados/FXOS (Firepower eXtensible Operating System)

Componentes Utilizados

- HW: Firepower 4125

- SW: 6.7.0 (Build 65) - plano de dados 9.15(1)

The information in this document was created from the devices in a specific lab environment. Todos os dispositivos usados neste documento iniciaram com uma configuração limpa (padrão). Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Configurar

A parte de configuração de uma implantação de cluster é abordada nos guias de configuração do FMC e do FXOS:

- Clustering da Firepower Threat Defense

- Implantação de um cluster para Firepower Threat Defense para escalabilidade e alta disponibilidade

Fundamentos do cluster

Arquitetura de NGFW

É importante entender como um Firepower 41xx ou 93xx Series aplica pacotes de trânsito:

1. Um pacote entra na interface de entrada e é tratado pelo switch interno do chassi.

2. O pacote passa pela Smart NIC. Se o fluxo for descarregado (aceleração de HW), o pacote será tratado somente pela Smart NIC e, em seguida, será enviado de volta à rede.

3. Se o pacote não for descarregado, o plano de dados FTD, que faz principalmente verificações de L3/L4.

4. Se a política exigir, o pacote é inspecionado pelo mecanismo Snort (principalmente inspeção L7).

5. O mecanismo Snort retorna um veredito (por exemplo, permitir ou bloquear) para o pacote.

6. O plano de dados descarta ou encaminha o pacote com base no veredito do Snort.

7. O pacote sai do chassi através do switch interno do chassi.

Capturas de cluster

Os dispositivos Firepower fornecem vários pontos de captura que permitem obter visibilidade dos fluxos de trânsito. Quando você soluciona problemas e habilita capturas de cluster, os principais desafios são:

- O número de capturas aumenta à medida que o número de unidades no cluster aumenta

- Você precisa estar ciente da forma como o cluster lida com um fluxo específico para poder acompanhar o pacote através do cluster

Este diagrama mostra um cluster de 2 unidades (por exemplo, FP941xx/FP9300):

No caso de um estabelecimento de conexão TCP assimétrica um TCP SYN, a troca SYN/ACK é semelhante a esta:

Encaminhar tráfego

1. O TCP SYN é enviado do Host-A para o Host-B.

2. O TCP SYN chega ao chassi (um dos membros do Po1).

3. O TCP SYN é enviado através de uma das interfaces do painel traseiro do chassi (por exemplo, E1/9, E1/10, etc.) para o plano de dados.

4. TCP SYN chega na interface de entrada do plano de dados (Po1.201/INSIDE). Neste exemplo, unit1-1 assume a propriedade do fluxo, faz a randomização do Número de Sequência Inicial (ISN) e codifica as informações de propriedade (cookie) no número Seq

5. TCP SYN é enviado de Po1.202/OUTSIDE (interface de saída do plano de dados).

6. O TCP SYN chega em uma das interfaces do painel traseiro do chassi (por exemplo, E1/9, E1/10, etc.).

7. O TCP SYN é enviado da interface física do chassi (um dos membros do Po1) para o Host-B.

Tráfego de retorno

8. O TCP SYN/ACK é enviado do Host-B e chega na unidade 2-1 (um dos membros do Po1).

9. O TCP SYN/ACK é enviado através de uma das interfaces do painel traseiro do chassi (por exemplo, E1/9, E1/10, etc.) para o plano de dados.

10. O TCP SYN/ACK chega na interface de entrada do plano de dados (Po1.202/OUTSIDE).

11. O TCP SYN/ACK é enviado do Cluster Control Link (CCL) para a unidade 1-1. Por padrão, o ISN está ativado. Assim, o encaminhador encontra as informações do proprietário para TCP SYN+ACKs sem o envolvimento do direcionador. Para outros pacotes ou quando o ISN está desabilitado, o direcionador é consultado.

12. O TCP SYN/ACK chega em uma das interfaces do painel traseiro do chassi (por exemplo, E1/9, E1/10, etc.).

13. O TCP SYN/ACK é enviado para fora da interface física do chassi (um dos membros do Po48) em direção à unidade 1-1.

14. O TCP SYN/ACK chega na unidade 1-1 (um dos membros do Po48).

15. O TCP SYN/ACK é encaminhado através de uma das interfaces do painel traseiro do chassi para a interface de canal de porta CCL do plano de dados (nome cluster if).

16. O plano de dados reinjeta o pacote TCP SYN/ACK para a interface de plano de dados Po1.202/OUTSIDE.

17. O TCP SYN/ACK é enviado de Po1.201/INSIDE (interface de saída do plano de dados) para o HOST-A.

18. O TCP SYN/ACK atravessa uma das interfaces do painel traseiro do chassi (por exemplo, E1/9, E1/10, etc.) e sai de um dos membros do Po1.

19. O TCP SYN/ACK chega ao Host-B.

Para obter mais detalhes sobre esse cenário, leia a seção relacionada nos Estudos de Caso de Estabelecimento de Conexão de Cluster.

Com base nessa troca de pacotes, todos os pontos de captura de cluster possíveis são:

Para a captura de tráfego de encaminhamento (por exemplo, TCP SYN) em:

1. A interface física do chassi (por exemplo, membros Po1). Esta captura é configurada a partir da IU do Gestor de Chassi (CM) ou da CLI do CM.

2. Interface de entrada do plano de dados (por exemplo, Po1.201 INSIDE).

3. Interface de saída do plano de dados (por exemplo, Po1.202 FORA).

4. Interfaces de backplane do chassi. No FP4100, há duas interfaces de backplane. No FP9300, há um total de 6 (2 por módulo). Como você não sabe em qual interface o pacote chega, você deve ativar a captura em todas as interfaces.

Para a captura de tráfego de retorno (por exemplo, TCP SYN/ACK) em:

5. A interface física do chassi (por exemplo, membros Po1). Esta captura é configurada a partir da IU do Gestor de Chassi (CM) ou da CLI do CM.

6. Interface de entrada do plano de dados (por exemplo, Po1.202 FORA).

7. Como o pacote é redirecionado, o próximo ponto de captura é o plano de dados CCL.

8. Interfaces de backplane do chassi. Novamente, você deve ativar a captura em ambas as interfaces.

9. Interfaces de membro CCL do chassi da unidade 1-1.

10. Interface CCL do plano de dados (nome do cluster).

11. Interface de entrada (Po1.202 FORA). Este é o pacote reenviado do CCL para o plano de dados.

12. Interface de saída do plano de dados (por exemplo, Po1.201 INSIDE).

13. Interfaces de backplane do chassi.

Como ativar as capturas de cluster

Capturas FXOS

O processo é descrito no Guia de configuração do FXOS: Captura do pacote

Note: As capturas de FXOS só podem ser feitas na direção de ingresso do ponto de vista do switch interno.

Capturas de plano de dados

A maneira recomendada de ativar a captura em todos os membros do cluster é com o comando exec do cluster.

Considere um cluster de 3 unidades:

Para verificar se há capturas ativas em todas as unidades de cluster, use este comando:

firepower# cluster exec show capture

unit-1-1(LOCAL):******************************************************

unit-2-1:*************************************************************

unit-3-1:*************************************************************

firepower#

Para ativar uma captura de plano de dados em todas as unidades em Po1.201 (INSIDE):

firepower# cluster exec capture CAPI interface INSIDE

É altamente recomendável especificar um filtro de captura e, caso você espere que muito tráfego aumente o buffer de captura:

firepower# cluster exec capture CAPI buffer 33554432 interface INSIDE match tcp host 192.168.240.50 host 192.168.241.50 eq 80

Verificação

firepower# cluster exec show capture

unit-1-1(LOCAL):******************************************************

capture CAPI type raw-data buffer 33554432 interface INSIDE [Capturing - 5140 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

unit-2-1:*************************************************************

capture CAPI type raw-data buffer 33554432 interface INSIDE [Capturing - 260 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

unit-3-1:*************************************************************

capture CAPI type raw-data buffer 33554432 interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

Para ver o conteúdo de todas as capturas (esta saída pode ser muito longa):

firepower# terminal pager 24

firepower# cluster exec show capture CAPI

unit-1-1(LOCAL):******************************************************

21 packets captured

1: 11:33:09.879226 802.1Q vlan#201 P0 192.168.240.50.45456 > 192.168.241.50.80: S 2225395909:2225395909(0) win 29200 <mss 1460,sackOK,timestamp 1110209649 0,nop,wscale 7>

2: 11:33:09.880401 802.1Q vlan#201 P0 192.168.241.50.80 > 192.168.240.50.45456: S 719653963:719653963(0) ack 2225395910 win 28960 <mss 1380,sackOK,timestamp 1120565119 1110209649,nop,wscale 7>

3: 11:33:09.880691 802.1Q vlan#201 P0 192.168.240.50.45456 > 192.168.241.50.80: . ack 719653964 win 229 <nop,nop,timestamp 1110209650 1120565119>

4: 11:33:09.880783 802.1Q vlan#201 P0 192.168.240.50.45456 > 192.168.241.50.80: P 2225395910:2225396054(144) ack 719653964 win 229 <nop,nop,timestamp 1110209650 1120565119>

unit-2-1:*************************************************************

0 packet captured

0 packet shown

unit-3-1:*************************************************************

0 packet captured

0 packet shown

Capturar rastreamentos

Se quiser ver como os pacotes de entrada são tratados pelo plano de dados em cada unidade, use a palavra-chave trace. Isso rastreia os primeiros 50 pacotes de entrada. Você pode rastrear até 1000 pacotes de entrada. Observe que, caso você tenha várias capturas aplicadas em uma interface, é possível rastrear um único pacote apenas uma vez.

Para rastrear os primeiros 1000 pacotes de entrada na interface FORA de todas as unidades de cluster:

firepower# cluster exec cap CAPO int OUTSIDE buff 33554432 trace trace-count 1000 match tcp host 192.168.240.50 host 192.168.241.50 eq www

Depois de capturar o fluxo de interesse, é necessário garantir que você rastreie os pacotes de interesse em cada unidade. O importante a ser lembrado é que um pacote específico pode ser #1 na unidade-1, mas #2 em outra unidade, etc.

Neste exemplo, você pode ver que SYN/ACK é o pacote #2 na unidade-2-1, mas o pacote #1 na unidade-3-1:

firepower# cluster exec show capture CAPO | include S.*ack

unit-1-1(LOCAL):******************************************************

1: 12:58:31.117700 802.1Q vlan#202 P0 192.168.240.50.45468 > 192.168.241.50.80: S 441626016:441626016(0) win 29200 <mss 1380,sackOK,timestamp 1115330849 0,nop,wscale 7>

2: 12:58:31.118341 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.45468: S 301658077:301658077(0) ack 441626017 win 28960 <mss 1460,sackOK,timestamp 1125686319 1115330849,nop,wscale 7>

unit-2-1:*************************************************************

unit-3-1:*************************************************************

1: 12:58:31.111429 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.45468: S 301658077:301658077(0) ack 441626017 win 28960 <mss 1460,sackOK,timestamp 1125686319 1115330849,nop,wscale 7>

Para rastrear o pacote nº 2 (SYN/ACK) na unidade local:

firepower# cluster exec show cap CAPO packet-number 2 trace

unit-1-1(LOCAL):******************************************************

2: 12:58:31.118341 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.45468: S 301658077:301658077(0) ack 441626017 win 28960 <mss 1460,sackOK,timestamp 1125686319 1115330849,nop,wscale 7>

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

...

Para rastrear o mesmo pacote (SYN/ACK) na unidade remota:

firepower# cluster exec unit unit-3-1 show cap CAPO packet-number 1 trace

1: 12:58:31.111429 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.45468: S 301658077:301658077(0) ack 441626017 win 28960 <mss 1460,sackOK,timestamp 1125686319 1115330849,nop,wscale 7>

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

...

Captura CCL

Para ativar a captura no link CCL (em todas as unidades):

firepower# cluster exec capture CCL interface cluster

unit-1-1(LOCAL):******************************************************

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Rejeitar Ocultar

Por padrão, uma captura habilitada em uma interface de dados do plano de dados mostra todos os pacotes:

- Os que chegam da rede física

- Os que são injetados novamente no CCL

Se você não quiser ver os pacotes reinjetados, use a opção reinject-hide. Isso pode ser útil se você quiser verificar se um fluxo é assimétrico:

firepower# cluster exec capture CAPI_RH reinject-hide interface INSIDE match tcp host 192.168.240.50 host 192.168.241.50 eq 80

Essa captura mostra apenas o que a unidade local realmente recebe na interface específica diretamente da rede física e não das outras unidades de cluster.

descartes de ASP

Se quiser verificar se há quedas de software para um fluxo específico, você pode habilitar a captura asp-drop. Se você não souber em qual motivo focar, use a palavra-chave all. Além disso, se você não estiver interessado no payload do pacote, poderá especificar a palavra-chave só de cabeçalhos. Isso permite capturar de 20 a 30 vezes mais pacotes:

firepower# cluster exec cap ASP type asp-drop all buffer 33554432 headers-only

unit-1-1(LOCAL):******************************************************

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Além disso, você pode especificar os IPs de interesse na captura do ASP:

firepower# cluster exec cap ASP type asp-drop all buffer 33554432 headers-only match ip host 192.0.2.100 any

Limpar uma captura

Para limpar o buffer de qualquer captura executada em todas as unidades de cluster. Isso não interrompe as capturas, mas apenas limpa os buffers:

firepower# cluster exec clear capture /all

unit-1-1(LOCAL):******************************************************

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Parar uma captura

Há duas maneiras de interromper uma captura ativa em todas as unidades de cluster. Mais tarde você pode continuar.

Via 1

firepower# cluster exec cap CAPI stop

unit-1-1(LOCAL):******************************************************

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Para continuar

firepower# cluster exec no capture CAPI stop

unit-1-1(LOCAL):******************************************************

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Via 2

firepower# cluster exec no capture CAPI interface INSIDE

unit-1-1(LOCAL):******************************************************

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Para continuar

firepower# cluster exec capture CAPI interface INSIDE

unit-1-1(LOCAL):******************************************************

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Coletar uma Captura

Há várias maneiras de exportar uma captura.

Forma 1 - Para um servidor remoto

Isso permite carregar uma captura do plano de dados para um servidor remoto (por exemplo, TFTP). Observe que os nomes de captura são alterados automaticamente para refletir a unidade de origem:

firepower# cluster exec copy /pcap capture:CAPI tftp://192.168.240.55/CAPI.pcap

unit-1-1(LOCAL):******************************************************

Source capture name [CAPI]?

Address or name of remote host [192.168.240.55]?

Destination filename [CAPI.pcap]?

INFO: Destination filename is changed to unit-1-1_CAPI.pcap !!!!!!!

81 packets copied in 0.40 secs

unit-2-1:*************************************************************

INFO: Destination filename is changed to unit-2-1_CAPI.pcap !

unit-3-1:*************************************************************

INFO: Destination filename is changed to unit-3-1_CAPI.pcap !

Os arquivos pcap carregados:

Forma 2 - Buscar as capturas do FMC

Este modo só se aplica ao DTF. Primeiro, você copia a captura para o disco FTD:

firepower# cluster exec copy /pcap capture:CAPI disk0:CAPI.pcap

unit-1-1(LOCAL):******************************************************

Source capture name [CAPI]?

Destination filename [CAPI.pcap]?

!!!!!

62 packets copied in 0.0 secs

No modo de especialista, copie o arquivo de /mnt/disk0/ para /ngfw/var/common/ diretory:

> expert

admin@firepower:~$ cd /mnt/disk0

admin@firepower:/mnt/disk0$ sudo cp CAPI.pcap /ngfw/var/common

Finalmente, na FMC, navegue até a seção System > Health > Monitor. Selecione View System & Troubleshoot Details > Advanced Troubleshooting e busque o arquivo de captura:

Excluir uma captura

Para remover uma captura de todas as unidades de cluster, use este comando:

firepower# cluster exec no capture CAPI

unit-1-1(LOCAL):******************************************************

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Fluxos descarregados

No FP41xx/FP9300, os fluxos podem ser descarregados no Acelerador de hardware estaticamente (por exemplo, regras de Fastpath) ou dinamicamente. Para obter mais detalhes sobre descarga de fluxo, consulte este documento:

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212321-clarify-the-firepower-threat-defense-acc.html#anc22

Se um fluxo for descarregado, somente alguns pacotes passarão pelo plano de dados FTD. O restante é tratado pelo acelerador de hardware (Smart NIC).

Do ponto de vista da captura, isso significa que, se você habilitar somente capturas de plano de dados FTD, não verá todos os pacotes que passam pelo dispositivo. Nesse caso, você também precisa ativar capturas no nível de chassi do FXOS.

Mensagens do Link de Controle de Cluster (CCL)

Se você capturar o CCL, perceberá que as unidades de cluster trocam diferentes tipos de mensagens. Os interesses são:

Protocolo

Descrição

UDP 49495

Pulsos do cluster (keepalives)

Difusão L3 (255.255.255.255)

Esses pacotes são enviados por cada unidade de cluster em 1/3 do valor do tempo de espera da verificação de integridade.

Observe que nem todos os pacotes UDP 49495 vistos na captura são heartbeats

Os batimentos cardíacos contêm um número de sequência

UDP 4193

Mensagens de caminho de dados do protocolo de controle de cluster

·Unicast

Esses pacotes contêm informações (metadados) sobre o proprietário do fluxo, direcionador, proprietário do backup etc. Exemplos são:

Uma mensagem ‘cluster add’ é enviada do proprietário ao direcionador quando um novo fluxo é criado

Uma mensagem de ‘exclusão de cluster’ é enviada do proprietário para o direcionador quando um fluxo é encerrado

Pacotes de dados

Pacotes de dados que pertencem aos vários fluxos de tráfego que atravessam o cluster

Pulsação do Cluster

Mensagens do Ponto de Controle de Cluster (CCP)

Além das mensagens de pulsação, há várias mensagens de controle de cluster que são trocadas através do CCL em cenários específicos. Alguns deles são mensagens unicast enquanto outros são broadcasts.

CLUSTER_QUIT_REASON_MASTER_UNIT_HC

Sempre que uma unidade perde 3 mensagens consecutivas de pulsação do nó de controle, ela gera uma mensagem CLUSTER_QUIT_REASON_MASTER_UNIT_HC sobre o CCL. Esta mensagem:

- É um unicast

- É enviado para cada uma das unidades com um intervalo de 1 segundo

- Quando uma unidade recebe esta mensagem sai do cluster (DESABILITADO) e junta-se novamente

P. Qual é a finalidade do CLUSTER_QUIT_REASON_MASTER_UNIT_HC?

A. Do ponto de vista da unidade-3-1 (Site-B), ela perde conexão com a unidade-1-1 e a unidade-2-1 do site A, portanto, ela precisa removê-los de sua lista de membros assim que possível, caso contrário, pode ter perdido o pacote se a unidade-2-1 ainda estiver em sua lista de membros e a unidade-2-1 for um diretor de uma conexão e a consulta de fluxo para a unidade-2-1 falhar.

CLUSTER_QUIT_REASON_UNIT_HC

Sempre que o nó de controle perde 3 mensagens consecutivas de pulsação de um nó de dados, ele envia a mensagem CLUSTER_QUIT_REASON_UNIT_HC pelo CCL. Esta mensagem é unicast.

CLUSTER_QUIT_REASON_STRAY_MEMBRO

Quando uma partição dividida se reconecta a uma partição peer, o novo nó de dados é tratado como um membro de fora pela unidade de controle dominante e recebe uma mensagem de abandono do CCP com o motivo de CLUSTER_QUIT_REASON_STRAY_MEMBRO.

CLUSTER_QUIT_MEMBRO_DROPOUT

Uma mensagem de broadcast gerada por um nó de dados e enviada como um broadcast. Quando uma unidade receber essa mensagem, ela passará para o status DESABILITADO. Além disso, a rejunção automática não é iniciada:

firepower# show cluster info trace | include DROPOUT

Nov 04 00:22:54.699 [DBUG]Receive CCP message: CCP_MSG_QUIT from unit-3-1 to unit-1-1 for reason CLUSTER_QUIT_MEMBER_DROPOUT

Nov 04 00:22:53.699 [DBUG]Receive CCP message: CCP_MSG_QUIT from unit-3-1 to unit-2-1 for reason CLUSTER_QUIT_MEMBER_DROPOUT

O histórico do cluster mostra:

MASTER       DISABLED      Received control message DISABLE (member dropout announcement)

Mecanismo de verificação de integridade do cluster (HC)

Pontos principais

- Cada unidade de cluster envia uma pulsação a cada 1/3 do valor do tempo de espera da verificação de integridade para todas as outras unidades (broadcast 255.255.255.255) e usa a porta UDP 49495 como transporte pelo CCL.

- Cada unidade de cluster rastreia de forma independente todas as outras unidades com um temporizador de Votação e um valor de contagem de Poll.

- Se uma unidade de cluster não receber nenhum pacote (heartbeat ou pacote de dados) de uma unidade peer de cluster dentro de um intervalo de pulsação, ele aumentará o valor da contagem de Poll.

- Quando o valor da contagem de Poll para uma unidade peer de cluster se torna 3, o peer é considerado inativo.

- Sempre que um heartbeat é recebido, seu número de sequência é verificado e, caso a diferença com o heartbeat recebido anteriormente seja diferente de 1, o contador de queda do heartbeat aumenta de acordo.

- Se o contador de contagem de Poll para um peer de cluster for diferente de 0 e um pacote for recebido pelo peer, o contador será redefinido para o valor 0.

Use este comando para verificar os contadores de integridade do cluster:

firepower# show cluster info health details

----------------------------------------------------------------------------------

|                Unit (ID)| Heartbeat| Heartbeat|   Average|   Maximum|      Poll|

|                         |     count|     drops|  gap (ms)| slip (ms)|     count|

----------------------------------------------------------------------------------

|            unit-2-1 ( 1)|       650|         0|      4999|         1|         0|

|            unit-3-1 ( 2)|       650|         0|      4999|         1|         0|

----------------------------------------------------------------------------------

Descrição das colunas principais

Coluna

Descrição

Unidade (ID)

A ID do peer do cluster remoto

Contagem de batimentos cardíacos

O número de batimentos cardíacos recebidos do peer remoto pelo CCL

Quedas de pulsação

O número de batimentos cardíacos perdidos. Este contador é calculado com base no número de sequência de pulsação recebido

Intervalo médio

O intervalo médio de tempo dos batimentos cardíacos recebidos

Contagem de sondagens

Quando este contador se torna 3, a unidade é removida do cluster. O intervalo de consulta de pesquisa é o mesmo que o intervalo de pulsação, mas é executado independentemente

Para redefinir os contadores, use este comando:

firepower# clear cluster info health details

P. Como verificar a frequência do batimento cardíaco

A. Verifique o valor médio da lacuna:

firepower# show cluster info health details

----------------------------------------------------------------------------------

|                Unit (ID)| Heartbeat| Heartbeat|   Average|   Maximum|      Poll|

|                         |     count|     drops|  gap (ms)| slip (ms)|     count|

----------------------------------------------------------------------------------

|            unit-2-1 ( 1)|      3036|         0|       999|         1|         0|

----------------------------------------------------------------------------------

P. Como você pode alterar o tempo de espera do cluster no FTD?

A. Usar FlexConfig

P. Quem se torna o nó de controle depois de um cérebro dividido?

A. A unidade com a prioridade mais alta (número mais baixo):

firepower# show run cluster | include priority

priority 9

Verifique o cenário de falha HC 1 para obter mais detalhes.

Visualização do mecanismo HC de cluster

Temporizadores indicativos: O mínimo e o máximo dependem da última chegada do pacote CCL recebido

Tempo de espera

Verificação de consulta de pesquisa

(frequência)

Tempo mínimo de detecção

Tempo máximo de detecção

3 seg (predefinição)

~1 s

~3,01 s

~3,99 s

4 s

~1,33 s

~4,01 s

~5,32 s

5 s

~1,66 s

~5,01 s

~6,65 s

6 s

~2 s

~6,01 s

~7,99 s

7 s

~2,33 s

~7,01 s

~9,32 s

8 s

~2,66 s

~8,01 s

~10,65 s

Cenários de falha de HC de cluster

Os objetivos desta seção são demonstrar:

- Diferentes cenários de falha de HC de cluster

- Como os diferentes registros e saídas de comando podem ser correlacionados

Topologia

Configuração de cluster

Unidade 1-1

Unidade 2-1

Unidade 3-1

cluster group GROUP1

key *****

local-unit unit-1-1

cluster-interface Port-channel48 ip 192.222.1.1 255.255.0.0

priority 9

health-check holdtime 3

health-check data-interface auto-rejoin 3 5 2

health-check cluster-interface auto-rejoin unlimited 5 1

health-check system auto-rejoin 3 5 2

health-check monitor-interface debounce-time 500

site-id 1

enable

cluster group GROUP1

key *****

local-unit unit-2-1

cluster-interface Port-channel48 ip 192.222.2.1 255.255.0.0

priority 17

health-check holdtime 3

health-check data-interface auto-rejoin 3 5 2

health-check cluster-interface auto-rejoin unlimited 5 1

health-check system auto-rejoin 3 5 2

health-check monitor-interface debounce-time 500

site-id 1

enable

cluster group GROUP1

key *****

local-unit unit-3-1

cluster-interface Port-channel48 ip 192.222.3.1 255.255.0.0

priority 25

health-check holdtime 3

health-check data-interface auto-rejoin 3 5 2

health-check cluster-interface auto-rejoin unlimited 5 1

health-check system auto-rejoin 3 5 2

health-check monitor-interface debounce-time 500

site-id 2

enable

Status do cluster

Unidade 1-1

Unidade 2-1

Unidade 3-1

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

This is "unit-1-1" in state MASTER

ID        : 0

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

Last join : 20:25:36 UTC Nov 1 2020

Last leave: 20:25:28 UTC Nov 1 2020

Other members in the cluster:

Unit "unit-3-1" in state SLAVE

ID        : 1

Site ID   : 2

Version   : 9.12(2)33

Serial No.: FCH22247MKJ

CCL IP    : 192.222.3.1

CCL MAC   : 0015.c500.038f

Last join : 20:58:45 UTC Nov 1 2020

Last leave: 20:58:37 UTC Nov 1 2020

Unit "unit-2-1" in state SLAVE

ID        : 2

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

Last join : 20:44:45 UTC Nov 1 2020

Last leave: 20:44:38 UTC Nov 1 2020

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

This is "unit-2-1" in state SLAVE

ID        : 2

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

Last join : 20:44:46 UTC Nov 1 2020

Last leave: 20:44:38 UTC Nov 1 2020

Other members in the cluster:

Unit "unit-1-1" in state MASTER

ID        : 0

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

Last join : 20:25:36 UTC Nov 1 2020

Last leave: 20:25:28 UTC Nov 1 2020

Unit "unit-3-1" in state SLAVE

ID        : 1

Site ID   : 2

Version   : 9.12(2)33

Serial No.: FCH22247MKJ

CCL IP    : 192.222.3.1

CCL MAC   : 0015.c500.038f

Last join : 20:58:45 UTC Nov 1 2020

Last leave: 20:58:37 UTC Nov 1 2020

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

This is "unit-3-1" in state SLAVE

ID        : 1

Site ID   : 2

Version   : 9.12(2)33

Serial No.: FCH22247MKJ

CCL IP    : 192.222.3.1

CCL MAC   : 0015.c500.038f

Last join : 20:58:45 UTC Nov 1 2020

Last leave: 20:58:37 UTC Nov 1 2020

Other members in the cluster:

Unit "unit-1-1" in state MASTER

ID        : 0

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

Last join : 20:25:36 UTC Nov 1 2020

Last leave: 20:25:28 UTC Nov 1 2020

Unit "unit-2-1" in state SLAVE

ID        : 2

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

Last join : 20:44:45 UTC Nov 1 2020

Last leave: 20:44:38 UTC Nov 1 2020

Cenário 1

Perda de comunicação CCL por aproximadamente 4+ segundos em ambas as direções

Antes da falha

FTD1

Ftd2

FTD3

Site A

Site A

Local B

nó de controle

Nó de dados

Nó de dados

Após a recuperação (sem alterações nas funções da unidade)

FTD1

Ftd2

FTD3

Site A

Site A

Local B

nó de controle

Nó de dados

Nó de dados

Análise

A falha (a comunicação CCL foi perdida)

A mensagem do console do plano de dados na unidade 3-1:

firepower#

WARNING: dynamic routing is not supported on management interface when cluster interface-mode is 'spanned'.

If dynamic routing is configured on any management interface, please remove it.

Cluster unit unit-3-1 transitioned from SLAVE to MASTER

Cluster disable is performing cleanup..done.

All data interfaces have been shutdown due to clustering being disabled.

To recover either enable clustering or remove cluster group configuration.

Logs de rastreamento de cluster da unidade 1-1:

firepower# show cluster info trace | include unit-3-1

Nov 02 09:38:14.239 [INFO]Notify chassis de-bundle port for blade unit-3-1, stack 0x000055a8918307fb 0x000055a8917fc6e8 0x000055a8917f79b5

Nov 02 09:38:14.239 [INFO]FTD - CD proxy received state notification (DISABLED) from unit unit-3-1

Nov 02 09:38:14.239 [DBUG]Send CCP message to all: CCP_MSG_QUIT from unit-1-1 to unit-3-1 for reason CLUSTER_QUIT_MEMBER_DROPOUT

Nov 02 09:38:14.239 [INFO]Notify chassis de-bundle port for blade unit-3-1, stack 0x000055a8917eb596 0x000055a8917f4838 0x000055a891abef9d

Nov 02 09:38:14.239 [DBUG]Send CCP message to id 1: CCP_MSG_QUIT from unit-1-1 to unit-3-1 for reason CLUSTER_QUIT_REASON_UNIT_HC

Nov 02 09:38:14.239 [CRIT]Received heartbeat event 'slave heartbeat failure' for member unit-3-1 (ID: 1).

Dividir cérebro

Unidade 1-1

Unidade 2-1

Unidade 3-1

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

This is "unit-1-1" in state MASTER

ID        : 0

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

Last join : 20:25:36 UTC Nov 1 2020

Last leave: 20:25:28 UTC Nov 1 2020

Other members in the cluster:

Unit "unit-2-1" in state SLAVE

ID        : 2

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

Last join : 20:44:45 UTC Nov 1 2020

Last leave: 20:44:38 UTC Nov 1 2020

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

This is "unit-2-1" in state SLAVE

ID        : 2

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

Last join : 20:44:46 UTC Nov 1 2020

Last leave: 20:44:38 UTC Nov 1 2020

Other members in the cluster:

Unit "unit-1-1" in state MASTER

ID        : 0

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

Last join : 20:25:36 UTC Nov 1 2020

Last leave: 20:25:28 UTC Nov 1 2020

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

This is "unit-3-1" in state MASTER

ID        : 1

Site ID   : 2

Version   : 9.12(2)33

Serial No.: FCH22247MKJ

CCL IP    : 192.222.3.1

CCL MAC   : 0015.c500.038f

Last join : 09:34:02 UTC Nov 2 2020

Last leave: 09:33:54 UTC Nov 2 2020

Other members in the cluster:

There is no other unit in the cluster

Histórico do cluster

Unidade 1-1

Unidade 2-1

Unidade 3-1

Nenhum evento

Nenhum evento

09:38:16 UTC Nov 2 2020

SLAVE                 MASTER_POST_CONFIG    Master relinquished role

09:38:17 UTC Nov 2 2020

MASTER_POST_CONFIG    MASTER                Master post config done and waiting for ntfy

restauração de comunicação CCL

A unidade-1-1 detecta o nó de controle atual e, como a unidade-1-1 tem prioridade mais alta envia para a unidade-3-1 uma mensagem CLUSTER_QUIT_REASON_STRAY_MEMBRO para disparar um novo processo de eleição. No final, a unidade 3-1 se junta novamente como um nó de dados.

Quando uma partição dividida se reconecta a uma partição peer, o nó de dados é tratado como um membro de fora pelo nó de controle dominante e recebe uma mensagem de saída CCP com um motivo de CLUSTER_QUIT_REASON_STRAY_MEMBRO.

Unit-3-1 console logs show:

Cluster unit unit-3-1 transitioned from MASTER to DISABLED

The 3DES/AES algorithms require a Encryption-3DES-AES activation key.

Detected Cluster Master.

Beginning configuration replication from Master.

WARNING: Local user database is empty and there are still 'aaa' commands for 'LOCAL'.

..

Cryptochecksum (changed): a9ed686f 8e2e689c 2553a104 7a2bd33a

End configuration replication from Master.

Cluster unit unit-3-1 transitioned from DISABLED to SLAVE

Ambas as unidades (unidade 1-1 e unidade 3-1) mostram em seus registros de cluster:

firepower# show cluster info trace | include retain

Nov 03 21:20:23.019 [CRIT]Found a split cluster with both unit-1-1 and unit-3-1 as master units. Master role retained by unit-1-1, unit-3-1 will leave then join as a slave

Nov 03 21:20:23.019 [CRIT]Found a split cluster with both unit-1-1 and unit-3-1 as master units. Master role retained by unit-1-1, unit-3-1 will leave then join as a slave

Há também mensagens de syslog geradas para o split-brain:

firepower# show log | include 747016

Nov 03 2020 21:20:23: %FTD-4-747016: Clustering: Found a split cluster with both unit-1-1 and unit-3-1 as master units. Master role retained by unit-1-1, unit-3-1 will leave then join as a slave

Nov 03 2020 21:20:23: %FTD-4-747016: Clustering: Found a split cluster with both unit-1-1 and unit-3-1 as master units. Master role retained by unit-1-1, unit-3-1 will leave then join as a slave

Histórico do cluster

Unidade 1-1

Unidade 2-1

Unidade 3-1

Nenhum evento

Nenhum evento

09:47:33 UTC Nov 2 2020

MASTER                DISABLED        Detected a splitted cluster

09:47:38 UTC Nov 2 2020

DISABLED              ELECTION        Enabled from CLI

09:47:38 UTC Nov 2 2020

ELECTION              SLAVE_COLD      Received cluster control message

09:47:38 UTC Nov 2 2020

SLAVE_COLD            SLAVE_APP_SYNC  Client progression done

09:48:18 UTC Nov 2 2020

SLAVE_APP_SYNC        SLAVE_CONFIG    Slave application configuration sync done

09:48:29 UTC Nov 2 2020

SLAVE_CONFIG          SLAVE_FILESYS   Configuration replication finished

09:48:30 UTC Nov 2 2020

SLAVE_FILESYS         SLAVE_BULK_SYNC Client progression done

09:48:54 UTC Nov 2 2020

SLAVE_BULK_SYNC       SLAVE           Client progression done

Cenário 2

Perda de comunicação CCL por aproximadamente 3 a 4 segundos em ambas as direções

Antes da falha

FTD1

Ftd2

FTD3

Site A

Site A

Local B

nó de controle

Nó de dados

Nó de dados

Após a recuperação (sem alterações nas funções da unidade)

FTD1

Ftd2

FTD3

Site A

Site A

Local B

nó de controle

Nó de dados

Nó de dados

Análise

Evento 1: O nó de controle perde 3 HCs da unidade 3-1 e envia uma mensagem para a unidade 3-1 para deixar o cluster.

Evento 2: O CCL recuperou muito rápido e a mensagem CLUSTER_QUIT_REASON_STRAY_MEMBRO do nó de controle chegou ao lado remoto. A unidade 3-1 vai diretamente para o modo DESABILITADO e não há cérebro dividido

Na unidade-1-1 (controle), você vê:

firepower#

Asking slave unit unit-3-1 to quit because it failed unit health-check.

Forcing stray member unit-3-1 to leave the cluster

Na unidade 3-1 (nó de dados) você vê:

firepower#

Cluster disable is performing cleanup..done.

All data interfaces have been shutdown due to clustering being disabled. To recover either enable clustering or remove cluster group configuration.

Cluster unit unit-3-1 transitioned from SLAVE to DISABLED

A unidade de cluster 3-1 transitou para um estado DESABILITADO e, depois que a comunicação CCL for restaurada, ela se junta novamente como um nó de dados:

firepower# show cluster history

20:58:40 UTC Nov 1 2020

SLAVE                 DISABLED              Received control message DISABLE (stray member)

20:58:45 UTC Nov 1 2020

DISABLED              ELECTION              Enabled from CLI

20:58:45 UTC Nov 1 2020

ELECTION              SLAVE_COLD            Received cluster control message

20:58:45 UTC Nov 1 2020

SLAVE_COLD            SLAVE_APP_SYNC        Client progression done

20:59:33 UTC Nov 1 2020

SLAVE_APP_SYNC        SLAVE_CONFIG          Slave application configuration sync done

20:59:44 UTC Nov 1 2020

SLAVE_CONFIG          SLAVE_FILESYS         Configuration replication finished

20:59:45 UTC Nov 1 2020

SLAVE_FILESYS         SLAVE_BULK_SYNC       Client progression done

21:00:09 UTC Nov 1 2020

SLAVE_BULK_SYNC       SLAVE                 Client progression done

Cenário 3

Perda de comunicação CCL por aproximadamente 3 a 4 segundos em ambas as direções

Antes da falha

FTD1

Ftd2

FTD3

Site A

Site A

Local B

nó de controle

Nó de dados

Nó de dados

Após a recuperação (o nó de controle foi alterado)

FTD1

Ftd2

FTD3

Site A

Site A

Local B

Nó de dados

nó de controle

Nó de dados

Análise

1. CCL cai.

2. A Unidade 1-1 não recebe 3 mensagens de HC da unidade 3-1 e envia uma mensagem de QUIT para a unidade 3-1. Esta mensagem nunca chega à unidade 3-1

3. A unidade 3-1 envia uma mensagem de QUIT para a unidade 2-1. Esta mensagem nunca chega à unidade 2-1.

CCL recupera

4. A unidade-1-1 vê que a unidade-3-1 se anunciou como um nó de controle e envia a mensagem QUIT_REASON_STRAY_MEMBRO para a unidade-3-1. Quando a unidade 3-1 recebe essa mensagem vai para um estado DESABILITADO. Ao mesmo tempo, a unidade-3-1 envia uma mensagem QUIT_REASON_MASTER_UNIT_HC para a unidade-1-1 e solicita que ela saia. Quando a unidade-1-1 recebe esta mensagem vai para o estado DESABILITADO

Histórico do cluster

Unidade 1-1

Unidade 2-1

Unidade 3-1

19:53:09 UTC Nov 2 2020

MASTER                DISABLED        Received control message DISABLE

(master unit health check failure)

19:53:13 UTC Nov 2 2020

DISABLED              ELECTION         Enabled from CLI

19:53:13 UTC Nov 2 2020

ELECTION              SLAVE_COLD       Received cluster control message

19:53:13 UTC Nov 2 2020

SLAVE_COLD            SLAVE_APP_SYNC   Client progression done

19:54:01 UTC Nov 2 2020

SLAVE_APP_SYNC        SLAVE_CONFIG     Slave application configuration sync done

19:54:12 UTC Nov 2 2020

SLAVE_CONFIG          SLAVE_FILESYS    Configuration replication finished

19:54:13 UTC Nov 2 2020

SLAVE_FILESYS         SLAVE_BULK_SYNC  Client progression done

19:54:37 UTC Nov 2 2020

SLAVE_BULK_SYNC       SLAVE            Client progression done

19:53:06 UTC Nov 2 2020

SLAVE      MASTER_POST_CONFIG  Master relinquished role

19:53:07 UTC Nov 2 2020

MASTER_POST_CONFIG  MASTER     Master post config done

and waiting for ntfy

19:53:06 UTC Nov 2 2020

SLAVE              MASTER_POST_CONFIG  Master relinquished role

19:53:07 UTC Nov 2 2020

MASTER_POST_CONFIG    MASTER           Master post config done

and waiting for ntfy

19:53:09 UTC Nov 2 2020

MASTER                DISABLED         Detected a splitted cluster

19:53:15 UTC Nov 2 2020

DISABLED              ELECTION         Enabled from CLI

...

19:53:20 UTC Nov 2 2020

ELECTION              ONCALL           Received cluster control message

19:54:44 UTC Nov 2 2020

ONCALL                SLAVE_COLD       Received cluster control message

19:54:44 UTC Nov 2 2020

SLAVE_COLD            SLAVE_APP_SYNC   Client progression done

19:55:32 UTC Nov 2 2020

SLAVE_APP_SYNC        SLAVE_CONFIG     Slave application

configuration sync done

19:55:43 UTC Nov 2 2020

SLAVE_CONFIG          SLAVE_FILESYS    Configuration replication finished

19:55:44 UTC Nov 2 2020

SLAVE_FILESYS         SLAVE_BULK_SYNC  Client progression done

19:56:08 Nov 2 2020

SLAVE_BULK_SYNC       SLAVE            Client progression done

Cenário 4

Perda de comunicação CCL por aproximadamente 3 a 4 segundos

Antes da falha

FTD1

Ftd2

FTD3

Site A

Site A

Local B

nó de controle

Nó de dados

Nó de dados

Após a recuperação (o nó de controle alterou os sites)

FTD1

Ftd2

FTD3

Site A

Site A

Local B

Nó de dados

Nó de dados

nó de controle

Análise

A falha

Um sabor diferente do mesmo fracasso. Nesse caso, a unidade-1-1 também não recebeu 3 mensagens de HC da unidade-3-1 e, depois de receber uma nova manutenção de atividade, tentou expulsar a unidade-3-1 com o uso de uma mensagem STRAY, mas a mensagem nunca chegou à unidade-3-1:

1. O CCL se torna unidirecional por alguns segundos. A unidade 3-1 não recebe 3 mensagens de HC da unidade-1-1 e torna-se um nó de controle

2. A Unidade 2-1 envia uma mensagem CLUSTER_QUIT_REASON_RETIREMENT (broadcast)

3. A unidade 3-1 envia uma mensagem QUIT_REASON_MASTER_UNIT_HC para a unidade 2-1. A Unidade 2-1 recebe e sai do cluster.

4. A unidade 3-1 envia uma mensagem QUIT_REASON_MASTER_UNIT_HC para a unidade 1-1. A Unidade 1-1 recebe e sai do cluster. CCL recupera.

5. As Unidades 1-1 e 2-1 reingressam no cluster como nós de dados

Nota

Se na etapa 5 o CCL não se recuperar, então no site A o FTD1 se tornará o novo nó de controle e, após a recuperação do CCL, ele ganhará a nova eleição.

Mensagens de syslog na unidade 1-1:

firepower# show log | include 747

Nov 03 2020 23:13:08: %FTD-7-747005: Clustering: State machine notify event CLUSTER_EVENT_MEMBER_STATE (unit-3-1,DISABLED,0x0000000000000000)

Nov 03 2020 23:13:09: %FTD-4-747015: Clustering: Forcing stray member unit-3-1 to leave the cluster

Nov 03 2020 23:13:09: %FTD-7-747005: Clustering: State machine notify event CLUSTER_EVENT_MEMBER_STATE (unit-2-1,DISABLED,0x0000000000000000)

Nov 03 2020 23:13:10: %FTD-4-747015: Clustering: Forcing stray member unit-3-1 to leave the cluster

Nov 03 2020 23:13:10: %FTD-6-747004: Clustering: State machine changed from state MASTER to DISABLED

Nov 03 2020 23:13:12: %FTD-7-747006: Clustering: State machine is at state DISABLED

Nov 03 2020 23:13:12: %FTD-7-747005: Clustering: State machine notify event CLUSTER_EVENT_MY_STATE (state DISABLED,0x0000000000000000,0x0000000000000000)

Nov 03 2020 23:13:18: %FTD-6-747004: Clustering: State machine changed from state ELECTION to ONCALL

Logs de rastreamento do cluster na unidade-1-1:

firepower# show cluster info trace | include QUIT

Nov 03 23:13:10.789 [DBUG]Send CCP message to all: CCP_MSG_QUIT from unit-1-1 for reason CLUSTER_QUIT_REASON_RETIREMENT

Nov 03 23:13:10.769 [DBUG]Receive CCP message: CCP_MSG_QUIT from unit-3-1 to unit-1-1 for reason CLUSTER_QUIT_REASON_MASTER_UNIT_HC

Nov 03 23:13:10.769 [DBUG]Send CCP message to id 1: CCP_MSG_QUIT from unit-1-1 to unit-3-1 for reason CLUSTER_QUIT_REASON_STRAY_MEMBER

Nov 03 23:13:09.789 [DBUG]Receive CCP message: CCP_MSG_QUIT from unit-2-1 for reason CLUSTER_QUIT_REASON_RETIREMENT

Nov 03 23:13:09.769 [DBUG]Send CCP message to id 1: CCP_MSG_QUIT from unit-1-1 to unit-3-1 for reason CLUSTER_QUIT_REASON_STRAY_MEMBER

Nov 03 23:13:08.559 [DBUG]Send CCP message to all: CCP_MSG_QUIT from unit-1-1 to unit-3-1 for reason CLUSTER_QUIT_MEMBER_DROPOUT

Nov 03 23:13:08.559 [DBUG]Send CCP message to id 1: CCP_MSG_QUIT from unit-1-1 to unit-3-1 for reason CLUSTER_QUIT_REASON_UNIT_HC

Mensagens de syslog na unidade 3-1:

firepower# show log | include 747

Nov 03 2020 23:13:09: %FTD-7-747005: Clustering: State machine notify event CLUSTER_EVENT_MEMBER_STATE (unit-2-1,DISABLED,0x0000000000000000)

Nov 03 2020 23:13:10: %FTD-7-747005: Clustering: State machine notify event CLUSTER_EVENT_MEMBER_STATE (unit-1-1,DISABLED,0x0000000000000000)

Nov 03 2020 23:13:10: %FTD-6-747004: Clustering: State machine changed from state SLAVE to MASTER

Nov 03 2020 23:13:10: %FTD-6-747004: Clustering: State machine changed from state MASTER_FAST to MASTER_DRAIN

Nov 03 2020 23:13:10: %FTD-6-747004: Clustering: State machine changed from state MASTER_DRAIN to MASTER_CONFIG

Nov 03 2020 23:13:10: %FTD-6-747004: Clustering: State machine changed from state MASTER_CONFIG to MASTER_POST_CONFIG

Nov 03 2020 23:13:10: %FTD-7-747006: Clustering: State machine is at state MASTER_POST_CONFIG

Nov 03 2020 23:13:10: %FTD-6-747004: Clustering: State machine changed from state MASTER_POST_CONFIG to MASTER

Nov 03 2020 23:13:10: %FTD-7-747006: Clustering: State machine is at state MASTER

Histórico do cluster

Unidade 1-1

Unidade 2-1

Unidade 3-1

23:13:13 UTC Nov 3 2020

MASTER          DISABLED        Received control message DISABLE

(master unit health check failure)

23:13:18 UTC Nov 3 2020

DISABLED        ELECTION        Enabled from CLI

23:13:18 UTC Nov 3 2020

ELECTION        ONCALL          Received cluster control message

23:13:23 UTC Nov 3 2020

ONCALL          ELECTION        Received cluster control message

…

23:14:48 UTC Nov 3 2020

ONCALL          ELECTION        Received cluster control message

23:14:48 UTC Nov 3 2020

ELECTION        SLAVE_COLD      Received cluster control message

23:14:48 UTC Nov 3 2020

SLAVE_COLD      SLAVE_APP_SYNC  Client progression done

23:15:36 UTC Nov 3 2020

SLAVE_APP_SYNC  SLAVE_CONFIG    Slave application configuration

sync done

23:15:48 UTC Nov 3 2020

SLAVE_CONFIG    SLAVE_FILESYS   Configuration replication finished

23:15:49 UTC Nov 3 2020

SLAVE_FILESYS   SLAVE_BULK_SYNC Client progression done

23:16:13 UTC Nov 3 2020

SLAVE_BULK_SYNC SLAVE           Client progression done

23:13:12 UTC Nov 3 2020

SLAVE           DISABLED         Received control message DISABLE

(master unit health check failure)

23:13:17 UTC Nov 3 2020

DISABLED        ELECTION         Enabled from CLI

23:13:17 UTC Nov 3 2020

ELECTION        SLAVE_COLD       Received cluster control message

23:13:17 UTC Nov 3 2020

SLAVE_COLD      SLAVE_APP_SYNC   Client progression done

23:14:05 UTC Nov 3 2020

SLAVE_APP_SYNC  SLAVE_CONFIG     Slave application configuration

sync done

23:14:16 UTC Nov 3 2020

SLAVE_CONFIG    SLAVE_FILESYS    Configuration replication finished

23:14:17 UTC Nov 3 2020

SLAVE_FILESYS   SLAVE_BULK_SYNC  Client progression done

23:14:41 UTC Nov 3 2020

SLAVE_BULK_SYNC SLAVE            Client progression done

23:13:10 UTC Nov 3 2020

SLAVE    MASTER_POST_CONFIG  Master relinquished role

23:13:11 UTC Nov 3 2020

MASTER_POST_CONFIG MASTER   Master post config

done and waiting for ntfy

Cenário 5

Antes da falha

FTD1

Ftd2

FTD3

Site A

Site A

Local B

nó de controle

Nó de dados

Nó de dados

Após a recuperação (sem alterações)

FTD1

Ftd2

FTD3

Site A

Site A

Local B

nó de controle

Nó de dados

Nó de dados

A falha

A unidade 3-1 enviou mensagens de QUIT para a unidade 1-1 e para a unidade 2-1, mas devido a problemas de conectividade, apenas a unidade 2-1 recebeu a mensagem de QUIT.

Logs de rastreamento de cluster da unidade 1-1:

firepower# show cluster info trace | include QUIT

Nov 04 00:52:10.429 [DBUG]Receive CCP message: CCP_MSG_QUIT from unit-3-1 for reason CLUSTER_QUIT_REASON_RETIREMENT

Nov 04 00:51:47.059 [DBUG]Receive CCP message: CCP_MSG_QUIT from unit-2-1 for reason CLUSTER_QUIT_REASON_RETIREMENT

Nov 04 00:51:45.429 [DBUG]Send CCP message to all: CCP_MSG_QUIT from unit-1-1 to unit-3-1 for reason CLUSTER_QUIT_MEMBER_DROPOUT

Nov 04 00:51:45.429 [DBUG]Send CCP message to unit-3-1(1): CCP_MSG_QUIT from unit-1-1 to unit-3-1 for reason CLUSTER_QUIT_REASON_UNIT_HC

Logs de rastreamento de cluster da unidade 2-1:

firepower# show cluster info trace | include QUIT

Nov 04 00:52:10.389 [DBUG]Receive CCP message: CCP_MSG_QUIT from unit-3-1 for reason CLUSTER_QUIT_REASON_RETIREMENT

Nov 04 00:51:47.019 [DBUG]Send CCP message to all: CCP_MSG_QUIT from unit-2-1 for reason CLUSTER_QUIT_REASON_RETIREMENT

Nov 04 00:51:46.999 [DBUG]Receive CCP message: CCP_MSG_QUIT from unit-3-1 to unit-2-1 for reason CLUSTER_QUIT_REASON_MASTER_UNIT_HC

Nov 04 00:51:45.389 [DBUG]Receive CCP message: CCP_MSG_QUIT from unit-1-1 to unit-3-1 for reason CLUSTER_QUIT_MEMBER_DROPOUT

Histórico do cluster

Unidade 1-1

Unidade 2-1

Unidade 3-1

Nenhum evento

00:51:50 UTC Nov 4 2020

SLAVE            DISABLED         Received control message DISABLE

(master unit health check failure)

00:51:54 UTC Nov 4 2020

DISABLED         ELECTION         Enabled from CLI

00:51:54 UTC Nov 4 2020

ELECTION         SLAVE_COLD       Received cluster control message

00:51:54 UTC Nov 4 2020

SLAVE_COLD       SLAVE_APP_SYNC   Client progression done

00:52:42 UTC Nov 4 2020

SLAVE_APP_SYNC   SLAVE_CONFIG     Slave application configuration

sync done

00:52:54 UTC Nov 4 2020

SLAVE_CONFIG     SLAVE_FILESYS    Configuration replication finished

00:52:55 UTC Nov 4 2020

SLAVE_FILESYS    SLAVE_BULK_SYNC  Client progression done

00:53:19 UTC Nov 4 2020

SLAVE_BULK_SYNC  SLAVE            Client progression done

00:51:47 UTC Nov 4 2020

SLAVE        MASTER_POST_CONFIG  Master relinquished role

00:51:48 UTC Nov 4 2020

MASTER_POST_CONFIG MASTER        Master post config done and

waiting for ntfy

00:52:12 UTC Nov 4 2020

MASTER           DISABLED        Detected a splitted cluster

00:52:17 UTC Nov 4 2020

DISABLED         ELECTION        Enabled from CLI

00:52:17 UTC Nov 4 2020

ELECTION         ONCALL          Received cluster control message

00:53:25 UTC Nov 4 2020

ONCALL           SLAVE_COLD      Received cluster control message

00:53:25 UTC Nov 4 2020

SLAVE_COLD       SLAVE_APP_SYNC  Client progression done

00:54:12 UTC Nov 4 2020

SLAVE_APP_SYNC   SLAVE_CONFIG    Slave application configuration

sync done

00:54:24 UTC Nov 4 2020

SLAVE_CONFIG     SLAVE_FILESYS   Configuration replication finished

00:54:25 UTC Nov 4 2020

SLAVE_FILESYS    SLAVE_BULK_SYNC Client progression done

00:54:49 UTC Nov 4 2020

SLAVE_BULK_SYNC  SLAVE           Client progression done

Estabelecimento de Conexão do Plano de Dados do Cluster

Pontos de captura do NGFW

O NGFW oferece recursos de captura nestes pontos:

- Switch interno do chassi (FXOS)

- Engine de plano de dados FTD

- mecanismo de Snort FTD

Quando você soluciona problemas de caminho de dados em um cluster, os pontos de captura usados na maioria dos casos são as capturas do mecanismo de plano de dados FXOS e FTD.

1. Captura de entrada FXOS na interface física

2. Captura de entrada FTD no mecanismo de plano de dados

3. Captura de saída FTD no mecanismo de plano de dados

4. Captura de entrada FXOS na interface do painel traseiro

Para obter detalhes adicionais sobre capturas de NGFW, consulte este documento:

Conceitos Básicos das Funções de Fluxo da Unidade de Cluster

As conexões podem ser estabelecidas por meio de um cluster de várias maneiras que dependem de fatores como:

- Tipo de tráfego (TCP, UDP, etc)

- Algoritmo de balanceamento de carga configurado no switch adjacente

- Recursos configurados no firewall

- Condições de rede (por exemplo, fragmentação de IP, atrasos de rede, etc.)

Função de fluxo

Descrição

Sinalizador(es)

PROPRIETÁRIO

Geralmente, a unidade que recebe inicialmente a conexão

UIO

Director

A unidade que lida com solicitações de pesquisa do proprietário de encaminhadores.

Y

Proprietário do backup

Desde que o direcionador não seja a mesma unidade do proprietário, o direcionador também é o proprietário do backup. Se o proprietário escolher a si mesmo como o direcionador, então um proprietário de backup separado é escolhido.

Y (se o direcionador também for o proprietário do backup)

y (se o direcionador não for o proprietário do backup)

Encaminhador

Uma unidade que encaminha pacotes ao proprietário

z

Proprietário do fragmento

A unidade que lida com o tráfego fragmentado

-

Backup do chassi

Em um cluster entre chassis quando os fluxos de diretor/backup e proprietário são de propriedade das unidades do mesmo chassi, uma unidade em um dos outros chassis se torna um backup/direcionador secundário.

Essa função é específica para clusters entre chassis do Firepower 9300 Series com mais de um blade.

w

- Para obter mais detalhes, consulte a seção relacionada no Guia de configuração (consulte os links nas Informações relacionadas)

- Em cenários específicos (ver seção de estudos de caso), alguns sinalizadores podem não ser mostrados

Estudos de caso de estabelecimento de conexão de cluster

A próxima seção aborda vários estudos de caso que demonstram algumas das maneiras pelas quais uma conexão pode ser estabelecida através de um cluster. As metas são:

- Familiarize-se com as diferentes funções de unidade

- Demonstrar como as várias saídas de comando podem ser correlacionadas

Topologia

Unidades e IDs de cluster:

Unidade 1-1

Unidade 2-1

Unidade 3-1

Cluster GROUP1: On

Interface mode: spanned

This is "unit-1-1" in state MASTER

ID        : 0

Site ID   : 1

Version   : 9.15(1)

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

Last join : 02:24:43 UTC Nov 27 2020

Last leave: N/A

Unit "unit-2-1" in state SLAVE

ID        : 1

Site ID   : 1

Version   : 9.15(1)

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

Last join : 02:04:19 UTC Nov 27 2020

Last leave: N/A

Unit "unit-3-1" in state SLAVE

ID        : 2

Site ID   : 2

Version   : 9.15(1)

Serial No.: FCH22247MKJ

CCL IP    : 192.222.3.1

CCL MAC   : 0015.c500.038f

Last join : 01:42:59 UTC Nov 27 2020

Last leave: 01:29:18 UTC Nov 27 2020

Capturas de cluster habilitadas:

cluster exec cap CAPI int INSIDE buffer 33554432 match tcp host 192.168.240.50 host 192.168.241.50 eq 80

cluster exec cap CAPO int OUTSIDE buffer 33554432 match tcp host 192.168.240.50 host 192.168.241.50 eq 80

cluster exec cap CAPI_RH reinject-hide int INSIDE buffer 33554432 match tcp host 192.168.240.50 host 192.168.241.50 eq 80

cluster exec cap CAPO_RH reinject-hide int OUTSIDE buffer 33554432 match tcp host 192.168.240.50 host 192.168.241.50 eq 80

cluster exec cap CCL int cluster buffer 33554432

Note: Esses testes foram executados em um ambiente de laboratório com tráfego mínimo através do cluster. Na produção, tente usar o máximo possível de filtros de captura específicos (por exemplo, porta de destino e, sempre que possível, porta de origem) para minimizar o "ruído" nas capturas.

Casos Práticos 1. Tráfego simétrico (o proprietário também é o diretor)

Observação 1. As capturas de re-ocultar mostram pacotes somente na unidade 1-1. Isso significa que o fluxo em ambas as direções passou pela unidade 1-1 (tráfego simétrico):

firepower# cluster exec show cap

unit-1-1(LOCAL):******************************************************

capture CCL type raw-data interface cluster [Capturing - 33513 bytes]

capture CAPI type raw-data buffer 33554432 trace interface INSIDE [Buffer Full - 33553914 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

capture CAPO type raw-data buffer 33554432 trace interface OUTSIDE [Buffer Full - 33553914 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

capture CAPI_RH type raw-data reinject-hide buffer 33554432 interface INSIDE [Buffer Full - 33553914 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

capture CAPO_RH type raw-data reinject-hide buffer 33554432 interface OUTSIDE [Buffer Full - 33553914 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

unit-2-1:*************************************************************

capture CCL type raw-data interface cluster [Capturing - 23245 bytes]

capture CAPI type raw-data buffer 33554432 trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

capture CAPO type raw-data buffer 33554432 trace interface OUTSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

capture CAPI_RH type raw-data reinject-hide buffer 33554432 interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

capture CAPO_RH type raw-data reinject-hide buffer 33554432 interface OUTSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

unit-3-1:*************************************************************

capture CCL type raw-data interface cluster [Capturing - 24815 bytes]

capture CAPI type raw-data buffer 33554432 trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

capture CAPO type raw-data buffer 33554432 trace interface OUTSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

capture CAPI_RH type raw-data reinject-hide buffer 33554432 interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

capture CAPO_RH type raw-data reinject-hide buffer 33554432 interface OUTSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq 80

Observação 2. Análise do sinalizador de conexão para fluxo com a porta origem 45954

firepower# cluster exec show conn

unit-1-1(LOCAL):******************************************************

22 in use, 25 most used

Cluster:

fwd connections: 0 in use, 1 most used

dir connections: 0 in use, 122 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 1 enabled, 0 in effect, 2 most enabled, 1 most in effect

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:45954, idle 0:00:00, bytes 487413076, flags UIO N1

unit-2-1:*************************************************************

22 in use, 271 most used

Cluster:

fwd connections: 0 in use, 2 most used

dir connections: 0 in use, 2 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 1 enabled, 0 in effect, 249 most enabled, 0 most in effect

unit-3-1:*************************************************************

17 in use, 20 most used

Cluster:

fwd connections: 1 in use, 2 most used

dir connections: 1 in use, 127 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 1 most enabled, 0 most in effect

TCP OUTSIDE 192.168.241.50:443 NP Identity Ifc 192.168.240.50:39698, idle 0:00:23, bytes 0, flags z

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:45954, idle 0:00:06, bytes 0, flags y

Unidade

Sinalizador

Nota

Unidade 1-1

UIO

· Flow Owner - A unidade lida com o fluxo

· Diretor - Uma vez que a unidade 3-1 tem "y" e não "Y", tal implica que a unidade 1-1 foi escolhida como diretor para este fluxo. Assim, como também é proprietária, outra unidade (unidade 3-1, neste caso) foi eleita como proprietária da cópia de segurança

Unidade 2-1

-

-

Unidade 3-1

y

A unidade é um proprietário de backup

Isso pode ser visualizado da seguinte maneira:

1. O pacote TCP SYN chega do Host-A para a unidade 1-1. A unidade 1-1 torna-se o proprietário do fluxo

2. A Unidade 1-1 também é eleita diretora de fluxo. Assim, ele também elege a unidade 3-1 como o proprietário do backup (mensagem de adição de cluster)

3. O pacote TCP SYN/ACK chega do Host-B para a unidade 3-1. O fluxo é simétrico

4. Quando a conexão é encerrada, o proprietário envia uma mensagem de exclusão de cluster para remover as informações de fluxo do proprietário do backup

Observação 3. Captura com rastreamento mostra que ambas as direções passam apenas pela unidade 1-1

Etapa 1. Identifique o fluxo e os pacotes de interesse em todas as unidades de cluster com base na porta de origem:

firepower# cluster exec show capture CAPI | i 45954

unit-1-1(LOCAL):******************************************************

1: 08:42:09.362697 802.1Q vlan#201 P0 192.168.240.50.45954 > 192.168.241.50.80: S 992089269:992089269(0) win 29200 <mss 1460,sackOK,timestamp 495153655 0,nop,wscale 7>

2: 08:42:09.363521 802.1Q vlan#201 P0 192.168.241.50.80 > 192.168.240.50.45954: S 4042762409:4042762409(0) ack 992089270 win 28960 <mss 1380,sackOK,timestamp 505509125 495153655,nop,wscale 7>

3: 08:42:09.363827 802.1Q vlan#201 P0 192.168.240.50.45954 > 192.168.241.50.80: . ack 4042762410 win 229 <nop,nop,timestamp 495153657 505509125>

…

unit-2-1:*************************************************************

unit-3-1:*************************************************************

firepower# cluster exec show capture CAPO | i 45954

unit-1-1(LOCAL):******************************************************

1: 08:42:09.362987 802.1Q vlan#202 P0 192.168.240.50.45954 > 192.168.241.50.80: S 2732339016:2732339016(0) win 29200 <mss 1380,sackOK,timestamp 495153655 0,nop,wscale 7>

2: 08:42:09.363415 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.45954: S 3603655982:3603655982(0) ack 2732339017 win 28960 <mss 1460,sackOK,timestamp 505509125 495153655,nop,wscale 7>

3: 08:42:09.363903 802.1Q vlan#202 P0 192.168.240.50.45954 > 192.168.241.50.80: . ack 3603655983 win 229 <nop,nop,timestamp 495153657 505509125>

…

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Etapa 2. Como esse é um fluxo TCP, rastreie os pacotes de handshake triplo. Como pode ser visto nesta saída, a unidade 1-1 é o proprietário. Para simplificar, as fases de rastreamento não relevantes são omitidas:

firepower# show cap CAPI packet-number 1 trace

25985 packets captured

1: 08:42:09.362697 802.1Q vlan#201 P0 192.168.240.50.45954 > 192.168.241.50.80: S 992089269:992089269(0) win 29200 <mss 1460,sackOK,timestamp 495153655 0,nop,wscale 7>

...

Phase: 4

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (0) got initial, attempting ownership.

Phase: 5

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (0) am becoming owner

...

O tráfego de retorno (TCP SYN/ACK):

firepower# show capture CAPO packet-number 2 trace

25985 packets captured

2: 08:42:09.363415 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.45954: S 3603655982:3603655982(0) ack 2732339017 win 28960 <mss 1460,sackOK,timestamp 505509125 495153655,nop,wscale 7>

...

Phase: 3

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found flow with id 9364, using existing flow

Observação 4. Os syslogs do plano de dados FTD mostram a criação e a terminação da conexão em todas as unidades:

firepower# cluster exec show log | include 45954

unit-1-1(LOCAL):******************************************************

Dec 01 2020 08:42:09: %FTD-6-302013: Built inbound TCP connection 9364 for INSIDE:192.168.240.50/45954 (192.168.240.50/45954) to OUTSIDE:192.168.241.50/80 (192.168.241.50/80)

Dec 01 2020 08:42:18: %FTD-6-302014: Teardown TCP connection 9364 for INSIDE:192.168.240.50/45954 to OUTSIDE:192.168.241.50/80 duration 0:00:08 bytes 1024000440 TCP FINs from INSIDE

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Dec 01 2020 08:42:09: %FTD-6-302022: Built backup stub TCP connection for INSIDE:192.168.240.50/45954 (192.168.240.50/45954) to OUTSIDE:192.168.241.50/80 (192.168.241.50/80)

Dec 01 2020 08:42:18: %FTD-6-302023: Teardown backup TCP connection for INSIDE:192.168.240.50/45954 to OUTSIDE:192.168.241.50/80 duration 0:00:08 forwarded bytes 0 Cluster flow with CLU closed on owner

Casos Práticos 2. Tráfego simétrico (proprietário diferente do direcionador)

- Igual ao estudo de caso nº 1, mas neste estudo de caso, o proprietário do fluxo é uma unidade diferente do direcionador.

- Todas as saídas são semelhantes ao estudo de caso nº 1. A principal diferença em relação ao estudo de caso nº 1 é o indicador "Y" que substitui o indicador "y" do cenário 1.

Observação 1. O proprietário é diferente do diretor

Análise do sinalizador de conexão para fluxo com a porta de origem 46278

firepower# cluster exec show conn

unit-1-1(LOCAL):******************************************************

23 in use, 25 most used

Cluster:

fwd connections: 0 in use, 1 most used

dir connections: 0 in use, 122 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 1 most in effect

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:46278, idle 0:00:00, bytes 508848268, flags UIO N1

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:46276, idle 0:00:03, bytes 0, flags aA N1

unit-2-1:*************************************************************

21 in use, 271 most used

Cluster:

fwd connections: 0 in use, 2 most used

dir connections: 0 in use, 2 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 249 most enabled, 0 most in effect

unit-3-1:*************************************************************

17 in use, 20 most used

Cluster:

fwd connections: 1 in use, 5 most used

dir connections: 1 in use, 127 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 1 most enabled, 0 most in effect

TCP OUTSIDE 192.168.241.50:80 NP Identity Ifc 192.168.240.50:46276, idle 0:00:02, bytes 0, flags z

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:46278, idle 0:00:06, bytes 0, flags Y

Unidade

Sinalizador

Nota

Unidade 1-1

UIO

· Flow Owner - A unidade lida com o fluxo

Unidade 2-1

-

-

Unidade 3-1

Y

· Diretor e Proprietário da Cópia de Segurança - A unidade 3-1 tem a bandeira Y (Diretor).

Isso pode ser visualizado da seguinte maneira:

1. O pacote TCP SYN chega do Host-A para a unidade 1-1. A unidade 1-1 torna-se o proprietário do fluxo

2. A unidade 3-1 é eleita diretor de fluxo. A Unidade 3-1 também é o proprietário do backup (mensagem 'cluster add' no UDP 4193 sobre o CCL)

3. O pacote TCP SYN/ACK chega do Host-B para a unidade 3-1. O fluxo é simétrico

4. Quando a conexão é encerrada, o proprietário envia pelo CCL uma mensagem de "exclusão de cluster" no UDP 4193 para remover as informações de fluxo do proprietário do backup

Observação 2. Captura com rastreamento mostra que ambas as direções passam apenas pela unidade 1-1

Etapa 1. Siga a mesma abordagem do estudo de caso 1 para identificar o fluxo e os pacotes de interesse em todas as unidades de cluster com base na porta de origem:

firepower# cluster exec show cap CAPI | include 46278

unit-1-1(LOCAL):******************************************************

3: 11:01:44.841631 802.1Q vlan#201 P0 192.168.240.50.46278 > 192.168.241.50.80: S 1972783998:1972783998(0) win 29200 <mss 1460,sackOK,timestamp 503529072 0,nop,wscale 7>

4: 11:01:44.842317 802.1Q vlan#201 P0 192.168.241.50.80 > 192.168.240.50.46278: S 3524167695:3524167695(0) ack 1972783999 win 28960 <mss 1380,sackOK,timestamp 513884542 503529072,nop,wscale 7>

5: 11:01:44.842592 802.1Q vlan#201 P0 192.168.240.50.46278 > 192.168.241.50.80: . ack 3524167696 win 229 <nop,nop,timestamp 503529073 513884542>

…

unit-2-1:*************************************************************

unit-3-1:*************************************************************

firepower#

Capturar na interface EXTERNA:

firepower# cluster exec show cap CAPO | include 46278

unit-1-1(LOCAL):******************************************************

3: 11:01:44.841921 802.1Q vlan#202 P0 192.168.240.50.46278 > 192.168.241.50.80: S 2153055699:2153055699(0) win 29200 <mss 1380,sackOK,timestamp 503529072 0,nop,wscale 7>

4: 11:01:44.842226 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.46278: S 3382481337:3382481337(0) ack 2153055700 win 28960 <mss 1460,sackOK,timestamp 513884542 503529072,nop,wscale 7>

5: 11:01:44.842638 802.1Q vlan#202 P0 192.168.240.50.46278 > 192.168.241.50.80: . ack 3382481338 win 229 <nop,nop,timestamp 503529073 513884542>

unit-2-1:*************************************************************

unit-3-1:*************************************************************

firepower#

Etapa 2. Foco nos pacotes de entrada (TCP SYN e TCP SYN/ACK):

firepower# cluster exec show cap CAPI packet-number 3 trace

unit-1-1(LOCAL):******************************************************

824 packets captured

3: 11:01:44.841631 802.1Q vlan#201 P0 192.168.240.50.46278 > 192.168.241.50.80: S 1972783998:1972783998(0) win 29200 <mss 1460,sackOK,timestamp 503529072 0,nop,wscale 7>

…

Phase: 4

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (0) got initial, attempting ownership.

Phase: 5

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (0) am becoming owner

Rastreie o SYN/ACK na unidade-1-1:

firepower# cluster exec show cap CAPO packet-number 4 trace

unit-1-1(LOCAL):******************************************************

4: 11:01:44.842226 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.46278: S 3382481337:3382481337(0) ack 2153055700 win 28960 <mss 1460,sackOK,timestamp 513884542 503529072,nop,wscale 7>

Phase: 3

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found flow with id 9583, using existing flow

Observação 3. Os syslogs do plano de dados FTD mostram a criação e a terminação da conexão no proprietário e no proprietário do backup:

firepower# cluster exec show log | include 46278

unit-1-1(LOCAL):******************************************************

Dec 01 2020 11:01:44: %FTD-6-302013: Built inbound TCP connection 9583 for INSIDE:192.168.240.50/46278 (192.168.240.50/46278) to OUTSIDE:192.168.241.50/80 (192.168.241.50/80)

Dec 01 2020 11:01:53: %FTD-6-302014: Teardown TCP connection 9583 for INSIDE:192.168.240.50/46278 to OUTSIDE:192.168.241.50/80 duration 0:00:08 bytes 1024001808 TCP FINs from INSIDE

unit-2-1:*************************************************************

unit-3-1:*************************************************************

Dec 01 2020 11:01:44: %FTD-6-302022: Built director stub TCP connection for INSIDE:192.168.240.50/46278 (192.168.240.50/46278) to OUTSIDE:192.168.241.50/80 (192.168.241.50/80)

Dec 01 2020 11:01:53: %FTD-6-302023: Teardown director TCP connection for INSIDE:192.168.240.50/46278 to OUTSIDE:192.168.241.50/80 duration 0:00:08 forwarded bytes 0 Cluster flow with CLU closed on owner

Casos Práticos 3. Tráfego assimétrico (diretor encaminha o tráfego)

Observação 1. As capturas de re-ocultação mostram pacotes na unidade-1-1 e na unidade-2-1 (fluxo assimétrico):

firepower# cluster exec show cap

unit-1-1(LOCAL):******************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Buffer Full - 33554320 bytes]

capture CAPI type raw-data buffer 100000 trace interface INSIDE [Buffer Full - 98552 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO type raw-data buffer 100000 trace interface OUTSIDE [Buffer Full - 98552 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPI_RH type raw-data reinject-hide buffer 100000 interface INSIDE [Buffer Full - 98552 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO_RH type raw-data reinject-hide buffer 100000 interface OUTSIDE [Buffer Full - 99932 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

unit-2-1:*************************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Buffer Full - 33553268 bytes]

capture CAPI type raw-data buffer 100000 trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO type raw-data buffer 100000 trace interface OUTSIDE [Buffer Full - 99052 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPI_RH type raw-data reinject-hide buffer 100000 interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO_RH type raw-data reinject-hide buffer 100000 interface OUTSIDE [Buffer Full - 99052 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

unit-3-1:*************************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Capturing - 53815 bytes]

capture CAPI type raw-data buffer 100000 trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO type raw-data buffer 100000 trace interface OUTSIDE [Capturing - 658 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPI_RH type raw-data reinject-hide buffer 100000 interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO_RH type raw-data reinject-hide buffer 100000 interface OUTSIDE [Capturing - 658 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

Observação 2. Análise do sinalizador de conexão para fluxo com a porta de origem 46502

firepower# cluster exec show conn

unit-1-1(LOCAL):******************************************************

23 in use, 25 most used

Cluster:

fwd connections: 0 in use, 1 most used

dir connections: 0 in use, 122 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 2 enabled, 0 in effect, 4 most enabled, 1 most in effect

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:46502, idle 0:00:00, bytes 448760236, flags UIO N1

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:46500, idle 0:00:06, bytes 0, flags aA N1

unit-2-1:*************************************************************

21 in use, 271 most used

Cluster:

fwd connections: 0 in use, 2 most used

dir connections: 1 in use, 2 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 249 most enabled, 0 most in effect

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:46502, idle 0:00:00, bytes 0, flags Y

unit-3-1:*************************************************************

17 in use, 20 most used

Cluster:

fwd connections: 1 in use, 5 most used

dir connections: 0 in use, 127 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 1 most enabled, 0 most in effect

Unidade

Sinalizador

Nota

Unidade 1-1

UIO

· Flow Owner - A unidade lida com o fluxo

Unidade 2-1

Y

· Diretor - Uma vez que a unidade 2-1 tem a bandeira "Y", tal implica que a unidade 2-1 foi escolhida como diretor para este fluxo.

Proprietário do backup ·

· Finalmente, embora não seja óbvio nesta saída, mas nas saídas show capture e show log, é evidente que a unidade 2-1 encaminha esse fluxo para o proprietário (embora tecnicamente não seja considerado um encaminhador neste cenário)

Note: Uma unidade não pode ser direcionador (fluxo Y) e encaminhador (fluxo z), essas duas funções são mutuamente exclusivas. Observe que os diretors (fluxo Y) ainda podem encaminhar o tráfego. Veja a saída show log mais adiante neste estudo de caso.

Unidade 3-1

-

-

Isso pode ser visualizado da seguinte maneira:

1. O pacote TCP SYN chega do Host-A para a unidade 1-1. A unidade 1-1 torna-se o proprietário do fluxo

2. A unidade 2-1 é eleita como diretor de fluxo e proprietário do backup. O proprietário do fluxo envia uma mensagem unicast 'cluster add' no UDP 4193 para informar o proprietário do backup sobre o fluxo

3. O pacote TCP SYN/ACK chega do Host-B para a unidade 2-1. O fluxo é assimétrico

4. A Unidade 2-1 encaminha o pacote através do CCL ao proprietário (devido ao TCP SYN Cookie)

5. O proprietário reinjeta o pacote na interface FORA e, em seguida, encaminha o pacote para o Host-A

6. Quando a conexão é encerrada, o proprietário envia uma mensagem de exclusão de cluster para remover as informações de fluxo do proprietário do backup

Observação 3. Captura com rastreamento mostra o tráfego assimétrico e o redirecionamento da unidade 2-1 para a unidade 1-1

Etapa 1. Identifique os pacotes que pertencem ao fluxo de interesse (porta 46502):

firepower# cluster exec show capture CAPI | include 46502

unit-1-1(LOCAL):******************************************************

3: 12:58:33.356121 802.1Q vlan#201 P0 192.168.240.50.46502 > 192.168.241.50.80: S 4124514680:4124514680(0) win 29200 <mss 1460,sackOK,timestamp 510537534 0,nop,wscale 7>

4: 12:58:33.357037 802.1Q vlan#201 P0 192.168.241.50.80 > 192.168.240.50.46502: S 883000451:883000451(0) ack 4124514681 win 28960 <mss 1380,sackOK,timestamp 520893004 510537534,nop,wscale 7>

5: 12:58:33.357357 802.1Q vlan#201 P0 192.168.240.50.46502 > 192.168.241.50.80: . ack 883000452 win 229 <nop,nop,timestamp 510537536 520893004>

unit-2-1:*************************************************************

unit-3-1:*************************************************************

A direção de retorno:

firepower# cluster exec show capture CAPO | include 46502

unit-1-1(LOCAL):******************************************************

3: 12:58:33.356426 802.1Q vlan#202 P0 192.168.240.50.46502 > 192.168.241.50.80: S 1434968587:1434968587(0) win 29200 <mss 1380,sackOK,timestamp 510537534 0,nop,wscale 7>

4: 12:58:33.356915 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.46502: S 4257314722:4257314722(0) ack 1434968588 win 28960 <mss 1460,sackOK,timestamp 520893004 510537534,nop,wscale 7>

5: 12:58:33.357403 802.1Q vlan#202 P0 192.168.240.50.46502 > 192.168.241.50.80: . ack 4257314723 win 229 <nop,nop,timestamp 510537536 520893004>

unit-2-1:*************************************************************

1: 12:58:33.359249 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.46502: S 4257314722:4257314722(0) ack 1434968588 win 28960 <mss 1460,sackOK,timestamp 520893004 510537534,nop,wscale 7>

2: 12:58:33.360302 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.46502: . ack 1434968736 win 235 <nop,nop,timestamp 520893005 510537536>

3: 12:58:33.361004 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.46502: . 4257314723:4257316091(1368) ack 1434968736 win 235 <nop,nop,timestamp 520893006 510537536>

…

unit-3-1:*************************************************************

Etapa 2. Rastreie os pacotes. Observe que, por padrão, somente os 50 primeiros pacotes de entrada são rastreados. Para simplificar, as fases de rastreamento não relevantes são omitidas.

Unidade 1-1 (proprietário):

firepower# cluster exec show capture CAPI packet-number 3 trace

unit-1-1(LOCAL):******************************************************

3: 12:58:33.356121 802.1Q vlan#201 P0 192.168.240.50.46502 > 192.168.241.50.80: S 4124514680:4124514680(0) win 29200 <mss 1460,sackOK,timestamp 510537534 0,nop,wscale 7>

...

Phase: 4

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (0) got initial, attempting ownership.

Phase: 5

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (0) am becoming owner

Unidade 2-1 (encaminhador)

O tráfego de retorno (TCP SYN/ACK). A unidade de interesse é a unidade 2-1, que é o proprietário do direcionador/backup e encaminha o tráfego para o proprietário:

firepower# cluster exec unit unit-2-1 show capture CAPO packet-number 1 trace

1: 12:58:33.359249 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.46502: S 4257314722:4257314722(0) ack 1434968588 win 28960 <mss 1460,sackOK,timestamp 520893004 510537534,nop,wscale 7>

...

Phase: 4

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: NO FLOW

I (1) got initial, attempting ownership.

Phase: 5

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: NO FLOW

I (1) am early redirecting to (0) due to matching action (-1).

Observação 4. Os syslogs do plano de dados FTD mostram a criação e a terminação da conexão em todas as unidades:

firepower# cluster exec show log | i 46502

unit-1-1(LOCAL):******************************************************

Dec 01 2020 12:58:33: %FTD-6-302013: Built inbound TCP connection 9742 for INSIDE:192.168.240.50/46502 (192.168.240.50/46502) to OUTSIDE:192.168.241.50/80 (192.168.241.50/80)

Dec 01 2020 12:59:02: %FTD-6-302014: Teardown TCP connection 9742 for INSIDE:192.168.240.50/46502 to OUTSIDE:192.168.241.50/80 duration 0:00:28 bytes 2048000440 TCP FINs from INSIDE

unit-2-1:*************************************************************

Dec 01 2020 12:58:33: %FTD-6-302022: Built forwarder stub TCP connection for OUTSIDE:192.168.241.50/80 (192.168.241.50/80) to unknown:192.168.240.50/46502 (192.168.240.50/46502)

Dec 01 2020 12:58:33: %FTD-6-302023: Teardown forwarder TCP connection for OUTSIDE:192.168.241.50/80 to unknown:192.168.240.50/46502 duration 0:00:00 forwarded bytes 0 Forwarding or redirect flow removed to create director or backup flow

Dec 01 2020 12:58:33: %FTD-6-302022: Built director stub TCP connection for INSIDE:192.168.240.50/46502 (192.168.240.50/46502) to OUTSIDE:192.168.241.50/80 (192.168.241.50/80)

Dec 01 2020 12:59:02: %FTD-6-302023: Teardown director TCP connection for INSIDE:192.168.240.50/46502 to OUTSIDE:192.168.241.50/80 duration 0:00:28 forwarded bytes 2048316300 Cluster flow with CLU closed on owner

unit-3-1:*************************************************************

firepower#

Casos Práticos 4. Tráfego assimétrico (proprietário é o diretor)

Observação 1. As capturas de re-ocultação mostram pacotes na unidade-1-1 e na unidade-2-1 (fluxo assimétrico):

firepower# cluster exec show cap

unit-1-1(LOCAL):******************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Buffer Full - 33554229 bytes]

capture CAPI type raw-data buffer 100000 trace interface INSIDE [Buffer Full - 98974 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO type raw-data buffer 100000 trace interface OUTSIDE [Buffer Full - 98974 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPI_RH type raw-data reinject-hide buffer 100000 interface INSIDE [Buffer Full - 98974 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO_RH type raw-data reinject-hide buffer 100000 interface OUTSIDE [Buffer Full - 99924 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

unit-2-1:*************************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Buffer Full - 33552925 bytes]

capture CAPI type raw-data buffer 100000 trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO type raw-data buffer 100000 trace interface OUTSIDE [Buffer Full - 99052 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPI_RH type raw-data reinject-hide buffer 100000 interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO_RH type raw-data reinject-hide buffer 100000 interface OUTSIDE [Buffer Full - 99052 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

unit-3-1:*************************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Capturing - 227690 bytes]

capture CAPI type raw-data buffer 100000 trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO type raw-data buffer 100000 trace interface OUTSIDE [Capturing - 4754 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPI_RH type raw-data reinject-hide buffer 100000 interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO_RH type raw-data reinject-hide buffer 100000 interface OUTSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

Observação 2. Análise do sinalizador de conexão para fluxo com a porta de origem 46916

firepower# cluster exec show conn

unit-1-1(LOCAL):******************************************************

23 in use, 25 most used

Cluster:

fwd connections: 0 in use, 1 most used

dir connections: 0 in use, 122 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 1 enabled, 0 in effect, 4 most enabled, 1 most in effect

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:46916, idle 0:00:00, bytes 414682616, flags UIO N1

unit-2-1:*************************************************************

21 in use, 271 most used

Cluster:

fwd connections: 1 in use, 2 most used

dir connections: 0 in use, 2 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 249 most enabled, 0 most in effect

TCP OUTSIDE 192.168.241.50:80 NP Identity Ifc 192.168.240.50:46916, idle 0:00:00, bytes 0, flags z

unit-3-1:*************************************************************

17 in use, 20 most used

Cluster:

fwd connections: 0 in use, 5 most used

dir connections: 1 in use, 127 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 1 most enabled, 0 most in effect

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:46916, idle 0:00:04, bytes 0, flags y

Unidade

Sinalizador

Nota

Unidade 1-1

UIO

· Flow Owner - A unidade lida com o fluxo

· Diretor - Uma vez que a unidade 3-1 tem "y" e não "Y", tal implica que a unidade 1-1 foi escolhida como diretor para este fluxo. Assim, como também é proprietária, outra unidade (unidade 3-1, neste caso) foi eleita como proprietária da cópia de segurança

Unidade 2-1

z

· Forwarder

Unidade 3-1

y

- Proprietário do backup

Isso pode ser visualizado da seguinte maneira:

1. O pacote TCP SYN chega do Host-A para a unidade 1-1. A Unidade 1-1 torna-se o proprietário do fluxo e é eleita como diretor

2. A Unidade 3-1 é selecionada como um proprietário de backup. O proprietário do fluxo envia uma mensagem unicast de adição de cluster no UDP 4193 para informar o proprietário do backup sobre o fluxo

3. O pacote TCP SYN/ACK chega do Host-B para a unidade 2-1. O fluxo é assimétrico

4. A Unidade 2-1 encaminha o pacote através do CCL ao proprietário (devido ao TCP SYN Cookie)

5. O proprietário reinjeta o pacote na interface FORA e, em seguida, encaminha o pacote para o Host-A

6. Quando a conexão é encerrada, o proprietário envia uma mensagem de exclusão de cluster para remover as informações de fluxo do proprietário do backup

Observação 3. Captura com rastreamento mostra o tráfego assimétrico e o redirecionamento da unidade 2-1 para a unidade 1-1

Unidade 2-1 (encaminhador)

firepower# cluster exec unit unit-2-1 show capture CAPO packet-number 1 trace

1: 16:11:33.653164 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.46916: S 1331019196:1331019196(0) ack 3089755618 win 28960 <mss 1460,sackOK,timestamp 532473211 522117741,nop,wscale 7>

...

Phase: 4

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: NO FLOW

I (1) got initial, attempting ownership.

Phase: 5

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: NO FLOW

I (1) am early redirecting to (0) due to matching action (-1).

Observação 4. Os syslogs do plano de dados FTD mostram a criação e a terminação da conexão em todas as unidades:

- Unidade 1-1 (proprietário)

- Unidade 2-1 (encaminhador)

- Unidade 3-1 (proprietário do backup)

firepower# cluster exec show log | i 46916

unit-1-1(LOCAL):******************************************************

Dec 01 2020 16:11:33: %FTD-6-302013: Built inbound TCP connection 10023 for INSIDE:192.168.240.50/46916 (192.168.240.50/46916) to OUTSIDE:192.168.241.50/80 (192.168.241.50/80)

Dec 01 2020 16:11:42: %FTD-6-302014: Teardown TCP connection 10023 for INSIDE:192.168.240.50/46916 to OUTSIDE:192.168.241.50/80 duration 0:00:09 bytes 1024010016 TCP FINs from INSIDE

unit-2-1:*************************************************************

Dec 01 2020 16:11:33: %FTD-6-302022: Built forwarder stub TCP connection for OUTSIDE:192.168.241.50/80 (192.168.241.50/80) to unknown:192.168.240.50/46916 (192.168.240.50/46916)

Dec 01 2020 16:11:42: %FTD-6-302023: Teardown forwarder TCP connection for OUTSIDE:192.168.241.50/80 to unknown:192.168.240.50/46916 duration 0:00:09 forwarded bytes 1024009868 Cluster flow with CLU closed on owner

unit-3-1:*************************************************************

Dec 01 2020 16:11:33: %FTD-6-302022: Built backup stub TCP connection for INSIDE:192.168.240.50/46916 (192.168.240.50/46916) to OUTSIDE:192.168.241.50/80 (192.168.241.50/80)

Dec 01 2020 16:11:42: %FTD-6-302023: Teardown backup TCP connection for INSIDE:192.168.240.50/46916 to OUTSIDE:192.168.241.50/80 duration 0:00:09 forwarded bytes 0 Cluster flow with CLU closed on owner

Casos Práticos 5. Tráfego assimétrico (o proprietário é diferente do direcionador)

Observação 1. As capturas de re-ocultação mostram pacotes na unidade-1-1 e na unidade-2-1 (fluxo assimétrico):

firepower# cluster exec show cap

unit-1-1(LOCAL):******************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Buffer Full - 33553207 bytes]

capture CAPI type raw-data buffer 100000 trace interface INSIDE [Buffer Full - 99396 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO type raw-data buffer 100000 trace interface OUTSIDE [Buffer Full - 99224 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPI_RH type raw-data reinject-hide buffer 100000 interface INSIDE [Buffer Full - 99396 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO_RH type raw-data reinject-hide buffer 100000 interface OUTSIDE [Buffer Full - 99928 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

unit-2-1:*************************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Buffer Full - 33554251 bytes]

capture CAPI type raw-data buffer 100000 trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO type raw-data buffer 100000 trace interface OUTSIDE [Buffer Full - 99052 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPI_RH type raw-data reinject-hide buffer 100000 interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO_RH type raw-data reinject-hide buffer 100000 interface OUTSIDE [Buffer Full - 99052 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

unit-3-1:*************************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Capturing - 131925 bytes]

capture CAPI type raw-data buffer 100000 trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO type raw-data buffer 100000 trace interface OUTSIDE [Capturing - 2592 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPI_RH type raw-data reinject-hide buffer 100000 interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

capture CAPO_RH type raw-data reinject-hide buffer 100000 interface OUTSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.241.50 eq www

Observação 2. Análise do sinalizador de conexão para fluxo com a porta de origem 46994

firepower# cluster exec show conn

unit-1-1(LOCAL):******************************************************

23 in use, 25 most used

Cluster:

fwd connections: 0 in use, 1 most used

dir connections: 0 in use, 122 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 1 enabled, 0 in effect, 4 most enabled, 1 most in effect

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:46994, idle 0:00:00, bytes 406028640, flags UIO N1

unit-2-1:*************************************************************

22 in use, 271 most used

Cluster:

fwd connections: 1 in use, 2 most used

dir connections: 0 in use, 2 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 249 most enabled, 0 most in effect

TCP OUTSIDE 192.168.241.50:80 NP Identity Ifc 192.168.240.50:46994, idle 0:00:00, bytes 0, flags z

unit-3-1:*************************************************************

17 in use, 20 most used

Cluster:

fwd connections: 2 in use, 5 most used

dir connections: 1 in use, 127 most used

centralized connections: 0 in use, 0 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 1 most enabled, 0 most in effect

TCP OUTSIDE 192.168.241.50:80 INSIDE 192.168.240.50:46994, idle 0:00:05, bytes 0, flags Y

Unidade

Sinalizador

Nota

Unidade 1-1

UIO

· Flow Owner - A unidade lida com o fluxo

Unidade 2-1

z

· Forwarder

Unidade 3-1

Y

Proprietário do backup ·

·Director

Isso pode ser visualizado da seguinte maneira:

1. O pacote TCP SYN chega do Host-A para a unidade 1-1. A unidade 1-1 torna-se o proprietário do fluxo

2. A Unidade 3-1 é eleita como diretora e proprietária de backup. O proprietário do fluxo envia uma mensagem unicast 'cluster add' no UDP 4193 para informar o proprietário do backup sobre o fluxo

3. O pacote TCP SYN/ACK chega do Host-B para a unidade 2-1. O fluxo é assimétrico

4. A Unidade 2-1 encaminha o pacote através do CCL ao proprietário (devido ao TCP SYN Cookie)

5. O proprietário reinjeta o pacote na interface FORA e, em seguida, encaminha o pacote para o Host-A

6. Quando a conexão é encerrada, o proprietário envia uma mensagem de exclusão de cluster para remover as informações de fluxo do proprietário do backup

Observação 3. Captura com rastreamento mostra o tráfego assimétrico e o redirecionamento da unidade 2-1 para a unidade 1-1

Unidade 1-1 (proprietário)

firepower# cluster exec show cap CAPI packet-number 1 trace

unit-1-1(LOCAL):******************************************************

…

Phase: 4

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (0) got initial, attempting ownership.

Phase: 5

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (0) am becoming owner

Unidade 2-1 (encaminhador)

firepower# cluster exec unit unit-2-1 show cap CAPO packet-number 1 trace

1: 16:46:44.232074 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.46994: S 2863659376:2863659376(0) ack 2879616990 win 28960 <mss 1460,sackOK,timestamp 534583774 524228304,nop,wscale 7>

…

Phase: 4

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: NO FLOW

I (1) got initial, attempting ownership.

Phase: 5

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: NO FLOW

I (1) am early redirecting to (0) due to matching action (-1).

Observação 4. Os syslogs do plano de dados FTD mostram a criação e a terminação da conexão em todas as unidades:

- Unidade 1-1 (proprietário)

- Unidade 2-1 (encaminhador)

- Unidade 3-1 (proprietário/diretor de backup)

firepower# cluster exec show log | i 46994

unit-1-1(LOCAL):******************************************************

Dec 01 2020 16:46:44: %FTD-6-302013: Built inbound TCP connection 10080 for INSIDE:192.168.240.50/46994 (192.168.240.50/46994) to OUTSIDE:192.168.241.50/80 (192.168.241.50/80)

Dec 01 2020 16:46:53: %FTD-6-302014: Teardown TCP connection 10080 for INSIDE:192.168.240.50/46994 to OUTSIDE:192.168.241.50/80 duration 0:00:09 bytes 1024000440 TCP FINs from INSIDE

unit-2-1:*************************************************************

Dec 01 2020 16:46:44: %FTD-6-302022: Built forwarder stub TCP connection for OUTSIDE:192.168.241.50/80 (192.168.241.50/80) to unknown:192.168.240.50/46994 (192.168.240.50/46994)

Dec 01 2020 16:46:53: %FTD-6-302023: Teardown forwarder TCP connection for OUTSIDE:192.168.241.50/80 to unknown:192.168.240.50/46994 duration 0:00:09 forwarded bytes 1024000292 Cluster flow with CLU closed on owner

unit-3-1:*************************************************************

Dec 01 2020 16:46:44: %FTD-6-302022: Built director stub TCP connection for INSIDE:192.168.240.50/46994 (192.168.240.50/46994) to OUTSIDE:192.168.241.50/80 (192.168.241.50/80)

Dec 01 2020 16:46:53: %FTD-6-302023: Teardown director TCP connection for INSIDE:192.168.240.50/46994 to OUTSIDE:192.168.241.50/80 duration 0:00:09 forwarded bytes 0 Cluster flow with CLU closed on owner

Para os próximos estudos de caso, a topologia usada é baseada em um cluster com conjuntos em linha:

Casos Práticos 6. Tráfego assimétrico (em linha, o proprietário é o diretor)

Observação 1. As capturas de re-ocultação mostram pacotes na unidade 1-1 e na unidade 2-1 (fluxo assimétrico). Além disso, o proprietário é a unidade 2-1 (há pacotes nas interfaces internas e externas para as capturas de ocultação de reinjeção, enquanto a unidade 1-1 tem apenas externo):

firepower# cluster exec show cap

unit-1-1(LOCAL):******************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Buffer Full - 33553253 bytes]

capture CAPO type raw-data trace interface OUTSIDE [Buffer Full - 523432 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPO_RH type raw-data reinject-hide interface OUTSIDE [Buffer Full - 523432 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI_RH type raw-data reinject-hide interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

unit-2-1:*************************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Buffer Full - 33554312 bytes]

capture CAPO type raw-data trace interface OUTSIDE [Buffer Full - 523782 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI type raw-data trace interface INSIDE [Buffer Full - 523782 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPO_RH type raw-data reinject-hide interface OUTSIDE [Buffer Full - 524218 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI_RH type raw-data reinject-hide interface INSIDE [Buffer Full - 523782 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

unit-3-1:*************************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Capturing - 53118 bytes]

capture CAPO type raw-data trace interface OUTSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPO_RH type raw-data reinject-hide interface OUTSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI_RH type raw-data reinject-hide interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

Observação 2. Análise do sinalizador de conexão para fluxo com a porta de origem 51844

firepower# cluster exec show conn addr 192.168.240.51

unit-1-1(LOCAL):******************************************************

30 in use, 102 most used

Cluster:

fwd connections: 1 in use, 1 most used

dir connections: 2 in use, 122 most used

centralized connections: 3 in use, 39 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 4 most enabled, 1 most in effect

TCP OUTSIDE 192.168.240.51:80 NP Identity Ifc 192.168.240.50:51844, idle 0:00:00, bytes 0, flags z

unit-2-1:*************************************************************

23 in use, 271 most used

Cluster:

fwd connections: 0 in use, 2 most used

dir connections: 4 in use, 26 most used

centralized connections: 0 in use, 14 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 249 most enabled, 0 most in effect

TCP OUTSIDE 192.168.240.51:80 INSIDE 192.168.240.50:51844, idle 0:00:00, bytes 231214400, flags b N

unit-3-1:*************************************************************

20 in use, 55 most used

Cluster:

fwd connections: 0 in use, 5 most used

dir connections: 1 in use, 127 most used

centralized connections: 0 in use, 24 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 1 most enabled, 0 most in effect

TCP OUTSIDE 192.168.240.51:80 INSIDE 192.168.240.50:51844, idle 0:00:01, bytes 0, flags y

Unidade

Sinalizador

Nota

Unidade 1-1

z

· Forwarder

Unidade 2-1

b N

· Flow Owner - A unidade lida com o fluxo

Unidade 3-1

y

Proprietário do backup ·

Isso pode ser visualizado da seguinte maneira:

1. O pacote TCP SYN chega do Host-A para a unidade 2-1. A Unidade 2-1 torna-se o proprietário do fluxo e é eleita como o direcionador

2. A Unidade 3-1 é selecionada como o proprietário do backup. O proprietário do fluxo envia uma mensagem unicast 'cluster add' no UDP 4193 para informar o proprietário do backup sobre o fluxo

3. O pacote TCP SYN/ACK chega do Host-B para a unidade 1-1. O fluxo é assimétrico

4. A Unidade 1-1 encaminha o pacote através do CCL ao direcionador (unidade 2-1)

5. A Unidade 2-1 também é a proprietária e reinjeta o pacote na interface FORA

6. A Unidade 2-1 encaminha o pacote para o Host-A

7. Quando a conexão é encerrada, o proprietário envia uma mensagem de exclusão de cluster para remover as informações de fluxo do proprietário do backup

Observação 3. Captura com rastreamento mostra o tráfego assimétrico e o redirecionamento de unit-1-1 para unit-2-1

Unidade 2-1 (proprietário/diretor)

firepower# cluster exec unit unit-2-1 show cap CAPI packet-number 1 trace

1: 18:10:12.842912 192.168.240.50.51844 > 192.168.240.51.80: S 4082593463:4082593463(0) win 29200 <mss 1460,sackOK,timestamp 76258053 0,nop,wscale 7>

Phase: 1

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (1) got initial, attempting ownership.

Phase: 2

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (1) am becoming owner

Unidade 1-1 (encaminhador)

firepower# cluster exec show cap CAPO packet-number 1 trace

unit-1-1(LOCAL):******************************************************

1: 18:10:12.842317 192.168.240.51.80 > 192.168.240.50.51844: S 2339579109:2339579109(0) ack 4082593464 win 28960 <mss 1460,sackOK,timestamp 513139467 76258053,nop,wscale 7>

Phase: 1

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: NO FLOW

I (0) am asking director (1).

Tráfego de retorno (TCP SYN/ACK)

Unidade 2-1 (proprietário/diretor)

firepower# cluster exec unit unit-2-1 show cap CAPO packet-number 2 trace

2: 18:10:12.843660 192.168.240.51.80 > 192.168.240.50.51844: S 2339579109:2339579109(0) ack 4082593464 win 28960 <mss 1460,sackOK,timestamp 513139467 76258053,nop,wscale 7>

Phase: 1

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: FULL

I (1) am owner, update sender (0).

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found flow with id 7109, using existing flow

Observação 4. Os syslogs do plano de dados FTD mostram a criação e a terminação da conexão em todas as unidades:

- Unidade 1-1 (proprietário)

- Unidade 2-1 (encaminhador)

- Unidade 3-1 (proprietário/diretor de backup)

firepower# cluster exec show log | include 51844

unit-1-1(LOCAL):******************************************************

Dec 02 2020 18:10:12: %FTD-6-302022: Built forwarder stub TCP connection for OUTSIDE:192.168.240.51/80 (192.168.240.51/80) to unknown:192.168.240.50/51844 (192.168.240.50/51844)

Dec 02 2020 18:10:22: %FTD-6-302023: Teardown forwarder TCP connection for OUTSIDE:192.168.240.51/80 to unknown:192.168.240.50/51844 duration 0:00:09 forwarded bytes 1024001740 Cluster flow with CLU closed on owner

unit-2-1:*************************************************************

Dec 02 2020 18:10:12: %FTD-6-302303: Built TCP state-bypass connection 7109 from INSIDE:192.168.240.50/51844 (192.168.240.50/51844) to OUTSIDE:192.168.240.51/80 (192.168.240.51/80)

Dec 02 2020 18:10:22: %FTD-6-302304: Teardown TCP state-bypass connection 7109 from INSIDE:192.168.240.50/51844 to OUTSIDE:192.168.240.51/80 duration 0:00:09 bytes 1024001888 TCP FINs

unit-3-1:*************************************************************

Dec 02 2020 18:10:12: %FTD-6-302022: Built backup stub TCP connection for INSIDE:192.168.240.50/51844 (192.168.240.50/51844) to OUTSIDE:192.168.240.51/80 (192.168.240.51/80)

Dec 02 2020 18:10:22: %FTD-6-302023: Teardown backup TCP connection for INSIDE:192.168.240.50/51844 to OUTSIDE:192.168.240.51/80 duration 0:00:09 forwarded bytes 0 Cluster flow with CLU closed on owner

Casos Práticos 7. Tráfego assimétrico (em linha, o proprietário é diferente do direcionador)

O proprietário é a unidade 2-1 (há pacotes em ambas as interfaces, INSIDE e OUTSIDE para as capturas de ocultação de reinjeção, enquanto a unidade 3-1 tem apenas OUTSIDE):

firepower# cluster exec show cap

unit-1-1(LOCAL):******************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Capturing - 13902 bytes]

capture CAPO type raw-data trace interface OUTSIDE [Capturing - 90 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPO_RH type raw-data reinject-hide interface OUTSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI_RH type raw-data reinject-hide interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

unit-2-1:*************************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Buffer Full - 33553936 bytes]

capture CAPO type raw-data trace interface OUTSIDE [Buffer Full - 523126 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI type raw-data trace interface INSIDE [Buffer Full - 523126 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPO_RH type raw-data reinject-hide interface OUTSIDE [Buffer Full - 524230 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI_RH type raw-data reinject-hide interface INSIDE [Buffer Full - 523126 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

unit-3-1:*************************************************************

capture CCL type raw-data buffer 33554432 interface cluster [Buffer Full - 33553566 bytes]

capture CAPO type raw-data trace interface OUTSIDE [Buffer Full - 523522 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI type raw-data trace interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPO_RH type raw-data reinject-hide interface OUTSIDE [Buffer Full - 523432 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

capture CAPI_RH type raw-data reinject-hide interface INSIDE [Capturing - 0 bytes]

match tcp host 192.168.240.50 host 192.168.240.51 eq www

Observação 2. Análise do sinalizador de conexão para fluxo com a porta de origem 59210

firepower# cluster exec show conn addr 192.168.240.51

unit-1-1(LOCAL):******************************************************

25 in use, 102 most used

Cluster:

fwd connections: 0 in use, 1 most used

dir connections: 2 in use, 122 most used

centralized connections: 0 in use, 39 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 4 most enabled, 1 most in effect

TCP OUTSIDE 192.168.240.51:80 INSIDE 192.168.240.50:59210, idle 0:00:03, bytes 0, flags Y

unit-2-1:*************************************************************

21 in use, 271 most used

Cluster:

fwd connections: 0 in use, 2 most used

dir connections: 0 in use, 28 most used

centralized connections: 0 in use, 14 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 249 most enabled, 0 most in effect

TCP OUTSIDE 192.168.240.51:80 INSIDE 192.168.240.50:59210, idle 0:00:00, bytes 610132872, flags b N

unit-3-1:*************************************************************

19 in use, 55 most used

Cluster:

fwd connections: 1 in use, 5 most used

dir connections: 0 in use, 127 most used

centralized connections: 0 in use, 24 most used

VPN redirect connections: 0 in use, 0 most used

Inspect Snort:

preserve-connection: 0 enabled, 0 in effect, 1 most enabled, 0 most in effect

TCP OUTSIDE 192.168.240.51:80 NP Identity Ifc 192.168.240.50:59210, idle 0:00:00, bytes 0, flags z

Unidade

Sinalizador

Nota

Unidade 1-1

Y

· Diretor/Proprietário do backup

Unidade 2-1

b N

· Flow Owner - A unidade lida com o fluxo

Unidade 3-1

z

· Forwarder

Isso pode ser visualizado da seguinte maneira:

1. O pacote TCP SYN chega do Host-A para a unidade 2-1. A unidade 2-1 torna-se o proprietário do fluxo e a unidade 1-1 é eleita como o diretor

2. A Unidade 1-1 é eleita o proprietário do backup (já que é o direcionador). O proprietário do fluxo envia uma mensagem unicast 'cluster add' no UDP 4193 para informar o proprietário do backup sobre o fluxo

3. O pacote TCP SYN/ACK chega do Host-B para a unidade 3-1. O fluxo é assimétrico

4. A unidade 3-1 encaminha o pacote através do CCL ao direcionador (unidade 1-1)

5. A Unidade 1-1 (diretor) sabe que o proprietário é a unidade 2-1, envia o pacote de volta ao encaminhador (unidade 3-1) e notifica-o de que o proprietário é a unidade 2-1

6. A unidade 3-1 envia o pacote para a unidade 2-1 (proprietário)

7. A Unidade 2-1 reinjeta o pacote na interface FORA

8. A Unidade 2-1 encaminha o pacote para o Host-A

9. Quando a conexão é encerrada, o proprietário envia uma mensagem de exclusão de cluster para remover as informações de fluxo do proprietário do backup

Note: É importante que a etapa 2 (pacote através do CCL) ocorra antes da etapa 4 (tráfego de dados). Em um caso diferente (por exemplo, condição de corrida), o diretor não está ciente do fluxo. Assim, como é um conjunto em linha, encaminha o pacote para o destino. Se as interfaces não estiverem em um conjunto em linha, o pacote de dados será descartado.

Observação 3. Captura com rastreamento mostra o tráfego assimétrico e as trocas pelo CCL:

Tráfego de encaminhamento (TCP SYN)

Unidade 2-1 (proprietário)

firepower# cluster exec unit unit-2-1 show cap CAPI packet-number 1 trace

1: 09:19:49.760702 192.168.240.50.59210 > 192.168.240.51.80: S 4110299695:4110299695(0) win 29200 <mss 1460,sackOK,timestamp 130834570 0,nop,wscale 7>

Phase: 1

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (1) got initial, attempting ownership.

Phase: 2

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'INSIDE'

Flow type: NO FLOW

I (1) am becoming owner

Tráfego de retorno (TCP SYN/ACK)

A unidade 3-1 (ID 2 - encaminhador) envia o pacote através do CCL para a unidade 1-1 (ID 0 - direcionador)

firepower# cluster exec unit unit-3-1 show cap CAPO packet-number 1 trace

1: 09:19:49.760336 192.168.240.51.80 > 192.168.240.50.59210: S 4209225081:4209225081(0) ack 4110299696 win 28960 <mss 1460,sackOK,timestamp 567715984 130834570,nop,wscale 7>

Phase: 1

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: NO FLOW

I (2) am asking director (0).

Unidade 1-1 (diretor) - Unidade 1-1 (ID 0) sabe que o proprietário do fluxo é a unidade 2-1 (ID 1) e envia o pacote pelo CCL de volta para a unidade 3-1 (ID 2 - encaminhador)

firepower# cluster exec show cap CAPO packet-number 1 trace

unit-1-1(LOCAL):******************************************************

1: 09:19:49.761038 192.168.240.51.80 > 192.168.240.50.59210: S 4209225081:4209225081(0) ack 4110299696 win 28960 <mss 1460,sackOK,timestamp 567715984 130834570,nop,wscale 7>

Phase: 1

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: STUB

I (0) am director, valid owner (1), update sender (2).

A unidade 3-1 (ID 2 - encaminhador) recebe o pacote pelo CCL e o envia para a unidade 2-1 (ID 1 - proprietário)

firepower# cluster exec unit unit-3-1 show cap CAPO packet-number 2 trace

...

2: 09:19:49.761008 192.168.240.51.80 > 192.168.240.50.59210: S 4209225081:4209225081(0) ack 4110299696 win 28960 <mss 1460,sackOK,timestamp 567715984 130834570,nop,wscale 7>

Phase: 1

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: STUB

I (2) am becoming forwarder to (1), sender (0).

O proprietário injeta e encaminha o pacote para o destino:

firepower# cluster exec unit unit-2-1 show cap CAPO packet-number 2 trace

2: 09:19:49.775701 192.168.240.51.80 > 192.168.240.50.59210: S 4209225081:4209225081(0) ack 4110299696 win 28960 <mss 1460,sackOK,timestamp 567715984 130834570,nop,wscale 7>

Phase: 1

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'OUTSIDE'

Flow type: FULL

I (1) am owner, sender (2).

Observação 4. Os syslogs do plano de dados FTD mostram a criação e a terminação da conexão em todas as unidades:

- Unidade 1-1 (diretor/proprietário do backup)

- Unidade 2-1 (proprietário)

- Unidade 3-1 (encaminhador)

firepower# cluster exec show log | i 59210

unit-1-1(LOCAL):******************************************************

Dec 03 2020 09:19:49: %FTD-6-302022: Built director stub TCP connection for INSIDE:192.168.240.50/59210 (192.168.240.50/59210) to OUTSIDE:192.168.240.51/80 (192.168.240.51/80)

Dec 03 2020 09:19:59: %FTD-6-302023: Teardown director TCP connection for INSIDE:192.168.240.50/59210 to OUTSIDE:192.168.240.51/80 duration 0:00:09 forwarded bytes 0 Cluster flow with CLU closed on owner

unit-2-1:*************************************************************

Dec 03 2020 09:19:49: %FTD-6-302303: Built TCP state-bypass connection 14483 from INSIDE:192.168.240.50/59210 (192.168.240.50/59210) to OUTSIDE:192.168.240.51/80 (192.168.240.51/80)

Dec 03 2020 09:19:59: %FTD-6-302304: Teardown TCP state-bypass connection 14483 from INSIDE:192.168.240.50/59210 to OUTSIDE:192.168.240.51/80 duration 0:00:09 bytes 1024003336 TCP FINs

unit-3-1:*************************************************************

Dec 03 2020 09:19:49: %FTD-6-302022: Built forwarder stub TCP connection for OUTSIDE:192.168.240.51/80 (192.168.240.51/80) to unknown:192.168.240.50/59210 (192.168.240.50/59210)

Dec 03 2020 09:19:59: %FTD-6-302023: Teardown forwarder TCP connection for OUTSIDE:192.168.240.51/80 to unknown:192.168.240.50/59210 duration 0:00:09 forwarded bytes 1024003188 Cluster flow with CLU closed on owner

Troubleshoot

Introdução à solução de problemas de cluster

Os problemas do cluster podem ser categorizados em:

- Problemas do plano de controle (problemas relacionados à estabilidade do cluster)

- Problemas do plano de dados (problemas relacionados ao tráfego de trânsito)

Problemas do plano de dados do cluster

Problemas comuns de NAT/PAT

Considerações importantes sobre a configuração

- Os pools de conversão de endereço de porta (PAT - Port Address Translation) devem ter pelo menos tantos IPs disponíveis quanto o número de unidades no cluster, preferencialmente mais IPs do que nós de cluster.

- Os comandos xlate per-session padrão devem ser mantidos, a menos que haja um motivo específico para desativá-los. Qualquer formato PAT criado para uma conexão que tenha xlate per-session disabled é sempre tratado pela unidade do nó de controle no cluster, o que pode causar degradação de desempenho.

Alta utilização do intervalo de pool de PAT devido ao tráfego originado de portas baixas que causa desequilíbrio de IP de cluster

O FTD divide um PAT IP em "intervalos" e tenta manter o xlate no mesmo intervalo de origem. Esta tabela mostra como uma porta de origem é convertida em uma porta global dentro do mesmo intervalo de origem.

Porta Src Original

Porta Src Traduzida

1-511

1-511

512-1023

512-1023

1024-65535

1024-65535

Quando um intervalo de portas de origem está cheio e um novo formato PAT precisa ser alocado desse intervalo, o FTD move-se para o próximo IP para alocar novas conversões para esse intervalo de portas de origem.

Sintomas

Problemas de conectividade para o tráfego NATed que atravessa o cluster

Verificação

# show nat pool

Os registros do plano de dados FTD mostram a exaustão do pool PAT:

Dec 9 09:00:00 192.0.2.10 FTD-FW %ASA-3-202010: PAT pool exhausted. Unable to create TCP connection from Inside:192.0.2.150/49464 to Outside:192.0.2.250/20015

Dec 9 09:00:00 192.0.2.10 FTD-FW %ASA-3-202010: PAT pool exhausted. Unable to create TCP connection from Inside:192.0.2.148/54141 to Outside:192.0.2.251/443

Atenuação

Configure o intervalo de portas planas NAT e inclua portas de reserva.

Além disso, no pós-6.7/9.15.1, você pode acabar com a distribuição de blocos de porta desequilibrada somente quando os nós saem/se juntam ao cluster com tráfego de segundo plano enorme que está sujeito ao PAT. A única maneira de se recuperar por si só é quando os blocos de porta são liberados para serem redistribuídos pelos nós.

Com a distribuição baseada em blocos de portas, quando um nó é alocado com, digamos, blocos de 10 portas como pb-1, pb-2 ... pb-10. O nó sempre começa com o primeiro bloco de portas disponível e aloca uma porta aleatória a partir dela até que ela termine. A alocação se move para o próximo bloco de portas somente quando todos os blocos de porta até esse ponto estão esgotados.

Por exemplo, se um host estabelece 512 conexões, a unidade aloca portas mapeadas para todas essas 512 conexões do pb-1 aleatoriamente. Agora, com todas essas 512 conexões ativas, quando o host estabelece a 513ª conexão desde que pb-1 está esgotado, ele se move para pb-2 e aloca uma porta aleatória dela. Agora novamente, das 513 conexões, suponha que a 10ª conexão foi concluída e removeu uma porta disponível em pb-1. Nesse ponto, se o host estabelecer a 514ª conexão, a unidade de cluster aloca uma porta mapeada de pb-1 e não de pb-2 porque pb-1 agora tem uma porta livre (que foi liberada como parte da 10ª remoção de conexão).

A parte importante a ser lembrada é que a alocação acontece a partir do primeiro bloco de portas disponível com portas livres para que os últimos blocos de portas estejam sempre disponíveis para redistribuição em um sistema normalmente carregado. Além disso, o PAT é tipicamente usado para conexões de vida curta. A probabilidade de um bloco de portas se tornar disponível em um tempo mais curto é muito alta. Assim, o tempo necessário para que a distribuição do pool se torne equilibrada pode melhorar com a distribuição do pool baseado em blocos de portas.

No entanto, caso todos os blocos de porta, de pb-1 a pb-10, estejam esgotados ou cada bloco de porta mantenha uma porta para uma conexão de longa duração, os blocos de porta nunca serão liberados rapidamente e serão redistribuídos. Nesse caso, a abordagem menos perturbadora é:

1. Identificar nós com blocos de porta excessivos (show nat pool cluster summary).

2. Identifique os blocos de porta menos usados nesse nó (show nat pool ip <addr> detail).

3. Limpar explora esses blocos de porta (clear xlate global <addr> gport 'start-end') para disponibilizá-los para redistribuição.

aviso: Isso interrompe as conexões relevantes.

Não é possível navegar para sites de canal duplo (como webmail, banco, etc.) ou para sites SSO quando ocorre o redirecionamento para um destino diferente

Sintomas

Não é possível navegar para sites de canal duplo (como webmail, sites bancários, etc.). Quando um usuário se conecta a um site que exige que o cliente abra um segundo soquete/conexão e a segunda conexão é conectada com um membro de cluster diferente daquele ao qual a primeira conexão foi conectada e o tráfego usa um pool de PAT IP, o tráfego é redefinido pelo servidor quando ele recebe a conexão de um endereço IP público diferente.

Verificação

Faça capturas de cluster de plano de dados para ver como o fluxo de trânsito afetado é tratado. Nesse caso, uma redefinição de TCP vem do site de destino.

Mitigação (pré-6.7/9.15.1)

- Observe se qualquer aplicativo de várias sessões usa vários endereços IP mapeados.

- Use o comando show nat pool cluster summary para verificar se o pool está distribuído uniformemente.

- Use o comando exec show conn do cluster para verificar se o tráfego está balanceado corretamente.

- Use o comando show nat pool cluster ip <address> detail para verificar o uso do pool de IP sticky.

- Ative o syslog 305021 (6.7/9.15) para ver quais conexões falharam ao usar IP sticky.

- Para resolver adicionar mais IPs ao pool PAT ou ajustar o algoritmo de balanceamento de carga em switches conectados.

Sobre o algoritmo de balanceamento de carga ether-channel:

- Para não FP9300 e se a autenticação ocorrer através de um servidor: Ajuste o algoritmo de balanceamento de carga do canal éter no switch adjacente de IP/Porta de Origem e IP/Porta de Destino para IP de Origem e IP de Destino.

- Para não FP9300 e se a autenticação ocorrer através de vários servidores: Ajuste o algoritmo de balanceamento de carga do canal éter no switch adjacente de IP/Porta de Origem e IP/Porta de Destino para IP de Origem.

- Para o FP9300: No chassi do FP9300, o algoritmo de balanceamento de carga é fixo como source-dest-ip source-dest-dest-mac e não pode ser alterado. A solução alternativa, nesse caso, é usar o FlexConfig para adicionar comandos xlate per-session deny à configuração do FTD para forçar o tráfego para determinados endereços IP de destino (para aplicativos problemáticos/incompatíveis) a serem tratados somente pelo nó de controle no cluster intra-chassi. A solução alternativa vem com estes efeitos colaterais:

- Nenhum balanceamento de carga do tráfego traduzido diferentemente (tudo vai para o nó de controle).

- Possibilidade de os slots de xlate ficarem sem execução (e afetarem adversamente a conversão de NAT para outro tráfego no nó de controle).

- Escalabilidade reduzida do cluster entre chassis.

Baixo desempenho do cluster devido a todo o tráfego enviado para o nó de controle devido a IPs PAT insuficientes nos pools

Sintomas

Não há IPs PAT suficientes no cluster para alocar um IP livre aos nós de dados e, portanto, todo o tráfego sujeito à configuração PAT é encaminhado ao nó de controle para processamento.

Verificação

Use o comando show nat pool cluster para ver as alocações de cada unidade e confirmar se todas possuem pelo menos um IP no pool.

Atenuação

Para pré-6.7/9.15.1, certifique-se de que você tenha um pool de PAT de tamanho pelo menos igual ao número de nós no cluster. No pós-6.7/9.15.1 com pool PAT, você aloca blocos de portas de todos os IPs do pool PAT. Se o uso do pool de PAT é realmente alto, o que leva à exaustão frequente do pool, você precisa aumentar o tamanho do pool de PAT (consulte a seção FAQ)

Baixo desempenho devido a todo o tráfego enviado para o nó de controle porque os pacotes não são ativados por sessão

Sintomas

Muitos fluxos de backup UDP de alta velocidade são processados através do nó de controle de cluster, o que pode afetar o desempenho.

Background

Somente as conexões que usam taxas ativadas por sessão podem ser processadas por um nó de dados que usa PAT. Use o comando show run all xlate para ver a configuração xlate per-session

Por sessão habilitada significa que o xlate é desligado imediatamente quando a conexão associada é interrompida. Isso ajuda a melhorar o desempenho da conexão por segundo quando as conexões são submetidas à PAT. As conversões não por sessão permanecem ativas por mais 30 segundos após a conexão associada ser interrompida e, se a taxa de conexão for alta o suficiente, as portas TCP/UDP disponíveis de 65 k em cada IP global podem ser usadas em um curto período de tempo.

Por padrão, todo o tráfego TCP é ativado por xlate e somente o tráfego DNS UDP é ativado por sessão. Isso significa que todo o tráfego UDP não-DNS é encaminhado ao nó de controle para processamento.

Verificação

Use este comando para verificar a conexão e a distribuição de pacotes entre as unidades de cluster:

firepower# show cluster info conn-distribution

firepower# show cluster info packet-distribution

firepower# show cluster info load-monitor

Use o comando exec de cluster show conn para ver quais nós de cluster possuem as conexões UDP.

firepower# cluster exec show conn

Use este comando para entender o uso do pool nos nós do cluster.

firepower# cluster exec show nat pool ip

| in UDP

Atenuação

Configure o PAT por sessão (comando permit udp por sessão) para o tráfego de interesse (por exemplo, UDP). Para o ICMP, você não pode alterar o PAT multisessão padrão, portanto, o tráfego IMCP é sempre tratado pelo nó de controle quando há PAT configurado.

A distribuição do pool PAT torna-se desequilibrada à medida que os nós saem/se juntam ao cluster.

Sintomas

- Problemas de conectividade, pois a alocação de PAT IP pode se tornar desequilibrada com o tempo devido às unidades que saem e se juntam ao cluster.

- No pós-6.7/9.15.1, pode haver casos em que o nó recém-associado não pode obter blocos de porta suficientes. Um nó que não tem nenhum bloco de portas redireciona o tráfego para o nó de controle. Um nó que tenha pelo menos um bloco de portas trata o tráfego e começa a descartá-lo quando o pool estiver esgotado.

Verificação

- Os syslogs do plano de dados mostram mensagens como:

%ASA-3-202010: NAT pool exhausted. Unable to create TCP connection from inside:192.0.2.1/2239 to outside:192.0.2.150/80

- Use o comando show nat pool cluster summary para identificar a distribuição do pool.

- Use o comando exec cluster show nat pool ip <addr> detail para entender o uso do pool nos nós do cluster.

Atenuação

- Para o pré-6.7/9.15.1, algumas soluções alternativas são descritas em https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd10530

- No pós-6.7/9.15.1, resolva isso usando o comando clear xlate global <ip> gport <start-end> para limpar manualmente alguns dos blocos de portas em outros nós para redistribuição aos nós necessários.

Sintomas

Principais problemas de conectividade para o tráfego que é PATed pelo cluster. Isso porque o plano de dados FTD , por design, não envia GARP para endereços NAT globais.

Verificação

A tabela ARP dos dispositivos conectados diretamente mostra o endereço MAC diferente da interface de dados do cluster após uma alteração do nó de controle:

root@kali2:~/tests# arp -a

? (192.168.240.1) at f4:db:e6:33:44:2e [ether] on eth0

root@kali2:~/tests# arp -a

? (192.168.240.1) at f4:db:e6:9e:3d:0e [ether] on eth0

Atenuação

Configure o MAC estático (virtual) nas interfaces de dados do cluster.

Conexões sujeitas a falha de PAT

Sintomas

Problemas de conectividade para o tráfego que é PATed pelo cluster.

Verificação/Mitigação

- Verifique se a configuração foi replicada corretamente.

- Verifique se o pool está distribuído uniformemente.

- Verifique se a propriedade do pool é válida.

- Nenhum incremento de contador de falha em show asp cluster counter.

- Certifique-se de que os fluxos do direcionador/encaminhador sejam criados com as informações corretas.

- Valide se os diagramas de backup são criados, atualizados e limpos conforme esperado.

- Valide se os pacotes são criados e terminados de acordo com o comportamento "por sessão".

- Ative "debug nat 2" para obter uma indicação de quaisquer erros. Observe que essa saída pode ser muito ruidosa, por exemplo

firepower#  debug nat 2

nat: no free blocks available to reserve for 192.168.241.59, proto 17

nat: no free blocks available to reserve for 192.168.241.59, proto 17

nat: no free blocks available to reserve for 192.168.241.58, proto 17

nat: no free blocks available to reserve for 192.168.241.58, proto 17

nat: no free blocks available to reserve for 192.168.241.57, proto 17

Para interromper a depuração:

firepower# un all

- Ative a conexão e os syslogs relacionados a NAT para correlacionar as informações a uma conexão com falha.

Aprimoramentos de PAT de cluster ASA e FTD (pós-9.15 e 6.7)

O que se alterou?

A operação PAT foi reprojetada. Os IPs individuais não são mais distribuídos para cada um dos membros do cluster. Em vez disso, os IPs PAT são divididos em blocos de portas e distribuem esses blocos de portas uniformemente (o máximo possível) entre os membros do cluster, em combinação com a operação de adesão ao IP.

O novo projeto aborda essas limitações (consulte a seção anterior):

- Os aplicativos de várias sessões são afetados devido à falta de fidelidade IP em todo o cluster.

- O requisito de ter um pool PAT de tamanho pelo menos igual ao número de nós no cluster.

- A distribuição do pool PAT torna-se desequilibrada à medida que os nós saem/se juntam ao cluster.

- Nenhum syslog para indicar desequilíbrio de pool PAT.

Tecnicamente, em vez dos intervalos de porta padrão 1-511, 512-1023 e 1024-65535, agora há 1024-65535 como o intervalo de portas padrão para PAT. Esse intervalo padrão pode ser estendido para incluir o intervalo de portas privilegiadas de 1 a 1023 para PAT regular (opção "include-reserve").

Este é um exemplo de uma configuração de pool PAT no FTD 6.7. Para obter mais detalhes, consulte a seção relacionada no Guia de configuração:

Informações adicionais sobre solução de problemas de PAT

Syslogs do plano de dados FTD (pós-6.7/9.15.1)

Um syslog de invalidação consistente é gerado quando todas as portas estão esgotadas no IP sticky em um nó de cluster e a alocação muda para o próximo IP disponível com portas livres. p. ex.

%ASA-4-305021: Ports exhausted in pre-allocated PAT pool IP 192.0.2.100 for host 198.51.100.100 Allocating from new PAT pool IP 203.0.113.100.

Um syslog de desequilíbrio de pool é gerado em um nó quando ele ingressa no cluster e não obtém nenhuma ou desigual participação de blocos de portas, por exemplo:

%ASA-4-305022: Cluster unit ASA-4 has been allocated 0 port blocks for PAT usage. All units should have at least 32 port blocks.

%ASA-4-305022: Cluster unit ASA-4 has been allocated 12 port blocks for PAT usage. All units should have at least 32 port blocks.

comandos show

Status de distribuição do pool

Na saída show nat pool cluster summary, para cada endereço IP PAT, não deve haver uma diferença de mais de um bloco de portas entre os nós em um cenário de distribuição equilibrado. Exemplos de uma distribuição de blocos de portas equilibrada e desequilibrada.

firepower# show nat pool cluster summary

port-blocks count display order: total, unit-1-1, unit-2-1, unit-3-1

IP OUTSIDE:ip_192.168.241.57-59 192.168.241.57 (126 - 42 / 42 / 42)

IP OUTSIDE:ip_192.168.241.57-59 192.168.241.58 (126 - 42 / 42 / 42)

IP OUTSIDE:ip_192.168.241.57-59 192.168.241.59 (126 - 42 / 42 / 42)

Distribuição equilibrada:

firepower# show nat pool cluster summary

port-blocks count display order: total, unit-1-1, unit-4-1, unit-2-1, unit-3-1

IP outside:src_map 192.0.2.100 (128 - 32 / 22 / 38 / 36)

Status de propriedade do pool

Na saída show nat pool cluster, não deve haver um único bloco de portas com proprietário ou backup como "DESCONHECIDO". Se houver um, isso indica um problema com a comunicação de propriedade do pool. Exemplo:

firepower# show nat pool cluster | in

[3072-3583], owner unit-4-1, backup <UNKNOWN>

[56832-57343], owner <UNKNOWN>, backup <UNKNOWN>

[10240-10751], owner unit-2-1, backup <UNKNOWN>

Contabilização das alocações de portas em blocos de portas

O comando show nat pool é aprimorado com opções adicionais para exibir informações detalhadas, bem como saída filtrada. Exemplo:

firepower# show nat pool detail

TCP PAT pool INSIDE, address 192.168.240.1, range 1-1023, allocated 0

TCP PAT pool INSIDE, address 192.168.240.1, range 1024-65535, allocated 18

UDP PAT pool INSIDE, address 192.168.240.1, range 1-1023, allocated 0

UDP PAT pool INSIDE, address 192.168.240.1, range 1024-65535, allocated 20

TCP PAT pool OUTSIDE, address 192.168.241.1, range 1-1023, allocated 0

TCP PAT pool OUTSIDE, address 192.168.241.1, range 1024-65535, allocated 18

UDP PAT pool OUTSIDE, address 192.168.241.1, range 1-1023, allocated 0

UDP PAT pool OUTSIDE, address 192.168.241.1, range 1024-65535, allocated 20

UDP PAT pool OUTSIDE, address 192.168.241.58

range 1024-1535, allocated 512

range 1536-2047, allocated 512

range 2048-2559, allocated 512

range 2560-3071, allocated 512

...

unit-2-1:*************************************************************

UDP PAT pool OUTSIDE, address 192.168.241.57

range 1024-1535, allocated 512 *

range 1536-2047, allocated 512 *

range 2048-2559, allocated 512 *

Note: ‘*’ indica que é um bloco de portas de backup

Para resolver isso, use o comando clear xlate global <ip> gport <start-end> para limpar manualmente alguns dos blocos de portas em outros nós para redistribuição aos nós necessários.

Redistribuição de blocos de portas acionada manualmente

- Em uma rede de produção com tráfego constante, quando um nó sai e se junta ao cluster (provavelmente devido a um rastreamento retroativo), pode haver casos em que ele não pode obter uma participação igual do pool ou, na pior das hipóteses, não pode obter nenhum bloco de portas.

- Use o comando show nat pool cluster summary para identificar qual nó possui mais blocos de porta do que o necessário.

- Nos nós que estão possuindo mais blocos de porta, use o comando show nat pool ip <addr> detail para descobrir os blocos de porta com o menor número de alocações.

- Use o comando clear xlate global <address> gport <start-end> para limpar as conversões criadas a partir desses blocos de portas para que elas se tornem disponíveis para redistribuição aos nós necessários, por exemplo:

firepower# show nat pool detail | i 19968

range 19968-20479, allocated 512

range 19968-20479, allocated 512

range 19968-20479, allocated 512

firepower# clear xlate global 192.168.241.57 gport 19968-20479

INFO: 1074 xlates deleted

Perguntas frequentes (FAQ) sobre PAT pós-6.7/9.15.1

P. Caso você tenha o número de IPs disponíveis para o número de unidades disponíveis no cluster, ainda é possível usar 1 IP por unidade como opção?

A. Não mais e não há alternância entre esquemas de distribuição de pool baseados em endereços IP e baseados em blocos de portas.

O esquema mais antigo de distribuição de pool baseado em endereço IP resultou em falhas de aplicativos em várias sessões, em que várias conexões (que fazem parte de uma única transação de aplicativo) de um host são balanceadas com carga em diferentes nós do cluster e, portanto, convertidas por diferentes endereços IP mapeados, que levam o servidor de destino a vê-las como originadas de entidades diferentes.

Além disso, com o novo esquema de distribuição baseado em blocos de portas, mesmo que agora você possa trabalhar com um único endereço IP PAT baixo, é sempre recomendável ter endereços IP PAT suficientes com base no número de conexões que são necessárias para o PAT.

P. Você ainda pode ter um pool de endereços IP para o pool PAT para o cluster?

A. Sim, você pode. Os blocos de portas de todos os IPs do pool PAT são distribuídos pelos nós do cluster.

P. Se você usa um número de endereços IP para o pool PAT, o mesmo bloco de portas é dado a cada membro por cada endereço IP?

A. Não, cada IP é distribuído independentemente.

P. Todos os nós de cluster têm todos os IPs públicos, mas apenas um subconjunto de portas? Se for esse o caso, será então garantido que toda vez que o IP de origem usa o mesmo IP público?

A. Isso está correto, cada IP PAT é parcialmente de propriedade de cada nó. Se um IP público escolhido estiver esgotado em um nó, um syslog será gerado indicando que o IP sticky não pode ser preservado e a alocação será movida para o próximo IP público disponível. Seja uma implantação independente, HA ou Cluster, a adesão ao IP é sempre uma base de melhor esforço, dependendo da disponibilidade do pool.

P. Tudo é baseado em um único endereço IP no pool PAT, mas não se aplica se estiver usando mais de um endereço IP no pool PAT?

A. Também se aplica a vários endereços IP no Pool PAT. Os blocos de portas de cada IP no Pool PAT são distribuídos entre nós de cluster. Cada endereço IP no pool PAT é dividido em todos os membros no cluster. Assim, se você tiver, uma classe C de endereços no pool PAT, cada membro do cluster terá pools de portas de cada um dos endereços do pool PAT.

P. Funciona com o CGNAT?

A. Sim, o CGNAT também é compatível. O CGNAT, também conhecido como PAT de "alocação de bloco", tem um tamanho de bloco padrão de '512' que pode ser modificado através da CLI xlate block-Allocation size. No caso de PAT dinâmico regular (não CGNAT), o tamanho do bloco é sempre '512', que é fixo e não configurável.

P. Se a unidade deixar o cluster, o nó de controle atribui o intervalo de blocos de portas a outras unidades ou o mantém em si mesmo?

A. Cada bloco de portas tem um proprietário e um backup. Toda vez que um xlate é criado a partir de um bloco de portas, ele também é replicado no nó de backup do bloco de portas. Quando um nó sai do cluster, o nó de backup possui todos os blocos de portas e todas as conexões atuais. O nó de backup, já que se tornou o proprietário desses blocos de porta adicionais, escolhe um novo backup para eles e replica todos os pacotes atuais para esse nó para lidar com cenários de falha.

P. Que medidas podem ser tomadas com base nesse alerta para impor a autossuficiência?

A. Há duas razões possíveis para que a aderência não possa ser preservada.

Motivo-1: O tráfego está incorretamente balanceado devido ao qual um dos nós vê um número mais alto de conexões do que outros, o que leva à exaustão particular de IP difícil. Isso pode ser endereçado se você assegurar que o tráfego seja distribuído uniformemente pelos nós do cluster. Por exemplo, em um cluster FPR41xx, ajuste o algoritmo de balanceamento de carga em switches conectados. Em um cluster FPR9300, assegure um número igual de blades no chassi.

Motivo 2: O uso do pool de PAT é realmente alto, o que leva à exaustão frequente do pool. Para lidar com isso, aumente o tamanho do pool PAT.

P. Como o suporte para a palavra-chave estendida é tratado? Ele mostra um erro e impede que todo o comando NAT seja adicionado durante a atualização ou remove a palavra-chave estendida e mostra um aviso?

A. A opção "estendida" de PAT não é suportada no cluster do ASA 9.15.1/FP 6.7 em diante. A opção de configuração não é removida de nenhum CLI/ASDM/CSM/FMC. Quando configurado (direta ou indiretamente por meio de uma atualização), você é notificado com uma mensagem de aviso e a configuração é aceita, mas você não vê a funcionalidade estendida do PAT em ação.

P. É o mesmo número de conversões que conexões simultâneas?

A. Em pre-6.7/9.15.1, embora fosse 1-65535, como as portas de origem nunca são muito usadas no intervalo 1-1024, elas efetivamente o tornam 1024-65535 (64512 conns). Na implementação pós-6.7/9.15.1 com 'flat' como comportamento padrão, é 1024-65535. Mas se quiser usar o 1-1024, você pode usar a opção "include-reserve".

P. Se o nó ingressar no cluster, ele terá o antigo nó de backup como "backup" e esse nó de backup fornecerá seu antigo bloco de portas a ele?

A. Depende da disponibilidade de blocos de portas naquele momento. Quando um nó sai do cluster, todos os seus blocos de porta são movidos para o nó de backup. É então o nó de controle que acumula blocos de porta livres e o distribui aos nós necessários.

P. Se houver uma alteração no estado do nó de controle, um novo nó de controle selecionado, a alocação de bloco PAT será mantida ou os blocos de porta serão realocados com base no novo nó de controle?

A. O novo nó de controle tem uma compreensão de quais blocos foram alocados e quais são livres e começam a partir daí.

P. O número máximo de taxas é igual ao número máximo de conexões simultâneas com esse novo comportamento?

A. Yes. O número máximo de taxas depende da disponibilidade das portas PAT. Não tem nada a ver com o número máximo de conexões simultâneas. Se você permitir apenas 1 endereço, terá 65535 conexões possíveis. Se precisar de mais, é preciso alocar mais endereços IP. Se houver endereços/portas suficientes, você pode alcançar o máximo de conexões simultâneas.

P. Qual é o processo de alocação de bloco de portas quando um novo membro de cluster é adicionado? O que acontece se um membro de cluster for adicionado devido à reinicialização?

A. Os blocos de portas são sempre distribuídos pelo nó de controle. Os blocos de porta são alocados a um novo nó somente quando há blocos de porta livres. Blocos de porta livres significam que nenhuma conexão é servida por qualquer porta mapeada dentro do bloco de portas.

Além disso, ao reingressar, cada nó recalcula o número de blocos que pode possuir. Se um nó contiver mais blocos do que deveria, ele liberará esses blocos de porta adicionais para o nó de controle quando e quando eles estiverem disponíveis. O nó de controle então os aloca ao nó de dados recém-ingressado.

P. Ele é compatível somente com protocolos TCP e UDP ou SCTP também?

A. O SCTP nunca foi suportado com PAT dinâmico. Para o tráfego SCTP, a recomendação é usar apenas um NAT de objeto de rede estático.

P. Se um nó ficar sem portas de bloqueio, ele descartará pacotes e não usará o próximo bloco IP disponível?

A. Não, não cai imediatamente. Usa blocos de portas disponíveis no próximo PAT IP. Se todos os blocos de porta em todos os IPs PAT estiverem esgotados, ele descartará o tráfego.

P. Para evitar a sobrecarga do nó de controle em uma janela de atualização de cluster, é melhor selecionar um novo controle manualmente antes (por exemplo, a meio caminho de uma atualização de cluster de 4 unidades), em vez de esperar que todas as conexões sejam tratadas no nó de controle?

A. O controle deve ser atualizado por último. Isso porque, quando o nó de controle executa a versão mais recente, ele não inicia a distribuição do pool a menos que todos os nós executem a versão mais recente. Além disso, quando uma atualização é executada, todos os nós de dados com uma versão mais recente ignoram as mensagens de distribuição do pool de um nó de controle se ele executa uma versão mais antiga.

Para explicar isso em detalhes, considere uma implantação de cluster com 4 nós A, B, C e D com A como controle. Aqui estão as etapas típicas de atualização sem interrupções:

1. Faça o download de uma nova versão em cada um dos nós.

2. Recarregue a unidade "D". Todas as conexões, explicações, são movidas para o nó de backup.

3. A unidade "D" aparece e:

a. Processa a configuração de PAT

b. Quebra cada IP PAT em blocos de portas

c. Tem todos os blocos de porta no estado não atribuído

d. Ignora versão mais antiga das mensagens PAT do cluster recebidas do controle

e. Redireciona todas as conexões PAT para o mestre

4. Da mesma forma, ative outros nós com a nova versão.

5. Recarregar o controlo da unidade "A". Como não há backup para controle, todas as conexões existentes são descartadas

6. O novo controle inicia a distribuição de blocos de portas no formato mais recente

7. A unidade "A" junta-se e pode aceitar e atuar em mensagens de distribuição de blocos de portas

Manuseio de Fragmentos

Sintoma

Em implantações de cluster entre locais, os pacotes fragmentados que devem ser tratados em um local específico (tráfego local do site) ainda podem ser enviados para as unidades em outros locais, pois um desses locais pode ter o proprietário do fragmento.

Na lógica do cluster, há uma função adicional definida para conexões com pacotes fragmentados: proprietário do fragmento.

Para pacotes fragmentados, as unidades de cluster que recebem um fragmento determinam um proprietário de fragmento com base em um hash do endereço IP origem do fragmento, endereço IP destino e ID do pacote. Todos os fragmentos são encaminhados ao proprietário do fragmento pelo link de controle do cluster. Os fragmentos podem ser balanceados para diferentes unidades de cluster porque somente o primeiro fragmento inclui a 5 tuplas usadas no hash de balanceamento de carga do switch. Outros fragmentos não contêm as portas origem e destino e podem ser balanceados para outras unidades de cluster. O proprietário do fragmento reagrupa temporariamente o pacote para que possa determinar o direcionador com base em um hash do endereço IP de origem/destino e das portas. Se for uma nova conexão, o proprietário do fragmento se tornará o proprietário da conexão. Se for uma conexão existente, o proprietário do fragmento encaminha todos os fragmentos para o proprietário da conexão pelo link de controle do cluster. O proprietário da conexão então reagrupa todos os fragmentos.

Considere esta topologia com o fluxo de uma solicitação de eco ICMP fragmentada do cliente para o servidor:

Para entender a ordem das operações, há capturas de pacotes em todo o cluster nas interfaces de link de controle de cluster internas, externas e configuradas com a opção de rastreamento. Além disso, uma captura de pacote com a opção reinject-hide é configurada na interface interna.

firepower# cluster exec capture capi interface inside trace match icmp any any

firepower# cluster exec capture capir interface inside reinject-hide trace match icmp any any

firepower# cluster exec capture capo interface outside trace match icmp any any

firepower# cluster exec capture capccl interface cluster trace match icmp any any

Ordem das operações no cluster:

1. a unidade-1-1 no local 1 recebe os pacotes de solicitação de eco ICMP fragmentado.

firepower# cluster exec show cap capir

unit-1-1(LOCAL):******************************************************

2 packets captured

1: 20:13:58.227801 802.1Q vlan#10 P0 192.0.2.10 > 203.0.113.10 icmp: echo request

2: 20:13:58.227832 802.1Q vlan#10 P0

2 packets shown

2. unit-1-1 seleciona a unidade-2-2 no local 2 como o proprietário do fragmento e envia pacotes fragmentados para ela.

O endereço MAC destino dos pacotes enviados da unidade-1-1 para a unidade-2-2 é o endereço MAC do link CCL na unidade-2-2.

firepower# show cap capccl packet-number 1 detail

7 packets captured

1: 20:13:58.227817 0015.c500.018f 0015.c500.029f 0x0800 Length: 1509

192.0.2.10 > 203.0.113.10 icmp: echo request (wrong icmp csum) (frag 46772:1475@0+) (ttl 3)

1 packet shown

firepower# show cap capccl packet-number 2 detail

7 packets captured

2: 20:13:58.227832 0015.c500.018f 0015.c500.029f 0x0800 Length: 637

192.0.2.10 > 203.0.113.10 (frag 46772:603@1480) (ttl 3)

1 packet shown

firepower# cluster exec show interface po48 | i MAC

unit-1-1(LOCAL):******************************************************

MAC address 0015.c500.018f, MTU 1500

unit-1-2:*************************************************************

MAC address 0015.c500.019f, MTU 1500

unit-2-2:*************************************************************

MAC address 0015.c500.029f, MTU 1500

unit-1-3:*************************************************************

MAC address 0015.c500.016f, MTU 1500

unit-2-1:*************************************************************

MAC address 0015.c500.028f, MTU 1500

unit-2-3:*************************************************************

MAC address 0015.c500.026f, MTU 1500

3. a unidade-2-2 recebe, reagrupa os pacotes fragmentados e torna-se proprietária do fluxo.

firepower# cluster exec unit unit-2-2 show capture capccl packet-number 1 trace

11 packets captured

1: 20:13:58.231845 192.0.2.10 > 203.0.113.10 icmp: echo request

Phase: 1

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'inside'

Flow type: NO FLOW

I (2) received a FWD_FRAG_TO_FRAG_OWNER from (0).

Phase: 2

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'inside'

Flow type: NO FLOW

I (2) have reassembled a packet and am processing it.

Phase: 3

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 5

Type: ROUTE-LOOKUP

Subtype: No ECMP load balancing

Result: ALLOW

Config:

Additional Information:

Destination is locally connected. No ECMP load balancing.

Found next-hop 203.0.113.10 using egress ifc outside(vrfid:0)

Phase: 6

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'inside'

Flow type: NO FLOW

I (2) am becoming owner

Phase: 7

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group CSM_FW_ACL_ global

access-list CSM_FW_ACL_ advanced trust ip any any rule-id 268435460 event-log flow-end

access-list CSM_FW_ACL_ remark rule-id 268435460: PREFILTER POLICY: igasimov_prefilter1

access-list CSM_FW_ACL_ remark rule-id 268435460: RULE: r1

Additional Information:

...

Phase: 19

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 1719, packet dispatched to next module

...

Result:

input-interface: cluster(vrfid:0)

input-status: up

input-line-status: up

output-interface: outside(vrfid:0)

output-status: up

output-line-status: up

Action: allow

1 packet shown

firepower# cluster exec unit unit-2-2 show capture capccl packet-number 2 trace

11 packets captured

2: 20:13:58.231875

Phase: 1

Type: CLUSTER-EVENT

Subtype:

Result: ALLOW

Config:

Additional Information:

Input interface: 'inside'

Flow type: NO FLOW

I (2) received a FWD_FRAG_TO_FRAG_OWNER from (0).

Result:

input-interface: cluster(vrfid:0)

input-status: up

input-line-status: up

Action: allow

1 packet shown

4. a unidade 2-2 permite os pacotes com base na política de segurança e os envia através da interface externa do site 2 para o site 1.

firepower# cluster exec unit unit-2-2 show cap capo

2 packets captured

1: 20:13:58.232058 802.1Q vlan#20 P0 192.0.2.10 > 203.0.113.10 icmp: echo request

2: 20:13:58.232058 802.1Q vlan#20 P0

Observações/avisos

- Ao contrário da função de direcionador, o proprietário do fragmento não pode ser localizado em um site específico. O proprietário do fragmento é determinado pela unidade que recebe originalmente os pacotes fragmentados de uma nova conexão e pode estar localizada em qualquer local.

- Como um proprietário de fragmento também pode se tornar o proprietário da conexão, para encaminhar os pacotes para o host de destino, ele deve ser capaz de resolver a interface de saída, localizar os endereços IP e MAC do host de destino ou do próximo salto. Isso pressupõe que os próximos saltos também devem ter a acessibilidade ao host de destino.

- Para reagrupar os pacotes fragmentados, o ASA/FTD mantém um módulo de remontagem de fragmento IP para cada interface nomeada. Para exibir os dados operacionais do módulo de remontagem de fragmento IP, use o comando show fragment:
Interface: inside

Configuration: Size: 200, Chain: 24, Timeout: 5, Reassembly: virtual

Run-time stats: Queue: 0, Full assembly: 0

Drops: Size overflow: 0, Timeout: 0,

Chain overflow: 0, Fragment queue threshold exceeded: 0,

Small fragments: 0, Invalid IP len: 0,

Reassembly overlap: 0, Fraghead alloc failed: 0,

SGT mismatch: 0, Block alloc failed: 0,

Invalid IPV6 header: 0, Passenger flow assembly failed: 0
Em implantações de cluster, o proprietário do fragmento ou o proprietário da conexão colocou os pacotes fragmentados na fila de fragmentos. O tamanho da fila de fragmentos é limitado pelo valor do contador Size (por padrão, 200) configurado com o comando fragment size <size> <nameif>. Quando o tamanho da fila de fragmentos atinge 2/3 do Tamanho, o limite da fila de fragmentos é considerado excedido, todos os fragmentos novos que não fazem parte da cadeia de fragmentos atual são descartados. Nesse caso, o limite de fila de fragmento excedido é incrementado e a mensagem de syslog FTD-3-209006 é gerada.

firepower# show fragment inside

Interface: inside

Configuration: Size: 200, Chain: 24, Timeout: 5, Reassembly: virtual

Run-time stats: Queue: 133, Full assembly: 0

Drops: Size overflow: 0, Timeout: 8178,

Chain overflow: 0, Fragment queue threshold exceeded: 40802,

Small fragments: 0, Invalid IP len: 0,

Reassembly overlap: 9673, Fraghead alloc failed: 0,

SGT mismatch: 0, Block alloc failed: 0,

Invalid IPV6 header: 0, Passenger flow assembly failed: 0

%FTD-3-209006: Fragment queue threshold exceeded, dropped TCP fragment from 192.0.2.10/21456 to 203.0.113.10/443 on inside interface.

Como solução alternativa, aumente o tamanho no Firepower Management Center > Devices > Device Management > [Edit Device] > Interfaces > [Interface] > Avançado > Configuração de Segurança > Substituir Configuração de Fragmento Padrão, salve a configuração e implante políticas. Em seguida, monitore o contador de fila na saída do comando show fragment e a ocorrência da mensagem syslog FTD-3-209006.

Problemas com a ACI

Problemas intermitentes de conectividade através do cluster devido à verificação de checksum L4 ativo no Pod da ACI

Sintoma

- Problemas intermitentes de conectividade por meio do cluster ASA/FTD implantado em um Pod da ACI.

- Se houver apenas uma unidade no cluster, os problemas de conectividade não serão observados.

- Os pacotes enviados de uma unidade de cluster para uma ou mais outras unidades no cluster não são visíveis no FXOS e nas capturas de plano de dados das unidades de destino.

Atenuação

- O tráfego redirecionado sobre o link de controle do cluster não tem uma soma de verificação L4 correta e esse é o comportamento esperado. Os switches no caminho do link de controle de cluster não devem verificar a soma de verificação L4. Os switches que verificam a soma de verificação L4 podem fazer com que o tráfego seja descartado. Verifique a configuração do switch de estrutura da ACI e certifique-se de que nenhuma soma de verificação L4 seja executada nos pacotes recebidos ou enviados através do link de controle de cluster.

Problemas do plano de controle de cluster

Unidade não pode ingressar no cluster

Tamanho da MTU no CCL

Sintomas

A unidade não pode ingressar no cluster e esta mensagem é mostrada:

The slave has left the cluster because application configuration sync is timed out on this unit. Disabling cluster now!

Cluster disable is performing cleanup..done.

Unit unit-2-1 is quitting due to system failure for 1 time(s) (last failure is Slave application configuration sync timeout). Rejoin will be attempted after 5 minutes.

All data interfaces have been shutdown due to clustering being disabled. To recover either enable clustering or remove cluster group configuration.

Verificação/Mitigação

- Use o comando show interface no FTD para verificar se o MTU na interface de link de controle de cluster é pelo menos 100 bytes maior que o MTU da interface de dados:

firepower# show interface

Interface Port-channel1 "Inside", is up, line protocol is up

Hardware is EtherSVI, BW 40000 Mbps, DLY 10 usec

MAC address 3890.a5f1.aa5e, MTU 9084

Interface Port-channel48 "cluster", is up, line protocol is up

Hardware is EtherSVI, BW 40000 Mbps, DLY 10 usec

Description: Clustering Interface

MAC address 0015.c500.028f, MTU 9184

IP address 127.2.2.1, subnet mask 255.255.0.

- Faça um ping através do CCL, com a opção size, para verificar se a configuração no CCL MTU está configurada corretamente em todos os dispositivos no caminho.

firepower# ping 127.2.1.1 size 9184

- Use o comando show interface no switch para verificar a configuração de MTU

Switch# show interface

port-channel12 is up

admin state is up,

Hardware: Port-Channel, address: 7069.5a3a.7976 (bia 7069.5a3a.7976)

MTU 9084 bytes, BW 40000000 Kbit , DLY 10 usec

port-channel13 is up

admin state is up,

Hardware: Port-Channel, address: 7069.5a3a.7967 (bia 7069.5a3a.7967)

MTU 9084 bytes, BW 40000000 Kbit , DLY 10 use

Incompatibilidade de interface entre unidades de cluster

Sintomas

A unidade não pode ingressar no cluster e esta mensagem é mostrada:

Interface mismatch between cluster master and joining unit unit-2-1. unit-2-1 aborting cluster join.

Cluster disable is performing cleanup..done.

Unit unit-2-1 is quitting due to system failure for 1 time(s) (last failure is Internal clustering error). Rejoin will be attempted after 5 minutes.

All data interfaces have been shutdown due to clustering being disabled. To recover either enable clustering or remove cluster group configuration.

Verificação/Mitigação

Faça login na GUI do FCM em cada chassi, navegue até a guia Interfaces e verifique se todos os membros do cluster têm a mesma configuração de interface:

- Interfaces atribuídas ao dispositivo lógico

- Velocidade de administração das interfaces

- Duplex administrativo das interfaces

- Status da interface

Problema de interface de canal de porta/dados

Divisão do cérebro devido a problemas de acessibilidade no CCL

Sintoma

Há várias unidades de controle no cluster. Considere esta topologia:

Gabinete 1:

firepower# show cluster info

Cluster ftd_cluster1: On

Interface mode: spanned

This is "unit-1-1" in state MASTER

ID : 0

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2103TU5H

CCL IP : 127.2.1.1

CCL MAC : 0015.c500.018f

Last join : 07:30:25 UTC Dec 14 2020

Last leave: N/A

Other members in the cluster:

Unit "unit-1-2" in state SLAVE

ID : 1

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2103TU4D

CCL IP : 127.2.1.2

CCL MAC : 0015.c500.019f

Last join : 07:30:26 UTC Dec 14 2020

Last leave: N/A

Unit "unit-1-3" in state SLAVE

ID : 3

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2102THJT

CCL IP : 127.2.1.3

CCL MAC : 0015.c500.016f

Last join : 07:31:49 UTC Dec 14 2020

Last leave: N/A

Gabinete 2:

firepower# show cluster info

Cluster ftd_cluster1: On

Interface mode: spanned

This is "unit-2-1" in state MASTER

ID : 4

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2103TUN1

CCL IP : 127.2.2.1

CCL MAC : 0015.c500.028f

Last join : 11:21:56 UTC Dec 23 2020

Last leave: 11:18:51 UTC Dec 23 2020

Other members in the cluster:

Unit "unit-2-2" in state SLAVE

ID : 2

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2102THR9

CCL IP : 127.2.2.2

CCL MAC : 0015.c500.029f

Last join : 11:18:58 UTC Dec 23 2020

Last leave: 22:28:01 UTC Dec 22 2020

Unit "unit-2-3" in state SLAVE

ID : 5

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2103TUML

CCL IP : 127.2.2.3

CCL MAC : 0015.c500.026f

Last join : 11:20:26 UTC Dec 23 2020

Last leave: 22:28:00 UTC Dec 22 2020

Verificação

- Use o comando ping para verificar a conectividade entre os endereços IP do link de controle de cluster (CCL) das unidades de controle:

firepower# ping 127.2.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 127.2.1.1, timeout is 2 seconds:

?????

Success rate is 0 percent (0/5)

- Verifique a tabela ARP:

firepower# show arp

cluster 127.2.2.3 0015.c500.026f 1

cluster 127.2.2.2 0015.c500.029f 1

- Nas unidades de controle, configure e verifique capturas nas interfaces CCL:

firepower# capture capccl interface cluster

firepower# show capture capccl | i 127.2.1.1

2: 12:10:57.652310 arp who-has 127.2.1.1 tell 127.2.2.1

41: 12:11:02.652859 arp who-has 127.2.1.1 tell 127.2.2.1

74: 12:11:07.653439 arp who-has 127.2.1.1 tell 127.2.2.1

97: 12:11:12.654018 arp who-has 127.2.1.1 tell 127.2.2.1

126: 12:11:17.654568 arp who-has 127.2.1.1 tell 127.2.2.1

151: 12:11:22.655148 arp who-has 127.2.1.1 tell 127.2.2.1

174: 12:11:27.655697 arp who-has 127.2.1.1 tell 127.2.2.1

Atenuação

- Certifique-se de que as interfaces de canal de porta do CCL estejam conectadas a interfaces de canal de porta separadas no switch.

- Quando canais de porta virtuais (vPC) forem usados em switches Nexus, certifique-se de que as interfaces de canal de porta do CCL estejam conectadas a diferentes vPCs e que a configuração do vPC não tenha o status de consistência com falha.

- Certifique-se de que as interfaces de canal de porta do CCL estejam no mesmo domínio de broadcast e que a VLAN do CCL seja criada e permitida nas interfaces.

Este é um exemplo de configuração de switch:

Nexus# show run int po48-49

interface port-channel48

description FPR1

switchport access vlan 48

vpc 48

interface port-channel49

description FPR2

switchport access vlan 48

vpc 49

Nexus# show vlan id 48

VLAN Name Status Ports

---- ----------- --------- -------------------------------

48 CCL active Po48, Po49, Po100, Eth1/53, Eth1/54

VLAN Type Vlan-mode

---- ----- ----------

48 enet CE

1  Po1  up success success 10,20

48 Po48 up success success 48

49 Po49 up success success 48

Nexus1# show vpc brief

Legend:

(*) - local vPC is down, forwarding via vPC peer-link

vPC domain id : 1

Peer status : peer adjacency formed ok

vPC keep-alive status : peer is alive

Configuration consistency status : success

Per-vlan consistency status : success

Type-2 consistency status : success

vPC role : primary

Number of vPCs configured : 3

Peer Gateway : Disabled

Dual-active excluded VLANs : -

Graceful Consistency Check : Enabled

Auto-recovery status : Disabled

Delay-restore status : Timer is off.(timeout = 30s)

Delay-restore SVI status : Timer is off.(timeout = 10s)

vPC Peer-link status

---------------------------------------------------------------------

id Port Status Active vlans

-- ---- ------ --------------------------------------------------

1 Po100 up 1,10,20,48-49,148

vPC status

----------------------------------------------------------------------

id Port Status Consistency Reason Active vlans

-- ---- ------ ----------- ------ ------------

1 Po1 up success success 10,20

48 Po48 up success success 48

49 Po49 up success success 48

Cluster desativado devido a interfaces suspensas de canal de porta de dados

Sintoma

Uma ou mais interfaces de canal de porta de dados estão suspensas. Quando uma interface de dados habilitada administrativamente é suspensa, todas as unidades de cluster no mesmo chassi são expulsas do cluster devido à falha na verificação de integridade da interface.

Considere esta topologia:

Verificação

- Verifique o console da unidade de controle:

firepower#

Beginning configuration replication to Slave unit-2-2

End Configuration Replication to slave.

Asking slave unit unit-2-2 to quit because it failed interface health check 4 times (last failure on Port-channel1). Clustering must be manually enabled on the unit to rejoin.

- Verifique a saída dos comandos show cluster history e show cluster info trace module hc na(s) unidade(s) afetada(s):

firepower# Unit is kicked out from cluster because of interface health check failure.

Cluster disable is performing cleanup..done.

All data interfaces have been shutdown due to clustering being disabled. To recover either enable clustering or remove cluster group configuration.

Cluster unit unit-2-1 transitioned from SLAVE to DISABLED

firepower# show cluster history

==========================================================================

From State To State Reason

==========================================================================

12:59:37 UTC Dec 23 2020

ONCALL SLAVE_COLD Received cluster control message

12:59:37 UTC Dec 23 2020

SLAVE_COLD SLAVE_APP_SYNC Client progression done

13:00:23 UTC Dec 23 2020

SLAVE_APP_SYNC SLAVE_CONFIG Slave application configuration sync done

13:00:35 UTC Dec 23 2020

SLAVE_CONFIG SLAVE_FILESYS Configuration replication finished

13:00:36 UTC Dec 23 2020

SLAVE_FILESYS SLAVE_BULK_SYNC Client progression done

13:01:35 UTC Dec 23 2020

SLAVE_BULK_SYNC DISABLED Received control message DISABLE (interface health check failure)

firepower# show cluster info trace module hc

Dec 23 13:01:36.636 [INFO]cluster_fsm_clear_np_flows: The clustering re-enable timer is started to expire in 598000 ms.

Dec 23 13:01:32.115 [INFO]cluster_fsm_disable: The clustering re-enable timer is stopped.

Dec 23 13:01:32.115 [INFO]Interface Port-channel1 is down

- Verifique a saída do comando show port-channel summary no shell de comando fxos:

FPR2(fxos)# show port-channel summary

Flags: D - Down P - Up in port-channel (members)

I - Individual H - Hot-standby (LACP only)

s - Suspended r - Module-removed

S - Switched R - Routed

U - Up (port-channel)

M - Not in use. Min-links not met

--------------------------------------------------------------------------

Group Port-Channel Type Protocol Member Ports

--------------------------------------------------------------------------

1 Po1(SD) Eth LACP Eth2/1(s) Eth2/2(s) Eth2/3(s) Eth2/4(s)

48 Po48(SU) Eth LACP Eth3/1(P) Eth3/2(P) Eth3/3(P) Eth3/4(P)

Atenuação

- Verifique se todos os chassis têm o mesmo nome de grupo de cluster e senha.

- Assegure-se de que as interfaces do canal de porta tenham ativadas administrativamente interfaces de membro físico com a mesma configuração duplex/velocidade em todos os chassis e switches.

- Em clusters entre locais, certifique-se de que a mesma interface de canal de porta de dados em todos os chassis esteja conectada à mesma interface de canal de porta no switch.

- Quando canais de porta virtuais (vPC) forem usados em switches Nexus, verifique se a configuração do vPC não tem o status de consistência com falha.

- Em clusters entre locais, certifique-se de que a mesma interface de canal de porta de dados em todos os chassis esteja conectada ao mesmo vPC.

Problemas de estabilidade do cluster

Rastreamento FXOS

Sintoma

A unidade sai do cluster.

Verificação/Mitigação

- Use o comando show cluster history para ver quando a unidade deixou o cluster

firepower# show cluster history

- Use estes comandos para verificar se o FXOS tinha um retorno de rastreamento

FPR4150# connect local-mgmt

FPR4150 (local-mgmt)# dir cores

- Colete o arquivo central gerado quando a unidade deixou o cluster e forneça-o ao TAC.

Disco cheio

Caso a utilização do disco na partição /ngfw de uma unidade de cluster atinja 94%, a unidade sai do cluster. A verificação de utilização do disco ocorre a cada 3 segundos:

> show disk

Filesystem Size Used Avail Use% Mounted on

rootfs 81G 421M 80G 1% /

devtmpfs 81G 1.9G 79G 3% /dev

tmpfs 94G 1.8M 94G 1% /run

tmpfs 94G 2.2M 94G 1% /var/volatile

/dev/sda1 1.5G 156M 1.4G 11% /mnt/boot

/dev/sda2 978M 28M 900M 3% /opt/cisco/config

/dev/sda3 4.6G 88M 4.2G 3% /opt/cisco/platform/logs

/dev/sda5 50G 52M 47G 1% /var/data/cores

/dev/sda6 191G 191G 13M 100% /ngfw

cgroup_root 94G 0 94G 0% /dev/cgroups

Nesse caso, a saída show cluster history mostra:

15:36:10 UTC May 19 2021

MASTER MASTER Event: Master unit unit-1-1 is quitting

due to diskstatus Application health check failure, and

master's application state is down

or

14:07:26 CEST May 18 2021

SLAVE DISABLED Received control message DISABLE (application health check failure)

Outra forma de verificar a falha é:

firepower# show cluster info health

Member ID to name mapping:

0 - unit-1-1(myself) 1 - unit-2-1

0   1

Port-channel48 up up

Ethernet1/1 up up

Port-channel12 up up

Port-channel13 up up

Unit overall            healthy healthy

Service health status:

0       1

diskstatus (monitor on) down down

snort (monitor on)      up      up

Cluster overall         healthy

Além disso, se o disco for ~100%, a unidade pode ter dificuldades para voltar ao cluster até que haja algum espaço em disco liberado.

Proteção contra estouro

A cada 5 minutos, cada unidade de cluster verifica a utilização da CPU e da memória nas unidades local e peer. Se a utilização exceder os limites do sistema (CPU LINA 50% ou memória LINA 59%), uma mensagem informativa será mostrada em:

- Syslogs (FTD-6-748008)

- Arquivo log/cluster_trace.log, por exemplo

firepower# more log/cluster_trace.log | i CPU

May 20 16:18:06.614 [INFO][CPU load 87% | memory load 37%] of module 1 in chassis 1 (unit-1-1) exceeds overflow protection threshold [CPU 50% | Memory 59%]. System may be oversubscribed on member failure.

May 20 16:18:06.614 [INFO][CPU load 87% | memory load 37%] of chassis 1 exceeds overflow protection threshold [CPU 50% | Memory 59%]. System may be oversubscribed on chassis failure.

May 20 16:23:06.644 [INFO][CPU load 84% | memory load 35%] of module 1 in chassis 1 (unit-1-1) exceeds overflow protection threshold [CPU 50% | Memory 59%]. System may be oversubscribed on member failure.

A mensagem indica que, em caso de falha da unidade, os recursos da(s) unidade(s) restante(s) podem ser sobrecarregados.

Modo simplificado

Comportamento em versões FMC anteriores a 6.3

- Você registra cada nó de cluster individualmente no FMC.

- Em seguida, você forma um cluster lógico no FMC.

- Para cada adição de nó de cluster novo, você deve registrar manualmente o nó.

FMC pós-6.3

- O recurso de modo simplificado permite registrar todo o cluster no FMC em uma etapa (registre qualquer nó do cluster).

Gerenciador mínimo suportado

Dispositivos gerenciados

Versão mínima do dispositivo gerenciado suportado necessária

Notas

FMC 6.3

Clusters FTD apenas no FP9300 e FP4100

6.2.0

Este é apenas um recurso FMC

aviso: Depois que o cluster for formado no FTD, você precisará aguardar o início do registro automático. Você não deve tentar registrar os nós de cluster manualmente (Adicionar dispositivo), mas usar a opção Reconcile.

Sintoma

Falhas de registro de nó

- Se o registro do nó de controle falhar por qualquer motivo, o cluster será excluído do FMC.

Atenuação

Se o registro de nó de dados falhar por qualquer motivo, há duas opções:

1. Com cada implantação no cluster, o FMC verifica se há nós de cluster que precisam ser registrados e, em seguida, inicia o registro automático desses nós.

2. Há uma opção Reconciliar disponível na guia Resumo do cluster (Dispositivos > Gerenciamento de dispositivos > guia Cluster > Exibir link Status do cluster). Quando a ação Reconcile é acionada, o FMC inicia o registro automático dos nós que precisam ser registrados.

Informações Relacionadas

- Clustering da Firepower Threat Defense

- Cluster ASA para o chassi Firepower 4100/9300

- Sobre clusters no chassi do Firepower 4100/9300

- Mergulho profundo no cluster NGFW Firepower - BRKSEC-3032

- Analisar as capturas do Firepower Firewall para solucionar problemas de rede com eficiência