Problemen oplossen met Firepower Threat Defense (FTD)-cluster

Inleiding

In dit document wordt beschreven hoe problemen met een clusterconfiguratie in de Next-Generation Firewall (NGFW) van Firepower kunnen worden opgelost.

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van deze onderwerpen (zie de sectie Verwante informatie voor links):

• Firepower-platformarchitectuur
• Configuratie en werking van Firepower Cluster
• Bekendheid met de FTD en Firepower Extensible Operating System (FXOS) CLI
• Logboeken NGFW/gegevensvlak
• NGFW/data plane packet-tracer
• FXOS/gegevensvlak vastleggen

Gebruikte componenten

• HW: Firepower 4125
• SW: 6.7.0 (Build 65) – gegevensvlak 9.15(1)

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

De meeste items die in dit document worden behandeld, zijn ook volledig van toepassing op de probleemoplossing van het cluster Adaptive Security Appliance (ASA).

Configureren

Het configuratiegedeelte van een clusterimplementatie wordt behandeld in de configuratiehandleidingen van de FMC en FXOS:

• Clustering voor de verdediging tegen vuurkracht
• Een cluster implementeren voor Firepower Threat Defense voor schaalbaarheid en hoge beschikbaarheid

Basisprincipes clusters

NGFW-architectuur

Het is belangrijk om te begrijpen hoe een Firepower 41xx- of 93xx-reeks met doorvoerpakketten omgaat:

1. Een pakket komt de ingangsinterface binnen en wordt afgehandeld door de interne switch van het chassis.
2. Het pakket gaat via de Smart NIC. Als de stroom wordt uitgeladen (HW-versnelling), wordt het pakket alleen door de Smart NIC afgehandeld en vervolgens teruggestuurd naar het netwerk.
3. Als het pakket niet wordt gelost, komt het in het FTD-gegevensvlak dat voornamelijk L3 / L4-controles uitvoert.
4. Als het beleid dit vereist, wordt het pakket geïnspecteerd door de Snort-motor (voornamelijk L7-inspectie).
5. De Snort-engine geeft een oordeel (bijvoorbeeld toestaan of blokkeren) voor het pakket.
6. Het gegevensvlak laat het pakket vallen of doorsturen op basis van het oordeel van Snort.
7. Het pakket verlaat het chassis via de interne switch van het chassis.

Clusteropnamen

Vuurkrachtapparaten bieden meerdere opnamepunten die zicht bieden op de doorvoerstromen. Wanneer u problemen oplost en clustervastleggingen inschakelt, zijn de belangrijkste uitdagingen:

• Het aantal opnames neemt toe naarmate het aantal eenheden in het cluster toeneemt.
• U moet zich bewust zijn van de manier waarop het cluster een specifieke stroom verwerkt om het pakket door het cluster te kunnen volgen.

Dit diagram toont een cluster met 2 eenheden (bijvoorbeeld FP941xx/FP9300):

In het geval van een asymmetrische TCP-verbinding ziet een TCP SYN, SYN/ACK-uitwisseling er als volgt uit:

Voorwaarts verkeer:

1. TCP-SYN wordt verzonden van host-A naar host-B.
2. TCP SYN arriveert op het chassis (een van de leden van Po1).
3. TCP SYN wordt via een van de backplaneinterfaces van het chassis (bijvoorbeeld E1/9, E1/10, enz.) naar het gegevensvlak verzonden.
4. TCP SYN arriveert op de ingangsinterface van het gegevensvlak (Po1.201/INSIDE). In dit voorbeeld neemt unit1-1 het eigendom van de stroom, doet Initial Sequence Number (ISN) randomisatie en codeert de eigendoms (cookie) informatie in Seq-nummer.
5. TCP SYN wordt verzonden vanuit Po1.202/OUTSIDE (data plane egress interface).
6. TCP SYN arriveert op een van de backplane-interfaces van het chassis (bijvoorbeeld E1/9, E1/10, enz.).
7. TCP SYN wordt vanuit de fysieke interface van het chassis (een van de leden van Po1) naar Host-B gestuurd.

Terugkeerverkeer:

8. TCP SYN/ACK wordt verzonden vanaf Host-B en arriveert op unit-2-1 (een van de leden van Po1).
9. TCP SYN/ACK wordt via een van de backplane-interfaces van het chassis (bijvoorbeeld E1/9, E1/10, enz.) naar het gegevensvlak verzonden.
10. TCP SYN/ACK arriveert op de ingangsinterface van het gegevensvlak (Po1.202/OUTSIDE).
11. TCP SYN/ACK wordt verzonden vanuit Cluster Control Link (CCL) naar unit-1-1. ISN is standaard ingeschakeld. Zo vindt de expediteur de eigenaarsinfo voor TCP SYN+ACK's zonder de betrokkenheid van de directeur. Voor andere pakketten of wanneer ISN is uitgeschakeld, wordt de regisseur gevraagd.
12. TCP SYN/ACK arriveert op een van de backplane-interfaces van het chassis (bijvoorbeeld E1/9, E1/10, enzovoort).
13. TCP SYN/ACK wordt vanuit de fysieke interface van het chassis (een van de leden van Po48) naar unit-1-1 gestuurd.
14. TCP SYN/ACK arriveert op unit-1-1 (een van de leden van Po48).
15. TCP SYN/ACK wordt via een van de backplane-interfaces van het chassis doorgestuurd naar de CCL-poort-kanaalinterface (nameif cluster) van het gegevensvlak.
16. Het gegevensvlak injecteert het TCP SYN/ACK-pakket opnieuw in de interface van het gegevensvlak Po1.202/OUTSIDE.
17. TCP SYN/ACK wordt verzonden vanuit Po1.201/INSIDE (data plane egress interface) naar HOST-A.
18. De TCP SYN/ACK doorkruist een van de backplane-interfaces van het chassis (bijvoorbeeld E1/9, E1/10, enz.) en schakelt een van de leden van Po1 uit.
19. TCP SYN/ACK komt op Host-A.

Lees voor meer informatie over dit scenario het gerelateerde gedeelte in de casestudy's van de vestiging van clusterverbindingen.

Op basis van deze pakketuitwisseling zijn alle mogelijke clusteropnamepunten:

Voor het voorwaartse verkeer (bijvoorbeeld TCP SYN) vastleggen op:

1. De fysieke interface van het chassis (bijvoorbeeld Po1-leden). Deze opname wordt geconfigureerd vanuit de Chassis Manager (CM) UI of de CM CLI.
2. Interface voor gegevensinvoer (bijvoorbeeld Po1.201 INSIDE).
3. Gegevensvlak uitgang interface (bijvoorbeeld Po1.202 BUITEN).
4. Chassis backplane-interfaces. Op FP4100 zijn er 2 backplane interfaces. Op FP9300 zijn er in totaal 6 (2 per module). Aangezien u niet weet in welke interface het pakket arriveert, moet u het vastleggen op alle interfaces inschakelen.

Voor het retourverkeer (bijvoorbeeld TCP SYN/ACK) op:

5. De fysieke interface van het chassis (bijvoorbeeld Po1-leden). Deze opname wordt geconfigureerd vanuit de Chassis Manager (CM) UI of de CM CLI.
6. Interface voor gegevensinvoer (bijvoorbeeld Po1.202 OUTSIDE).
7. Aangezien het pakket wordt omgeleid, is het volgende opnamepunt het gegevensvlak CCL.
8. Chassis backplane-interfaces. Nogmaals, u moet het vastleggen op beide interfaces inschakelen.
9. Unit-1-1 chassis CCL-ledeninterfaces.
10. Data plane CCL-interface (naam van cluster).
11. Ingress interface (Po1.202 BUITEN). Dit is het opnieuw geïnjecteerde pakket van CCL naar het gegevensvlak.
12. Data plane-uitgang-interface (bijvoorbeeld Po1.201 INSIDE).
13. Chassis backplane-interfaces.

Hoe de clusteropnamen in te schakelen

FXOS-opnamen

Het proces wordt beschreven in de FXOS Config Guide: Packet Capture

Opmerking: FXOS-opnamen kunnen alleen vanuit het oogpunt van de interne switch in de ingangsrichting worden gemaakt.

Opnamen van gegevensvlak

De aanbevolen manier om vastleggen op alle clusterleden in te schakelen, is met de opdracht clusterexec.

Overweeg een cluster met drie eenheden:

Gebruik deze opdracht om te controleren of alle clustereenheden actieve opnamen bevatten:

firepower# cluster exec show capture
unit-1-1(LOCAL):******************************************************

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

unit-3-1:*************************************************************
firepower#

Om een data plane capture op alle eenheden op Po1.201 (INSIDE) mogelijk te maken:

firepower# cluster exec capture CAPI interface INSIDE

Het wordt ten zeerste aanbevolen om een opnamefilter op te geven en, als u veel verkeer verwacht, de opnamebuffer te verhogen:

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

Verificatie:

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

De inhoud van alle opnamen bekijken (deze uitvoer kan erg lang zijn):

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

Sporen vastleggen

Als u wilt zien hoe de ingangspakketten worden afgehandeld door het gegevensvlak op elke eenheid, gebruikt u het trefwoord trace. Dit traceert de eerste 50 ingresspakketten. U kunt maximaal 1000 ingress-pakketten traceren.

Opmerking: als u meerdere opnamen hebt toegepast op een interface, kunt u slechts één pakket één keer traceren.

Om de eerste 1000 ingresspakketten op de interface OUTSIDE op alle clustereenheden te traceren:

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

Zodra u de interessestroom hebt vastgelegd, moet u ervoor zorgen dat u de interessepakketten op elke eenheid traceert. Het belangrijkste om te onthouden is dat een specifiek pakket # 1 kan zijn op unit-1-1, maar # 2 op een andere unit, enzovoort.

In dit voorbeeld kunt u zien dat de SYN / ACK is pakket # 2 op unit-2-1, maar pakket # 1 op unit-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>

Pakket nr. 2 (SYN/ACK) op de lokale eenheid traceren:

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
...

Hetzelfde pakket (SYN/ACK) op de externe eenheid traceren:

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
...

CCL-opname

Opname inschakelen op de CCL-koppeling (op alle eenheden):

firepower# cluster exec capture CCL interface cluster
unit-1-1(LOCAL):******************************************************

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

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

Hide opnieuw injecteren

Standaard worden bij een opname die is ingeschakeld op een gegevensinterface van een gegevensvlak alle pakketten weergegeven:

• Degenen die uit het fysieke netwerk komen
• Degenen die opnieuw worden geïnjecteerd uit de CCL

Als u de opnieuw geïnjecteerde pakketten niet wilt zien, gebruikt u de optie opnieuw injecteren verbergen. Dit kan handig zijn als u wilt controleren of een stroom asymmetrisch is:

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

Deze opname laat alleen zien wat de lokale eenheid daadwerkelijk ontvangt op de specifieke interface rechtstreeks van het fysieke netwerk, en niet van de andere clustereenheden.

ASP Drops

Als u wilt controleren op softwaredruppels voor een specifieke stroom, kunt u asp-drop vastleggen inschakelen. Als u niet weet op welke dropreden u zich moet concentreren, gebruikt u het zoekwoord allemaal. Bovendien, als u niet geïnteresseerd bent in de pakketlading, kunt u het trefwoord voor alleen headers opgeven. Hiermee kunt u 20-30 keer meer pakketten vastleggen:

firepower# cluster exec cap ASP type asp-drop all buffer 33554432 headers-only
unit-1-1(LOCAL):******************************************************

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

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

Daarnaast kunt u de IP's opgeven die van belang zijn voor de ASP-vastlegging:

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

Een vastlegging wissen

De buffer vrijmaken van elke opname die in alle clustereenheden wordt uitgevoerd. Dit stopt de opnames niet, maar ruimt alleen de buffers op:

firepower# cluster exec clear capture /all
unit-1-1(LOCAL):******************************************************

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

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

Een opname stoppen

Er zijn 2 manieren om actieve vastlegging op alle clustereenheden te stoppen. Later kun je weer verder.

Manier 1:

firepower# cluster exec cap CAPI stop
unit-1-1(LOCAL):******************************************************

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

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

Om te hervatten:

firepower# cluster exec no capture CAPI stop
unit-1-1(LOCAL):******************************************************

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

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

Manier 2:

firepower# cluster exec no capture CAPI interface INSIDE
unit-1-1(LOCAL):******************************************************

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

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

Om te hervatten:

firepower# cluster exec capture CAPI interface INSIDE
unit-1-1(LOCAL):******************************************************

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

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

Verzamel een opname

Er zijn meerdere manieren om een opname te exporteren.

Manier 1 - Naar een externe server:

Hiermee kunt u een opname uploaden van het gegevensvlak naar een externe server (bijvoorbeeld TFTP). De namen van de vastlegging worden automatisch gewijzigd om de broneenheid weer te geven:

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 !

De geüploade pcap-bestanden:

Way 2 - Haal de opnames op bij het FMC:

Dit is alleen van toepassing op FTD. Eerst kopieert u de opname naar de FTD-schijf:

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

Kopieer het bestand vanuit de expertmodus van /mnt/disk0/ naar /ngfw/var/common/ directory:

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

Navigeer ten slotte op FMC naar Systeem > Gezondheid > sectie Monitor. Kies Systeem bekijken en problemen oplossen > Geavanceerde probleemoplossing en haal het vastleggingsbestand op:

Een opname verwijderen

Als u een opname uit alle clustereenheden wilt verwijderen, gebruikt u deze opdracht:

firepower# cluster exec no capture CAPI
unit-1-1(LOCAL):******************************************************

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

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

geoffloade stromen

Op FP41xx/FP9300 kunnen stromen worden overgeladen naar HW Accelerator, hetzij statisch (bijvoorbeeld Fastpath-regels) of dynamisch. Raadpleeg dit document voor meer informatie over flow-offload: Verduidelijking van FTD-beleidsregels voor toegangscontrole.

Als een stroom wordt uitgeladen, gaan er maar een paar pakketten door het FTD-gegevensvlak. De rest wordt afgehandeld door de HW-versneller (Smart NIC).

Vanuit het oogpunt van vastleggen betekent dit dat als u alleen FTD-opnamen op gegevensniveau inschakelt, u niet alle pakketten ziet die door het apparaat gaan. In dit geval moet u ook FXOS-opnamen op chassisniveau inschakelen.

CCL-berichten (Cluster Control Link)

Als u een opname maakt op de CCL, merkt u dat de clustereenheden verschillende soorten berichten uitwisselen. De meest interessante zijn:

Cluster hartslag:

Berichten van het Cluster Control Point (CCP)

Naast de hartslagberichten zijn er een aantal clustercontroleberichten die in specifieke scenario’s via de CCL worden uitgewisseld. Sommige daarvan zijn unicast-berichten, terwijl andere uitzendingen zijn.

CLUSTER_QUIT_REASON_PRIMARY_UNIT_HC

Wanneer een eenheid 3 opeenvolgende hartslagberichten van de controlenode verliest, genereert deze een CLUSTER_QUIT_REASON_PRIMARY_UNIT_HC-bericht via de CCL. Dit bericht:

• Het is een unicast.
• Het wordt verzonden naar elk van de eenheden met een interval van 1 sec.
• Wanneer een eenheid dit bericht ontvangt, sluit het cluster (UITGESCHAKELD) en wordt opnieuw lid.

V. Wat is het doel van de CLUSTER_QUIT_REASON_PRIMARY_UNIT_HC?

A. Vanuit het oogpunt van unit-3-1 (Site-B) verliest het de verbinding met zowel unit-1-1 als unit-2-1 van site A, dus het moet ze zo snel mogelijk uit zijn ledenlijst verwijderen, anders kan het pakket verloren gaan als unit-2-1 nog steeds in zijn ledenlijst staat en unit-2-1 toevallig een regisseur van een verbinding is en de stroomquery naar unit-2-1 mislukt.

CLUSTER_QUIT_REASON_UNIT_HC

Wanneer de control node 3 opeenvolgende hartslagberichten verliest van een data node, stuurt deze een CLUSTER_QUIT_REASON_UNIT_HC bericht over de CCL. Dit bericht is unicast.

CLUSTER_QUIT_REASON_STRAY_MEMBER

Wanneer een gesplitste partitie opnieuw verbinding maakt met een peer-partitie, wordt het nieuwe gegevensknooppunt door de dominante besturingseenheid behandeld als een verdwaald lid en ontvangt het een CCP-stopbericht met de reden CLUSTER_QUIT_REASON_STRAY_MEMBER.

CLUSTER_QUIT_MEMBER_DROPOUT

Een broadcast-bericht dat wordt gegenereerd door een gegevensknooppunt en wordt verzonden als een uitzending. Zodra een eenheid dit bericht ontvangt, gaat deze naar de status UITGESCHAKELD. Bovendien wordt automatisch opnieuw lid worden niet afgetrapt:

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

De clustergeschiedenis laat zien:

PRIMARY       DISABLED      Received control message DISABLE (member dropout announcement)

Cluster Health Check (HC)-mechanisme

Hoofdpunten:

• Elke clustereenheid verzendt een hartslag om de 1/3 van de wachttijd voor de gezondheidscontrole naar alle andere eenheden (uitgezonden op 255.255.255.255) en gebruikt UDP-poort 49495 als transport over de CCL.
• Elke clustereenheid volgt onafhankelijk elke andere eenheid met een poll-timer en een poll-telwaarde.
• Als een clustereenheid binnen een hartslaginterval geen pakket (hartslag of gegevenspakket) ontvangt van een clusterpeer-eenheid, wordt de waarde voor het aantal polls verhoogd.
• Wanneer de waarde voor het aantal peilingen voor een cluster-peereenheid 3 wordt, wordt de peer als omlaag beschouwd.
• Wanneer een hartslag wordt ontvangen, wordt het volgnummer gecontroleerd en in het geval dat het verschil met de eerder ontvangen hartslag anders is dan 1, neemt de hartslagvalteller dienovereenkomstig toe.
• Als de teller voor het aantal polls voor een clusterpeer anders is dan 0 en de peer een pakket ontvangt, wordt de teller teruggezet naar een waarde van 0.

Gebruik deze opdracht om de statustellers van het cluster te controleren:

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|
----------------------------------------------------------------------------------

Beschrijving van de belangrijkste kolommen:

U kunt de tellers als volgt resetten:

firepower# clear cluster info health details

V. Hoe de frequentie van de hartslag te controleren?

A. Controleer de gemiddelde waarde van de tussenruimte:

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|
----------------------------------------------------------------------------------

V. Hoe kunt u de wachttijd van het cluster op FTD wijzigen?

A. FlexConfig gebruiken.

V. Wie wordt het controleknooppunt na een split-brain?

De eenheid met de hoogste prioriteit (laagste aantal):

firepower# show run cluster | include priority
priority 9

Controleer HC-faalscenario 1 voor meer details.

Het HC-mechanisme voor clustervisualisatie

Indicatieve timers: De min en max zijn afhankelijk van de laatst ontvangen CCL-pakketaankomst.

Cluster HC-storingsscenario's

Het doel van deze sectie is om aan te tonen:

• Verschillende HC-faalscenario's voor clusters.
• Hoe de verschillende logs en commando-uitgangen kunnen worden gecorreleerd.

Topologie

Clusterconfiguratie:

cluster group GROUP1
 key *****
 local-unit unit-1-1
 cluster-interface Port-channel48 ip 10.17.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 10.17.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 10.17.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

Clusterstatus:

firepower# show cluster info
Cluster GROUP1: On
    Interface mode: spanned
    This is "unit-1-1" in state PRIMARY
        ID        : 0
        Site ID   : 1
        Version   : 9.12(2)33
        Serial No.: FCH22247LNK
        CCL IP    : 10.17.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 secondary
        ID        : 1
        Site ID   : 2
        Version   : 9.12(2)33
        Serial No.: FCH22247MKJ
        CCL IP    : 10.17.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 SECONDARY
        ID        : 2
        Site ID   : 1
        Version   : 9.12(2)33
        Serial No.: FCH23157Y9N
        CCL IP    : 10.17.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 SECONDARY
        ID        : 2
        Site ID   : 1
        Version   : 9.12(2)33
        Serial No.: FCH23157Y9N
        CCL IP    : 10.17.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 PRIMARY
        ID        : 0
        Site ID   : 1
        Version   : 9.12(2)33
        Serial No.: FCH22247LNK
        CCL IP    : 10.17.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 SECONDARY
        ID        : 1
        Site ID   : 2
        Version   : 9.12(2)33
        Serial No.: FCH22247MKJ
        CCL IP    : 10.17.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 SECONDARY
        ID        : 1
        Site ID   : 2
        Version   : 9.12(2)33
        Serial No.: FCH22247MKJ
        CCL IP    : 10.17.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 PRIMARY
        ID        : 0
        Site ID   : 1
        Version   : 9.12(2)33
        Serial No.: FCH22247LNK
        CCL IP    : 10.17.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 SECONDARY
        ID        : 2
        Site ID   : 1
        Version   : 9.12(2)33
        Serial No.: FCH23157Y9N
        CCL IP    : 10.17.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

Scenario 1 - CCL-communicatieverlies voor ~4+ seconden in beide richtingen

Voor de mislukking:

Na het herstel (geen wijzigingen in de eenheidsrollen):

analyse

De storing (CCL-communicatie ging verloren).

Het bericht op de console van het gegevensvlak op unit-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 SECONDARY to PRIMARY
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.

Eenheid-1-1-clustertraceringslogs:

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 'SECONDARY heartbeat failure' for member unit-3-1 (ID: 1).

Gespleten hersenen:

firepower# show cluster info
Cluster GROUP1: On
    Interface mode: spanned
    This is "unit-1-1" in state PRIMARY
        ID        : 0
        Site ID   : 1
        Version   : 9.12(2)33
        Serial No.: FCH22247LNK
        CCL IP    : 10.17.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 SECONDARY
        ID        : 2
        Site ID   : 1
        Version   : 9.12(2)33
        Serial No.: FCH23157Y9N
        CCL IP    : 10.17.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 SECONDARY
        ID        : 2
        Site ID   : 1
        Version   : 9.12(2)33
        Serial No.: FCH23157Y9N
        CCL IP    : 10.17.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 PRIMARY
        ID        : 0
        Site ID   : 1
        Version   : 9.12(2)33
        Serial No.: FCH22247LNK
        CCL IP    : 10.17.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 PRIMARY
        ID        : 1
        Site ID   : 2
        Version   : 9.12(2)33
        Serial No.: FCH22247MKJ
        CCL IP    : 10.17.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

Clustergeschiedenis:

09:38:16 UTC Nov 2 2020
SECONDARY                 PRIMARY_POST_CONFIG    Primary relinquished role

09:38:17 UTC Nov 2 2020
PRIMARY_POST_CONFIG    Primary               Primary post config done and waiting for ntfy

CCL-communicatieherstel

Unit-1-1 detecteert de huidige controlenode en aangezien unit-1-1 een hogere prioriteit heeft, stuurt een CLUSTER_QUIT_REASON_STRAY_MEMBER-bericht naar unit-3-1 om een nieuw selectieproces te starten. Eenheid-3-1 wordt uiteindelijk opnieuw toegevoegd als een gegevensknooppunt.

Wanneer een gesplitste partitie opnieuw verbinding maakt met een peer-partitie, wordt het gegevensknooppunt door het dominante controleknooppunt behandeld als een verdwaald lid en ontvangt het een CCP-stop msg met een reden van CLUSTER_QUIT_REASON_STRAY_MEMBER.

Unit-3-1 console logs show:
Cluster unit unit-3-1 transitioned from PRIMARY to DISABLED
The 3DES/AES algorithms require a Encryption-3DES-AES activation key.
Detected Cluster Primart.
Beginning configuration replication from Primary.
WARNING: Local user database is empty and there are still 'aaa' commands for 'LOCAL'.
..
Cryptochecksum (changed): a9ed686f 8e2e689c 2553a104 7a2bd33a
End configuration replication from Primary.
Cluster unit unit-3-1 transitioned from DISABLED to SECONDARY

Beide eenheden (unit-1-1 en unit-3-1) tonen in hun clusterlogboeken:

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 primary units. Primary role retained by unit-1-1, unit-3-1 will leave then join as a secondary
Nov 03 21:20:23.019 [CRIT]Found a split cluster with both unit-1-1 and unit-3-1 as primary units. Primary role retained by unit-1-1, unit-3-1 will leave then join as a secondary

Er zijn ook syslog-berichten gegenereerd voor de 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 primary units. Primary role retained by unit-1-1, unit-3-1 will leave then join as a secondary
Nov 03 2020 21:20:23: %FTD-4-747016: Clustering: Found a split cluster with both unit-1-1 and unit-3-1 as primary units. Primary role retained by unit-1-1, unit-3-1 will leave then join as a secondary

Clustergeschiedenis:

09:47:33 UTC Nov 2 2020
Primary          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              SECONDARY_COLD      Received cluster control message
09:47:38 UTC Nov 2 2020
SECONDARY_COLD            SECONDARY_APP_SYNC  Client progression done
09:48:18 UTC Nov 2 2020
SECONDARY_APP_SYNC        SECONDARY_CONFIG    SECONDARY application configuration sync done
09:48:29 UTC Nov 2 2020
SECONDARY_CONFIG          SECONDARY_FILESYS   Configuration replication finished
09:48:30 UTC Nov 2 2020
SECONDARY_FILESYS         SECONDARY_BULK_SYNC Client progression done
09:48:54 UTC Nov 2 2020
SECONDARY_BULK_SYNC       SECONDARY           Client progression done

Scenario 2 - CCL-communicatieverlies voor ~ 3-4 seconden in beide richtingen

Voor de mislukking:

Na het herstel (geen wijzigingen in de eenheidsrollen):

analyse

Gebeurtenis 1: De controlenode verliest 3 HC's van de unit-3-1 en stuurt een bericht naar unit-3-1 om het cluster te verlaten.

Gebeurtenis 2: De CCL herstelde zeer snel en het bericht CLUSTER_QUIT_REASON_STRAY_MEMBER van de control node bereikte de externe zijde. Unit-3-1 gaat direct naar DISABLED-modus en er is geen split-brain

Op unit-1-1 (controle) zie je:

firepower#
Asking SECONDARY unit unit-3-1 to quit because it failed unit health-check.
Forcing stray member unit-3-1 to leave the cluster

Op unit-3-1 (data node) zie je:

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 SECONDARY to DISABLED

Clustereenheid-3-1 wordt overgezet naar een UITGESCHAKELDE status en zodra de CCL-communicatie is hersteld, wordt deze opnieuw als een gegevensknooppunt toegevoegd:

firepower# show cluster history
20:58:40 UTC Nov 1 2020
SECONDARY                 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              SECONDARY_COLD            Received cluster control message
20:58:45 UTC Nov 1 2020
SECONDARY_COLD            SECONDARY_APP_SYNC        Client progression done
20:59:33 UTC Nov 1 2020
SECONDARY_APP_SYNC        SECONDARY_CONFIG          SECONDARY application configuration sync done
20:59:44 UTC Nov 1 2020
SECONDARY_CONFIG          SECONDARY_FILESYS         Configuration replication finished
20:59:45 UTC Nov 1 2020
SECONDARY_FILESYS         SECONDARY_BULK_SYNC       Client progression done
21:00:09 UTC Nov 1 2020
SECONDARY_BULK_SYNC       SECONDARY                 Client progression done

Scenario 3 - CCL-communicatieverlies voor ~ 3-4 seconden in beide richtingen

Voor de mislukking:

Na het herstel (de controlenode is gewijzigd):

analyse

1. CCL gaat naar beneden.
2. Unit-1-1 krijgt geen 3 HC-berichten van unit-3-1 en stuurt een QUIT-bericht naar unit-3-1. Dit bericht bereikt nooit eenheid-3-1.
3. Unit-3-1 stuurt een QUIT-bericht naar unit-2-1. Dit bericht bereikt nooit eenheid-2-1.

CCL herstelt.

4. Unit-1-1 ziet dat unit-3-1 zichzelf heeft geadverteerd als een control node en verzendt QUIT_REASON_STRAY_MEMBER bericht naar unit-3-1. Zodra unit-3-1 krijgt dit bericht gaat naar een UITGESCHAKELD staat. Tegelijkertijd stuurt unit-3-1 een QUIT_REASON_PRIMARY_UNIT_HC-bericht naar unit-1-1 en vraagt het om te stoppen. Zodra unit-1-1 dit bericht krijgt, gaat het naar een UITGESCHAKELDE status.

Clustergeschiedenis:

19:53:09 UTC Nov 2 2020
PRIMARY         DISABLED        Received control message DISABLE 
                                       (primary unit health check failure)
19:53:13 UTC Nov 2 2020
DISABLED              ELECTION         Enabled from CLI
19:53:13 UTC Nov 2 2020
ELECTION              SECONDARY_COLD       Received cluster control message
19:53:13 UTC Nov 2 2020
SECONDARY_COLD            SECONDARY_APP_SYNC   Client progression done
19:54:01 UTC Nov 2 2020
SECONDARY_APP_SYNC        SECONDARY_CONFIG     SECONDARY application configuration sync done
19:54:12 UTC Nov 2 2020
SECONDARY_CONFIG          SECONDARY_FILESYS    Configuration replication finished
19:54:13 UTC Nov 2 2020
SECONDARY_FILESYS         SECONDARY_BULK_SYNC  Client progression done
19:54:37 UTC Nov 2 2020
SECONDARY_BULK_SYNC       SECONDARY            Client progression done

19:53:06 UTC Nov 2 2020
SECONDARY      Primary  Primary relinquished role

19:53:07 UTC Nov 2 2020
Primary_POST_CONFIG  Primary post config done 
                               and waiting for ntfy

19:53:06 UTC Nov 2 2020
SECONDARY              PRIMARY_POST_CONFIG  Primary relinquished role
19:53:07 UTC Nov 2 2020
PRIMARY_POST_CONFIG    PRIMARY      Primary post config done 
                                       and waiting for ntfy
19:53:09 UTC Nov 2 2020
PRIMARY               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                SECONDARY_COLD       Received cluster control message
19:54:44 UTC Nov 2 2020
SECONDARY_COLD            SECONDARY_APP_SYNC   Client progression done
19:55:32 UTC Nov 2 2020
SECONDARY_APP_SYNC        SECONDARY_CONFIG     SECONDARY application 
                                       configuration sync done
19:55:43 UTC Nov 2 2020
SECONDARY_CONFIG          SECONDARY_FILESYS    Configuration replication finished
19:55:44 UTC Nov 2 2020
SECONDARY_FILESYS         SECONDARY_BULK_SYNC  Client progression done
19:56:08 Nov 2 2020
SECONDARY_BULK_SYNC       SECONDARY            Client progression done

Scenario 4 - CCL-communicatieverlies voor ~3-4 seconden

Voor de mislukking:

Na het herstel (de controlenode veranderde van locatie):

analyse

De mislukking

Een andere smaak van dezelfde mislukking. In dit geval kreeg de unit-1-1 ook geen 3 HC-berichten van de unit-3-1, en zodra het een nieuwe keepalive kreeg, probeerde het de unit-3-1 uit te schoppen met behulp van een STRAY-bericht, maar het bericht bereikte nooit de unit-3-1:

1. CCL wordt een paar seconden eenrichtingsverkeer. Unit-3-1 ontvangt geen 3 HC-berichten van de unit-1-1 en wordt een besturingsknooppunt.
2. Unit-2-1 stuurt een CLUSTER_QUIT_REASON_RETIREMENT-bericht (broadcast).
3. Unit-3-1 stuurt een QUIT_REASON_PRIMARY_UNIT_HC bericht naar unit-2-1. Unit-2-1 ontvangt het en verlaat het cluster.
4. Unit-3-1 stuurt een QUIT_REASON_PRIMARY_UNIT_HC bericht naar unit-1-1. Unit-1-1 ontvangt het en verlaat het cluster. CCL herstelt.
5. De eenheden 1-1 en 2-1 sluiten zich opnieuw aan bij het cluster als gegevensknooppunten.

Opmerking: Als in stap 5 de CCL niet herstelt, wordt in site-A de FTD1 de nieuwe besturingsnode en na het CCL-herstel wint deze de nieuwe verkiezing.

Syslog-berichten op unit-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 PRIMARY 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

Clustertraceringslogs op eenheid-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_PRIMARY_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

Syslog-berichten op unit-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 SECONDARY to PRIMARY
Nov 03 2020 23:13:10: %FTD-6-747004: Clustering: State machine changed from state PRIMARY_FAST to PRIMARY_DRAIN
Nov 03 2020 23:13:10: %FTD-6-747004: Clustering: State machine changed from state PRIMARY_DRAIN to PRIMARY_CONFIG
Nov 03 2020 23:13:10: %FTD-6-747004: Clustering: State machine changed from state PRIMARY_CONFIG to PRIMARY_POST_CONFIG
Nov 03 2020 23:13:10: %FTD-7-747006: Clustering: State machine is at state PRIMARY_POST_CONFIG
Nov 03 2020 23:13:10: %FTD-6-747004: Clustering: State machine changed from state PRIMARY_POST_CONFIG to PRIMARY
Nov 03 2020 23:13:10: %FTD-7-747006: Clustering: State machine is at state PRIMARY

Clustergeschiedenis

23:13:13 UTC Nov 3 2020
PRIMARY       DISABLED        Received control message DISABLE 
                                (primary 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        SECONDARY_COLD      Received cluster control message
23:14:48 UTC Nov 3 2020
SECONDARY_COLD      SECONDARY_APP_SYNC  Client progression done
23:15:36 UTC Nov 3 2020
SECONDARY_APP_SYNC  SECONDARY_CONFIG    SECONDARY application configuration 
                                sync done
23:15:48 UTC Nov 3 2020
SECONDARY_CONFIG    SECONDARY_FILESYS   Configuration replication finished
23:15:49 UTC Nov 3 2020
SECONDARY_FILESYS   SECONDARY_BULK_SYNC Client progression done
23:16:13 UTC Nov 3 2020
SECONDARY_BULK_SYNC SECONDARY           Client progression done

23:13:12 UTC Nov 3 2020
SECONDARY           DISABLED         Received control message DISABLE 
                                 (primary unit health check failure)
23:13:17 UTC Nov 3 2020
DISABLED        ELECTION         Enabled from CLI
23:13:17 UTC Nov 3 2020
ELECTION        SECONDARY_COLD       Received cluster control message
23:13:17 UTC Nov 3 2020
SECONDARY_COLD      SECONDARY_APP_SYNC   Client progression done
23:14:05 UTC Nov 3 2020
SECONDARY_APP_SYNC  SECONDARY_CONFIG     SECONDARY application configuration 
                                  sync done
23:14:16 UTC Nov 3 2020
SECONDARY_CONFIG    SECONDARY_FILESYS    Configuration replication finished
23:14:17 UTC Nov 3 2020
SECONDARY_FILESYS   SECONDARY_BULK_SYNC  Client progression done
23:14:41 UTC Nov 3 2020
SECONDARY_BULK_SYNC SECONDARY            Client progression done

23:13:10 UTC Nov 3 2020
SECONDARY    PRIMARY_POST_CONFIG  Primary relinquished role
23:13:11 UTC Nov 3 2020
PRIMARY_POST_CONFIG PRIMARY post config 
                             done and waiting for ntfy

Scenario 5

Voor de mislukking:

Na herstel (geen wijzigingen):

De mislukking:

Unit-3-1 stuurde QUIT-berichten naar zowel unit-1-1 als unit-2-1, maar vanwege connectiviteitsproblemen ontving alleen unit-2-1 het QUIT-bericht.

Eenheid-1-1-clustertraceringslogs:

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

Eenheid-2-1-clustertraceringslogs:

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_PRIMARY_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

Clustergeschiedenis:

00:51:50 UTC Nov 4 2020 
SECONDARY            DISABLED         Received control message DISABLE 
                                  (primary unit health check failure)
00:51:54 UTC Nov 4 2020
DISABLED         ELECTION         Enabled from CLI
00:51:54 UTC Nov 4 2020
ELECTION         SECONDARY_COLD       Received cluster control message
00:51:54 UTC Nov 4 2020
SECONDARY_COLD       SECONDARY_APP_SYNC   Client progression done
00:52:42 UTC Nov 4 2020
SECONDARY_APP_SYNC   SECONDARY_CONFIG     SECONDARY application configuration 
                                  sync done
00:52:54 UTC Nov 4 2020
SECONDARY_CONFIG     SECONDARY_FILESYS    Configuration replication finished
00:52:55 UTC Nov 4 2020
SECONDARY_FILESYS    SECONDARY_BULK_SYNC  Client progression done
00:53:19 UTC Nov 4 2020
SECONDARY_BULK_SYNC  SECONDARY            Client progression done

00:51:47 UTC Nov 4 2020
SECONDARY        PRIMARY_POST_CONFIG  Primary relinquished role
00:51:48 UTC Nov 4 2020
PRIMARY_POST_CONFIG PRIMARY        Primary post config done and 
                                 waiting for ntfy
00:52:12 UTC Nov 4 2020
PRIMARY           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           SECONDARY_COLD      Received cluster control message
00:53:25 UTC Nov 4 2020
SECONDARY_COLD       SECONDARY_APP_SYNC  Client progression done
00:54:12 UTC Nov 4 2020
SECONDARY_APP_SYNC   SECONDARY_CONFIG    SECONDARY application configuration 
                                 sync done
00:54:24 UTC Nov 4 2020
SECONDARY_CONFIG     SECONDARY_FILESYS   Configuration replication finished
00:54:25 UTC Nov 4 2020
SECONDARY_FILESYS    SECONDARY_BULK_SYNC Client progression done
00:54:49 UTC Nov 4 2020
SECONDARY_BULK_SYNC  SECONDARY           Client progression done

installatie voor de verbinding van het clustergegevensvliegtuig

NGFW-opnamepunten

De NGFW biedt mogelijkheden voor het vastleggen van deze punten:

• Interne switch van het chassis (FXOS)
• FTD-gegevensvliegtuigmotor
• FTD Snort-engine

Wanneer u problemen met gegevenspaden in een cluster oplost, zijn de opnamepunten die in de meeste gevallen worden gebruikt de FXOS- en FTD-gegevensvliegtuigmotoropnamen.

1. FXOS-ingangsopname op de fysieke interface
2. FTD-ingangsopname in de data plane-engine
3. FTD-regresregistratie in gegevensvliegtuigmotor
4. FXOS-ingangsopname op backplaneinterface

Raadpleeg dit document voor meer informatie over NGFW-opnamen:

Basisbeginselen voor stroomrollen voor clustereenheden

Verbindingen kunnen op verschillende manieren worden gemaakt via een cluster, afhankelijk van factoren zoals:

• Soort verkeer (TCP, UDP, enz.)
• Algoritme voor taakverdeling geconfigureerd op de aangrenzende switch
• Functies geconfigureerd op de firewall
• Netwerkcondities (bijvoorbeeld IP-fragmentatie, netwerkvertragingen, enzovoort)

• Raadpleeg het betreffende gedeelte in de configuratiehandleiding voor meer informatie (zie koppelingen in de gerelateerde informatie)
• In specifieke scenario's (zie het gedeelte met casestudy's) worden sommige vlag(s) niet altijd getoond.

Casestudy's over het opzetten van clusterverbindingen

In het volgende gedeelte worden verschillende casestudy's behandeld die enkele manieren aantonen waarop een verbinding via een cluster kan worden gemaakt. De doelstellingen zijn:

• Maak je vertrouwd met de verschillende rollen.
• Demonstreer hoe de verschillende commando-uitgangen kunnen worden gecorreleerd.

Topologie

Clustereenheden en ID's:

Cluster GROUP1: On
    Interface mode: spanned
    This is "unit-1-1" in state PRIMARY
        ID        : 0
        Site ID   : 1
        Version   : 9.15(1)
        Serial No.: FCH22247LNK
        CCL IP    : 10.17.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 SECONDARY
        ID        : 1
        Site ID   : 1
        Version   : 9.15(1)
        Serial No.: FCH23157Y9N
        CCL IP    : 10.17.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 SECONDARY
        ID        : 2
        Site ID   : 2
        Version   : 9.15(1)
        Serial No.: FCH22247MKJ
        CCL IP    : 10.17.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

Clusteropnamen ingeschakeld:

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

Opmerking: deze tests werden uitgevoerd in een laboratoriumomgeving met minimaal verkeer door het cluster. Probeer in de productie zo specifiek mogelijke opnamefilters te gebruiken (bijvoorbeeld bestemmingspoort en waar mogelijk de bronpoort) om het ‘geluid’ in de opnamen te minimaliseren.

Casestudy 1. Symmetrisch verkeer (eigenaar is ook de directeur)

Bevinding 1. De herinjecteerbare captures tonen alleen pakketten op unit-1-1. Dit betekent dat de stroom in beide richtingen ging door unit-1-1 (symmetrisch verkeer):

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

Opmerking 2. Analyse van de verbindingsvlag voor stroom met bronpoort 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

Dit kan als volgt worden weergegeven:

1. TCP SYN-pakket komt van host-A naar unit-1-1. Unit-1-1 wordt de eigenaar van de stroom.
2. Unit-1-1 wordt ook gekozen als de flow director. Zo wordt ook unit-3-1 gekozen als de back-up-eigenaar (clusteradd-bericht).
3. TCP SYN/ACK-pakket komt van host-B naar unit-3-1. De stroming is symmetrisch.
4. Zodra de verbinding is beëindigd, stuurt de eigenaar een bericht voor het verwijderen van clusters om de stroominformatie van de eigenaar van de back-up te verwijderen.

Opmerking 3. Opname met spoor laat zien dat beide richtingen alleen door eenheid-1-1 gaan:

Stap 1. Identificeer de stroom en pakketten die van belang zijn voor alle clustereenheden op basis van de bronpoort:    

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:*************************************************************

Stap 2. Aangezien dit een TCP-stroom is, traceert u de 3-weg handshake-pakketten. Zoals te zien is in deze output, is unit-1-1 de eigenaar. Voor de eenvoud worden de niet-relevante traceringsfasen weggelaten:

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
...

Het retourverkeer (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

Opmerking 4. De FTD-gegevensvliegtuigsystemen tonen het maken en beëindigen van de verbinding op alle eenheden:

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

Casestudy 2. Symmetrisch verkeer (eigenaar anders dan de directeur)

• Hetzelfde als casestudy #1, maar in deze casestudy is een flow-eigenaar een andere eenheid dan de directeur.
• Alle resultaten zijn vergelijkbaar met casestudy #1. Het belangrijkste verschil ten opzichte van casestudy #1 is de ‘Y’-vlag die de ‘y’-vlag van scenario 1 vervangt.

Bevinding 1. De eigenaar is anders dan de directeur.

Analyse van de verbindingsvlag voor stroom met bronpoort 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

Dit kan als volgt worden weergegeven:

1. TCP SYN-pakket komt van host-A naar unit-1-1. Unit-1-1 wordt de eigenaar van de stroom.
2. Unit-3-1 wordt gekozen als de flow director. Unit-3-1 is ook de eigenaar van de back-up ("cluster add"-bericht op UDP 4193 via de CCL).
3. TCP SYN/ACK-pakket komt van host-B naar unit-3-1. De stroming is symmetrisch.
4. Zodra de verbinding is beëindigd, verzendt de eigenaar via de CCL een "cluster delete" -bericht op UDP 4193 om de stroominformatie van de eigenaar van de back-up te verwijderen.

Opmerking 2. Opname met spoor laat zien dat beide richtingen alleen door eenheid-1-1 gaan.

Stap 1. Gebruik dezelfde aanpak als in casestudy 1 om de stroom en pakketten te identificeren die van belang zijn voor alle clustereenheden op basis van de bronpoort:

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#

Opnemen via de interface BUITEN:

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#

Stap 2. Focus op de toegangspakketten (TCP SYN en 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

Volg de SYN/ACK op unit-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

Opmerking 3. De FTD-gegevensvliegtuigsystemen tonen het maken en beëindigen van de verbinding voor de eigenaar en de eigenaar van de back-up:

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

Casestudy 3. Asymmetrisch verkeer (Directeur Vooruit het verkeer)

Bevinding 1. De opnieuw injecteren-verbergen captures tonen pakketten op unit-1-1 en unit-2-1 (asymmetrische flow):

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

Opmerking 2. Analyse van de verbindingsvlag voor stroom met bronpoort 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

Dit kan als volgt worden weergegeven:

1. TCP SYN-pakket komt van host-A naar unit-1-1. Unit-1-1 wordt de eigenaar van de stroom.
2. Unit-2-1 wordt gekozen als de flow director en back-up eigenaar. De eigenaar van de stroom verzendt een unicastbericht "cluster add" op UDP 4193 om de eigenaar van de back-up te informeren over de stroom.
3. TCP SYN/ACK-pakket komt van host-B naar unit-2-1. De stroming is asymmetrisch.
4. Unit-2-1 stuurt het pakket door de CCL naar de eigenaar (vanwege TCP SYN Cookie).
5. De eigenaar injecteert het pakket opnieuw op de interface BUITEN en stuurt het pakket vervolgens door naar Host-A.
6. Zodra de verbinding is beëindigd, stuurt de eigenaar een bericht voor het verwijderen van clusters om de stroominformatie van de eigenaar van de back-up te verwijderen.

Opmerking 3. Opname met spoor toont het asymmetrische verkeer en de omleiding van eenheid-2-1 naar eenheid-1-1.

Stap 1. Identificeer de pakketten die behoren tot de stroom van belang (poort 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:*************************************************************

De terugkeerrichting:

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:*************************************************************

Stap 2. Traceer de pakketten. Standaard worden alleen de eerste 50 ingresspakketten getraceerd. Voor de eenvoud worden de niet-relevante traceringsfasen weggelaten.

Unit-1-1 (eigenaar)

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

Unit-2-1 (Forwarder)

Het retourverkeer (TCP SYN/ACK) De eenheid van belang is unit-2-1 die de directeur/back-up eigenaar is en het verkeer doorstuurt naar de eigenaar:

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).

Opmerking 4. De FTD-gegevensvliegtuigsystemen tonen het maken en beëindigen van de verbinding op alle eenheden:

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#

Casestudy 4. Asymmetrisch verkeer (eigenaar is de directeur)

Bevinding 1. De opnieuw injecteren-verbergen captures tonen pakketten op unit-1-1 en unit-2-1 (asymmetrische flow):

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

Opmerking 2. Analyse van de verbindingsvlag voor stroom met bronpoort 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

Dit kan als volgt worden weergegeven:

1. TCP SYN-pakket komt van host-A naar unit-1-1. Unit-1-1 wordt de eigenaar van de stroom en wordt gekozen als een directeur.
2. Unit-3-1 wordt gekozen als back-up eigenaar. De eigenaar van de stroom verzendt een unicast "cluster add"-bericht op UDP 4193 om de eigenaar van de back-up te informeren over de stroom.
3. TCP SYN/ACK-pakket komt van host-B naar unit-2-1. De stroming is asymmetrisch.
4. Unit-2-1 stuurt het pakket door de CCL naar de eigenaar (vanwege TCP SYN Cookie).
5. De eigenaar injecteert het pakket opnieuw op de interface BUITEN en stuurt het pakket vervolgens door naar Host-A.
6. Zodra de verbinding is beëindigd, stuurt de eigenaar een bericht voor het verwijderen van clusters om de stroominformatie van de eigenaar van de back-up te verwijderen.

Opmerking 3. Opname met spoor toont het asymmetrische verkeer en de omleiding van eenheid-2-1 naar eenheid-1-1.

Unit-2-1 (forwarder):

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).

Opmerking 4. De FTD-gegevensvliegtuigsystemen tonen het maken en beëindigen van de verbinding op alle eenheden:

• Unit-1-1 (eigenaar)
• Unit-2-1 (forwarder)
• Unit-3-1 (eigenaar back-up)

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

Casestudy 5. Asymmetrisch verkeer (eigenaar is anders dan de directeur)

Bevinding 1. De opnieuw injecteren-verbergen captures tonen pakketten op unit-1-1 en unit-2-1 (asymmetrische flow):

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

Opmerking 2. Analyse van de verbindingsvlag voor stroom met bronpoort 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

Dit kan als volgt worden weergegeven:

1. TCP SYN-pakket komt van host-A naar unit-1-1. Unit-1-1 wordt de eigenaar van de stroom.
2. Unit-3-1 wordt gekozen als een directeur en back-up eigenaar. De eigenaar van de stroom verzendt een unicastbericht "cluster add" op UDP 4193 om de eigenaar van de back-up te informeren over de stroom.
3. TCP SYN/ACK-pakket komt van host-B naar unit-2-1. De stroming is asymmetrisch
4. Unit-2-1 stuurt het pakket door de CCL naar de eigenaar (vanwege TCP SYN Cookie).
5. De eigenaar injecteert het pakket opnieuw op de interface BUITEN en stuurt het pakket vervolgens door naar Host-A.
6. Zodra de verbinding is beëindigd, stuurt de eigenaar een bericht voor het verwijderen van clusters om de stroominformatie van de eigenaar van de back-up te verwijderen.

Opmerking 3. Opname met spoor toont het asymmetrische verkeer en de omleiding van eenheid-2-1 naar eenheid-1-1.

Unit-1-1 (eigenaar):

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

Unit-2-1 (forwarder):

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).

Opmerking 4. De FTD-gegevensvliegtuigsystemen tonen het maken en beëindigen van de verbinding op alle eenheden:

• Unit-1-1 (eigenaar)
• Unit-2-1 (forwarder)
• Unit-3-1 (eigenaar/directeur back-up)

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

Voor de volgende case studies is de gebruikte topologie gebaseerd op een cluster met inline sets:

Casestudy 6. Asymmetrisch verkeer (Inline-set, eigenaar is de directeur)

Bevinding 1. De opnieuw injecteren-verbergen captures tonen pakketten op unit-1-1 en unit-2-1 (asymmetrische flow). Bovendien is de eigenaar unit-2-1 (er zijn pakketten op beide, BINNEN en BUITEN. Interfaces voor de re-injectie-hide captures, terwijl unit-1-1 alleen op BUITEN heeft):

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

Opmerking 2. Verbindingsvlaganalyse voor stroom met bronpoort 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

Dit kan als volgt worden weergegeven:

1. TCP SYN-pakket komt van host-A naar unit-2-1. Unit-2-1 wordt de eigenaar van de stroom en wordt gekozen als de directeur.
2. Unit-3-1 wordt gekozen als de back-up eigenaar. De eigenaar van de stroom verzendt een unicastbericht "cluster add" op UDP 4193 om de eigenaar van de back-up te informeren over de stroom.
3. TCP SYN/ACK-pakket komt van host-B naar unit-1-1. De stroming is asymmetrisch.
4. Unit-1-1 stuurt het pakket door de CCL naar de regisseur (unit-2-1).
5. Unit-2-1 is ook de eigenaar en injecteert het pakket opnieuw op de interface BUITEN.
6. Unit-2-1 stuurt het pakket door naar Host-A.
7. Zodra de verbinding is beëindigd, stuurt de eigenaar een bericht voor het verwijderen van clusters om de stroominformatie van de eigenaar van de back-up te verwijderen.

Opmerking 3. Opname met spoor toont het asymmetrische verkeer en de omleiding van eenheid-1-1 naar eenheid-2-1.

Unit-2-1 (eigenaar/directeur):

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

Unit-1-1 (forwarder):

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).

Terugkeerverkeer (TCP/SYN/ACK)

Unit-2-1 (eigenaar/directeur):

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

Opmerking 4. De FTD-gegevensvliegtuigsystemen tonen het maken en beëindigen van de verbinding op alle eenheden:

• Unit-1-1 (eigenaar)
• Unit-2-1 (forwarder)
• Unit-3-1 (eigenaar/directeur back-up)

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

Casestudy 7. Asymmetrisch verkeer (Inline-set, eigenaar is anders dan de directeur)

De eigenaar is unit-2-1 (er zijn pakketten op beide, INSIDE en OUTSIDE interfaces voor de re-injectie-hide captures, terwijl unit-3-1 heeft alleen op 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

Opmerking 2. Analyse van de verbindingsvlag voor stroom met bronpoort 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

Dit kan als volgt worden weergegeven:

1. TCP SYN-pakket komt van host-A naar unit-2-1. Unit-2-1 wordt de eigenaar van de stroom en unit-1-1 wordt gekozen als de directeur
2. Unit-1-1 wordt gekozen als de back-up eigenaar (omdat het de directeur). De eigenaar van de stroom verzendt een "cluster add" unicast-bericht op UDP 4193. om de eigenaar van de back-up te informeren over de stroom.
3. TCP SYN/ACK-pakket komt van host-B naar unit-3-1. De stroming is asymmetrisch.
4. Unit-3-1 stuurt het pakket door de CCL naar de regisseur (unit-1-1).
5. Unit-1-1 (regisseur) weet dat de eigenaar unit-2-1 is, stuurt het pakket terug naar de expediteur (unit-3-1) en meldt hem dat de eigenaar unit-2-1 is.
6. Unit-3-1 stuurt het pakket naar unit-2-1 (eigenaar).
7. Unit-2-1 injecteert het pakket opnieuw op de interface BUITEN.
8. Unit-2-1 stuurt het pakket door naar Host-A.
9. Zodra de verbinding is beëindigd, stuurt de eigenaar een bericht voor het verwijderen van clusters om de stroominformatie van de eigenaar van de back-up te verwijderen.

Opmerking: Het is belangrijk dat stap 2 (pakket via de CCL) plaatsvindt vóór stap 4 (dataverkeer). In een ander geval (bijvoorbeeld de race-conditie) is de regisseur niet op de hoogte van de flow. Aangezien het een inline set is, stuurt u het pakket naar de bestemming. Als de interfaces zich niet in een inline-set bevinden, wordt het gegevenspakket weggelaten.

Opmerking 3. Capture with trace toont het asymmetrische verkeer en de uitwisselingen over de CCL:

Voorwaarts verkeer (TCP SYN)

Unit-2-1 (eigenaar):

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

Terugkeerverkeer (TCP/SYN/ACK)

Unit-3-1 (ID 2 - forwarder) stuurt het pakket door de CCL naar unit-1-1 (ID 0 - director):

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).

Unit-1-1 (regisseur) – Unit-1-1 (ID 0) weet dat de eigenaar van de stroom unit-2-1 (ID 1) is en stuurt het pakket via de CCL terug naar unit-3-1 (ID 2 - doorstuurder):

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).

Unit-3-1 (ID 2 - forwarder) krijgt het pakket via de CCL en stuurt het naar unit-2-1 (ID 1 - eigenaar):

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).

De eigenaar injecteert het pakket opnieuw en stuurt het door naar de bestemming:

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).

Opmerking 4. De FTD-gegevensvliegtuigsystemen tonen het maken en beëindigen van de verbinding op alle eenheden:

• Unit-1-1 (directeur/eigenaar back-up)
• Unit-2-1 (eigenaar)
• Unit-3-1 (forwarder)

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

Problemen oplossen

Inleiding probleemoplossing voor clusters

De clusterproblemen kunnen worden onderverdeeld in:

• Problemen met het controlevlak (problemen met betrekking tot de stabiliteit van het cluster)
• Problemen met het gegevensvliegtuig (problemen in verband met het transitoverkeer)

Problemen met het clustergegevensvlak

NAT/PAT Gemeenschappelijke vraagstukken

Belangrijke configuratieoverwegingen

• PAT-pools (Port Address Translation) moeten ten minste evenveel IP's beschikbaar hebben als het aantal eenheden in het cluster, bij voorkeur meer IP's dan clusternodes.
• De standaard opdrachten per sessie moeten blijven staan, tenzij er een specifieke reden is om ze uit te schakelen. Elk PAT-sjabloon dat is gebouwd voor een verbinding waarbij de variabele per sessie is uitgeschakeld, wordt altijd afgehandeld door de knooppunteenheid in het cluster, wat kan leiden tot prestatievermindering.

Hoog PAT-poolbereik door verkeer afkomstig van poorten met een laag bereik waardoor IP-onbalans in het cluster wordt veroorzaakt

De FTD verdeelt een PAT IP in bereiken en probeert de leisteen in hetzelfde bronbereik te houden. Deze tabel laat zien hoe een bronpoort wordt vertaald naar een globale poort binnen hetzelfde bronbereik.

Wanneer een bronpoortbereik vol is en een nieuw PAT-sjabloon moet worden toegewezen vanuit dat bereik, gaat FTD naar het volgende IP om nieuwe vertalingen toe te wijzen voor dat bronpoortbereik.

Symptomen:

Connectiviteitsproblemen voor NATed-verkeer dat het cluster doorkruist

Verificatie:

# show nat pool

FTD-logboeken voor gegevensvlakken tonen uitputting van PAT-pool:

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

Mitigatie:

Configureer het NAT Flat Port-bereik en neem reservepoorten op.

Bovendien kunt u in post-6.7/9.15.1 alleen eindigen met een onevenwichtige verdeling van poortblokken wanneer knooppunten het cluster verlaten / lid worden met enorm achtergrondverkeer dat onderworpen is aan PAT. De enige manier waarop het zichzelf herstelt, is wanneer poortblokken worden vrijgemaakt om over nodes te worden herverdeeld.

Met op poortblokken gebaseerde distributie, wanneer een node wordt toegewezen met bijvoorbeeld 10 poortblokken zoals pb-1, pb-2 ... pb-10. De node begint altijd met het eerste beschikbare poortblok en wijst een willekeurige poort toe totdat deze is uitgeput. De toewijzing wordt alleen naar het volgende poortblok verplaatst wanneer alle poortblokken tot dat punt zijn uitgeput.

Als een host bijvoorbeeld 512 verbindingen tot stand brengt, wijst de eenheid toegewezen poorten voor al die 512 verbindingen van pb-1 willekeurig toe. Nu, met al deze 512-verbindingen actief, wanneer de host de 513e verbinding tot stand brengt sinds pb-1 is uitgeput, gaat deze naar pb-2 en wijst er een willekeurige poort vanaf toe. Nogmaals, van de 513 verbindingen, veronderstel dat de 10e verbinding klaar is en één poort die beschikbaar is in pb-1 heeft gewist. Op dit punt, als de host de 514e verbinding tot stand brengt, wijst de clustereenheid een toegewezen poort toe vanaf pb-1 en niet pb-2, omdat pb-1 nu een vrije poort heeft (die werd vrijgegeven als onderdeel van de 10e verbindingsverwijdering).

Het belangrijkste om in gedachten te houden is dat de toewijzing gebeurt vanaf het eerste beschikbare poortblok met vrije poorten, zodat de laatste poortblokken altijd beschikbaar zijn voor herdistributie in een normaal geladen systeem. Bovendien wordt PAT meestal gebruikt voor verbindingen met een korte levensduur. De kans dat een havenblok in een kortere tijd beschikbaar komt, is zeer groot. De tijd die nodig is om de pooldistributie in evenwicht te brengen, kan dus verbeteren met op poortblokken gebaseerde pooldistributie.

Als alle poortblokken, van pb-1 tot pb-10, echter uitgeput zijn of elk poortblok een poort heeft voor een langdurige verbinding, worden de poortblokken nooit snel vrijgemaakt en worden ze opnieuw verdeeld. In een dergelijk geval is de minst ontwrichtende aanpak:

1. Nodes identificeren met buitensporige poortblokken (overzicht van de NAT-pool weergeven).
2. Identificeer de minst gebruikte poortblokken op dat knooppunt (toon details van de IP <addr> van de nat-pool).
3. Duidelijke datums voor dergelijke poortblokken (wissen xlate global <addr> gport 'start-end') om ze beschikbaar te maken voor herdistributie.

Waarschuwing: Dit verstoort de relevante verbindingen.

Kan niet bladeren naar dual-channel websites (zoals webmail, bankieren, enz.) of naar SSO-websites wanneer omleiding naar een andere bestemming plaatsvindt.

Symptomen:

Kan niet bladeren naar dual-channel websites (zoals webmail, bankwebsites, enzovoort). Wanneer een gebruiker verbinding maakt met een website waarvoor de client een tweede socket/verbinding moet openen en de tweede verbinding wordt gehasht naar een clusterlid dat verschilt van het clusterlid waarop de eerste verbinding is gehasht en het verkeer een IP PAT-pool gebruikt, wordt het verkeer door de server gereset omdat het de verbinding ontvangt van een ander openbaar IP-adres.

Verificatie:

Neem data plane cluster-opnames om te zien hoe de getroffen doorvoerstroom wordt afgehandeld. In dit geval komt een TCP-reset van de bestemmingswebsite.

Mitigatie (vóór 6,7/9,15,1):

• Let op als er toepassingen met meerdere sessies zijn die meerdere toegewezen IP-adressen gebruiken.
• Gebruik de opdracht NAT-pool-clusteroverzicht weergeven om te controleren of de groep gelijkmatig is verdeeld.
• Gebruik de opdracht clusterexec show conn om te controleren of het verkeer goed is verdeeld.
• Gebruik de opdracht IP <adres> voor details van de clustergroep weergeven om het gebruik van de groep van kleverige IP te controleren.
• Schakel syslog 305021 (6.7/9.15) in om te zien welke verbindingen geen kleverige IP hebben gebruikt.
• Om meer IP's aan de PAT-pool toe te voegen of het algoritme voor de taakverdeling op verbonden switches te verfijnen.

Over het algoritme voor werklastverdeling via het ether-kanaal:

• Voor niet-FP9300 en als verificatie via één server plaatsvindt: pas het algoritme voor werklastverdeling via het ether-kanaal op de aangrenzende switch aan van bron-IP/poort en bestemmings-IP/poort naar bron-IP en bestemmings-IP.
• Voor niet-FP9300 en als verificatie via meerdere servers plaatsvindt: pas het algoritme voor werklastverdeling via het ether-kanaal op de aangrenzende switch aan van bron-IP/poort en bestemmings-IP/poort naar bron-IP.
• Voor FP9300: op het FP9300-chassis is het algoritme voor werklastverdeling vastgelegd als source-dest-port source-dest-ip source-dest-mac en kan het niet worden gewijzigd. De oplossing is in dit geval om FlexConfig te gebruiken om per sessie opdrachten toe te voegen aan de FTD-configuratie om verkeer voor bepaalde IP-adressen van bestemmingen (voor de problematische/incompatibele toepassingen) te forceren dat alleen door de besturingsnode in het cluster binnen het chassis wordt afgehandeld. De workaround wordt geleverd met deze bijwerkingen:
  • Geen load balancing van het verschillend vertaalde verkeer (alles gaat naar de control node).
  • Potentieel voor late slots om uit te lopen (en nadelige invloed op NAT vertaling voor ander verkeer op de control node).
  • Verminderde schaalbaarheid van het cluster binnen het chassis.

Lage clusterprestaties door al het verkeer dat naar de controlenode wordt verzonden vanwege onvoldoende PAT-IP's in de pools.

Symptomen:

Er zijn niet genoeg PAT-IP's in het cluster om een gratis IP aan de gegevensknooppunten toe te wijzen, en daarom wordt al het verkeer dat onder de PAT-configuratie valt, doorgestuurd naar het besturingsknooppunt voor verwerking.

Verificatie:

Gebruik de opdracht nat pool cluster weergeven om de toewijzingen voor elke eenheid te bekijken en te bevestigen dat ze allemaal ten minste één IP in de pool bezitten.

Mitigatie:

Voor pre-6.7/9.15.1 moet u een PAT-pool hebben die ten minste gelijk is aan het aantal knooppunten in het cluster. In post-6.7/9.15.1 met PAT-pool wijst u poortblokken toe uit alle PAT-pool-IP's. Als het PAT-zwembadgebruik echt hoog is, wat leidt tot frequente uitputting van het zwembad, moet u de PAT-zwembadgrootte vergroten (zie het gedeelte Veelgestelde vragen).

Lage prestaties vanwege al het verkeer dat naar de besturingsnode wordt verzonden, omdat de datums niet per sessie zijn ingeschakeld.

Symptomen:

Veel snelle UDP-back-upstromen worden verwerkt via de clusterbesturingsnode, wat van invloed kan zijn op de prestaties.

Achtergrond:

Alleen verbindingen die datums gebruiken die per sessie zijn ingeschakeld, kunnen worden verwerkt door een gegevensknooppunt dat PAT gebruikt. Gebruik de opdracht show run all xlate om de xlate per-sessie configuratie te zien.

Per-sessie ingeschakeld betekent dat het verwijderaar onmiddellijk wordt afgebroken wanneer de bijbehorende verbinding wordt afgebroken. Dit helpt de prestaties van de verbinding per seconde te verbeteren wanneer de verbindingen worden onderworpen aan PAT. Niet-per-sessie-datums blijven nog eens 30 seconden actief nadat de bijbehorende verbinding is afgebroken en als de verbindingssnelheid hoog genoeg is, kunnen de beschikbare 65k TCP/UDP-poorten op elk globaal IP-adres in korte tijd worden gebruikt.

Standaard is al het TCP-verkeer per xlate ingeschakeld en is alleen het UDP DNS-verkeer per sessie ingeschakeld. Dit betekent dat al het niet-DNS UDP-verkeer wordt doorgestuurd naar de controlenode voor verwerking.

Verificatie:

Gebruik deze opdracht om de verbinding en pakketdistributie tussen de clustereenheden te controleren:

firepower# show cluster info conn-distribution
firepower# show cluster info packet-distribution
firepower# show cluster info load-monitor

Gebruik de opdracht clusterexec show conn om te zien welke clusternodes de UDP-verbindingen bezitten.

firepower# cluster exec show conn

Gebruik deze opdracht om inzicht te krijgen in het gebruik van de pool in clusternodes.

firepower# cluster exec show nat pool ip  | in UDP

Mitigatie:

Configureer per sessie PAT (per sessie permit udp command) voor het verkeer van belang (bijvoorbeeld UDP). Voor ICMP kunt u de standaard PAT voor meerdere sessies niet wijzigen, zodat ICMP-verkeer altijd wordt afgehandeld door de besturingsnode wanneer er PAT is geconfigureerd.

De verdeling van de PAT-pool wordt onevenwichtig wanneer knooppunten het cluster verlaten of zich bij het cluster aansluiten.

Symptomen:

• Connectiviteitsproblemen sinds PAT IP-toewijzing kunnen na verloop van tijd uit balans raken als gevolg van eenheden die het cluster verlaten en zich bij het cluster aansluiten.
• In post-6.7/9.15.1 kunnen er gevallen zijn waarin de nieuw samengevoegde node niet genoeg poortblokken kan krijgen. Een node die geen poortblok heeft, leidt het verkeer om naar de controlenode. Een node met ten minste één poortblok behandelt het verkeer en laat het vallen zodra de pool is uitgeput.

Verificatie:

• De syslogs van het gegevensvlak tonen berichten zoals:

%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

• Gebruik de opdracht NAT-groepsclusteroverzicht weergeven om de groepsdistributie te identificeren.
• Gebruik de opdracht clusterexec show nat pool ip <addr> detail om inzicht te krijgen in het gebruik van de groep in clusternodes.

Mitigatie:

• Voor pre-6.7/9.15.1 zijn een paar oplossingen beschreven in Cisco bug ID CSCvd10530
• Gebruik in post-6.7/9.15.1 de opdracht clear xlate global <ip> gport <start-end> om handmatig een aantal van de poortblokken op andere knooppunten te wissen voor herdistributie naar de vereiste knooppunten.

Symptomen:

Belangrijke connectiviteitsproblemen voor verkeer dat door het cluster wordt gepatcht. Dit komt omdat het FTD-gegevensvlak, per ontwerp, geen GARP verzendt voor wereldwijde NAT-adressen.

Verificatie:

De ARP-tabel van de direct verbonden apparaten toont het verschillende MAC-adres van de clustergegevensinterface na een wijziging van de besturingsnode:

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

Mitigatie:

Statische (virtuele) MAC configureren op clustergegevensinterfaces.

Verbindingen waarop PAT is toegepast, zijn mislukt

Symptomen:

Connectiviteitsproblemen voor verkeer dat door het cluster wordt gepatcht.

Verificatie/beperking:

• Zorg ervoor dat de configuratie correct wordt gerepliceerd.
• Zorg ervoor dat het zwembad gelijkmatig verdeeld is.
• Zorg ervoor dat eigendom van de pool geldig is.
• Er zijn geen fouttellerstappen in de asp-clusterteller.
• Zorg ervoor dat de stromen van de directeur/expediteur worden gemaakt met de juiste informatie.
• Valideren of back-updatesnelheden worden gemaakt, bijgewerkt en opgeruimd zoals verwacht.
• Valideren of datums worden gemaakt en beëindigd volgens het "per-sessie" -gedrag.
• Schakel "debug nat 2" in voor een indicatie van eventuele fouten. Let op, deze uitvoer kan erg luidruchtig zijn, bijvoorbeeld:

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

       Om het debuggen te stoppen:

firepower# un all

• Schakel verbinding en NAT-gerelateerde syslogs in om de informatie te correleren met een mislukte verbinding.

ASA en FTD Clustering PAT Verbeteringen (post-9.15 en 6.7)

Wat is er veranderd?

De PAT-operatie werd opnieuw ontworpen. Individuele IP's worden niet meer verdeeld over elk van de clusterleden. In plaats daarvan worden de PAT-IP's opgesplitst in poortblokken en worden die poortblokken gelijkmatig (zoveel mogelijk) verdeeld tussen de clusterleden, in combinatie met IP-kleverigheid.

Het nieuwe ontwerp pakt deze beperkingen aan (zie de vorige paragraaf):

• Toepassingen voor meerdere sessies worden beïnvloed door een gebrek aan IP-kleverigheid voor het hele cluster.
• De vereiste is om een PAT-pool van grootte te hebben die ten minste gelijk is aan het aantal knooppunten in het cluster.
• De verdeling van de PAT-pool wordt onevenwichtig wanneer knooppunten het cluster verlaten of zich bij het cluster aansluiten.
• Geen syslogs om de onbalans van de PAT-pool aan te geven.

In plaats van de standaard 1-511-, 512-1023- en 1024-65535-poortbereiken, is er nu 1024-65535 als het standaardpoortbereik voor PAT. Dit standaardbereik kan worden uitgebreid met het geprivilegieerde poortbereik 1-1023 voor reguliere PAT (inclusief reserve optie).

Dit is een voorbeeld van een PAT-poolconfiguratie op FTD 6.7. Raadpleeg voor meer informatie het betreffende gedeelte in de Configuratiegids:

Aanvullende informatie over probleemoplossing over PAT

FTD-gegevensvliegtuigsystemen (post-6.7/9.15.1)

Een stickiness invaliditeitssyslog wordt gegenereerd wanneer alle poorten zijn uitgeput in het kleverige IP op een clusterknooppunt en toewijzing wordt verplaatst naar het volgende beschikbare IP met vrije poorten, bijvoorbeeld:

%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.

Een pool-onbalanssyslog wordt gegenereerd op een node wanneer deze zich bij het cluster aansluit en krijgt geen of ongelijk aandeel van poortblokken, bijvoorbeeld:

%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.

Opdrachten weergeven

Groepsdistributiestatus

In de overzichtsuitvoer van de natpool-cluster mag er voor elk PAT IP-adres niet meer dan 1 poortblok over de knooppunten verschillen in een evenwichtig distributiescenario. Voorbeelden van een gebalanceerde en ongebalanceerde poortblokverdeling.

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)

Onevenwichtige verdeling:

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)

Eigendomsstatus van pool

In de uitvoer van het natpool-cluster tonen, mag er geen enkel poortblok zijn met de eigenaar of back-up als ONBEKEND. Als er een is, duidt dit op een probleem met de communicatie over groepseigendom. Voorbeeld:

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>

Boekhouding van haventoewijzingen in havenblokken

De opdracht NAT-pool weergeven is uitgebreid met extra opties om gedetailleerde informatie en gefilterde uitvoer weer te geven. Voorbeeld:

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 *

'*' geeft aan dat het een back-uppoortblok is

Om dit op te lossen, gebruikt u de opdracht clear xlate global <ip> gport <start-end> om handmatig een aantal van de poortblokken op andere knooppunten te wissen voor herdistributie naar de vereiste knooppunten.

Handmatig getriggerde herverdeling van poortblokken

• In een productienetwerk met constant verkeer, wanneer een knooppunt het cluster verlaat en opnieuw aansluit (waarschijnlijk vanwege een traceback), kunnen er gevallen zijn waarin het geen gelijk aandeel van de pool kan krijgen of, in het ergste geval, het geen poortblok kan krijgen.
• Gebruik de opdracht NAT-poolcluster weergeven om te bepalen welke node meer poortblokken bezit dan vereist.
• Op de knooppunten die meer poortblokken bezitten, gebruikt u de opdracht show nat pool ip <addr> detail om de poortblokken met het minste aantal toewijzingen te achterhalen.
• Gebruik de opdracht clear xlate global <address> gport <start-end> om vertalingen die uit die poortblokken zijn gemaakt te wissen, zodat ze beschikbaar komen voor herdistributie naar de vereiste nodes, bijvoorbeeld:

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

Veelgestelde vragen voor post-6.7/9.15.1 PAT

V. Als u het aantal beschikbare IP's hebt voor het aantal beschikbare eenheden in het cluster, kunt u dan nog steeds 1 IP per eenheid als optie gebruiken?

A. Niet meer, en er is geen wisselwerking tussen op IP-adressen gebaseerde en op poortblokken gebaseerde pooldistributieschema's voor switch.

Het oudere schema van op IP-adressen gebaseerde pooldistributie resulteerde in toepassingsfouten met meerdere sessies waarbij meerdere verbindingen (die deel uitmaken van een enkele toepassingstransactie) van een host op verschillende knooppunten van het cluster worden geladen en dus worden vertaald door verschillende toegewezen IP-adressen die leiden naar de bestemmingsserver om ze te zien als afkomstig van verschillende entiteiten.

En met het nieuwe op poortblokken gebaseerde distributieschema, hoewel u nu met slechts één PAT IP-adres kunt werken, wordt het altijd aanbevolen om voldoende PAT IP-adressen te hebben op basis van het aantal verbindingen dat vereist is om PATed te zijn.

V. Kunt u nog steeds een pool met IP-adressen voor de PAT-pool voor het cluster hebben?

A. Ja, dat kan. Poortblokken van alle IP's van de PAT-pool worden verdeeld over de clusternodes.

V. Als u een aantal IP-adressen gebruikt voor de PAT-pool, wordt dan hetzelfde blok poorten per IP-adres aan elk lid verstrekt?

Nee, elk IP-adres wordt onafhankelijk verdeeld.

V. Alle clusternodes hebben alle openbare IP's, maar slechts een subset van poorten? Als dit het geval is, is het dan gegarandeerd dat elke keer dat de bron-IP hetzelfde openbare IP gebruikt?

A. Dat klopt, elke PAT IP is gedeeltelijk eigendom van elke node. Als een gekozen openbaar IP-adres op een node is uitgeput, wordt een syslog gegenereerd die aangeeft dat kleverig IP niet kan worden bewaard en de toewijzing wordt verplaatst naar het volgende beschikbare openbare IP-adres. Of het nu gaat om een standalone, HA of Cluster-implementatie, de IP-kleverigheid is altijd optimaal afhankelijk van de beschikbaarheid van de pool.

V. Is alles gebaseerd op één IP-adres in de PAT-pool, maar is dit niet van toepassing als meer dan één IP-adres in de PAT-pool wordt gebruikt?

A. Het is ook van toepassing op meerdere IP-adressen in de PAT-pool. Poortblokken van elk IP-adres in de PAT-pool zijn verdeeld over clusternodes. Elk IP-adres in de PAT-pool wordt verdeeld over alle leden in het cluster. Dus als u een klasse C van adressen in de PAT-pool hebt, heeft elk clusterlid poortpools van elk van de PAT-pooladressen.

V. Werkt het met CGNAT?

A. Ja, CGNAT wordt ook ondersteund. CGNAT, ook bekend als block-allocatie PAT, heeft een standaard blokgrootte van '512' die kan worden gewijzigd door middel van cli voor blokallocatie. In het geval van reguliere dynamische PAT (niet-CGNAT) is de blokgrootte altijd '512', die vast en niet-configureerbaar is.

V. Als de eenheid het cluster verlaat, wijst de besturingsnode het poortblokbereik dan toe aan andere eenheden of houdt deze het voor zichzelf?

A. Elk poortblok heeft een eigenaar en een back-up. Elke keer dat een xlate wordt gemaakt van een poortblok, wordt deze ook gerepliceerd naar de back-upnode van het poortblok. Wanneer een node het cluster verlaat, is de back-upnode eigenaar van alle poortblokken en alle huidige verbindingen. Aangezien de back-upnode eigenaar is geworden van deze extra poortblokken, selecteert deze een nieuwe back-up voor deze blokken en repliceert alle huidige datums naar die node om storingsscenario's af te handelen.

V. Welke maatregelen kunnen op basis van die waarschuwing worden genomen om de kleverigheid af te dwingen?

A. Er zijn twee mogelijke redenen waarom kleverigheid niet kan worden behouden.

Reden-1: Het verkeer is onjuist load-balanced als gevolg waarvan een van de knooppunten ziet een hoger aantal verbindingen dan anderen, wat leidt tot de bijzondere kleverige IP uitputting. Dit kan worden aangepakt als u ervoor zorgt dat het verkeer gelijkmatig over clusternodes wordt verdeeld. Op een FPR41xx-cluster kunt u bijvoorbeeld het algoritme voor werklastverdeling op verbonden switches aanpassen. Zorg op een FPR9300-cluster voor een gelijk aantal blades in het chassis.

Reden-2: PAT zwembad gebruik is echt hoog, wat leidt tot frequente uitputting van het zwembad. Om deze toename aan te pakken, neemt de omvang van de PAT-pool toe.

V. Hoe wordt de ondersteuning voor het uitgebreide zoekwoord behandeld? Geeft het een fout weer en voorkomt het dat de hele NAT-opdracht wordt toegevoegd tijdens de upgrade, of verwijdert het het uitgebreide zoekwoord en toont het een waarschuwing?

A. De optie PAT extended wordt niet ondersteund in Cluster vanaf ASA 9.15.1/FP 6.7. De configuratieoptie wordt niet verwijderd uit CLI/ASDM/CSM/FMC. Bij configuratie (direct of indirect via een upgrade) krijgt u een waarschuwingsbericht en wordt de configuratie geaccepteerd, maar ziet u de uitgebreide functionaliteit van PAT niet in actie.

V. Is het aantal vertalingen gelijk aan het aantal gelijktijdige verbindingen?

A. In pre-6.7 / 9.15.1, hoewel het 1-65535 was, omdat de bronpoorten nooit veel worden gebruikt in het bereik 1-1024, maakt het effectief 1024-65535 (64512 conns). In de post-6.7/9.15.1-implementatie met 'plat' als standaardgedrag is dit 1024-65535. Maar als u de 1-1024 wilt gebruiken, kunt u kiezen voor de optie "inclusief-reserve".

V. Als de node zich weer bij het cluster aansluit, heeft deze de oude back-upnode als back-up en geeft die back-upnode zijn oude poortblokkering aan?

A. Het hangt af van de beschikbaarheid van havenblokken op dat moment. Wanneer een node het cluster verlaat, worden alle poortblokken verplaatst naar de back-upnode. Het is dan de controle node die vrije poort blokken accumuleert en distribueert ze naar de vereiste knooppunten.

V. Als er een wijziging is opgetreden in de status van het besturingsknooppunt, wordt een nieuw besturingsknooppunt geselecteerd, wordt de PAT-bloktoewijzing gehandhaafd of worden de poortblokken opnieuw toegewezen op basis van het nieuwe besturingsknooppunt?

A. Het nieuwe besturingsknooppunt heeft inzicht in welke blokken zijn toegewezen en welke gratis zijn en begint vanaf daar.

V. Is het maximale aantal datums hetzelfde als het maximale aantal gelijktijdige verbindingen met dit nieuwe gedrag?

A. Ja. Het maximale aantal datums is afhankelijk van de beschikbaarheid van PAT-poorten. Het heeft niets te maken met het maximale aantal gelijktijdige verbindingen. Als u slechts 1 adres toestaat, heeft u 65535 mogelijke verbindingen. Als u meer nodig heeft, moet u meer IP-adressen toewijzen. Als er voldoende adressen/poorten zijn, kunt u maximaal gelijktijdige verbindingen bereiken.

V. Hoe verloopt de toewijzing van het havenblok wanneer een nieuw clusterlid wordt toegevoegd?  Wat gebeurt er als een clusterlid wordt toegevoegd als gevolg van reboot?

A. Poortblokken worden altijd gedistribueerd door de besturingsnode. Poortblokken worden alleen aan een nieuw knooppunt toegewezen als er vrije poortblokken zijn. Vrije poortblokken betekenen dat er geen verbinding wordt aangeboden via een toegewezen poort in het poortblok.

Verder, bij het opnieuw aansluiten, herberekent elk knooppunt het aantal blokken dat het kan bezitten. Als een node meer blokken bevat dan het zou moeten, geeft het dergelijke extra poortblokken vrij aan de besturingsnode als en wanneer ze beschikbaar komen. De control node wijst ze vervolgens toe aan de nieuw samengevoegde data node.

V. Wordt het ook alleen ondersteund door TCP- en UDP-protocollen of SCTP?

A. SCTP werd nooit ondersteund met dynamische PAT. Voor SCTP-verkeer is de aanbeveling om alleen een statisch netwerkobject NAT te gebruiken.

V. Als een node geen blokpoorten meer heeft, laat hij dan pakketten vallen en gebruikt hij niet het volgende beschikbare IP-blok?

A. Nee, het zakt niet onmiddellijk. Het maakt gebruik van beschikbare poortblokken van de volgende PAT IP. Als alle poortblokken van alle PAT-IP's zijn uitgeput, daalt het verkeer.

V. Om de overbelasting van de besturingsnode in een venster voor clusterupgrades te voorkomen, is het beter om eerder handmatig een nieuw besturingselement te selecteren (bijvoorbeeld halverwege een clusterupgrade met 4 eenheden), in plaats van te wachten tot alle verbindingen op de besturingsnode zijn afgehandeld?

A. De controle moet als laatste worden bijgewerkt. Dit komt omdat wanneer de besturingsnode de nieuwere versie uitvoert, deze geen groepsdistributie initieert, tenzij alle knooppunten de nieuwere versie uitvoeren. Wanneer een upgrade wordt uitgevoerd, negeren alle gegevensknooppunten met een nieuwere versie bovendien de distributieberichten van een besturingsknooppunt als deze een oudere versie uitvoert.

Beschouw een clusterimplementatie met 4 knooppunten A, B, C en D als controle om dit in detail uit te leggen. Hier zijn de typische hitless upgrade stappen:

1. Download een nieuwe versie op elk van de knooppunten.
2. Eenheid "D" opnieuw laden. Alle verbindingen en datums worden verplaatst naar de back-upnode.
3. Eenheid D komt naar boven en:

a. Processen PAT-configuratie

b. Breekt elke PAT IP in poortblokken

c. Heeft alle poortblokken in niet-toegewezen staat

d. Negeert oudere versie van PAT-clusterberichten die zijn ontvangen van besturingselement

e. Hiermee worden alle PAT-verbindingen omgeleid naar Primair.

4. Breng ook andere knooppunten naar voren met de nieuwe versie.

5. Bedieningsorgaan "A" van de herlaadeenheid. Omdat er geen back-up voor controle is, worden alle bestaande verbindingen verwijderd

6. Het nieuwe besturingselement start de distributie van poortblokken in het nieuwere formaat

7. Eenheid "A" sluit zich opnieuw aan en kan berichten over de distributie van havenblokken aanvaarden en uitvoeren

fragmentbehandeling

Symptoom:

In inter-site clusterimplementaties kunnen gefragmenteerde pakketten die in 1 specifieke site moeten worden verwerkt (site-lokaal verkeer), nog steeds worden verzonden naar de eenheden op andere sites, omdat een van deze sites de eigenaar van het fragment kan hebben.

In clusterlogica is er een extra rol gedefinieerd voor verbindingen met gefragmenteerde pakketten: eigenaar van het fragment.

Voor gefragmenteerde pakketten bepalen clustereenheden die een fragment ontvangen een fragmenteigenaar op basis van een hash van het IP-adres van de fragmentbron, het IP-adres van de bestemming en de pakket-ID. Alle fragmenten worden vervolgens doorgestuurd naar de eigenaar van het fragment via de koppeling voor clusterbesturing. Fragmenten kunnen worden verdeeld over verschillende clustereenheden, omdat alleen het eerste fragment de 5-tuple bevat die wordt gebruikt in de hash voor de verdeling van de belasting van de switch. Andere fragmenten bevatten geen bron- en bestemmingspoorten en kunnen worden geladen in balans met andere clustereenheden. De eigenaar van het fragment stelt het pakket tijdelijk opnieuw samen, zodat het de regisseur kan bepalen op basis van een hash van het IP-adres en de poorten van de bron/bestemming. Als het een nieuwe verbinding is, wordt de eigenaar van het fragment de eigenaar van de verbinding. Als het een bestaande verbinding is, stuurt de eigenaar van het fragment alle fragmenten door naar de eigenaar van de verbinding via de koppeling voor clusterbesturing. De eigenaar van de verbinding herschikt vervolgens alle fragmenten.

Overweeg deze topologie met de stroom van een gefragmenteerd ICMP-echoverzoek van de client naar de server:

Om de volgorde van de bewerkingen te begrijpen, zijn er clusterbrede pakketopnames aan de binnenkant, buitenkant en clusterbesturingsverbindingsinterfaces geconfigureerd met de traceringsoptie. Daarnaast is een pakketopname met de optie opnieuw injecteren-verbergen geconfigureerd op de interne interface.

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

Volgorde van activiteiten binnen het cluster:

1. unit-1-1 in site 1 ontvangt de gefragmenteerde ICMP-echo-verzoekpakketten.

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 selecteert unit-2-2 in Site 2 als eigenaar van het fragment en stuurt er gefragmenteerde pakketten naar toe.
Het MAC-adres van de bestemming van de pakketten die van unit-1-1 naar unit-2-2 worden verzonden, is het MAC-adres van de CCL-koppeling in unit-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. Unit-2-2 ontvangt, herassembleert de gefragmenteerde pakketten en wordt de eigenaar van de stroom.

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. Unit-2-2 staat de pakketten toe op basis van het beveiligingsbeleid en verzendt ze via de externe interface van site 2 naar 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

Opmerkingen/kanttekeningen:

• In tegenstelling tot de rol van de regisseur, kan de eigenaar van het fragment niet worden gelokaliseerd binnen een bepaalde site. De eigenaar van het fragment wordt bepaald door de eenheid die oorspronkelijk de gefragmenteerde pakketten van een nieuwe verbinding ontvangt en zich op elke locatie kan bevinden.
• Aangezien een eigenaar van een fragment ook de eigenaar van de verbinding kan worden, moet hij, om de pakketten door te sturen naar de bestemmingshost, de uitgang-interface kunnen oplossen en de IP- en MAC-adressen van de bestemmingshost of de volgende hop kunnen vinden. Dit veronderstelt dat de volgende hop(s) ook de bereikbaarheid naar de bestemmingshoofd moet(en) hebben.
• Om de gefragmenteerde pakketten opnieuw samen te stellen, onderhoudt de ASA / FTD een IP-fragmentherassemblagemodule voor elke benoemde interface. Als u de operationele gegevens van de module voor het opnieuw samenvoegen van IP-fragmenten wilt weergeven, gebruikt u de opdracht fragment tonen:

  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

  In clusterimplementaties plaatst de eigenaar van het fragment of de eigenaar van de verbinding de gefragmenteerde pakketten in de fragmentwachtrij. De grootte van de fragmentwachtrij wordt beperkt door de waarde van de Grootteteller (standaard 200) die is geconfigureerd met de opdracht fragmentgrootte <size> <nameif>. Wanneer de grootte van de fragmentwachtrij 2/3 van de grootte bereikt, wordt de drempel voor de fragmentwachtrij als overschreden beschouwd en worden nieuwe fragmenten die geen deel uitmaken van de huidige fragmentketen, verwijderd. In dit geval wordt de drempel voor de Fragmentwachtrij overschreden verhoogd en wordt syslog-bericht FTD-3-209006 gegenereerd.

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.

Als tijdelijke oplossing kunt u de grootte vergroten in Firepower Management Center > Apparaten > Apparaatbeheer > [Apparaat bewerken] > Interfaces > [Interface] > Geavanceerd > Beveiligingsconfiguratie > Standaardfragmentinstelling negeren, configuratie opslaan en beleid implementeren. Controleer vervolgens de wachtrijteller in de opdracht fragment tonen en het optreden van syslog-bericht FTD-3-209006.

ACI-kwesties

Intermitterende connectiviteitsproblemen via het cluster als gevolg van actieve L4-controlesomverificatie in ACI Pod

Symptoom:

• Intermitterende connectiviteitsproblemen via het ASA/FTD-cluster dat wordt geïmplementeerd in een ACI Pod.
• Als er slechts 1 eenheid in het cluster is, worden de verbindingsproblemen niet waargenomen.
• Pakketten die van één clustereenheid naar één of meer andere eenheden in het cluster worden verzonden, zijn niet zichtbaar in de FXOS- en gegevensvlakopnamen van de doeleenheden.

verzachting

• Omgeleid verkeer via de koppeling voor clusterbesturing heeft geen juiste L4-controlesom en dit gedrag wordt verwacht. Switches op het koppelingspad voor clusterbesturingselementen mogen de L4-controlesom niet verifiëren. Switches die de L4 checksum controleren, kunnen ervoor zorgen dat het verkeer wordt weggelaten. Controleer de configuratie van de ACI Fabric switch en controleer of er geen L4-controlesom is uitgevoerd op de ontvangen of verzonden pakketten via de koppeling voor clusterbesturing. 

Problemen met clusterbesturingsvlak

Eenheid kan zich niet bij het cluster aansluiten

MTU-grootte op CCL 

Symptomen:

De eenheid kan zich niet bij het cluster aansluiten en dit bericht wordt weergegeven:

The SECONDARY 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 SECONDARY 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.

Verificatie/beperking:

• Gebruik de opdracht interface tonen op de FTD om te controleren of de MTU op de koppelingsinterface voor clusterbesturing ten minste 100 bytes hoger is dan de MTU voor de gegevensinterface:

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.

• Voer een ping uit via de CCL met de optie voor de grootte om te controleren of de configuratie op de CCL MTU correct is geconfigureerd op alle apparaten in het pad.

firepower# ping 127.2.1.1 size 9184

• Gebruik de opdracht interface tonen op de switch om de MTU-configuratie te controleren

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

Interfacemismatch tussen clustereenheden

Symptomen:

De eenheid kan zich niet bij het cluster aansluiten en dit bericht wordt weergegeven:

Interface mismatch between cluster primary 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.

Verificatie/beperking:

Meld u aan bij de FCM GUI op elk chassis, ga naar het tabblad Interfaces en controleer of alle clusterleden dezelfde interfaceconfiguratie hebben:

• Interfaces die aan het logische apparaat zijn toegewezen
• Beheersnelheid van de interfaces
• Admin duplex van de interfaces
• Interfacestatus

Probleem met gegevens/poort-kanaalinterface

Split-brain als gevolg van problemen met bereikbaarheid via de CCL

Symptoom:

Er zijn meerdere besturingseenheden in het cluster. Bekijk de volgende topologie:

Chassis 1: 

firepower# show cluster info

Cluster ftd_cluster1: On
Interface mode: spanned
This is "unit-1-1" in state PRIMARY
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 SECONDARY
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 SECONDARY
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

Chassis 2:

firepower# show cluster info

Cluster ftd_cluster1: On
Interface mode: spanned
This is "unit-2-1" in state PRIMARY
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 SECONDARY
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 SECONDARY
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

Verificatie:

• Gebruik de opdracht ping om de connectiviteit tussen de IP-adressen van de besturingseenheden van de clusterbesturingskoppeling (CCL) te verifiëren:

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)

• Controleer de ARP-tabel:

firepower# show arp 
cluster 127.2.2.3 0015.c500.026f 1
cluster 127.2.2.2 0015.c500.029f 1 

• Configureer en controleer in besturingseenheden de opnamen op de CCL-interfaces:

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

Mitigatie:

• Zorg ervoor dat de CCL-poortkanaalinterfaces zijn verbonden met afzonderlijke poortkanaalinterfaces op de switch.
• Wanneer Virtual Port-Channels (vPC) worden gebruikt op Nexus-switches, moet u ervoor zorgen dat de CCL-poortkanaalinterfaces zijn verbonden met verschillende vPC's en dat de vPC-configuratie niet de status voor consistentie heeft.
• Zorg ervoor dat de CCL-poortkanaalinterfaces zich in hetzelfde broadcast-domein bevinden en dat het CCL-VLAN is gemaakt en is toegestaan op de interfaces.

Dit is een voorbeeld van een 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 uitgeschakeld vanwege onderbroken gegevenspoort-kanaalinterfaces

Symptoom:

Een of meer gegevenspoort-kanaalinterfaces zijn opgeschort. Wanneer een beheerdersinterface wordt onderbroken, worden alle clustereenheden in hetzelfde chassis uit het cluster geschopt vanwege een fout in de statuscontrole van de interface.

Bekijk de volgende topologie:

Verificatie:

• Controleer de console van de besturingseenheid:

firepower# 
Beginning configuration replication to SECONDARY unit-2-2
End Configuration Replication to SECONDARY.
Asking SECONDARY 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.

• Controleer de uitvoer van de clustergeschiedenis tonen en de opdracht clusterinfo traceren module HC in de betreffende eenheid (eenheden):

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 SECONDARY to DISABLED


firepower# show cluster history 
==========================================================================
From State To State Reason
==========================================================================

12:59:37 UTC Dec 23 2020
ONCALL SECONDARY_COLD Received cluster control message

12:59:37 UTC Dec 23 2020
SECONDARY_COLD SECONDARY_APP_SYNC Client progression done

13:00:23 UTC Dec 23 2020
SECONDARY_APP_SYNC SECONDARY_CONFIG SECONDARY application configuration sync done

13:00:35 UTC Dec 23 2020
SECONDARY_CONFIG SECONDARY_FILESYS Configuration replication finished

13:00:36 UTC Dec 23 2020
SECONDARY_FILESYS SECONDARY_BULK_SYNC Client progression done

13:01:35 UTC Dec 23 2020
SECONDARY_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

• Controleer de uitvoer van de opdracht port-channel summary weergeven in de fxos command shell:

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)

Mitigatie:

• Zorg ervoor dat alle chassis dezelfde clustergroepnaam en hetzelfde wachtwoord hebben.
• Ervoor zorgen dat de poortkanaalinterfaces in alle chassis en switches voor de fysieke lidinterfaces dezelfde duplex-/snelheidsconfiguratie hebben ingeschakeld.
• In intra-site clusters moet ervoor worden gezorgd dat dezelfde poort-kanaalinterface voor gegevens in alle chassis is verbonden met dezelfde poort-kanaalinterface op de switch.
• Wanneer Virtual Port-Channels (vPC) worden gebruikt in Nexus-switches, moet u ervoor zorgen dat de vPC-configuratie niet de status voor een defecte consistentie heeft.
• In intra-site clusters moet ervoor worden gezorgd dat dezelfde interface tussen gegevenspoort en kanaal in alle chassis is verbonden met dezelfde vPC.

Problemen met clusterstabiliteit

FXOS-traceback

Symptoom:

De eenheid verlaat het cluster.

Verificatie/beperking:

• Gebruik de opdracht clustergeschiedenis weergeven om te zien wanneer de eenheid het cluster heeft verlaten

firepower# show cluster history

• Gebruik deze opdrachten om te controleren of de FXOS een traceback had

FPR4150# connect local-mgmt
FPR4150 (local-mgmt)# dir cores

• Verzamel het kernbestand dat is gegenereerd rond het tijdstip waarop de eenheid het cluster heeft verlaten en geef het aan TAC.

Schijf vol

In het geval dat het schijfgebruik in de /ngfw-partitie van een clustereenheid 94% bereikt, wordt de eenheid uit het cluster verwijderd. De controle van het schijfgebruik vindt elke 3 seconden plaats:

> 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

In dit geval toont de uitvoer van de clustergeschiedenis:

15:36:10 UTC May 19 2021
PRIMARY Event: Primary unit unit-1-1 is quitting
                    due to diskstatus Application health check failure, and
                    primary's application state is down

of

14:07:26 CEST May 18 2021
SECONDARY DISABLED Received control message DISABLE (application health check failure)

Een andere manier om het falen te controleren is:

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

Als de schijf ~100% is, kan het apparaat bovendien problemen ondervinden om weer deel te nemen aan het cluster totdat er enige schijfruimte is vrijgekomen.

overloopbeveiliging

Elke 5 minuten controleert elke clustereenheid de lokale en de peer-eenheid op CPU- en geheugengebruik. Als het gebruik hoger is dan de systeemdrempels (LINA CPU 50% of LINA geheugen 59%) wordt een informatief bericht weergegeven in:

• Syslogs (FTD-6-748008)
• Bestand log/cluster_trace.log, bijvoorbeeld:

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.

Het bericht geeft aan dat in het geval van een eenheid falen van de andere eenheid (en) middelen kunnen worden overtekend.

Vereenvoudigde modus

Gedrag bij FMC-releases vóór 6.3

• U registreert elk clusterknooppunt afzonderlijk op FMC.
• Vervolgens vormt u een logisch cluster in FMC.
• Voor elke nieuwe toevoeging van een clusternode moet u de node handmatig registreren.

Post-6.3 FMC:

• Met de functie Vereenvoudigde modus kunt u het hele cluster in één stap op FMC registreren (u hoeft slechts één node van het cluster te registreren).

Waarschuwing: zodra het cluster is gevormd op FTD, moet u wachten tot de automatische registratie van start gaat. U moet niet proberen de clusternodes handmatig te registreren (Apparaat toevoegen), maar de optie Reconcile gebruiken.

Symptoom:

Mislukte knooppuntenregistratie

• Als de registratie van de control node om welke reden dan ook mislukt, wordt het cluster verwijderd uit FMC.

Mitigatie:

Als de registratie van een gegevensknooppunt om welke reden dan ook mislukt, zijn er 2 opties:

1. Bij elke implementatie in het cluster controleert FMC of er clusternodes zijn die moeten worden geregistreerd en start vervolgens de automatische registratie voor deze nodes.
2. Er is een optie Verbinden beschikbaar onder het tabblad Clusteroverzicht (Apparaten > Apparaatbeheer > tabblad Cluster > koppeling Clusterstatus weergeven). Zodra de Reconcile-actie is geactiveerd, start de FMC met de automatische registratie van de nodes die moeten worden geregistreerd.

Gerelateerde informatie

• Clustering voor de verdediging tegen vuurkracht
• ASA-cluster voor het Firepower 4100/9300-chassis
• Over clustering op het Firepower 4100/9300-chassis
• Vuurkracht NGFW Clustering Deep Dive - BRKSEC-3032
• Vastleggingen van de Firepower-firewall analyseren om netwerkproblemen effectief te troubleshooten