Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konfiguration

Cluster-Grundlagen

NGFW-Architektur

Cluster-Erfassung

CCL-Nachrichten (Cluster Control Link)

Nachrichten von Cluster Control Point (CCP)

Cluster Health Check (HC)-Mechanismus

Szenarien für Cluster-HC-Ausfälle

Verbindungsaufbau für Cluster-Datenebene

Fehlerbehebung

Cluster-Datenebenenprobleme

Häufige Probleme mit NAT/PAT

Fragment-Verarbeitung

ACI-Probleme

Probleme mit der Cluster-Kontrollebene

Einheit kann dem Cluster nicht beitreten

Problem mit der Daten-/Port-Channel-Schnittstelle

Probleme mit der Cluster-Stabilität

Vereinfachter Modus

Zugehörige Informationen

Einführung

Dieses Dokument beschreibt die Fehlerbehebung bei einer Cluster-Konfiguration auf Firepower Next-Generation Firewall (NGFW). Die meisten in diesem Dokument behandelten Punkte gelten auch für die ASA-Cluster-Fehlerbehebung (Adaptive Security Appliance).

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in diesen Themen verfügen (Links finden Sie im Abschnitt Verwandte Informationen):

- Architektur der FirePOWER-Plattform

- Konfiguration und Betrieb des FirePOWER-Clusters

- Vertrautheit mit der FTD und der FXOS-CLI

- NGFW-/Datenebenenprotokolle

- Paket-Tracer für NGFW/Datenebene

- FirePOWER eXtensible Operating System (FXOS)/Datenebene erfasst

Verwendete Komponenten

- HW: FirePOWER 4125

- SW: 6.7.0 (Build 65) - Datenebene 9.15(1)

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konfiguration

Die Konfigurationskomponente einer Cluster-Bereitstellung wird in den FMC- und FXOS-Konfigurationsanleitungen behandelt:

- Clustering für den Schutz vor Bedrohungen durch Firepower

- Bereitstellung eines Clusters für Firepower Threat Defense für Skalierbarkeit und hohe Verfügbarkeit

Cluster-Grundlagen

NGFW-Architektur

Es ist wichtig zu verstehen, wie die Firepower 41xx- oder 93xx-Serie Transitpakete anwendet:

1. Ein Paket geht in die Eingangs-Schnittstelle ein, und es wird vom internen Switch des Chassis verarbeitet.

2. Das Paket wird über die Smart NIC übertragen. Wenn der Datenfluss ausgelagert wird (HW-Beschleunigung), wird das Paket ausschließlich von der Smart NIC verarbeitet und dann zurück an das Netzwerk gesendet.

3. Wenn das Paket nicht ausgelagert wird, gelangt es in die FTD-Datenebene, die hauptsächlich L3/L4-Überprüfungen durchführt.

4. Wenn die Richtlinie dies erfordert, wird das Paket von der Snort-Engine (hauptsächlich L7-Prüfung) überprüft.

5. Die Snort-Engine gibt ein Verdict (z. B. allow oder block) für das Paket zurück.

6. Die Datenebene verwirft oder leitet das Paket basierend auf dem Urteil von Snort weiter.

7. Das Paket leitet das Chassis über den internen Chassis-Switch aus.

Cluster-Erfassung

FirePOWER-Appliances bieten mehrere Erfassungspunkte, die einen transparenten Überblick über die Übertragungsflüsse ermöglichen. Bei der Fehlerbehebung und Aktivierung des Clusters ergeben sich folgende Hauptprobleme:

- Die Anzahl der Erfassungen steigt mit zunehmender Anzahl von Einheiten im Cluster

- Sie müssen wissen, wie der Cluster einen bestimmten Datenfluss behandelt, um das Paket durch den Cluster verfolgen zu können.

Dieses Diagramm zeigt einen Cluster mit zwei Einheiten (z. B. FP941xx/FP9300):

Im Falle einer asymmetrischen TCP-Verbindung, die ein TCP-SYN herstellt, sieht der SYN/ACK-Austausch wie folgt aus:

Datenverkehr weiterleiten

1. TCP-SYN wird von Host-A an Host-B gesendet.

2. TCP-SYN kommt im Chassis an (eine der Komponenten von Po1).

3. Die TCP-SYN wird über eine der Chassis-Backplane-Schnittstellen (z. B. E1/9, E1/10 usw.) an die Datenebene gesendet.

4. TCP-SYN kommt an der Datenebene-Eingangs-Schnittstelle an (Po1.201/INSIDE). In diesem Beispiel übernimmt Unit1-1 die Verantwortung für den Fluss, führt die Randomisierung der Initial Sequence Number (ISN) durch und codiert die Besitzerinformationen (Cookie) in der Suchnummer

5. TCP-SYN wird aus Po1.202/OUTSIDE (Datenebene-Ausgangsschnittstelle) gesendet.

6. TCP-SYN erreicht eine der Backplane-Schnittstellen im Chassis (z. B. E1/9, E1/10 usw.).

7. TCP-SYN wird von der physischen Chassis-Schnittstelle (eines der Mitglieder von Po1) an Host-B gesendet.

Rücksendungsverkehr

8. TCP-SYN/ACK wird von Host-B gesendet und erreicht Einheit-2-1 (eines der Mitglieder von Po1).

9. TCP-SYN/ACK wird über eine der Chassis-Backplane-Schnittstellen (z. B. E1/9, E1/10 usw.) an die Datenebene gesendet.

10. TCP SYN/ACK erreicht die Eingangs-Schnittstelle auf der Datenebene (Po1.202/OUTSIDE).

11. TCP-SYN/ACK wird über Cluster Control Link (CCL) an Einheit-1-1 gesendet. ISN ist standardmäßig aktiviert. Somit findet der Forwarder die Besitzerinformationen für TCP SYN+ACKs ohne Mitwirkung des Regisseurs. Bei anderen Paketen oder wenn ISN deaktiviert ist, wird der Director (Director) abgefragt.

12. TCP SYN/ACK erreicht eine der Backplane-Schnittstellen des Chassis (z. B. E1/9, E1/10 usw.).

13. TCP-SYN/ACK wird aus der physischen Chassis-Schnittstelle (eines der Elemente von Po48) an Einheit 1-1 gesendet.

14. TCP-SYN/ACK erreicht Einheit-1-1 (eines der Mitglieder von Po48).

15. TCP-SYN/ACK wird über eine der Chassis-Backplane-Schnittstellen an die CCL-Port-Channel-Schnittstelle der Datenebene weitergeleitet (d. h. Cluster).

16. Die Datenebene sendet das TCP-SYN/ACK-Paket an die Datenebenenschnittstelle Po1.202/OUTSIDE zurück.

17. TCP-SYN/ACK wird aus Po1.201/INSIDE (Datenebene-Ausgangsschnittstelle) an HOST-A gesendet.

18. Das TCP-SYN/ACK durchläuft eine der Backplane-Schnittstellen des Chassis (z. B. E1/9, E1/10 usw.) und führt einen der Member von Po1 aus.

19. TCP-SYN/ACK kommt auf Host-B an.

Weitere Einzelheiten zu diesem Szenario finden Sie im entsprechenden Abschnitt in den Anwenderberichten zur Clusterverbindungseinrichtung.

Basierend auf diesem Paketaustausch sind alle möglichen Cluster-Erfassungspunkte:

Für den Weiterleitungsverkehr (z. B. TCP SYN) erfassen Sie Folgendes:

1. Die physische Chassis-Schnittstelle (z. B. Po1-Member). Diese Erfassung wird über die Chassis Manager (CM)-Benutzeroberfläche oder die CM-CLI konfiguriert.

2. Eingangs-Schnittstelle der Datenebene (z. B. Po1.201 INSIDE).

3. Ausgangsschnittstelle der Datenebene (z. B. Po1.202 OUTSIDE).

4. Chassis-Backplane-Schnittstellen. Auf dem FP4100 gibt es zwei Backplane-Schnittstellen. Auf dem FP9300 sind insgesamt 6 (2 pro Modul) vorhanden. Da Sie nicht wissen, in welcher Schnittstelle das Paket ankommt, müssen Sie die Erfassung auf allen Schnittstellen aktivieren.

Erfassung des Rückverkehrs (z. B. TCP SYN/ACK) über:

5. Die physische Chassis-Schnittstelle (z. B. Po1-Member). Diese Erfassung wird über die Chassis Manager (CM)-Benutzeroberfläche oder die CM-CLI konfiguriert.

6. Datenebene-Eingangs-Schnittstelle (z. B. Po1.202 OUTSIDE).

7. Da das Paket umgeleitet wird, ist der nächste Erfassungspunkt die Datenebene CCL.

8. Chassis-Backplane-Schnittstellen. Auch hier müssen Sie die Erfassung auf beiden Schnittstellen aktivieren.

9. Chassis-CCL-Teilnehmerschnittstellen (Einheit 1-1).

10. CCL-Schnittstelle der Datenebene (Cluster genannt).

11. Eingangs-Schnittstelle (POS1.202 AUSSEN). Hierbei handelt es sich um das zurückgeleitete Paket von CCL zur Datenebene.

12. Ausgangsschnittstelle der Datenebene (z. B. Po1.201 INSIDE).

13. Chassis-Backplane-Schnittstellen.

Aktivieren der Cluster-Erfassung

FXOS-Erfassung

Der Vorgang wird im FXOS-Konfigurationshandbuch beschrieben: Paketerfassung

Hinweis: FXOS-Aufnahmen können nur aus Sicht des internen Switches in Eingangsrichtung ausgeführt werden.

Datenebenenerfassung

Die empfohlene Methode zur Aktivierung der Erfassung auf allen Cluster-Mitgliedern ist der Cluster Exec-Befehl.

Ein Cluster mit drei Einheiten ist denkbar:

Verwenden Sie folgenden Befehl, um zu überprüfen, ob in allen Cluster-Einheiten aktive Erfassungen vorhanden sind:

firepower# cluster exec show capture

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

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

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

firepower#

So aktivieren Sie eine Erfassung auf Datenebene auf allen Einheiten von Po1.201 (INSIDE):

firepower# cluster exec capture CAPI interface INSIDE

Es wird dringend empfohlen, einen Erfassungsfilter anzugeben, und falls Sie eine Menge Datenverkehr erwarten, um den Erfassungspuffer zu erhöhen:

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

Überprüfung

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

So zeigen Sie den Inhalt aller Erfassungen an (diese Ausgabe kann sehr lang sein):

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

Erfassung von Spuren

Wenn Sie sehen möchten, wie die eingehenden Pakete auf jeder Einheit von der Datenebene verarbeitet werden, verwenden Sie das trace-Schlüsselwort. Dadurch werden die ersten 50 eingehenden Pakete verfolgt. Sie können bis zu 1000 eingehende Pakete verfolgen. Beachten Sie, dass Sie bei Anwendung mehrerer Captures auf eine Schnittstelle nur ein einzelnes Paket zurückverfolgen können.

So verfolgen Sie die ersten 1000 eingehenden Pakete an der Schnittstelle OUTSIDE auf allen Cluster-Einheiten:

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

Wenn Sie den Interessensfluss erfasst haben, müssen Sie sicherstellen, dass Sie die für die einzelnen Einheiten relevanten Pakete verfolgen. Wichtig ist, dass ein bestimmtes Paket auf Einheit-1-1 vielleicht die Nummer 1, aber auf einer anderen Einheit die Nummer 2 ist.

In diesem Beispiel sehen Sie, dass die SYN/ACK-Nachricht Paket Nr. 2 auf Einheit 2-1, Paket Nr. 1 auf Einheit-3-1 lautet:

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>

So verfolgen Sie Paket Nr. 2 (SYN/ACK) auf der lokalen Einheit:

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

...

So verfolgen Sie dasselbe Paket (SYN/ACK) auf der Remote-Einheit:

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

So aktivieren Sie die Erfassung auf der CCL-Verbindung (auf allen Einheiten):

firepower# cluster exec capture CCL interface cluster

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

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

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

Ausblenden erneut auswerfen

Standardmäßig zeigt eine Erfassung, die auf einer Datenschnittstelle der Datenebene aktiviert ist, alle Pakete an:

- Die Anrufe aus dem physischen Netzwerk

- Die Dateien, die vom CCL zurückgewiesen werden

Wenn Sie die zurückgeleiteten Pakete nicht sehen möchten, verwenden Sie die Option zum Ausblenden mit erneuter Auswurffunktion. Dies kann hilfreich sein, wenn Sie überprüfen möchten, ob ein Fluss asymmetrisch ist:

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

Diese Erfassung zeigt nur, was die lokale Einheit tatsächlich auf der spezifischen Schnittstelle direkt vom physischen Netzwerk und nicht von den anderen Cluster-Einheiten erhält.

ASP-Drops

Wenn Sie nach Softwareverlusten für einen bestimmten Datenstrom suchen möchten, können Sie die asp-drop-Erfassung aktivieren. Wenn Sie nicht wissen, auf welchen Grund Sie sich konzentrieren sollten, verwenden Sie das Stichwort all. Wenn Sie nicht an der Paketnutzlast interessiert sind, können Sie außerdem das Headers-only-Schlüsselwort angeben. So können Sie 20- bis 30-mal mehr Pakete erfassen:

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

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

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

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

Darüber hinaus können Sie die IPs angeben, die von Interesse für die ASP-Erfassung sind:

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

Erfassen löschen

Löschen des Puffers einer beliebigen Erfassung, die in allen Cluster-Einheiten ausgeführt wird. Dadurch werden die Captures nicht gestoppt, sondern nur die Puffer gelöscht:

firepower# cluster exec clear capture /all

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

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

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

Erfassen beenden

Es gibt zwei Möglichkeiten, eine aktive Erfassung auf allen Cluster-Einheiten zu beenden. Später können Sie fortfahren.

Weg 1

firepower# cluster exec cap CAPI stop

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

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

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

Fortsetzen

firepower# cluster exec no capture CAPI stop

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

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

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

2. Weg

firepower# cluster exec no capture CAPI interface INSIDE

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

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

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

Fortsetzen

firepower# cluster exec capture CAPI interface INSIDE

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

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

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

Erfassen einer Erfassung

Es gibt mehrere Möglichkeiten, eine Erfassung zu exportieren.

Möglichkeit 1 - An einen Remote-Server

Dadurch können Sie eine Erfassung von der Datenebene auf einen Remote-Server (z. B. TFTP) hochladen. Beachten Sie, dass die Erfassungsnamen automatisch geändert werden, um die Quelleinheit wiederzugeben:

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 !

Die hochgeladenen pcap-Dateien:

Möglichkeit 2: Abrufen der Aufnahmen vom FMC

Dies gilt nur für FTD. Zuerst kopieren Sie die Erfassung auf die FTD-Festplatte:

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

Kopieren Sie die Datei im Expertenmodus aus dem Verzeichnis /mnt/disk0/ in das Verzeichnis /ngfw/var/common/:

> expert

admin@firepower:~$ cd /mnt/disk0

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

Navigieren Sie schließlich auf dem FMC zum Abschnitt System > Health > Monitor (System > Zustand > Monitor). Wählen Sie System- und Fehlerbehebungsdetails anzeigen > Erweiterte Fehlerbehebung aus, und rufen Sie die Erfassungsdatei ab:

Erfassen löschen

Um eine Erfassung aus allen Cluster-Einheiten zu entfernen, verwenden Sie den folgenden Befehl:

firepower# cluster exec no capture CAPI

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

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

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

Offload-Abläufe

Auf FP41xx/FP9300 können Flows entweder statisch (z. B. Fastpath-Regeln) oder dynamisch an HW Accelerator ausgelagert werden. Weitere Informationen zum Flow-Offload finden Sie in diesem Dokument:

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

Wenn ein Datenfluss ausgelagert wird, durchlaufen nur wenige Pakete die FTD-Datenebene. Der Rest wird vom HW Accelerator (Smart NIC) übernommen.

Aus Erfassungssicht bedeutet dies, dass, wenn Sie nur FTD-Datenerfassungen aktivieren, nicht alle Pakete angezeigt werden, die das Gerät durchlaufen. In diesem Fall müssen Sie auch die Erfassung auf Chassis-Ebene von FXOS aktivieren.

CCL-Nachrichten (Cluster Control Link)

Wenn Sie eine Erfassung im CCL vornehmen, stellen Sie fest, dass die Cluster-Einheiten verschiedene Arten von Nachrichten austauschen. Interessant sind:

Protokolle

Beschreibung

UDP 49495

Cluster-Heartbeats (Keepalives)

· L3-Broadcast (255.255.255.255)

· Diese Pakete werden von jeder Cluster-Einheit mit einem Drittel des Haltezeitwerts für die Statusprüfung gesendet.

· Beachten Sie, dass nicht alle bei der Erfassung erkannten UDP 49495-Pakete Heartbeats sind.

· Die Heartbeats enthalten eine Folgenummer

UDP 4193

Datenpfadnachrichten im Cluster Control Protocol

Unicast

· Diese Pakete enthalten Informationen (Metadaten) zum Besitzer des Datenflusses, zum Director, zum Eigentümer des Backups usw. Beispiele:

· Beim Erstellen eines neuen Datenflusses wird eine "Cluster-Add"-Nachricht vom Eigentümer an den Director gesendet.

· Wenn ein Datenfluss beendet wird, wird eine "Cluster-Löschen"-Nachricht vom Eigentümer an den Director gesendet.

Datenpakete

Datenpakete, die zu den verschiedenen Datenverkehrsflüssen gehören, die den Cluster durchlaufen

Cluster-Heartbeat

Nachrichten von Cluster Control Point (CCP)

Neben den Heartbeat-Nachrichten gibt es eine Reihe von Cluster-Kontrollnachrichten, die in bestimmten Szenarien über den CCL ausgetauscht werden. Einige von ihnen sind Unicast-Nachrichten, während andere Broadcasts sind.

CLUSTER_QUIT_REASON_MASTER_UNIT_HC

Wenn ein Gerät drei aufeinander folgende Heartbeat-Nachrichten vom Kontrollknoten verliert, generiert es eine CLUSTER_QUIT_REASON_MASTER_UNIT_HC-Nachricht über den CCL. Diese Nachricht:

- Ist Unicast

- Sie wird mit einem Intervall von 1 Sek. an alle Einheiten gesendet

- Wenn ein Gerät diese Nachricht empfängt, beendet das Cluster (DISABLED) und schließt sich erneut an

F. Wozu dient CLUSTER_QUIT_REASON_MASTER_UNIT_HC?

Antwort: Aus Sicht der Einheit-3-1 (Standort-B) verliert sie die Verbindung sowohl zu Einheit-1-1 als auch zu Einheit-2-1 von Standort A, sodass sie so schnell wie möglich aus der Mitgliedsliste entfernt werden müssen. Andernfalls kann das Paket verloren gehen, wenn Einheit-2-1 weiterhin in der Mitgliedsliste steht und Einheit-2-1 zufällig der Leiter einer Verbindung ist und die Datenflussabfrage zu Einheit-2-1 fehlschlägt.

CLUSTER_QUIT_REASON_UNIT_HC

Wenn der Kontrollknoten drei aufeinander folgende Heartbeat-Nachrichten von einem Datenknoten verliert, sendet er eine CLUSTER_QUIT_REASON_UNIT_HC-Nachricht über den CCL. Diese Nachricht ist Unicast.

CLUSTER_QUIT_REASON_STRAY_MEMBER

Wenn eine Split-Partition erneut mit einer Peer-Partition verbunden wird, wird der neue Datenknoten von der dominierenden Kontrolleinheit als Streammitglied behandelt und erhält eine CCP-quit-Nachricht mit dem Grund CLUSTER_QUIT_REASON_STRAY_MEMBER.

CLUSTER_QUIT_MEMBER_DROPOUT

Eine Broadcast-Nachricht, die von einem Datenknoten generiert und als Broadcast gesendet wird. Sobald ein Gerät diese Nachricht erhält, wechselt der Status DEABLED (DEAKTIVIERT). Darüber hinaus startet die automatische Wiederherstellung nicht:

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

Der Cluster-Verlauf zeigt Folgendes an:

MASTER       DISABLED      Received control message DISABLE (member dropout announcement)

Cluster Health Check (HC)-Mechanismus

Hauptpunkte

- Jede Cluster-Einheit sendet einen Heartbeat-Wert für alle ein Drittel der Haltezeit für Statusprüfungen an alle anderen Einheiten (Broadcast 255.255.255.255) und verwendet den UDP-Port 49495 als Transport über die CCL.

- Jede Cluster-Einheit verfolgt jede andere Einheit unabhängig mit einem Abfragetimer und einem Zählwert.

- Wenn eine Cluster-Einheit innerhalb eines Heartbeat-Intervalls kein Paket (Heartbeat- oder Datenpaket) von einer Cluster-Peer-Einheit empfängt, erhöht dies den Wert für die Umfrageanzahl.

- Wenn der Wert für die Umfrageanzahl für eine Cluster-Peer-Einheit zu 3 wird, gilt der Peer als ausgefallen.

- Wenn ein Heartbeat empfangen wird, wird seine Sequenznummer überprüft und der Diff mit dem zuvor empfangenen Heartbeat anders als 1 ist, erhöht sich der Heartbeat-Drop-Zähler entsprechend.

- Wenn der Zähler für die Umfrageanzahl für einen Cluster-Peer nicht 0 ist und ein Paket vom Peer empfangen wird, wird der Zähler auf den Wert 0 zurückgesetzt.

Verwenden Sie diesen Befehl, um die Cluster-Gesundheitszähler zu überprüfen:

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|

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

Beschreibung der Hauptspalten

Spalte

Beschreibung

Einheit (ID)

Die ID des Remote-Cluster-Peers

Heartbeat-Anzahl

Die Anzahl der vom Remote-Peer über CCL empfangenen Heartbeats

Herzschlag-Verfall

Die Anzahl der versäumten Herzschläge. Dieser Zähler wird basierend auf der empfangenen Heartbeat-Sequenznummer berechnet

Durchschnittliche Lücke

Das durchschnittliche Zeitintervall der empfangenen Herzschläge.

Umfrageanzahl

Wenn dieser Zähler zu 3 wird, wird die Einheit aus dem Cluster entfernt. Das Abfrageintervall entspricht dem Heartbeat-Intervall, wird jedoch unabhängig voneinander ausgeführt.

Um die Zähler zurückzusetzen, verwenden Sie den folgenden Befehl:

firepower# clear cluster info health details

F. Überprüfen der Heartbeat-Frequenz

Antwort: Durchschnittlicher Lückenwert überprüfen:

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|

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

F. Wie können Sie die Haltezeit des Clusters in FTD ändern?

Antwort: FlexConfig verwenden

F. Wer wird nach einem Split-Gehirn der Kontrollknoten?

Antwort: Die Einheit mit der höchsten Priorität (niedrigste Nummer):

firepower# show run cluster | include priority

priority 9

Weitere Einzelheiten finden Sie in Szenario 1 des HC-Ausfalls.

Visualisierung des Cluster-HC-Mechanismus

Indikative Timer: Die Min. und Max. hängen von der zuletzt empfangenen CCL-Paketankündigung ab.

Haltezeit

Abfrage-Prüfung

(Häufigkeit)

Minimale Erkennungszeit

Max. Erkennungszeit

3 Sek. (Standard)

ca. 1 Sek.

~3,01 Sek.

~3,99 Sek.

4 Sek.

~1,33 Sek.

~4,01 Sek.

~5,32 Sek.

5 Sek.

~1,66 Sek.

~5,01 Sek.

~6,65 Sek.

6 Sek.

~2 Sekunden

~6,01 Sek.

~7,99 Sek.

7 Sek.

~2,33 Sek.

~7,01 Sek.

~9,32 Sek.

8 Sek.

~2,66 Sek.

~8,01 Sek.

~10,65 Sek.

Szenarien für Cluster-HC-Ausfälle

Die Ziele dieses Abschnitts sind, Folgendes zu demonstrieren:

- Unterschiedliche Cluster-HC-Fehlerszenarien

- Wie die verschiedenen Protokolle und Befehlsausgaben korreliert werden können

Topologie

Clusterkonfiguration

Einheit-1-1

Einheit-2-1

Einheit-3-1

cluster group GROUP1

key *****

local-unit unit-1-1

cluster-interface Port-channel48 ip 192.222.1.1 255.255.0.0

priority 9

health-check holdtime 3

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

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

health-check system auto-rejoin 3 5 2

health-check monitor-interface debounce-time 500

site-id 1

enable

cluster group GROUP1

key *****

local-unit unit-2-1

cluster-interface Port-channel48 ip 192.222.2.1 255.255.0.0

priority 17

health-check holdtime 3

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

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

health-check system auto-rejoin 3 5 2

health-check monitor-interface debounce-time 500

site-id 1

enable

cluster group GROUP1

key *****

local-unit unit-3-1

cluster-interface Port-channel48 ip 192.222.3.1 255.255.0.0

priority 25

health-check holdtime 3

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

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

health-check system auto-rejoin 3 5 2

health-check monitor-interface debounce-time 500

site-id 2

enable

Cluster-Status

Einheit-1-1

Einheit-2-1

Einheit-3-1

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

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

ID        : 0

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

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

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

Other members in the cluster:

Unit "unit-3-1" in state SLAVE

ID        : 1

Site ID   : 2

Version   : 9.12(2)33

Serial No.: FCH22247MKJ

CCL IP    : 192.222.3.1

CCL MAC   : 0015.c500.038f

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

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

Unit "unit-2-1" in state SLAVE

ID        : 2

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

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

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

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

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

ID        : 2

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

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

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

Other members in the cluster:

Unit "unit-1-1" in state MASTER

ID        : 0

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

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

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

Unit "unit-3-1" in state SLAVE

ID        : 1

Site ID   : 2

Version   : 9.12(2)33

Serial No.: FCH22247MKJ

CCL IP    : 192.222.3.1

CCL MAC   : 0015.c500.038f

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

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

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

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

ID        : 1

Site ID   : 2

Version   : 9.12(2)33

Serial No.: FCH22247MKJ

CCL IP    : 192.222.3.1

CCL MAC   : 0015.c500.038f

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

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

Other members in the cluster:

Unit "unit-1-1" in state MASTER

ID        : 0

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

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

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

Unit "unit-2-1" in state SLAVE

ID        : 2

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

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

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

Szenario 1

CCL-Kommunikationsverlust für ~4+ Sekunden in beide Richtungen

Vor dem Ausfall

FTD1

FT2

FTD3

Standort A

Standort A

Standort B

Kontrollknoten

Datenknoten

Datenknoten

Nach der Wiederherstellung (keine Änderungen in den Rollen der Einheiten)

FTD1

FT2

FTD3

Standort A

Standort A

Standort B

Kontrollknoten

Datenknoten

Datenknoten

Analyse

Der Fehler (CCL-Kommunikation ist verloren gegangen)

Die Datenebenenkonsolenmeldung auf Einheit-3-1:

firepower#

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

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

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

Cluster disable is performing cleanup..done.

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

To recover either enable clustering or remove cluster group configuration.

Cluster-Ablaufverfolgungsprotokolle für Einheit-1-1:

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

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

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

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

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

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

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

Split-Gehirn

Einheit-1-1

Einheit-2-1

Einheit-3-1

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

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

ID        : 0

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

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

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

Other members in the cluster:

Unit "unit-2-1" in state SLAVE

ID        : 2

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

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

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

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

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

ID        : 2

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

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

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

Other members in the cluster:

Unit "unit-1-1" in state MASTER

ID        : 0

Site ID   : 1

Version   : 9.12(2)33

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

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

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

firepower# show cluster info

Cluster GROUP1: On

Interface mode: spanned

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

ID        : 1

Site ID   : 2

Version   : 9.12(2)33

Serial No.: FCH22247MKJ

CCL IP    : 192.222.3.1

CCL MAC   : 0015.c500.038f

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

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

Other members in the cluster:

There is no other unit in the cluster

Clusterverlauf

Einheit-1-1

Einheit-2-1

Einheit-3-1

Keine Veranstaltungen

Keine Veranstaltungen

09:38:16 UTC Nov 2 2020

SLAVE                 MASTER_POST_CONFIG    Master relinquished role

09:38:17 UTC Nov 2 2020

MASTER_POST_CONFIG    MASTER                Master post config done and waiting for ntfy

Wiederherstellung der CCL-Kommunikation

Unit-1-1 erkennt den aktuellen Kontrollknoten und sendet, da Einheit-1-1 eine höhere Priorität hat, eine CLUSTER_QUIT_REASON_STRAY_MEMBER-Nachricht an Einheit-3-1, um einen neuen Wahlvorgang zu starten. Am Ende schließt sich Einheit-3-1 wieder als Datenknoten an.

Wenn eine Split-Partition erneut mit einer Peer-Partition verbunden wird, wird der Datenknoten vom dominierenden Kontrollknoten als Streammitglied behandelt und erhält eine CCP-quit-msg mit einem Grund für CLUSTER_QUIT_REASON_STRAY_MEMBER.

Unit-3-1 console logs show:

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

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

Detected Cluster Master.

Beginning configuration replication from Master.

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

..

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

End configuration replication from Master.

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

Beide Einheiten (Einheit-1-1 und Einheit-3-1) werden in ihren Clusterprotokollen angezeigt:

firepower# show cluster info trace | include retain

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

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

Es werden auch Syslog-Meldungen für das Split-Gehirn generiert:

firepower# show log | include 747016

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

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

Clusterverlauf

Einheit-1-1

Einheit-2-1

Einheit-3-1

Keine Veranstaltungen

Keine Veranstaltungen

09:47:33 UTC Nov 2 2020

MASTER                DISABLED        Detected a splitted cluster

09:47:38 UTC Nov 2 2020

DISABLED              ELECTION        Enabled from CLI

09:47:38 UTC Nov 2 2020

ELECTION              SLAVE_COLD      Received cluster control message

09:47:38 UTC Nov 2 2020

SLAVE_COLD            SLAVE_APP_SYNC  Client progression done

09:48:18 UTC Nov 2 2020

SLAVE_APP_SYNC        SLAVE_CONFIG    Slave application configuration sync done

09:48:29 UTC Nov 2 2020

SLAVE_CONFIG          SLAVE_FILESYS   Configuration replication finished

09:48:30 UTC Nov 2 2020

SLAVE_FILESYS         SLAVE_BULK_SYNC Client progression done

09:48:54 UTC Nov 2 2020

SLAVE_BULK_SYNC       SLAVE           Client progression done

Szenario 2

CCL-Kommunikationsverlust für ~3-4 Sek. in beide Richtungen

Vor dem Ausfall

FTD1

FT2

FTD3

Standort A

Standort A

Standort B

Kontrollknoten

Datenknoten

Datenknoten

Nach der Wiederherstellung (keine Änderungen in den Rollen der Einheiten)

FTD1

FT2

FTD3

Standort A

Standort A

Standort B

Kontrollknoten

Datenknoten

Datenknoten

Analyse

Veranstaltung 1: Der Steuerungsknoten verliert 3 HCs von der Einheit-3-1 und sendet eine Nachricht an Einheit-3-1, um den Cluster zu verlassen.

Veranstaltung 2: Der CCL hat sich sehr schnell wiederhergestellt, und die CLUSTER_QUIT_REASON_STRAY_MEMBER-Nachricht vom Steuerungsknoten hat sie zur Remote-Seite weitergeleitet. Gerät-3-1 wechselt direkt in den DEAKLED-Modus und es gibt kein Split-Hirn

Auf Einheit-1-1 (Steuerung) sehen Sie:

firepower#

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

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

Auf Einheit-3-1 (Datenknoten) sehen Sie:

firepower#

Cluster disable is performing cleanup..done.

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

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

Cluster-Einheit-3-1 wechselt in DISABLED-Status und schließt sich nach Wiederherstellung der CCL-Kommunikation wieder als Datenknoten an:

firepower# show cluster history

20:58:40 UTC Nov 1 2020

SLAVE                 DISABLED              Received control message DISABLE (stray member)

20:58:45 UTC Nov 1 2020

DISABLED              ELECTION              Enabled from CLI

20:58:45 UTC Nov 1 2020

ELECTION              SLAVE_COLD            Received cluster control message

20:58:45 UTC Nov 1 2020

SLAVE_COLD            SLAVE_APP_SYNC        Client progression done

20:59:33 UTC Nov 1 2020

SLAVE_APP_SYNC        SLAVE_CONFIG          Slave application configuration sync done

20:59:44 UTC Nov 1 2020

SLAVE_CONFIG          SLAVE_FILESYS         Configuration replication finished

20:59:45 UTC Nov 1 2020

SLAVE_FILESYS         SLAVE_BULK_SYNC       Client progression done

21:00:09 UTC Nov 1 2020

SLAVE_BULK_SYNC       SLAVE                 Client progression done

Szenario 3

CCL-Kommunikationsverlust für ~3-4 Sek. in beide Richtungen

Vor dem Ausfall

FTD1

FT2

FTD3

Standort A

Standort A

Standort B

Kontrollknoten

Datenknoten

Datenknoten

Nach der Wiederherstellung (der Kontrollknoten wurde geändert)

FTD1

FT2

FTD3

Standort A

Standort A

Standort B

Datenknoten

Kontrollknoten

Datenknoten

Analyse

1. CCL wird deaktiviert.

2. Unit-1-1 empfängt nicht 3 HC-Nachrichten von Einheit-3-1 und sendet eine QUIT-Nachricht an Einheit-3-1. Diese Nachricht erreicht nie Unit-3-1

3. Einheit-3-1 sendet eine QUIT-Nachricht an Einheit-2-1. Diese Nachricht erreicht nie Unit-2-1.

CCL-Wiederherstellung

4. In Unit-1-1 wird die Meldung Unit-3-1 als Kontrollknoten angezeigt und sendet eine QUIT_REASON_STRAY_MEMBER-Nachricht an Unit-3-1. Sobald Einheit-3-1 diese Nachricht erhält, wechselt sie in den Status DISABLED. Gleichzeitig sendet die Einheit-3-1 eine QUIT_REASON_MASTER_UNIT_HC-Nachricht an Unit-1-1 und fordert sie auf, den Vorgang zu beenden. Sobald die Einheit-1-1 diese Nachricht erhält, wechselt sie in den Status DEAKTIVIERT

Clusterverlauf

Einheit-1-1

Einheit-2-1

Einheit-3-1

19:53:09 UTC Nov 2 2020

MASTER                DISABLED        Received control message DISABLE

(master unit health check failure)

19:53:13 UTC Nov 2 2020

DISABLED              ELECTION         Enabled from CLI

19:53:13 UTC Nov 2 2020

ELECTION              SLAVE_COLD       Received cluster control message

19:53:13 UTC Nov 2 2020

SLAVE_COLD            SLAVE_APP_SYNC   Client progression done

19:54:01 UTC Nov 2 2020

SLAVE_APP_SYNC        SLAVE_CONFIG     Slave application configuration sync done

19:54:12 UTC Nov 2 2020

SLAVE_CONFIG          SLAVE_FILESYS    Configuration replication finished

19:54:13 UTC Nov 2 2020

SLAVE_FILESYS         SLAVE_BULK_SYNC  Client progression done

19:54:37 UTC Nov 2 2020

SLAVE_BULK_SYNC       SLAVE            Client progression done

19:53:06 UTC Nov 2 2020

SLAVE      MASTER_POST_CONFIG  Master relinquished role

19:53:07 UTC Nov 2 2020

MASTER_POST_CONFIG  MASTER     Master post config done

and waiting for ntfy

19:53:06 UTC Nov 2 2020

SLAVE              MASTER_POST_CONFIG  Master relinquished role

19:53:07 UTC Nov 2 2020

MASTER_POST_CONFIG    MASTER           Master post config done

and waiting for ntfy

19:53:09 UTC Nov 2 2020

MASTER                DISABLED         Detected a splitted cluster

19:53:15 UTC Nov 2 2020

DISABLED              ELECTION         Enabled from CLI

...

19:53:20 UTC Nov 2 2020

ELECTION              ONCALL           Received cluster control message

19:54:44 UTC Nov 2 2020

ONCALL                SLAVE_COLD       Received cluster control message

19:54:44 UTC Nov 2 2020

SLAVE_COLD            SLAVE_APP_SYNC   Client progression done

19:55:32 UTC Nov 2 2020

SLAVE_APP_SYNC        SLAVE_CONFIG     Slave application

configuration sync done

19:55:43 UTC Nov 2 2020

SLAVE_CONFIG          SLAVE_FILESYS    Configuration replication finished

19:55:44 UTC Nov 2 2020

SLAVE_FILESYS         SLAVE_BULK_SYNC  Client progression done

19:56:08 Nov 2 2020

SLAVE_BULK_SYNC       SLAVE            Client progression done

Szenario 4

CCL-Kommunikationsverlust von ~3-4 Sek.

Vor dem Ausfall

FTD1

FT2

FTD3

Standort A

Standort A

Standort B

Kontrollknoten

Datenknoten

Datenknoten

Nach der Wiederherstellung (der Kontrollknoten hat die Standorte geändert)

FTD1

FT2

FTD3

Standort A

Standort A

Standort B

Datenknoten

Datenknoten

Kontrollknoten

Analyse

Der Ausfall

Eine andere Variante desselben Fehlers. In diesem Fall erhielt die Einheit-1-1 auch nicht 3 HC-Nachrichten von der Einheit-3-1 und nachdem sie einen neuen Keepalive erhalten hatte, der versucht hat, die Einheit-3-1 mithilfe einer STRAY-Nachricht zu starten, aber die Nachricht hat es nie zur Einheit-3-1 geschafft:

1. CCL wird für einige Sekunden unidirektional. Unit-3-1 empfängt nicht 3 HC-Meldungen von Einheit-1-1 und wird zum Kontrollknoten

2. Unit-2-1 sendet eine CLUSTER_QUIT_REASON_RETIREMENT-Nachricht (Broadcast)

3. Unit-3-1 sendet eine QUIT_REASON_MASTER_UNIT_HC-Nachricht an Unit-2-1. Gerät 2-1 empfängt es und beendet den Cluster.

4. Unit-3-1 sendet eine QUIT_REASON_MASTER_UNIT_HC-Nachricht an Unit-1-1. Gerät 1-1 empfängt es und beendet den Cluster. CCL-Wiederherstellungen.

5. Einheiten-1-1 und 2-1 treten erneut als Datenknoten in den Cluster ein

Hinweis

Wenn in Schritt 5 die CCL nicht wiederhergestellt wird, wird in Standort-A die FTD1 zum neuen Kontrollknoten, und nach der CCL-Wiederherstellung gewinnt sie die neue Wahl.

Syslog-Meldungen auf Einheit-1-1:

firepower# show log | include 747

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

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

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

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

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

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

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

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

Cluster-Nachverfolgungsprotokolle für Einheit-1-1:

firepower# show cluster info trace | include QUIT

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

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

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

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

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

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

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

Syslog-Meldungen auf Einheit-3-1:

firepower# show log | include 747

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

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

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

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

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

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

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

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

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

Clusterverlauf

Einheit-1-1

Einheit-2-1

Einheit-3-1

23:13:13 UTC Nov 3 2020

MASTER          DISABLED        Received control message DISABLE

(master unit health check failure)

23:13:18 UTC Nov 3 2020

DISABLED        ELECTION        Enabled from CLI

23:13:18 UTC Nov 3 2020

ELECTION        ONCALL          Received cluster control message

23:13:23 UTC Nov 3 2020

ONCALL          ELECTION        Received cluster control message

…

23:14:48 UTC Nov 3 2020

ONCALL          ELECTION        Received cluster control message

23:14:48 UTC Nov 3 2020

ELECTION        SLAVE_COLD      Received cluster control message

23:14:48 UTC Nov 3 2020

SLAVE_COLD      SLAVE_APP_SYNC  Client progression done

23:15:36 UTC Nov 3 2020

SLAVE_APP_SYNC  SLAVE_CONFIG    Slave application configuration

sync done

23:15:48 UTC Nov 3 2020

SLAVE_CONFIG    SLAVE_FILESYS   Configuration replication finished

23:15:49 UTC Nov 3 2020

SLAVE_FILESYS   SLAVE_BULK_SYNC Client progression done

23:16:13 UTC Nov 3 2020

SLAVE_BULK_SYNC SLAVE           Client progression done

23:13:12 UTC Nov 3 2020

SLAVE           DISABLED         Received control message DISABLE

(master unit health check failure)

23:13:17 UTC Nov 3 2020

DISABLED        ELECTION         Enabled from CLI

23:13:17 UTC Nov 3 2020

ELECTION        SLAVE_COLD       Received cluster control message

23:13:17 UTC Nov 3 2020

SLAVE_COLD      SLAVE_APP_SYNC   Client progression done

23:14:05 UTC Nov 3 2020

SLAVE_APP_SYNC  SLAVE_CONFIG     Slave application configuration

sync done

23:14:16 UTC Nov 3 2020

SLAVE_CONFIG    SLAVE_FILESYS    Configuration replication finished

23:14:17 UTC Nov 3 2020

SLAVE_FILESYS   SLAVE_BULK_SYNC  Client progression done

23:14:41 UTC Nov 3 2020

SLAVE_BULK_SYNC SLAVE            Client progression done

23:13:10 UTC Nov 3 2020

SLAVE    MASTER_POST_CONFIG  Master relinquished role

23:13:11 UTC Nov 3 2020

MASTER_POST_CONFIG MASTER   Master post config

done and waiting for ntfy

Szenario 5

Vor dem Ausfall

FTD1

FT2

FTD3

Standort A

Standort A

Standort B

Kontrollknoten

Datenknoten

Datenknoten

Nach der Wiederherstellung (keine Änderungen)

FTD1

FT2

FTD3

Standort A

Standort A

Standort B

Kontrollknoten

Datenknoten

Datenknoten

Der Ausfall

Unit-3-1 sendete QUIT-Nachrichten an Einheit-1-1 und Einheit-2-1, aber aufgrund von Verbindungsproblemen empfing nur Gerät-2-1 die QUIT-Nachricht.

Cluster-Ablaufverfolgungsprotokolle für Einheit-1-1:

firepower# show cluster info trace | include QUIT

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

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

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

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

Cluster-Ablaufverfolgungsprotokolle für Einheit-2-1:

firepower# show cluster info trace | include QUIT

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

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

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

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

Clusterverlauf

Einheit-1-1

Einheit-2-1

Einheit-3-1

Keine Veranstaltungen

00:51:50 UTC Nov 4 2020

SLAVE            DISABLED         Received control message DISABLE

(master unit health check failure)

00:51:54 UTC Nov 4 2020

DISABLED         ELECTION         Enabled from CLI

00:51:54 UTC Nov 4 2020

ELECTION         SLAVE_COLD       Received cluster control message

00:51:54 UTC Nov 4 2020

SLAVE_COLD       SLAVE_APP_SYNC   Client progression done

00:52:42 UTC Nov 4 2020

SLAVE_APP_SYNC   SLAVE_CONFIG     Slave application configuration

sync done

00:52:54 UTC Nov 4 2020

SLAVE_CONFIG     SLAVE_FILESYS    Configuration replication finished

00:52:55 UTC Nov 4 2020

SLAVE_FILESYS    SLAVE_BULK_SYNC  Client progression done

00:53:19 UTC Nov 4 2020

SLAVE_BULK_SYNC  SLAVE            Client progression done

00:51:47 UTC Nov 4 2020

SLAVE        MASTER_POST_CONFIG  Master relinquished role

00:51:48 UTC Nov 4 2020

MASTER_POST_CONFIG MASTER        Master post config done and

waiting for ntfy

00:52:12 UTC Nov 4 2020

MASTER           DISABLED        Detected a splitted cluster

00:52:17 UTC Nov 4 2020

DISABLED         ELECTION        Enabled from CLI

00:52:17 UTC Nov 4 2020

ELECTION         ONCALL          Received cluster control message

00:53:25 UTC Nov 4 2020

ONCALL           SLAVE_COLD      Received cluster control message

00:53:25 UTC Nov 4 2020

SLAVE_COLD       SLAVE_APP_SYNC  Client progression done

00:54:12 UTC Nov 4 2020

SLAVE_APP_SYNC   SLAVE_CONFIG    Slave application configuration

sync done

00:54:24 UTC Nov 4 2020

SLAVE_CONFIG     SLAVE_FILESYS   Configuration replication finished

00:54:25 UTC Nov 4 2020

SLAVE_FILESYS    SLAVE_BULK_SYNC Client progression done

00:54:49 UTC Nov 4 2020

SLAVE_BULK_SYNC  SLAVE           Client progression done

Verbindungsaufbau für Cluster-Datenebene

NGFW-Erfassungspunkte

Die NGFW bietet die folgenden Funktionen zur Erfassung:

- Interner Switch im Chassis (FXOS)

- FTD-Datenebenenmotor

- FTD-Snort-Engine

Bei der Fehlerbehebung von Datenpfadproblemen in einem Cluster kommen in den meisten Fällen die FXOS- und FTD-Engine-Erfassungen für Datenebenen zum Einsatz.

1. FXOS-Eingangserfassung auf der physischen Schnittstelle

2. FTD-Eingangserfassung in Datenebenenmotor

3. FTD-Ausgangs-Erfassung auf Datenebene Engine

4. FXOS-Eingangserfassung an Backplane-Schnittstelle

Weitere Einzelheiten zu NGFW-Erfassungen finden Sie in diesem Dokument:

Grundlagen zu Cluster-Unit-Flow-Rollen

Verbindungen können über einen Cluster auf verschiedene Weise hergestellt werden, die von Faktoren wie den folgenden abhängen:

- Art des Datenverkehrs (TCP, UDP usw.)

- Auf dem benachbarten Switch konfigurierter Lastenausgleichsalgorithmus

- Auf der Firewall konfigurierte Funktionen

- Netzwerkbedingungen (z. B. IP-Fragmentierung, Netzwerkverzögerung usw.)

Flow-Rolle

Beschreibung

Markierung(n)

Eigentümer

In der Regel bezieht das Gerät die Verbindung zunächst

UIO

Direktor

Die Einheit, die Anfragen von Weiterleitungsinstanzen zur Suche nach Besitzern verarbeitet.

J

Backup-Besitzer

Solange der Director Switch nicht die gleiche Einheit wie der Eigentümer ist, ist der Director Director Switch auch der Eigentümer der Datensicherung. Wenn sich der Eigentümer selbst als Director auswählt, wird ein separater Backup-Besitzer ausgewählt.

Y (wenn der Director auch der Eigentümer des Backups ist)

y (wenn der Director nicht der Eigentümer der Sicherung ist)

Weiterleiten

Eine Einheit, die Pakete an den Besitzer weiterleitet

z

Fragmenteigentümer

Die Einheit, die den fragmentierten Datenverkehr verarbeitet

-

Chassis-Backup

In einem Chassis-übergreifenden Cluster, in dem Director-/Backup- und Ownerflows den Einheiten desselben Chassis gehören, wird eine Einheit in einem der anderen Chassis zu einem sekundären Backup-/Director-Gerät.

Diese Rolle ist spezifisch für Chassis-übergreifende Cluster der Firepower 9300-Serie mit mehr als einem Blade.

w

- Weitere Informationen finden Sie im zugehörigen Abschnitt des Konfigurationsleitfadens (siehe Links in den zugehörigen Informationen).

- In bestimmten Szenarien (siehe Abschnitt "Fallstudien") werden möglicherweise einige Flaggen nicht angezeigt.

Anwenderberichte zur Einrichtung von Cluster-Verbindungen

Der nächste Abschnitt behandelt verschiedene Fallstudien, die zeigen, wie eine Verbindung über einen Cluster hergestellt werden kann. Die Ziele sind:

- Machen Sie sich mit den verschiedenen Rollen vertraut.

- Demonstrieren der möglichen Korrelation der verschiedenen Befehlsausgaben

Topologie

Cluster-Einheiten und IDs:

Einheit-1-1

Einheit-2-1

Einheit-3-1

Cluster GROUP1: On

Interface mode: spanned

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

ID        : 0

Site ID   : 1

Version   : 9.15(1)

Serial No.: FCH22247LNK

CCL IP    : 192.222.1.1

CCL MAC   : 0015.c500.018f

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

Last leave: N/A

Unit "unit-2-1" in state SLAVE

ID        : 1

Site ID   : 1

Version   : 9.15(1)

Serial No.: FCH23157Y9N

CCL IP    : 192.222.2.1

CCL MAC   : 0015.c500.028f

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

Last leave: N/A

Unit "unit-3-1" in state SLAVE

ID        : 2

Site ID   : 2

Version   : 9.15(1)

Serial No.: FCH22247MKJ

CCL IP    : 192.222.3.1

CCL MAC   : 0015.c500.038f

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

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

Cluster-Erfassung aktiviert:

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

Hinweis: Diese Tests wurden in einer Laborumgebung mit minimalem Datenverkehr durch den Cluster ausgeführt. Versuchen Sie, in der Produktion möglichst spezifische Erfassungsfilter (z. B. Zielport und möglichst Quellport) zu verwenden, um das "Geräusch" in den Erfassungen zu minimieren.

Anwenderbericht 1. Symmetrischer Datenverkehr (Eigentümer ist auch der Director)

Beobachtung 1. Die Erfassung zum Ausblenden mit erneuter Auswurffunktion zeigt nur Pakete auf Einheit-1-1 an. Dies bedeutet, dass der Datenfluss in beide Richtungen durch Einheit-1-1 (symmetrischer Datenverkehr) geleitet wurde:

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

Beobachtung 2. Verbindungsmarkierungsanalyse für Datenfluss mit Quellport 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

Einheit

Markierung

Hinweis

Einheit-1-1

UIO

· Flow Owner - Das Gerät übernimmt den Fluss

· Director: Da die Einheit 3-1 "y" und nicht "Y" aufweist, bedeutet dies, dass die Einheit 1-1 als Director für diesen Fluss ausgewählt wurde. Da es sich also auch um den Eigentümer handelt, wurde eine weitere Einheit (in diesem Fall Einheit-3-1) als Eigentümer der Datensicherung gewählt

Einheit-2-1

-

-

Einheit-3-1

y

Die Einheit ist ein Eigentümer der Sicherung.

Dies kann visualisiert werden als:

1. Das TCP-SYN-Paket kommt von Host-A zu Einheit-1-1. Einheit-1-1 wird zum Eigentümer des Datenflusses

2. Unit-1-1 wird ebenfalls zum Flow Director gewählt. Daher wird auch Einheit-3-1 als Backup-Besitzer ausgewählt (Cluster-Add-Nachricht).

3. Das TCP-SYN/ACK-Paket kommt von Host-B zu Einheit-3-1. Der Fluss ist symmetrisch

4. Sobald die Verbindung beendet ist, sendet der Eigentümer eine Cluster-Löschmeldung, um die Flow-Informationen vom Sicherungseigentümer zu entfernen.

Beobachtung 3. Die Erfassung mit Ablaufverfolgung zeigt, dass beide Richtungen nur durch Einheit-1-1 verlaufen.

Schritt 1: Identifizieren Sie den Fluss und die Pakete von Interesse in allen Cluster-Einheiten, basierend auf dem Quell-Port:

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

Schritt 2: Da es sich um einen TCP-Flow handelt, werden die 3-Wege-Handshake-Pakete verfolgt. Wie in dieser Ausgabe zu sehen ist, ist Einheit-1-1 der Eigentümer. Aus Gründen der Einfachheit werden die nicht relevanten Ablaufverfolgungsphasen weggelassen:

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

...

Rückverkehr (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

Beobachtung 4. FTD-Datenebenensyslogs zeigen die Erstellung und Beendigung der Verbindung auf allen Geräten an:

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

Anwenderbericht 2. Symmetrischer Datenverkehr (Eigentümer anders als Director)

- Ähnlich wie in Anwenderbericht 1, aber in diesem Anwenderbericht ist der Besitzer des Datenflusses eine andere Einheit als der Director.

- Alle Ergebnisse ähneln denen des Anwenderberichts 1. Der Hauptunterschied im Vergleich zu Fallstudie 1 ist die "Y"-Markierung, die die "y"-Markierung von Szenario 1 ersetzt.

Beobachtung 1. Der Eigentümer ist anders als der Direktor.

Analyse von Verbindungsmarkierungen für Datenfluss mit Quellport 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

Einheit

Markierung

Hinweis

Einheit-1-1

UIO

· Flow Owner - Das Gerät übernimmt den Fluss

Einheit-2-1

-

-

Einheit-3-1

J

· Director und Backup Owner - Unit 3-1 hat die Markierung Y (Director).

Dies kann visualisiert werden als:

1. Das TCP-SYN-Paket kommt von Host-A zu Einheit-1-1. Einheit-1-1 wird zum Eigentümer des Datenflusses

2. Unit-3-1 wird zum Flow Director gewählt. Einheit-3-1 ist auch der Eigentümer der Sicherung ("Cluster-Add-Nachricht" auf UDP 4193 über CCL)

3. Das TCP-SYN/ACK-Paket kommt von Host-B zu Einheit-3-1. Der Fluss ist symmetrisch

4. Sobald die Verbindung beendet ist, sendet der Eigentümer über den CCL eine "Cluster-Löschen"-Nachricht auf UDP 4193, um die Flow-Informationen vom Sicherungseigentümer zu entfernen.

Beobachtung 2. Die Erfassung mit Ablaufverfolgung zeigt, dass beide Richtungen nur durch Einheit-1-1 verlaufen.

Schritt 1: Befolgen Sie den gleichen Ansatz wie in Fallstudie 1, um den Datenfluss und die Pakete von Interesse in allen Cluster-Einheiten auf Basis des Quellports zu identifizieren:

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#

Erfassen Sie die OUTSIDE-Schnittstelle:

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#

Schritt 2: Konzentrieren Sie sich auf die eingehenden Pakete (TCP SYN und 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

Verfolgen Sie die SYN/ACK auf Einheit-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

Beobachtung 3. FTD-Systeme auf Datenebene zeigen die Erstellung und Beendigung der Verbindung beim Eigentümer und Eigentümer des Backups an:

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

Anwenderbericht 3. Asymmetrischer Datenverkehr (Director Forwards the Traffic)

Beobachtung 1. Die Erfassung zum Ausblenden erneut ausblenden zeigt Pakete auf Einheit-1-1 und Einheit-2-1 (asymmetrischer Fluss) an:

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

Beobachtung 2. Analyse von Verbindungsmarkierungen für Datenfluss mit Quellport 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

Einheit

Markierung

Hinweis

Einheit-1-1

UIO

· Flow Owner - Das Gerät übernimmt den Fluss

Einheit-2-1

J

· Director - Da die Einheit 2-1 die Markierung "Y" trägt, bedeutet dies, dass die Einheit 2-1 als Director für diesen Fluss ausgewählt wurde.

· Sicherungseigentümer

· Schließlich ist es, obwohl es nicht offensichtlich ist, aus dieser Ausgabe, aber aus der Show Capture und show log Ausgaben ist es offensichtlich, dass die Einheit-2-1 diesen Fluss an den Eigentümer weiterleitet (obwohl es in diesem Szenario technisch nicht als Forwarder gilt)

Hinweis: Eine Einheit kann nicht sowohl Director (Y Flow) als auch Forwarder (z Flow) sein. Diese beiden Rollen schließen sich gegenseitig aus. Beachten Sie, dass Directors (Y flow) weiterhin Datenverkehr weiterleiten können. Später in dieser Fallstudie finden Sie die Ausgabe des Anzeigeprotokolls.

Einheit-3-1

-

-

Dies kann visualisiert werden als:

1. Das TCP-SYN-Paket kommt von Host-A zu Einheit-1-1. Einheit-1-1 wird zum Eigentümer des Datenflusses

2. Unit-2-1 wird zum Flow-Director und Backup-Besitzer gewählt. Der Besitzer des Datenflusses sendet eine Unicast-Nachricht "Cluster Add" auf UDP 4193, um den Eigentümer der Sicherung über den Datenfluss zu informieren.

3. Das TCP-SYN/ACK-Paket kommt von Host-B zu Einheit-2-1. Der Fluss ist asymmetrisch

4. Unit-2-1 leitet das Paket über die CCL an den Besitzer weiter (aufgrund von TCP-SYN-Cookie).

5. Der Besitzer sendet das Paket an die Schnittstelle OUTSIDE zurück und leitet es dann an Host-A weiter.

6. Sobald die Verbindung beendet ist, sendet der Eigentümer eine Cluster-Löschmeldung, um die Flow-Informationen vom Sicherungseigentümer zu entfernen.

Beobachtung 3. Die Erfassung mit Trace zeigt den asymmetrischen Datenverkehr und die Umleitung von Einheit-2-1 zu Einheit-1-1 an

Schritt 1: Identifizieren Sie die Pakete, die zum interessierenden Fluss gehören (Port 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:*************************************************************

Die Rückrichtung:

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

Schritt 2: Verfolgen Sie die Pakete. Beachten Sie, dass standardmäßig nur die ersten 50 eingehenden Pakete verfolgt werden. Aus Gründen der Einfachheit werden die nicht relevanten Ablaufverfolgungsphasen weggelassen.

Einheit-1-1 (Eigentümer):

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

Einheit-2-1 (Forwarder)

Der Rückverkehr (TCP SYN/ACK). Die Interesseneinheit ist die Einheit 2-1, die der Director/Backup-Besitzer ist und den Datenverkehr an den Besitzer weiterleitet:

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

Beobachtung 4. FTD-Datenebenensyslogs zeigen die Erstellung und Beendigung der Verbindung auf allen Geräten an:

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#

Anwenderbericht 4: Asymmetrischer Datenverkehr (Eigentümer ist Director)

Beobachtung 1. Die Erfassung zum Ausblenden erneut ausblenden zeigt Pakete auf Einheit-1-1 und Einheit-2-1 (asymmetrischer Fluss) an:

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

Beobachtung 2. Analyse von Verbindungsmarkierungen für Datenfluss mit Quellport 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

Einheit

Markierung

Hinweis

Einheit-1-1

UIO

· Flow Owner - Das Gerät übernimmt den Fluss

· Director: Da die Einheit 3-1 "y" und nicht "Y" aufweist, bedeutet dies, dass die Einheit 1-1 als Director für diesen Fluss ausgewählt wurde. Da es sich also auch um den Eigentümer handelt, wurde eine weitere Einheit (in diesem Fall Einheit-3-1) als Eigentümer der Datensicherung gewählt

Einheit-2-1

z

· Forwarder

Einheit-3-1

y

- Sicherungseigentümer

Dies kann visualisiert werden als:

1. Das TCP-SYN-Paket kommt von Host-A zu Einheit-1-1. Unit-1-1 wird zum Flow-Besitzer und zum Director gewählt.

2. Einheit-3-1 wird als Eigentümer der Datensicherung ausgewählt. Der Besitzer des Datenflusses sendet eine Unicast-Meldung für das Cluster-Hinzufügen auf UDP 4193, um den Besitzer der Sicherung über den Datenfluss zu informieren.

3. Das TCP-SYN/ACK-Paket kommt von Host-B zu Einheit-2-1. Der Fluss ist asymmetrisch

4. Unit-2-1 leitet das Paket über die CCL an den Besitzer weiter (aufgrund von TCP-SYN-Cookie).

5. Der Besitzer sendet das Paket an die Schnittstelle OUTSIDE zurück und leitet es dann an Host-A weiter.

6. Sobald die Verbindung beendet ist, sendet der Eigentümer eine Cluster-Löschmeldung, um die Flow-Informationen vom Sicherungseigentümer zu entfernen.

Beobachtung 3. Die Erfassung mit Trace zeigt den asymmetrischen Datenverkehr und die Umleitung von Einheit-2-1 zu Einheit-1-1 an

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

Beobachtung 4. FTD-Datenebenensyslogs zeigen die Erstellung und Beendigung der Verbindung auf allen Geräten an:

- Einheit-1-1 (Eigentümer)

- Einheit-2-1 (Forwarder)

- Einheit-3-1 (Sicherungseigentümer)

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

Anwenderbericht 5. Asymmetrischer Datenverkehr (Eigentümer ist anders als Director)

Beobachtung 1. Die Erfassung zum Ausblenden erneut ausblenden zeigt Pakete auf Einheit-1-1 und Einheit-2-1 (asymmetrischer Fluss) an:

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

Beobachtung 2. Analyse von Verbindungsmarkierungen für Datenfluss mit Quellport 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

Einheit

Markierung

Hinweis

Einheit-1-1

UIO

· Flow Owner - Das Gerät übernimmt den Fluss

Einheit-2-1

z

· Forwarder

Einheit-3-1

J

· Sicherungseigentümer

· Director

Dies kann visualisiert werden als:

1. Das TCP-SYN-Paket kommt von Host-A zu Einheit-1-1. Einheit-1-1 wird zum Eigentümer des Datenflusses

2. Unit-3-1 wird zum Director und Backup-Eigentümer gewählt. Der Besitzer des Datenflusses sendet eine Unicast-Nachricht "Cluster Add" auf UDP 4193, um den Eigentümer der Sicherung über den Datenfluss zu informieren.

3. Das TCP-SYN/ACK-Paket kommt von Host-B zu Einheit-2-1. Der Fluss ist asymmetrisch

4. Unit-2-1 leitet das Paket über die CCL an den Besitzer weiter (aufgrund von TCP-SYN-Cookie).

5. Der Besitzer sendet das Paket an die Schnittstelle OUTSIDE zurück und leitet es dann an Host-A weiter.

6. Sobald die Verbindung beendet ist, sendet der Eigentümer eine Cluster-Löschmeldung, um die Flow-Informationen vom Sicherungseigentümer zu entfernen.

Beobachtung 3. Die Erfassung mit Trace zeigt den asymmetrischen Datenverkehr und die Umleitung von Einheit-2-1 zu Einheit-1-1 an

Einheit-1-1 (Eigentümer)

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

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

Beobachtung 4. FTD-Datenebenensyslogs zeigen die Erstellung und Beendigung der Verbindung auf allen Geräten an:

- Einheit-1-1 (Eigentümer)

- Einheit-2-1 (Forwarder)

- Einheit-3-1 (Backup-Besitzer/Director)

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

Für die nächsten Fallstudien basiert die verwendete Topologie auf einem Cluster mit Inline-Sets:

Anwenderbericht 6. Asymmetrischer Datenverkehr (Inline-Set, Eigentümer ist Director)

Beobachtung 1. Die Erfassung zum Ausblenden mit erneuter Auswurffunktion zeigt Pakete auf Einheit-1-1 und Einheit-2-1 (asymmetrischer Fluss) an. Zusätzlich ist der Eigentümer Einheit-2-1 (es gibt Pakete auf beiden, INSIDE- und OUTSIDE-Schnittstellen für die Erfassung zum Ausblenden neu einwerfen, während Einheit-1-1 nur auf AUSSEN liegt):

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

Beobachtung 2. Analyse von Verbindungsmarkierungen für Datenfluss mit Quellport 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

Einheit

Markierung

Hinweis

Einheit-1-1

z

· Forwarder

Einheit-2-1

b n

· Flow Owner - Das Gerät übernimmt den Fluss

Einheit-3-1

y

· Sicherungseigentümer

Dies kann visualisiert werden als:

1. Das TCP-SYN-Paket kommt von Host-A zu Einheit-2-1. Unit-2-1 wird zum Flow-Besitzer und wird zum Director gewählt.

2. Einheit-3-1 wird zum Eigentümer der Sicherung gewählt. Der Besitzer des Datenflusses sendet eine Unicast-Nachricht "Cluster Add" auf UDP 4193, um den Eigentümer der Sicherung über den Datenfluss zu informieren.

3. Das TCP-SYN/ACK-Paket kommt von Host-B zu Einheit-1-1. Der Fluss ist asymmetrisch

4. Unit-1-1 leitet das Paket über die CCL an den Director Switch (Einheit-2-1) weiter.

5. Unit-2-1 ist ebenfalls der Besitzer und schaltet das Paket auf die Schnittstelle OUTSIDE zurück

6. Unit-2-1 leitet das Paket an Host-A weiter

7. Sobald die Verbindung beendet ist, sendet der Eigentümer eine Cluster-Löschmeldung, um die Flow-Informationen vom Sicherungseigentümer zu entfernen.

Beobachtung 3. Die Erfassung mit Trace zeigt den asymmetrischen Datenverkehr und die Umleitung von Einheit-1-1 zu Einheit-2-1 an

Einheit 2-1 (Eigentümer/Direktor)

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

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

Rückverkehr (TCP SYN/ACK)

Einheit 2-1 (Eigentümer/Direktor)

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

Beobachtung 4. FTD-Datenebenensyslogs zeigen die Erstellung und Beendigung der Verbindung auf allen Geräten an:

- Einheit-1-1 (Eigentümer)

- Einheit-2-1 (Forwarder)

- Einheit-3-1 (Backup-Besitzer/Director)

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

Anwenderbericht 7. Asymmetrischer Datenverkehr (Inline-Satz; Eigentümer ist anders als der Director)

Der Eigentümer ist die Einheit 2-1 (es gibt Pakete auf beiden, INSIDE- und OUTSIDE-Schnittstellen für die Erfassung zum Ausblenden der Wiedereingliederung, während die Einheit 3-1 nur auf AUSSEN liegt):

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

Beobachtung 2. Analyse von Verbindungsmarkierungen für Datenfluss mit Quellport 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

Einheit

Markierung

Hinweis

Einheit-1-1

J

· Director/Backup-Besitzer

Einheit-2-1

b n

· Flow Owner - Das Gerät übernimmt den Fluss

Einheit-3-1

z

· Forwarder

Dies kann visualisiert werden als:

1. Das TCP-SYN-Paket kommt von Host-A zu Einheit-2-1. Unit-2-1 wird zum Flow-Besitzer und Unit-1-1 wird zum Director gewählt.

2. Unit-1-1 wird zum Eigentümer der Datensicherung gewählt (da es der Director ist). Der Besitzer des Datenflusses sendet eine Unicast-Nachricht "Cluster Add" auf UDP 4193, um den Eigentümer der Sicherung über den Datenfluss zu informieren.

3. Das TCP-SYN/ACK-Paket kommt von Host-B zu Einheit-3-1. Der Fluss ist asymmetrisch

4. Unit-3-1 leitet das Paket über die CCL an den Director Switch weiter (Einheit-1-1).

5. Unit-1-1 (Director) weiß, dass der Besitzer Einheit-2-1 ist, sendet das Paket zurück an den Forwarder (Einheit-3-1) und teilt ihm mit, dass der Eigentümer Einheit-2-1 ist

6. Einheit-3-1 sendet das Paket an Einheit-2-1 (Eigentümer)

7. Einheit-2-1 schaltet das Paket auf der Schnittstelle OUTSIDE erneut ein

8. Unit-2-1 leitet das Paket an Host-A weiter

9. Sobald die Verbindung beendet ist, sendet der Eigentümer eine Cluster-Löschmeldung, um die Flow-Informationen vom Sicherungseigentümer zu entfernen.

Hinweis: Es ist wichtig, dass Schritt 2 (Paket durch CCL) vor Schritt 4 (Datenverkehr) stattfindet. In einem anderen Fall (z. B. bei einem Rennen) ist dem Regisseur der Fluss nicht bekannt. Da es sich um ein Inline-Set handelt, wird das Paket an das Ziel weitergeleitet. Wenn sich die Schnittstellen nicht in einem Inline-Set befinden, wird das Datenpaket verworfen.

Beobachtung 3. Die Erfassung mit Trace zeigt den asymmetrischen Datenverkehr und den Austausch über die CCL:

Weiterleitungsverkehr (TCP-SYN)

Einheit-2-1 (Eigentümer)

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

Rückverkehr (TCP SYN/ACK)

Unit-3-1 (ID 2 - Forwarder) sendet das Paket über die CCL an Einheit-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 (Director) - Unit-1-1 (ID 0) weiß, dass der Besitzer des Datenflusses Einheit-2-1 (ID 1) ist, und sendet das Paket über die CCL zurück an Einheit-3-1 (ID 2 - Forwarder)

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) ruft das Paket über die CCL ab und sendet es an Einheit-2-1 (ID 1 - Eigentümer)

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

Der Besitzer schaltet das Paket zurück und leitet es an das Ziel weiter:

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

Beobachtung 4. FTD-Datenebenensyslogs zeigen die Erstellung und Beendigung der Verbindung auf allen Geräten an:

- Einheit-1-1 (Director/Backup Owner)

- Einheit-2-1 (Eigentümer)

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

Fehlerbehebung

Einführung in die Cluster-Fehlerbehebung

Die Cluster-Probleme können wie folgt kategorisiert werden:

- Probleme auf der Kontrollebene (Probleme im Zusammenhang mit der Cluster-Stabilität)

- Probleme auf Datenebene (Probleme im Zusammenhang mit dem Transitverkehr)

Cluster-Datenebenenprobleme

Häufige Probleme mit NAT/PAT

Wichtige Überlegungen zur Konfiguration

- Port Address Translation (PAT)-Pools müssen mindestens so viele IPs zur Verfügung haben wie Einheiten im Cluster, vorzugsweise mehr IPs als Cluster-Knoten.

- Die Xlate-Standardbefehle pro Sitzung müssen beibehalten werden, es sei denn, es gibt einen bestimmten Grund, sie zu deaktivieren. Jede PAT-Erweiterung, die für eine Verbindung erstellt wurde, bei der Xlate pro Sitzung deaktiviert ist, wird immer von der Kontrollknoteneinheit im Cluster behandelt, was zu Leistungseinbußen führen kann.

Nutzung des hohen PAT-Poolbereichs aufgrund von Datenverkehr von niedrigen Ports, der zu einem Ungleichgewicht zwischen Cluster-IP führt

Das FTD teilt eine PAT-IP in "Bereiche" auf und versucht, die Xlate im gleichen Quellbereich zu halten. Diese Tabelle zeigt, wie ein Quellport in einen globalen Port im gleichen Quellbereich übersetzt wird.

Ursprünglicher SRC-Port

Übersetzter SRC-Port

1-511

1-511

512-1023

512-1023

1024-65535

1024-65535

Wenn ein Quell-Port-Bereich voll ist und eine neue PAT-Erweiterung aus diesem Bereich zugewiesen werden muss, wechselt FTD zur nächsten IP, um neue Übersetzungen für diesen Quell-Port-Bereich zuzuweisen.

Symptome

Verbindungsprobleme für NAT-Datenverkehr, der den Cluster passiert

Überprüfung

# show nat pool

FTD-Datenebenenprotokolle zeigen die Erschöpfung des PAT-Pools an:

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

Eindämmung

Konfigurieren des NAT-Flat-Port-Bereichs und Integrieren von Reserve-Ports

Darüber hinaus können Sie nach 6.7/9.15.1 eine unausgewogene Port-Block-Verteilung nur dann erreichen, wenn Knoten den Cluster mit einem riesigen Hintergrunddatenverkehr, der der PAT unterliegt, verlassen bzw. ihm beitreten. Die einzige Möglichkeit, wie sie sich selbst wiederherstellt, besteht darin, Port-Blöcke freizugeben, um sie über Knoten neu verteilt zu werden.

Bei blockbasierter Portverteilung, wenn ein Knoten mit etwa 10 Port-Blöcken wie pb-1, pb-2 zugewiesen wird ... Seite 10. Der Knoten beginnt immer mit dem ersten verfügbaren Port-Block und weist ihm einen zufälligen Port zu, bis er erschöpft ist. Die Zuweisung wird nur dann zum nächsten Port-Block verschoben, wenn alle Port-Blöcke bis zu diesem Punkt ausgeschöpft sind.

Wenn beispielsweise ein Host 512 Verbindungen herstellt, weist die Einheit zugeordnete Ports für alle diese 512 Verbindungen von pb-1 zufällig zu. Wenn nun alle diese 512 Verbindungen aktiv sind, wechselt der Host, wenn er die 513. Verbindung herstellt, seit pb-1 erschöpft ist, zu pb-2 und weist ihm einen zufälligen Port zu. Nehmen wir an, die 10. Verbindung ist beendet und von den 513 Verbindungen wird ein Port gelöscht, der in pb-1 verfügbar ist. Wenn der Host an diesem Punkt die 514. Verbindung herstellt, weist die Cluster-Einheit einen zugeordneten Port von pb-1 und nicht von pb-2 zu, da pb-1 jetzt einen freien Port hat (der als Teil der 10. Verbindungs-Entfernung freigegeben wurde).

Dabei ist zu beachten, dass die Zuweisung vom ersten verfügbaren Port-Block mit freien Ports erfolgt, sodass die letzten Port-Blöcke immer für die Neuverteilung in einem normal geladenen System verfügbar sind. Darüber hinaus wird PAT in der Regel für kurzlebige Verbindungen verwendet. Die Wahrscheinlichkeit, dass ein Port-Block in kürzerer Zeit verfügbar ist, ist sehr hoch. Die für eine ausgewogene Verteilung der Pools erforderliche Zeit kann sich also durch eine Port-Block-basierte Poolverteilung verbessern.

Falls jedoch alle Port-Bausteine, von pb-1 bis pb-10, erschöpft sind oder jeder Port-Block einen Port für eine langlebige Verbindung enthält, werden die Port-Bausteine nie schnell freigegeben und neu verteilt. In einem solchen Fall besteht der am wenigsten disruptive Ansatz darin,

1. Identifizieren Sie Knoten mit exzessiven Port-Blöcken (Nat Pool Cluster Summary).

2. Identifizieren Sie die am wenigsten genutzten Port-Blöcke auf diesem Knoten (show nat pool ip <addr> detail).

3. Klartext für solche Port-Blöcke (clear xlate global <addr> gport 'start-end'), um sie für die Neuverteilung zur Verfügung zu stellen.

Warnung: Dadurch werden die relevanten Verbindungen unterbrochen.

Bei der Umleitung an ein anderes Ziel kann nicht auf Dual-Channel-Websites (z. B. Webmail, Banking usw.) oder auf SSO-Websites zugegriffen werden.

Symptome

Websites mit zwei Kanälen können nicht aufgerufen werden (z. B. Webmail, Bank-Websites usw.). Wenn ein Benutzer eine Verbindung zu einer Website herstellt, für die der Client eine zweite Socket/Verbindung öffnen muss, und die zweite Verbindung an einen Cluster-Teilnehmer gehasht wird, der nicht mit dem Cluster verbunden ist, an den die erste Verbindung gehasht wurde, und der Datenverkehr einen IP-PAT-Pool verwendet, wird der Datenverkehr vom Server zurückgesetzt, da er die Verbindung von einer anderen öffentlichen IP-Adresse erhält.

Überprüfung

Führen Sie Cluster-Erfassungen auf Datenebene durch, um zu sehen, wie der betroffene Transitfluss behandelt wird. In diesem Fall wird das TCP von der Ziel-Website zurückgesetzt.

Eindämmung (vor 6,7/9,15,1)

- Überprüfen Sie, ob bei Anwendungen für mehrere Sitzungen mehrere zugeordnete IP-Adressen verwendet werden.

- Mit dem Befehl show nat pool cluster summary überprüfen Sie, ob der Pool gleichmäßig verteilt ist.

- Verwenden Sie den Befehl show conn des Clusters, um zu überprüfen, ob der Datenverkehr ordnungsgemäß mit Load Balancing behandelt wird.

- Verwenden Sie den Befehl show nat pool cluster ip <address> detail, um die Poolnutzung der sticky IP zu überprüfen.

- Aktivieren Sie Syslog 305021 (6.7/9.15), um zu sehen, welche Verbindungen die klebende IP nicht verwenden können.

- Um weitere IPs zum PAT-Pool hinzuzufügen oder den Lastenausgleichsalgorithmus auf verbundenen Switches zu optimieren.

Informationen zum EtherChannel-Lastenausgleichsalgorithmus:

- Für Nicht-FP9300 und wenn die Authentifizierung über einen Server erfolgt: Passen Sie den Etherchannel-Lastenausgleichsalgorithmus auf dem benachbarten Switch von Quell-IP/Port und Ziel-IP/Port an Quell-IP und Ziel-IP an.

- Für Nicht-FP9300 und wenn die Authentifizierung über mehrere Server erfolgt: Passen Sie den EtherChannel-Lastenausgleichsalgorithmus auf dem benachbarten Switch von Quell-IP/Port und Ziel-IP/Port an Quell-IP an.

- Für FP9300: Im FP9300-Chassis ist der Lastenausgleichsalgorithmus als Quell-Quell-Quell-IP-Quell-MAC festgelegt und kann nicht geändert werden. Die Lösung besteht in diesem Fall darin, mithilfe von FlexConfig der FTD-Konfiguration deny-Befehle pro Sitzung hinzuzufügen, um zu erzwingen, dass der Datenverkehr für bestimmte Ziel-IP-Adressen (für problematische/inkompatible Anwendungen) nur vom Steuerungsknoten im Chassis-internen Cluster verarbeitet wird. Die Lösung hat folgende Nebenwirkungen:

- Keine Lastverteilung des anders übersetzten Datenverkehrs (alles geht zum Kontrollknoten).

- Potenzial für ungenutzte Steckplätze (und Beeinträchtigung der NAT-Übersetzung für anderen Datenverkehr auf dem Steuerungsknoten).

- Geringere Skalierbarkeit des Intra-Chassis-Clusters.

Geringe Cluster-Leistung aufgrund des gesamten Datenverkehrs, der an den Kontrollknoten gesendet wird, da nicht genügend PAT-IPs in den Pools vorhanden sind

Symptome

Es gibt nicht genügend PAT-IPs im Cluster, um den Datenknoten eine freie IP zuzuweisen. Daher wird der gesamte Datenverkehr, der der PAT-Konfiguration unterliegt, zur Verarbeitung an den Kontrollknoten weitergeleitet.

Überprüfung

Verwenden Sie den Befehl show nat pool cluster, um die Zuweisungen für jede Einheit anzuzeigen und zu bestätigen, dass alle über mindestens eine IP im Pool verfügen.

Eindämmung

Stellen Sie für die Version vor 6.7/9.15.1 sicher, dass ein PAT-Pool von mindestens der Anzahl der Knoten im Cluster entspricht. Bei PAT-Pool nach 6.7/9.15.1 weisen Sie Port-Blöcke aller PAT-Pool-IPs zu. Wenn die Nutzung des PAT-Pools wirklich hoch ist und der Pool häufig erschöpft ist, müssen Sie die Größe des PAT-Pools erhöhen (siehe FAQ).

Geringe Leistung aufgrund des gesamten Datenverkehrs, der an den Steuerungsknoten gesendet wird, da XLATE nicht pro Sitzung aktiviert sind

Symptome

Viele UDP-Backup-Datenflüsse werden über den Cluster-Steuerungsknoten verarbeitet, was sich auf die Leistung auswirken kann.

Hintergrund

Nur Verbindungen, die XLATE verwenden, die pro Sitzung aktiviert sind, können von einem Datenknoten verarbeitet werden, der PAT verwendet. Verwenden Sie den Befehl show run all xlate, um die Xlate-Konfiguration pro Sitzung anzuzeigen.

Bei Aktivierung pro Sitzung wird der Text sofort beendet, wenn die zugehörige Verbindung beendet wird. Dies verbessert die Leistung der Verbindungen pro Sekunde, wenn die Verbindungen PAT ausgesetzt sind. Wenn die Verbindungsrate hoch genug ist, können die verfügbaren 65.000 TCP/UDP-Ports auf jeder globalen IP innerhalb kurzer Zeit belegt werden.

Standardmäßig ist der gesamte TCP-Datenverkehr pro Xlate aktiviert, und pro Sitzung ist nur UDP-DNS-Datenverkehr aktiviert. Das bedeutet, dass der gesamte Nicht-DNS-UDP-Datenverkehr zur Verarbeitung an den Kontrollknoten weitergeleitet wird.

Überprüfung

Verwenden Sie diesen Befehl, um die Verbindung und Paketverteilung zwischen den Cluster-Einheiten zu überprüfen:

firepower# show cluster info conn-distribution

firepower# show cluster info packet-distribution

firepower# show cluster info load-monitor

Verwenden Sie den Befehl show conn des Clusters, um zu sehen, welche Cluster-Knoten die UDP-Verbindungen besitzen.

firepower# cluster exec show conn

Verwenden Sie diesen Befehl, um die Poolnutzung für alle Cluster-Knoten zu verstehen.

firepower# cluster exec show nat pool ip

| in UDP

Eindämmung

PAT pro Sitzung (pro Sitzung permit udp-Befehl) für den Datenverkehr von Interesse (z. B. UDP) konfigurieren. Für ICMP können Sie nicht von der standardmäßigen Multi-Session-PAT wechseln. Daher wird der IMCP-Verkehr immer vom Steuerungsknoten behandelt, wenn PAT konfiguriert ist.

Die Verteilung des PAT-Pools wird unausgewogen, wenn Knoten den Cluster verlassen bzw. ihm beitreten.

Symptome

- Verbindungsprobleme, da die PAT-IP-Zuweisung mit der Zeit aufgrund von Einheiten, die das Cluster verlassen und ihm beitreten, unausgewogen werden kann.

- Nach 6.7/9.15.1 kann es Fälle geben, in denen der neu verbundene Knoten nicht genügend Port-Blöcke abrufen kann. Ein Knoten ohne Port-Block leitet den Datenverkehr zum Kontrollknoten um. Ein Knoten mit mindestens einem Port-Block verarbeitet den Datenverkehr und beginnt, ihn zu verwerfen, sobald der Pool erschöpft ist.

Überprüfung

- Die Syslogs auf der Datenebene zeigen Meldungen an wie:

%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

- Verwenden Sie den Befehl show nat pool cluster summary, um die Poolverteilung zu identifizieren.

- Verwenden Sie den Befehl cluster exec show nat pool ip <addr> detail, um die Poolnutzung über Cluster-Knoten hinweg zu verstehen.

Eindämmung

- Für die Version vor 6.7/9.15.1 werden einige Problemumgehungen unter https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd10530 beschrieben.

- Lösen Sie diese Probleme nach 6.7/9.15.1 mithilfe des Befehls clear xlate global <ip> gport <start-end>, um einige der Port-Blöcke auf anderen Knoten manuell zu löschen, damit sie an die erforderlichen Knoten umverteilt werden können.

Symptome

Wichtigste Verbindungsprobleme für Datenverkehr, der vom Cluster über PAT geleitet wird. Dies liegt daran, dass die FTD-Datenebene gemäß Design kein GARP für globale NAT-Adressen sendet.

Überprüfung

Die ARP-Tabelle der direkt verbundenen Geräte zeigt nach einer Änderung des Kontrollknotens eine andere MAC-Adresse der Datenschnittstelle des Clusters:

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

Eindämmung

Konfigurieren Sie statische (virtuelle) MACs auf Cluster-Datenschnittstellen.

Verbindungen, die PAT ausgesetzt sind, fehlschlagen

Symptome

Verbindungsprobleme für Datenverkehr, der vom Cluster über PAT geleitet wird.

Verifizierung/Risikominderung

- Stellen Sie sicher, dass die Konfiguration ordnungsgemäß repliziert wurde.

- Stellen Sie sicher, dass der Pool gleichmäßig verteilt ist.

- Stellen Sie sicher, dass der Poolbesitzer gültig ist.

- Keine Fehlerzählerinkremente im show asp cluster counter.

- Stellen Sie sicher, dass Director-/Forwarder-Flows mit den richtigen Informationen erstellt werden.

- Überprüfen Sie, ob Sicherungsdateien wie erwartet erstellt, aktualisiert und bereinigt werden.

- Überprüfen Sie, ob XLATE gemäß dem Verhalten "pro Sitzung" erstellt und beendet werden.

- Aktivieren Sie "debug nat 2", um auf Fehler hinzuweisen. Beachten Sie, dass diese Ausgabe sehr laut sein kann, z.

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

So beenden Sie das Debuggen:

firepower# un all

- Aktivieren Sie Verbindungen und NAT-bezogene Syslogs, um die Informationen mit einer fehlgeschlagenen Verbindung zu korrelieren.

PAT-Verbesserungen für ASA- und FTD-Clustering (nach 9.15 und 6.7)

Was hat sich geändert?

Der PAT-Vorgang wurde überarbeitet. Einzelne IPs werden nicht mehr an die einzelnen Cluster-Mitglieder verteilt. Stattdessen werden die PAT-IPs in Port-Blöcke aufgeteilt und in Kombination mit dem IP-Stickiness-Vorgang gleichmäßig (so weit wie möglich) zwischen den Cluster-Mitgliedern verteilt.

Das neue Design begegnet diesen Einschränkungen (siehe vorherigen Abschnitt):

- Multisession-Anwendungen sind betroffen, weil es im gesamten Cluster keine IP-Stickiness gibt.

- Die Anforderung, einen PAT-Pool von mindestens der Anzahl der Knoten im Cluster zu haben.

- Die Verteilung des PAT-Pools wird unausgewogen, wenn Knoten den Cluster verlassen bzw. ihm beitreten.

- Keine Syslogs zur Anzeige von PAT-Pool-Ungleichgewichten.

Anstelle der standardmäßigen Portbereiche 1-511, 512-1023 und 1024-65535 gibt es jetzt den Port-Standardbereich 1024-65535 für PAT. Dieser Standardbereich kann für reguläre PAT auf den privilegierten Port-Bereich 1-1023 erweitert werden (Option "include-reserve").

Dies ist ein Beispiel für eine PAT-Pool-Konfiguration in FTD 6.7. Weitere Informationen finden Sie im zugehörigen Abschnitt des Konfigurationsleitfadens:

Zusätzliche Informationen zur Fehlerbehebung für PAT

FTD-Systeme für Datenebene (nach 6.7/9.15.1)

Wenn alle Ports in der Klebestückungs-IP auf einem Cluster-Knoten ausgeschöpft sind, wird ein Syslog zur Sperrung des Datenverkehrs generiert, und die Zuweisung wird zur nächsten verfügbaren IP mit freien Ports verschoben. z. B.

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

Ein Pool-Ungleichgewicht-Syslog wird auf einem Knoten generiert, wenn er dem Cluster beitritt und keinen oder ungleichen Anteil an Port-Blöcken erhält, z. B.

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

Befehle anzeigen

Pool-Verteilungsstatus

In der Ausgabe der show nat pool cluster summary darf für jede PAT-IP-Adresse in einem ausgewogenen Verteilungsszenario keine Differenz von mehr als einem Port-Block zwischen den Knoten bestehen. Beispiele für eine ausgewogene und ungleichmäßige Verteilung von Portblöcken.

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)

Unausgewogene Verteilung:

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)

Poolbesitzstatus

In der Ausgabe von show nat pool cluster darf es keinen Port-Block mit Owner oder Backup als "UNKNOWN" geben. Wenn ein Pool vorhanden ist, weist dies auf ein Problem mit der Pooleigentumskommunikation hin. Beispiel:

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>

Buchhaltung von Port-Zuweisungen in Port-Blöcken

Der Befehl show nat pool wird durch zusätzliche Optionen zur Anzeige detaillierter Informationen sowie gefilterter Ausgabe ergänzt. Beispiel:

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 *

Hinweis: "*" bedeutet, dass es sich um einen gesicherten Port-Block handelt

Um dies zu beheben, verwenden Sie den Befehl clear xlate global <ip> gport <start-end>, um einige der Port-Blöcke auf anderen Knoten manuell zu löschen und sie an die erforderlichen Knoten weiterzuleiten.

Manuell ausgelöste Neuverteilung von Port-Blöcken

- In einem Produktionsnetzwerk mit konstantem Datenverkehr kann es vorkommen, dass ein Knoten den Cluster verlässt und wieder verbindet (vermutlich aufgrund einer Rückverfolgung), dass er keinen gleichen Anteil am Pool erhält oder im schlimmsten Fall keinen Port-Block erhält.

- Mit dem Befehl show nat pool cluster summary können Sie ermitteln, welcher Knoten mehr Port-Blöcke besitzt als erforderlich.

- Verwenden Sie auf Knoten, die mehr Port-Blöcke besitzen, den Befehl show nat pool ip <addr> detail, um die Port-Blöcke mit der geringsten Anzahl von Zuweisungen auszumachen.

- Verwenden Sie den Befehl clear xlate global <address> gport <start-end>, um Übersetzungen zu löschen, die aus diesen Port-Blöcken erstellt wurden, sodass diese für die Neuverteilung an die erforderlichen Knoten verfügbar sind, z. B.

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

Häufig gestellte Fragen (FAQ) für PAT nach 6.7/9.15.1

F. Wenn Sie die Anzahl der für die Anzahl der verfügbaren Einheiten im Cluster verfügbaren IPs haben, können Sie auch weiterhin 1 IP pro Einheit verwenden.

Antwort: Das ist nicht mehr der Fall, und es gibt keinen Wechsel zwischen IP-Adressen- und Port-Block-basierten Pool-Verteilungsschemata.

Das ältere Schema der IP-Adressen-basierten Poolverteilung führte zu Anwendungsfehlern für mehrere Sitzungen, bei denen mehrere Verbindungen (die Teil einer einzelnen Anwendungstransaktion sind) von einem Host auf verschiedene Knoten des Clusters verteilt werden und daher durch unterschiedliche zugeordnete IP-Adressen übersetzt werden, sodass der Zielserver sie als von verschiedenen Einheiten stammen sehen kann.

Und mit dem neuen Port-Block-basierten Verteilungsschema, obwohl Sie jetzt mit nur einer PAT-IP-Adresse arbeiten können, wird immer empfohlen, über genügend PAT-IP-Adressen zu verfügen, basierend auf der Anzahl der Verbindungen, die für die PAT-Zuweisung erforderlich sind.

F. Können Sie immer noch einen Pool von IP-Adressen für den PAT-Pool für den Cluster haben?

Antwort: Ja. Port-Blöcke aller PAT-Pool-IPs werden auf die Cluster-Knoten verteilt.

F. Wenn Sie eine Anzahl von IP-Adressen für den PAT-Pool verwenden, ist der gleiche Port-Block für jedes Mitglied pro IP-Adresse angegeben?

Antwort: Nein, jede IP wird unabhängig voneinander verteilt.

F. Alle Cluster-Knoten haben alle öffentlichen IPs, aber nur einen Teil der Ports? Wenn dies der Fall ist, wird dann garantiert, dass die Quell-IP jedes Mal, wenn sie dieselbe öffentliche IP verwendet, verwendet wird?

Antwort: Das ist richtig, jede PAT-IP ist teilweise Eigentum jedes Knotens. Wenn eine ausgewählte öffentliche IP auf einem Knoten erschöpft ist, wird ein Syslog generiert, das angibt, dass die klebende IP nicht beibehalten werden kann, und die Zuweisung wird zur nächsten verfügbaren öffentlichen IP verschoben. Ob Standalone-, HA- oder Cluster-Bereitstellung - die IP-Stickiness-Analyse hängt von der Verfügbarkeit des Pools ab.

F. Basiert alles auf einer einzigen IP-Adresse im PAT-Pool, gilt aber nicht, wenn mehr als eine IP-Adresse im PAT-Pool verwendet wird?

Antwort: Sie gilt auch für mehrere IP-Adressen im PAT-Pool. Port-Blöcke von jeder IP-Adresse im PAT-Pool werden auf Cluster-Knoten verteilt. Jede IP-Adresse im PAT-Pool wird auf alle Mitglieder im Cluster aufgeteilt. Wenn Sie also über eine Klasse C von Adressen im PAT-Pool verfügen, verfügt jeder Cluster-Member über Port-Pools von jeder einzelnen PAT-Pooladresse.

F. Funktioniert es mit CGNAT?

Antwort: Ja, CGNAT wird ebenfalls unterstützt. CGNAT, auch als "Block-Allokation" bezeichnet, hat eine standardmäßige Blockgröße von '512', die durch die CLI der Blockzuweisungsgröße geändert werden kann. Bei einer regulären dynamischen PAT (nicht CGNAT) ist die Blockgröße immer '512', d. h. fest und nicht konfigurierbar.

F. Weist der Kontrollknoten den Port-Block-Bereich anderen Einheiten zu oder behält er sich selbst bei, wenn die Einheit den Cluster verlässt?

Antwort: Jeder Port-Block verfügt über einen Besitzer und eine Sicherung. Jedes Mal, wenn eine Xlate aus einem Port-Block erstellt wird, wird sie auch auf den Backup-Knoten des Port-Blocks repliziert. Wenn ein Knoten den Cluster verlässt, besitzt der Backup-Knoten alle Port-Blöcke und alle aktuellen Verbindungen. Da der Backup-Knoten Eigentümer dieser zusätzlichen Port-Blöcke geworden ist, wählt er eine neue Datensicherung für sie aus und repliziert alle aktuellen XLates auf diesen Knoten, um Fehlerszenarien zu behandeln.

F. Welche Maßnahmen können auf der Grundlage dieser Warnung ergriffen werden, um Stickiness durchzusetzen?

Antwort: Es gibt zwei mögliche Gründe, warum Stickigkeit nicht erhalten werden kann.

Grund-1: Der Datenverkehr ist falsch-ausgeglichen, da einer der Knoten eine höhere Anzahl an Verbindungen als andere erkennt, was zu einer bestimmten klebrigen IP-Erschöpfung führt. Dies kann behoben werden, wenn der Datenverkehr gleichmäßig auf Cluster-Knoten verteilt wird. z. B. auf einem FPR41xx-Cluster den Lastenausgleichsalgorithmus auf angeschlossenen Switches anpassen. Stellen Sie bei einem FPR9300-Cluster sicher, dass im gesamten Chassis dieselbe Anzahl von Blades vorhanden ist.

Grund-2: Die Nutzung des PAT-Pools ist sehr hoch, was zu einer häufigen Erschöpfung des Pools führt. Um diesem Problem zu begegnen, erhöhen Sie die PAT-Pool-Größe.

F. Wie wird die Unterstützung für das erweiterte Schlüsselwort gehandhabt? Zeigt es einen Fehler an und verhindert, dass der gesamte NAT-Befehl während des Upgrades hinzugefügt wird, oder entfernt er das erweiterte Schlüsselwort und zeigt eine Warnung an?

Antwort: Die Option "extended" (erweiterte PAT) wird vom Cluster ab ASA 9.15.1/FP 6.7 nicht unterstützt. Die Konfigurationsoption wird nicht aus CLI/ASDM/CSM/FMC entfernt. Bei der Konfiguration (direkt oder indirekt durch ein Upgrade) erhalten Sie eine Warnmeldung, und die Konfiguration wird akzeptiert, aber die erweiterte Funktionalität von PAT wird nicht in Aktion angezeigt.

F. Ist es die gleiche Anzahl von Übersetzungen wie gleichzeitige Verbindungen?

Antwort: In der Zeit vor 6.7/9.15.1 war es 1-65.535, da die Quellports nie viel im Bereich von 1-1024 verwendet werden, wird es praktisch zu 1024-65535 (64.512 Verbindungen). In der Implementierung nach 6.7/9.15.1 mit dem Standardverhalten "flach" lautet sie 1024-65535. Wenn Sie jedoch die 1-1024 verwenden möchten, können Sie die Option "include-reserve" verwenden.

F. Wenn der Knoten dem Cluster wieder beitritt, hat er den alten Backup-Knoten als "backup" und dieser Backup-Knoten gibt ihm seinen alten Port-Block?

Antwort: Dies hängt von der Verfügbarkeit der Port-Blöcke zu diesem Zeitpunkt ab. Wenn ein Knoten den Cluster verlässt, werden alle seine Port-Blöcke in den Backup-Knoten verschoben. Anschließend sammelt der Kontrollknoten freie Portblöcke und verteilt sie an die erforderlichen Knoten.

F. Wenn sich der Zustand des Kontrollknotens ändert, ein neuer Kontrollknoten ausgewählt wird, wird die PAT-Blockzuweisung beibehalten, oder werden die Port-Blöcke basierend auf dem neuen Kontrollknoten neu zugewiesen?

Antwort: Der neue Steuerelementknoten erkennt, welche Blöcke zugewiesen wurden und welche frei sind und beginnt von dort.

F. Entspricht die maximale Anzahl an Xlates der maximalen Anzahl gleichzeitiger Verbindungen mit diesem neuen Verhalten?

Antwort: Ja. Die maximale Anzahl an XLATE hängt von der Verfügbarkeit der PAT-Ports ab. Es hat nichts mit der maximalen Anzahl gleichzeitiger Verbindungen zu tun. Wenn Sie nur eine Adresse zulassen, haben Sie 65535 mögliche Verbindungen. Wenn Sie mehr benötigen, müssen Sie mehr IP-Adressen zuweisen. Wenn genügend Adressen/Ports vorhanden sind, können Sie die maximale Anzahl gleichzeitiger Verbindungen erreichen.

F. Wie erfolgt die Zuweisung von Port-Blöcken, wenn ein neuer Cluster-Member hinzugefügt wird? Was geschieht, wenn ein Cluster-Mitglied aufgrund eines Neustarts hinzugefügt wird?

Antwort: Port-Blöcke werden immer vom Kontrollknoten verteilt. Port-Blöcke werden einem neuen Knoten nur dann zugewiesen, wenn freie Port-Blöcke vorhanden sind. Freie Port-Blöcke bedeuten, dass keine Verbindung über einen zugeordneten Port im Port-Block hergestellt wird.

Außerdem berechnet jeder Knoten bei der erneuten Zusammenführung die Anzahl der Blöcke, die er besitzen kann. Wenn ein Knoten mehr Blöcke als vorgesehen besitzt, werden diese zusätzlichen Port-Blöcke an den Kontrollknoten freigegeben, sobald sie verfügbar sind. Der Steuerelementknoten weist sie dann dem neu hinzugefügten Datenknoten zu.

F. Wird nur TCP- und UDP-Protokolle oder SCTP unterstützt?

Antwort: SCTP wurde nicht von dynamischen PAT unterstützt. Für SCTP-Datenverkehr wird empfohlen, nur ein statisches Netzwerkobjekt als NAT zu verwenden.

F. Läuft einem Knoten die Blockports aus, werden Pakete verworfen und der nächste verfügbare IP-Block wird nicht verwendet?

Antwort: Nein, es geht nicht sofort. Es verwendet verfügbare Port-Blöcke von der nächsten PAT-IP-Adresse. Wenn alle Port-Blöcke aller PAT-IPs ausgeschöpft sind, wird der Datenverkehr verworfen.

F. Ist es besser, ein neues Steuerelement früher manuell auszuwählen (z. B. zur Hälfte durch ein Cluster-Upgrade), um die Überlastung des Steuerungsknotens in einem Cluster-Upgrade-Fenster zu vermeiden, anstatt abzuwarten, bis alle Verbindungen auf dem Steuerungsknoten verarbeitet werden?

Antwort: Das Steuerelement muss zuletzt aktualisiert werden. Dies liegt daran, dass der Steuerknoten beim Ausführen der neueren Version nur dann die Verteilung des Pools initiiert, wenn alle Knoten die neuere Version ausführen. Wenn ein Upgrade ausgeführt wird, ignorieren alle Datenknoten mit einer neueren Version Poolverteilungsmeldungen von einem Kontrollknoten, wenn eine ältere Version ausgeführt wird.

Um dies detailliert zu erklären, betrachten Sie eine Cluster-Bereitstellung mit 4 Knoten A, B, C und D mit A als Steuerelement. Nachfolgend sind die typischen Upgrade-Schritte aufgeführt:

1. Laden Sie eine neue Version auf die einzelnen Knoten herunter.

2. Gerät "D" neu laden. Alle Verbindungen, XLATE werden zum Sicherungsknoten verschoben.

3. Einheit "D" wird angezeigt und:

a) Prozesse PAT-Konfiguration

b) Unterteilt jede PAT-IP in Port-Blöcke

c) Enthält alle Port-Blöcke im nicht zugewiesenen Status

d) Ignoriert ältere Versionen von Cluster-PAT-Nachrichten, die von der Kontrolle empfangen wurden

e Umleitung aller PAT-Verbindungen zum Master

4. Wechseln Sie mit der neuen Version auf andere Knoten.

5. Steuerung der Einheit "A" neu laden. Da keine Datensicherung für die Steuerung vorhanden ist, werden alle vorhandenen Verbindungen verworfen

6. Die neue Steuerung startet die Verteilung von Port-Blöcken im neueren Format

7. Einheit "A" fügt sich zusammen und kann Port-Block-Verteilungsmeldungen akzeptieren und bearbeiten.

Fragment-Verarbeitung

Symptom

In Clusterbereitstellungen zwischen Standorten können fragmentierte Pakete, die an einem bestimmten Standort (Site-Local-Datenverkehr) behandelt werden müssen, dennoch an die Einheiten an anderen Standorten gesendet werden, da einer dieser Standorte den Eigentümer des Fragments haben kann.

In der Cluster-Logik gibt es eine zusätzliche Rolle für Verbindungen mit fragmentierten Paketen: Fragmentbesitzer.

Bei fragmentierten Paketen bestimmen Cluster-Einheiten, die ein Fragment empfangen, anhand eines Hashs aus der Quell-IP-Adresse, der Ziel-IP-Adresse und der Paket-ID den Eigentümer des Fragments. Alle Fragmente werden dann über die Cluster-Steuerungsverbindung an den Fragmentbesitzer weitergeleitet. Fragmente können auf unterschiedliche Cluster-Einheiten verteilt werden, da nur das erste Fragment den 5-Tupel-Hash für den Lastenausgleich des Switches enthält. Andere Fragmente enthalten nicht die Quell- und Ziel-Ports und können mit einem Load Balancing auf andere Cluster-Einheiten verbunden werden. Der Eigentümer des Fragments reassembliert das Paket vorübergehend, sodass er den Director anhand eines Hashs der Quell-/Ziel-IP-Adresse und -Ports ermitteln kann. Wenn es sich um eine neue Verbindung handelt, wird der Eigentümer des Fragments zum Besitzer der Verbindung. Wenn es sich um eine vorhandene Verbindung handelt, leitet der Fragmentbesitzer alle Fragmente über die Cluster-Steuerungsverbindung an den Verbindungsverantwortlichen weiter. Der Besitzer der Verbindung setzt dann alle Fragmente wieder zusammen.

Betrachten Sie diese Topologie mit dem Fluss einer fragmentierten ICMP-Echoanfrage vom Client zum Server:

Um die Reihenfolge der Vorgänge zu ermitteln, gibt es clusterweite Paketerfassungen auf der internen, externen und Cluster-Steuerungsschnittstelle, die mit der Option trace konfiguriert sind. Zusätzlich wird auf der internen Schnittstelle eine Paketerfassung mit der Option reject-hide konfiguriert.

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

Reihenfolge der Vorgänge im Cluster:

1. Die Einheit-1-1 an Standort 1 empfängt die fragmentierten ICMP-Echoanforderungspakete.

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 wählt Einheit-2-2 an Standort 2 als Fragmentbesitzer aus und sendet fragmentierte Pakete an diese.

Die Ziel-MAC-Adresse der Pakete, die von Einheit-1-1 an Einheit-2-2 gesendet werden, ist die MAC-Adresse der CCL-Verbindung in Einheit-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 empfängt, reassembliert die fragmentierten Pakete und wird zum Eigentümer des Datenflusses.

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. In Einheit 2-2 werden die Pakete auf der Grundlage der Sicherheitsrichtlinie zugelassen und über die externe Schnittstelle von Standort 2 an Standort 1 gesendet.

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

Beobachtungen/Einwände

- Im Gegensatz zur Director-Rolle kann der Fragmentbesitzer nicht innerhalb einer bestimmten Site lokalisiert werden. Der Eigentümer des Fragments wird von der Einheit bestimmt, die die fragmentierten Pakete einer neuen Verbindung ursprünglich empfängt und sich an einem beliebigen Standort befinden kann.

- Da ein Fragmentbesitzer auch der Eigentümer der Verbindung werden kann, muss er dann in der Lage sein, die Ausgangsschnittstelle aufzulösen, die IP- und MAC-Adressen des Ziel-Hosts oder des nächsten Hop zu finden, um die Pakete an den Ziel-Host weiterzuleiten. Dies setzt voraus, dass der nächste Hop bzw. die nächsten Hosts auch die Erreichbarkeit zum Ziel-Host haben müssen.

- Um die fragmentierten Pakete neu zusammenzufügen, unterhält ASA/FTD ein IP-Fragmentreassemblierungsmodul für jede benannte Schnittstelle. Um die Betriebsdaten des IP-Fragmentreassemblierungsmoduls anzuzeigen, verwenden Sie den Befehl show fragment:
Interface: inside

Configuration: Size: 200, Chain: 24, Timeout: 5, Reassembly: virtual

Run-time stats: Queue: 0, Full assembly: 0

Drops: Size overflow: 0, Timeout: 0,

Chain overflow: 0, Fragment queue threshold exceeded: 0,

Small fragments: 0, Invalid IP len: 0,

Reassembly overlap: 0, Fraghead alloc failed: 0,

SGT mismatch: 0, Block alloc failed: 0,

Invalid IPV6 header: 0, Passenger flow assembly failed: 0
In Clusterbereitstellungen steckte der Fragmentbesitzer oder der Verbindungspersonal die fragmentierten Pakete in die Fragmentwarteschlange. Die Fragmentwarteschlangengröße wird durch den Wert des Zählers Größe (standardmäßig 200) begrenzt, der mit dem Befehl fragment size <size> <name> konfiguriert ist. Wenn die Fragmentwarteschlangengröße 2/3 der Size (Größe) erreicht, wird der Fragmentwarteschlangenschwellenwert als überschritten angesehen. Alle neuen Fragmente, die nicht Teil der aktuellen Fragmentkette sind, werden verworfen. In diesem Fall wird der Grenzwert für die Fragment-Warteschlange erhöht, und die Syslog-Meldung FTD-3-209006 wird generiert.

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 Problemumgehung können Sie die Größe in FirePOWER Management Center > Devices > Device Management > [Edit Device] > Interfaces > [Interface] > Advanced > Security Configuration > Override Default Fragment Setting erhöhen, Konfigurations- und Bereitstellungsrichtlinien speichern. Überwachen Sie dann den Zähler für Warteschlangen in der Befehlsausgabe show fragment und das Auftreten der Syslog-Meldung FTD-3-209006.

ACI-Probleme

Intermittierende Verbindungsprobleme über den Cluster aufgrund der aktiven L4-Prüfsummenüberprüfung in ACI Pod

Symptom

- Gelegentliche Verbindungsprobleme über das ASA/FTD-Cluster, das in einem ACI-POD bereitgestellt wird.

- Wenn sich im Cluster nur eine Einheit befindet, werden die Verbindungsprobleme nicht beobachtet.

- Pakete, die von einer Clustereinheit an eine oder mehrere andere Einheiten im Cluster gesendet werden, sind in den FXOS- und Datenebenenaufnahmen der Zieleinheiten nicht sichtbar.

Eindämmung

- Umgeleiteter Datenverkehr über die Cluster-Steuerungsverbindung verfügt nicht über eine richtige L4-Prüfsumme, und dieses Verhalten wird erwartet. Switches im Cluster-Steuerelementverknüpfungspfad dürfen die L4-Prüfsumme nicht überprüfen. Switches, die die L4-Prüfsumme überprüfen, können dazu führen, dass Datenverkehr verworfen wird. Überprüfen Sie die ACI Fabric Switch-Konfiguration, und stellen Sie sicher, dass keine L4-Prüfsumme für die empfangenen oder versendeten Pakete über die Cluster Control Link durchgeführt wird.

Probleme mit der Cluster-Kontrollebene

Einheit kann dem Cluster nicht beitreten

MTU-Größe in CCL

Symptome

Die Einheit kann dem Cluster nicht beitreten, und diese Meldung wird angezeigt:

The slave has left the cluster because application configuration sync is timed out on this unit. Disabling cluster now!

Cluster disable is performing cleanup..done.

Unit unit-2-1 is quitting due to system failure for 1 time(s) (last failure is Slave application configuration sync timeout). Rejoin will be attempted after 5 minutes.

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

Verifizierung/Risikominderung

- Verwenden Sie den Befehl show interface im FTD, um zu überprüfen, ob die MTU der Cluster-Steuerungsverbindungsschnittstelle mindestens 100 Byte höher ist als die MTU der Datenschnittstelle:

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.

- Führen Sie einen Ping mit der Größenoption über CCL aus, um zu überprüfen, ob die Konfiguration für die CCL-MTU auf allen Geräten im Pfad korrekt konfiguriert ist.

firepower# ping 127.2.1.1 size 9184

- Verwenden Sie den Befehl show interface auf dem Switch, um die MTU-Konfiguration zu überprüfen.

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

Schnittstellenungleichheit zwischen Cluster-Einheiten

Symptome

Die Einheit kann dem Cluster nicht beitreten, und diese Meldung wird angezeigt:

Interface mismatch between cluster master and joining unit unit-2-1. unit-2-1 aborting cluster join.

Cluster disable is performing cleanup..done.

Unit unit-2-1 is quitting due to system failure for 1 time(s) (last failure is Internal clustering error). Rejoin will be attempted after 5 minutes.

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

Verifizierung/Risikominderung

Melden Sie sich in der FCM-GUI jedes Chassis an, navigieren Sie zur Registerkarte Schnittstellen, und überprüfen Sie, ob alle Cluster-Mitglieder die gleiche Schnittstellenkonfiguration haben:

- Dem logischen Gerät zugewiesene Schnittstellen

- Administratorgeschwindigkeit der Schnittstellen

- Admin-Duplex der Schnittstellen

- Schnittstellenstatus

Problem mit der Daten-/Port-Channel-Schnittstelle

Split-Hirn aufgrund von Erreichbarkeitsproblemen über CCL

Symptom

Im Cluster gibt es mehrere Kontrolleinheiten. Betrachten Sie die folgende Topologie:

Chassis 1:

firepower# show cluster info

Cluster ftd_cluster1: On

Interface mode: spanned

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

ID : 0

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2103TU5H

CCL IP : 127.2.1.1

CCL MAC : 0015.c500.018f

Last join : 07:30:25 UTC Dec 14 2020

Last leave: N/A

Other members in the cluster:

Unit "unit-1-2" in state SLAVE

ID : 1

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2103TU4D

CCL IP : 127.2.1.2

CCL MAC : 0015.c500.019f

Last join : 07:30:26 UTC Dec 14 2020

Last leave: N/A

Unit "unit-1-3" in state SLAVE

ID : 3

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2102THJT

CCL IP : 127.2.1.3

CCL MAC : 0015.c500.016f

Last join : 07:31:49 UTC Dec 14 2020

Last leave: N/A

Chassis 2:

firepower# show cluster info

Cluster ftd_cluster1: On

Interface mode: spanned

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

ID : 4

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2103TUN1

CCL IP : 127.2.2.1

CCL MAC : 0015.c500.028f

Last join : 11:21:56 UTC Dec 23 2020

Last leave: 11:18:51 UTC Dec 23 2020

Other members in the cluster:

Unit "unit-2-2" in state SLAVE

ID : 2

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2102THR9

CCL IP : 127.2.2.2

CCL MAC : 0015.c500.029f

Last join : 11:18:58 UTC Dec 23 2020

Last leave: 22:28:01 UTC Dec 22 2020

Unit "unit-2-3" in state SLAVE

ID : 5

Site ID : 1

Version : 9.15(1)

Serial No.: FLM2103TUML

CCL IP : 127.2.2.3

CCL MAC : 0015.c500.026f

Last join : 11:20:26 UTC Dec 23 2020

Last leave: 22:28:00 UTC Dec 22 2020

Überprüfung

- Verwenden Sie den Befehl ping, um die Verbindung zwischen den IP-Adressen der Kontrolleinheiten der Cluster Control Link (CCL) zu überprüfen:

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)

- Überprüfen Sie die ARP-Tabelle:

firepower# show arp

cluster 127.2.2.3 0015.c500.026f 1

cluster 127.2.2.2 0015.c500.029f 1

- Konfigurieren und überprüfen Sie in Steuereinheiten die Erfassung der CCL-Schnittstellen:

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

Eindämmung

- Stellen Sie sicher, dass die CCL-Port-Channel-Schnittstellen mit separaten Port-Channel-Schnittstellen am Switch verbunden sind.

- Wenn auf Nexus-Switches virtuelle Port-Channels (vPC) verwendet werden, stellen Sie sicher, dass die CCL-Port-Channel-Schnittstellen mit unterschiedlichen vPCs verbunden sind und dass die vPC-Konfiguration nicht über einen fehlgeschlagenen Konsistenzstatus verfügt.

- Stellen Sie sicher, dass sich die CCL-Port-Channel-Schnittstellen in derselben Broadcast-Domäne befinden und das CCL-VLAN erstellt und für die Schnittstellen zugelassen ist.

Dies ist eine Switch-Beispielkonfiguration:

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

Deaktiviertes Cluster aufgrund ausgesetzter Port-Channel-Schnittstellen für Daten

Symptom

Eine oder mehrere Daten-Port-Channel-Schnittstellen werden ausgesetzt. Wenn eine administrativ aktivierte Datenschnittstelle ausgesetzt wird, werden alle Cluster-Einheiten im gleichen Chassis aufgrund eines Ausfalls der Schnittstellenstatusprüfung aus dem Cluster entfernt.

Betrachten Sie die folgende Topologie:

Überprüfung

- Überprüfen Sie die Systemsteuerungskonsole:

firepower#

Beginning configuration replication to Slave unit-2-2

End Configuration Replication to slave.

Asking slave unit unit-2-2 to quit because it failed interface health check 4 times (last failure on Port-channel1). Clustering must be manually enabled on the unit to rejoin.

- Überprüfen Sie die Ausgabe der Befehle show cluster history und show cluster info trace module hc in den betroffenen Einheiten:

firepower# Unit is kicked out from cluster because of interface health check failure.

Cluster disable is performing cleanup..done.

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

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

firepower# show cluster history

==========================================================================

From State To State Reason

==========================================================================

12:59:37 UTC Dec 23 2020

ONCALL SLAVE_COLD Received cluster control message

12:59:37 UTC Dec 23 2020

SLAVE_COLD SLAVE_APP_SYNC Client progression done

13:00:23 UTC Dec 23 2020

SLAVE_APP_SYNC SLAVE_CONFIG Slave application configuration sync done

13:00:35 UTC Dec 23 2020

SLAVE_CONFIG SLAVE_FILESYS Configuration replication finished

13:00:36 UTC Dec 23 2020

SLAVE_FILESYS SLAVE_BULK_SYNC Client progression done

13:01:35 UTC Dec 23 2020

SLAVE_BULK_SYNC DISABLED Received control message DISABLE (interface health check failure)

firepower# show cluster info trace module hc

Dec 23 13:01:36.636 [INFO]cluster_fsm_clear_np_flows: The clustering re-enable timer is started to expire in 598000 ms.

Dec 23 13:01:32.115 [INFO]cluster_fsm_disable: The clustering re-enable timer is stopped.

Dec 23 13:01:32.115 [INFO]Interface Port-channel1 is down

- Überprüfen Sie die Ausgabe des Befehls show port-channel summary in der fxos-Befehlsshell:

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)

Eindämmung

- Stellen Sie sicher, dass alle Chassis denselben Clustergruppennamen und dasselbe Kennwort haben.

- Stellen Sie sicher, dass die Port-Channel-Schnittstellen über administrativ aktivierte physische Mitgliedschnittstellen mit derselben Duplex/Geschwindigkeit-Konfiguration in allen Chassis und Switches verfügen.

- In standortinternen Clustern wird sichergestellt, dass dieselbe Datenport-Channel-Schnittstelle in allen Chassis mit derselben Port-Channel-Schnittstelle am Switch verbunden ist.

- Wenn in Nexus-Switches virtuelle Port-Channels (vPC) verwendet werden, müssen Sie sicherstellen, dass die vPC-Konfiguration nicht über einen fehlgeschlagenen Konsistenzstatus verfügt.

- In standortinternen Clustern wird sichergestellt, dass dieselbe Daten-Port-Channel-Schnittstelle in allen Chassis mit demselben vPC verbunden ist.

Probleme mit der Cluster-Stabilität

FXOS-Traceback

Symptom

Die Einheit verlässt den Cluster.

Verifizierung/Risikominderung

- Verwenden Sie den Befehl show cluster history, um zu sehen, wann die Einheit das Cluster verlassen hat.

firepower# show cluster history

- Verwenden Sie diese Befehle, um zu überprüfen, ob der FXOS über eine Rückverfolgung verfügt.

FPR4150# connect local-mgmt

FPR4150 (local-mgmt)# dir cores

- Sammeln Sie die Core-Datei, die um den Zeitpunkt generiert wurde, an dem die Einheit den Cluster verlassen hat, und stellen Sie sie dem TAC zur Verfügung.

Festplatte voll

Falls die Festplattenauslastung in der /ngfw-Partition einer Cluster-Einheit 94 % erreicht, beendet die Einheit den Cluster. Die Festplattenauslastungsprüfung findet alle 3 Sekunden statt:

> 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 diesem Fall zeigt die Ausgabe zum Anzeigen des Clusterverlaufs Folgendes an:

15:36:10 UTC May 19 2021

MASTER MASTER Event: Master unit unit-1-1 is quitting

due to diskstatus Application health check failure, and

master's application state is down

Oder

14:07:26 CEST May 18 2021

SLAVE DISABLED Received control message DISABLE (application health check failure)

Eine weitere Möglichkeit zum Überprüfen des Fehlers ist:

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

Wenn der Datenträger ~100 % beträgt, kann es außerdem Schwierigkeiten beim Beitreten zum Cluster geben, bis Speicherplatz freigegeben ist.

Überlaufschutz

Alle 5 Minuten prüft jede Cluster-Einheit die lokale und die Peer-Einheit auf CPU- und Speichernutzung. Wenn die Auslastung die Systemschwellenwerte (LINA CPU 50% oder LINA Memory 59%) überschreitet, wird eine Informationsmeldung angezeigt in:

- Syslogs (FTD-6-748008)

- Datei log/cluster_trace.log, z. B.

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.

Die Meldung bedeutet, dass bei einem Geräteausfall die verbleibenden Ressourcen der Einheit(en) überbelegt werden können.

Vereinfachter Modus

Verhalten bei FMC-Versionen vor 6.3

- Sie registrieren jeden Cluster-Knoten einzeln auf FMC.

- Dann bilden Sie einen logischen Cluster im FMC.

- Für jede neue Cluster-Knoten-Hinzufügung müssen Sie den Knoten manuell registrieren.

Nach 6,3 FMC

- Mit der vereinfachten Modusfunktion können Sie den gesamten Cluster in einem Schritt auf dem FMC registrieren (nur einen Knoten des Clusters registrieren).

Mindestanzahl unterstützter Manager

Verwaltete Geräte

Min. unterstützte Version für verwaltete Geräte erforderlich

Hinweise

FMC 6.3

FTD-Cluster nur auf FP9300 und FP4100

6.2.0

Dies ist nur eine FMC-Funktion.

Warnung: Sobald der Cluster in FTD gebildet wurde, müssen Sie auf den Start der automatischen Registrierung warten. Sie dürfen die Cluster-Knoten nicht manuell registrieren (Gerät hinzufügen), sondern die Option Reconcile (Ausgleich) verwenden.

Symptom

Fehler bei der Knotenregistrierung

- Wenn die Registrierung des Kontrollknotens aus irgendeinem Grund fehlschlägt, wird der Cluster vom FMC gelöscht.

Eindämmung

Wenn die Registrierung eines Datenknotens aus irgendeinem Grund fehlschlägt, gibt es zwei Optionen:

1. Bei jeder Bereitstellung für Cluster überprüft das FMC, ob Cluster-Knoten registriert werden müssen, und startet dann die automatische Registrierung für diese Knoten.

2. Auf der Registerkarte Clusterübersicht ist eine Option zum Ausgleichen verfügbar (Geräte > Gerätemanagement > Registerkarte Cluster > Cluster-Status anzeigen). Sobald die Reconcile-Aktion ausgelöst wurde, startet FMC die automatische Registrierung der zu registrierenden Knoten.

Zugehörige Informationen

- Clustering für den Schutz vor Bedrohungen durch Firepower

- ASA-Cluster für das FirePOWER 4100/9300-Chassis

- Informationen zum Clustering auf dem FirePOWER 4100/9300-Chassis

- FirePOWER NGFW Clustering Deep Dive - BRKSEC-3032

- Analyse der FirePOWER Firewall-Erfassungen zur effektiven Behebung von Netzwerkproblemen