Firepower Threat Defense(FTD)クラスタのトラブルシューティング

ダウンロードオプション

PDF (4.1 MB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (4.0 MB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (2.6 MB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2021 年 5 月 20 日

Document ID:216745

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

概要

前提条件

要件

使用するコンポーネント

設定

クラスタの基本

NGFWアーキテクチャ

クラスタキャプチャ

Cluster Control Link(CCL)メッセージ

クラスタ制御ポイント(CCP)メッセージ

クラスタヘルスチェック(HC)メカニズム

クラスタHC障害シナリオ

クラスタデータプレーン接続の確立

トラブルシュート

クラスタデータプレーンの問題

NAT/PATの一般的な問題

フラグメント処理

ACIの問題

クラスタコントロールプレーンの問題

ユニットがクラスタに参加できない

データ/ポートチャネルインターフェイスの問題

クラスタの安定性の問題

簡易モード

概要

このドキュメントでは、Firepower Next-Generation Firewall(NGFW)でのクラスタ設定のトラブルシューティングについて説明します。このドキュメントで説明する項目の大部分は、適応型セキュリティアプライアンス(ASA)クラスタのトラブルシューティングにも完全に適用されます。

前提条件

要件

次の項目に関する知識があることが推奨されます（リンクについては、「関連情報」の項を参照）。

Firepowerプラットフォームアーキテクチャ
Firepowerクラスタの設定と動作
FTDおよびFXOS CLIに関する知識
NGFW/データプレーンログ
NGFW/データプレーンパケットトレーサ
Firepower eXtensible Operating System(FXOS)/データプレーンキャプチャ

使用するコンポーネント

HW:Firepower 4125
SW :6.7.0（ビルド65） – データプレーン9.15(1)

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメント内で使用されているデバイスはすべて、クリアな設定（デフォルト）から作業を始めています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

設定

クラスタ導入の設定部分については、FMCおよびFXOSのコンフィギュレーションガイドで説明します。

クラスタの基本

NGFWアーキテクチャ

Firepower 41xxまたは93xxシリーズが適用するトランジットパケットの処理方法を理解することが重要です。

パケットは入力インターフェイスに入り、シャーシ内部スイッチによって処理されます。
パケットはスマートNICを通過します。フローがオフロード（HWアクセラレーション）されると、パケットはスマートNICによってのみ処理され、ネットワークに返送されます。
パケットがオフロードされない場合は、主にL3/L4チェックを行うFTDデータプレーンに入ります。
ポリシーが必要な場合、パケットはSnortエンジン（主にL7検査）によって検査されます。
Snortエンジンは、パケットの判定（許可やブロックなど）を返します。
データプレーンは、Snortの判定に基づいてパケットをドロップまたは転送します。
パケットは、内部シャーシスイッチを通じてシャーシに出力されます。

クラスタキャプチャ

Firepowerアプライアンスは、複数のキャプチャポイントを提供し、トランジットフローを可視化します。クラスタをトラブルシューティングして有効にすると、主な課題は次のようになります。

クラスタ内のユニット数が増加すると、キャプチャ数が増加します
クラスタを通過するパケットを追跡するために、クラスタが特定のフローを処理する方法を認識する必要があります

次の図は、2台のクラスタ（FP941xx/FP9300など）を示しています。

非対称TCP接続がTCP SYNを確立する場合、SYN/ACK交換は次のようになります。

トラフィックの転送

TCP SYNはホストAからホストBに送信されます。
TCP SYNがシャーシ（Po1のメンバの1つ）に到達します。
TCP SYNは、シャーシバックプレーンインターフェイス（E1/9、E1/10など）のいずれかを介してデータプレーンに送信されます。
TCP SYNがデータプレーン入力インターフェイス(Po1.201/INSIDE)に到達します。この例では、unit1-1がフローの所有権を取得し、Initial Sequence Number（ISN；初期シーケンス番号）のランダム化を行い、所有権(cookie)情報をSeq番号でエンコードします
TCP SYNはPo1.202/OUTSIDE（データプレーン出力インターフェイス）から送信されます。
TCP SYNがシャーシバックプレーンインターフェイス（E1/9、E1/10など）のいずれかに到達します。
TCP SYNは、シャーシの物理インターフェイス（Po1のメンバの1つ）からホストBに送信されます。

リターントラフィック

TCP SYN/ACKはホストBから送信され、ユニット2-1（Po1のメンバの1つ）に到達します。
TCP SYN/ACKは、シャーシバックプレーンインターフェイス（E1/9、E1/10など）を介してデータプレーンに送信されます。
TCP SYN/ACKがデータプレーン入力インターフェイス(Po1.202/OUTSIDE)に到達します。
TCP SYN/ACKはCluster Control Link(CCL)からユニット1-1に向けて送信されます。デフォルトでは、ISNは有効です。したがって、フォワーダはディレクタの関与なしにTCP SYN+ACKの所有者情報を検出します。他のパケットの場合、またはISNが無効の場合は、ディレクタに照会されます。
TCP SYN/ACKがシャーシバックプレーンインターフェイス（E1/9、E1/10など）のいずれかに到達します。
TCP SYN/ACKは、シャーシの物理インターフェイス（Po48のメンバの1つ）からユニット1-1に向けて送信されます。
TCP SYN/ACKがユニット1-1（Po48のメンバの1つ）に到着します。
TCP SYN/ACKは、シャーシバックプレーンインターフェイスの1つを介して、データプレーンCCLポートチャネルインターフェイス（nameifクラスタ）に転送されます。
データプレーンは、データプレーンインターフェイスPo1.202/OUTSIDEにTCP SYN/ACKパケットを再注入します。
TCP SYN/ACKがPo1.201/INSIDE（データプレーン出力インターフェイス）からHOST-Aに送信されます。
TCP SYN/ACKは、シャーシバックプレーンインターフェイス（E1/9、E1/10など）のいずれかを通過し、Po1のメンバの1つを出力します。
TCP SYN/ACKがホストBに到達します。

このシナリオの詳細については、「クラスタ接続確立のケーススタディ」の関連セクションを参照してください。

このパケット交換に基づいて、可能なすべてのクラスタキャプチャポイントは次のとおりです。

転送トラフィック（TCP SYNなど）のキャプチャ：

シャーシの物理インターフェイス（Po1メンバなど）。このキャプチャは、Chassis Manager(CM)UIまたはCM CLIから設定します。
データプレーン入力インターフェイス（Po1.201 INSIDEなど）。
データプレーン出力インターフェイス（Po1.202 OUTSIDEなど）。
シャーシバックプレーンインターフェイス。FP4100には2つのバックプレーンインターフェイスがあります。FP9300では、合計6個（モジュールあたり2個）です。パケットがどのインターフェイスに到達したかわからないため、すべてのインターフェイスでキャプチャを有効にする必要があります。

リターントラフィック（TCP SYN/ACKなど）のキャプチャ：

シャーシの物理インターフェイス（Po1メンバなど）。このキャプチャは、Chassis Manager(CM)UIまたはCM CLIから設定します。
データプレーン入力インターフェイス（Po1.202 OUTSIDEなど）。
パケットがリダイレクトされるため、次のキャプチャポイントはデータプレーンCCLです。
シャーシバックプレーンインターフェイス。ここでも、両方のインターフェイスでキャプチャを有効にする必要があります。
ユニット1-1シャーシのCCLメンバーインターフェイス
データプレーンCCLインターフェイス（nameifクラスタ）。
入力インターフェイス(Po1.202 OUTSIDE)。これは、CCLからデータプレーンへの再注入パケットです。
データプレーン出力インターフェイス（Po1.201 INSIDEなど）。
シャーシバックプレーンインターフェイス。

クラスタキャプチャを有効にする方法

FXOSキャプチャ

このプロセスについては、『FXOS Config Guide:パケットキャプチャ

注：FXOSキャプチャは、内部スイッチの観点から入力方向でのみ取得できます。

データプレーンキャプチャ

すべてのクラスタメンバーでキャプチャを有効にする推奨方法は、cluster execコマンドを使用します。

3ユニットのクラスタについて考えてみましょう。

すべてのクラスタユニットにアクティブなキャプチャがあるかどうかを確認するには、次のコマンドを使用します。

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

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

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

Po1.201（内部）のすべてのユニットでデータプレーンキャプチャを有効にするには、次の手順を実行します。

firepower# cluster exec capture CAPI interface INSIDE

キャプチャフィルタを指定することを強く推奨します。キャプチャバッファを増やすトラフィックが多いと予想される場合は、次の手順を実行します。

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

確認

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

すべてのキャプチャの内容を表示するには（この出力は非常に長い場合があります）:

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

トレースのキャプチャ

各ユニットのデータプレーンで入力パケットがどのように処理されるかを確認するには、traceキーワードを使用します。これにより、最初の50個の入力パケットがトレースされます。最大1000の入力パケットをトレースできます。インターフェイスに複数のキャプチャが適用されている場合は、1つのパケットを1回だけトレースできます。

すべてのクラスタユニットのインターフェイスOUTSIDEで最初の1000の入力パケットをトレースするには、次の手順を実行します。

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

対象のフローをキャプチャしたら、各ユニットの対象パケットを確実にトレースする必要があります。注意すべき重要な点は、特定のパケットがunit-1-1上に存在する場合#1、別のユニット上に存在する場合#2あることです。

この例では、SYN/ACKがユニット2-1のパケット#2であり、ユニット3-1のパケット#1であることがわかります。

firepower# cluster exec show capture CAPO | include S.*ack
unit-1-1(LOCAL):******************************************************
1: 12:58:31.117700 802.1Q vlan#202 P0 192.168.240.50.45468 > 192.168.241.50.80: S 441626016:441626016(0) win 29200 <mss 1380,sackOK,timestamp 1115330849 0,nop,wscale 7>
2: 12:58:31.118341 802.1Q vlan#202 P0 192.168.241.50.80 > 192.168.240.50.45468: S 301658077:301658077(0) ack 441626017 win 28960 <mss 1460,sackOK,timestamp 1125686319 1115330849,nop,wscale 7>

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

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

ローカルユニットでパケット#2(SYN/ACK)をトレースするには、次の手順を実行します。

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

リモートユニットで同じパケット(SYN/ACK)をトレースするには、次の手順を実行します。

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キャプチャ

CCLリンク（すべてのユニット）でキャプチャを有効にするには、次の手順に従います。

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

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

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

再オブジェクト非表示

デフォルトでは、データプレーンデータインターフェイスで有効になっているキャプチャはすべてのパケットを表示します。

物理ネットワークから到達するもの
CCLから再注入されたもの

再注入されたパケットを表示しない場合は、reinject-hideオプションを使用します。これは、フローが非対称であるかどうかを確認する場合に役立ちます。

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

このキャプチャは、ローカルユニットが物理ネットワークから直接インターフェイスで実際に受信した内容だけを示し、他のクラスタユニットからは受信しません。

ASPドロップ

特定のフローに対するソフトウェアのドロップを確認する場合は、asp-dropキャプチャを有効にします。どのドロップ理由に注目すべきかわからない場合は、キーワードallを使用します。さらに、パケットペイロードに興味がない場合は、headers-onlyキーワードを指定できます。これにより、20 ～ 30倍のパケットをキャプチャできます。

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

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

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

さらに、ASPキャプチャに関連するIPを指定できます。

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

キャプチャのクリア

すべてのクラスタユニットで実行されているキャプチャのバッファをクリアする。これにより、キャプチャは停止されませんが、バッファだけがクリアされます。

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

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

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

キャプチャの停止

すべてのクラスタユニットでアクティブなキャプチャを停止するには、2つの方法があります。後で再開できます。

方法1

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

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

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

再開するには

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

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

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

方法2

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

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

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

再開するには

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

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

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

キャプチャの収集

キャプチャをエクスポートするには、複数の方法があります。

方法1 – リモートサーバへ

これにより、データプレーンからリモートサーバ（TFTPなど）にキャプチャをアップロードできます。キャプチャ名は、ソース単位を反映するように自動的に変更されます。

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 !

アップロードされたpcapファイル：

方法2:FMCからのキャプチャの取得

この方法はFTDにのみ適用されます。まず、キャプチャをFTDディスクにコピーします。

firepower# cluster exec copy /pcap capture:CAPI disk0:CAPI.pcap
unit-1-1(LOCAL):******************************************************

Source capture name [CAPI]?

Destination filename [CAPI.pcap]?
!!!!!
62 packets copied in 0.0 secs

エキスパートモードから/mnt/disk0/から/ngfw/var/common/ディレクトリにファイルをコピーします。

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

最後に、FMCで、[System] > [Health] > [Monitor]セクションに移動します。[View System & Troubleshoot Details] > [Advanced Troubleshooting]を選択し、キャプチャファイルを取得します。

キャプチャの削除

すべてのクラスタユニットからキャプチャを削除するには、次のコマンドを使用します。

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

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

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

オフロードされたフロー

FP41xx/FP9300のフローは、静的（Fastpathルールなど）または動的にHWアクセラレータにオフロードできます。フローオフロードの詳細については、次のドキュメントを参照してください。

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

フローがオフロードされている場合、FTDデータプレーンを通過するパケットは少数です。その他はHWアクセラレータ（スマートNIC）で処理されます。

キャプチャの観点から見ると、これは、FTDデータプレーンレベルのキャプチャだけを有効にすると、デバイスを通過するすべてのパケットが表示されないことを意味します。この場合は、FXOSシャーシレベルのキャプチャも有効にする必要があります。

Cluster Control Link(CCL)メッセージ

CCLでキャプチャを取得すると、クラスタユニットが異なるタイプのメッセージを交換していることがわかります。次の点に注目してください。

プロトコル	説明
UDP 49495	クラスタハートビート（キープアライブ）・ L3ブロードキャスト(255.255.255.255) ・これらのパケットは、ヘルスチェック保留時間値の1/3で、各クラスタユニットによって送信されます。・キャプチャで見られるすべてのUDP 49495パケットがハートビートではないことに注意してください・ハートビートにはシーケンス番号が含まれます
UDP 4193	Cluster Control Protocolデータパスメッセージ・ユニキャスト・これらのパケットには、フローオーナー、ディレクタ、バックアップオーナーなどに関する情報（メタデータ）が含まれます。例は、・新しいフローが作成されると、「cluster add」メッセージが所有者からダイレクタに送信される・フローが終了すると、「cluster delete」メッセージが所有者からダイレクタに送信される
データパケット	クラスタを通過するさまざまなトラフィックフローに属するデータパケット

クラスタハートビート

クラスタ制御ポイント(CCP)メッセージ

ハートビートメッセージに加えて、特定のシナリオでCCLを介して交換されるクラスタ制御メッセージが多数あります。一部はユニキャストメッセージで、他はブロードキャストです。

CLUSTER_QUIT_REASON_MASTER_UNIT_HC

ユニットが制御ノードから3つの連続するハートビートメッセージを失うと、CCL上でCLUSTER_QUIT_REASON_MASTER_UNIT_HCメッセージが生成されます。このメッセージ：

ユニキャスト
1秒の間隔で各ユニットに送信されます
ユニットがこのメッセージを受信すると、クラスタが終了し(DISABLED)、再度参加します

Q. CLUSTER_QUIT_REASON_MASTER_UNIT_HCの目的は何ですか。

A.ユニット–3-1の（サイトB）から見ると、サイトAからユニット–1-1とユニット–2-1の両方への接続が失われるので、できるだけ早くメンバーリストから削除する必要があります。ユニット–2-1がメンバーのリストに残り、ユニット–2-1にクエリ失敗します。

CLUSTER_QUIT_REASON_UNIT_HC

制御ノードは、データノードから3つの連続したハートビートメッセージを失うと、CCL経由でCLUSTER_QUIT_REASON_UNIT_HCメッセージを送信します。このメッセージはユニキャストです。

CLUSTER_QUIT_REASON_STRAY_MEMBER

分割パーティションがピアパーティションに再接続すると、新しいデータノードは支配的な制御ユニットによって迷子のメンバとして扱われ、CLUSTER_QUIT_REASON_STRAY_MEMBERの理由を含むCCP終了メッセージを受信します。

CLUSTER_QUIT_MEMBER_DROPOUT

データノードによって生成され、ブロードキャストとして送信されるブロードキャストメッセージ。ユニットがこのメッセージを受信すると、DISABLEDステータスに移行します。さらに、自動再結合はキックオフしません。

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

クラスタ履歴には次のように表示されます。

MASTER       DISABLED      Received control message DISABLE (member dropout announcement)

クラスタヘルスチェック(HC)メカニズム

主なポイント

各クラスタユニットは、ヘルスチェック保留時間の値の1/3ごとにハートビートを他のすべてのユニット(ブロードキャスト255.255.255.255)に送信し、CCL上の転送としてUDPポート49495を使用します。
各クラスタユニットは、PollタイマーとPollカウント値を使用して、他のユニットごとに個別に追跡します。
クラスタユニットがハートビート間隔内にクラスタピアユニットからパケット（ハートビートまたはデータパケット）を受信しない場合、Poll countの値が増加します。
クラスタピアユニットのポーリングカウント値が3になると、ピアはダウンしていると見なされます。
ハートビートが受信されるたびに、そのシーケンス番号がチェックされ、以前に受信したハートビートとの差分が1と異なる場合、ハートビート廃棄カウンタが増加します。
クラスタピアのポーリングカウントカウンタが0以外で、パケットがピアで受信された場合、カウンタは0にリセットされます。

クラスタのヘルスカウンタを確認するには、次のコマンドを使用します。

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

メイン列の説明

カラム	説明
ユニット(ID)	リモートクラスタピアのID
ハートビート数	CCL経由でリモートピアから受信したハートビートの数
ハートビートのドロップ	失われたハートビートの数。このカウンタは、受信したハートビートシーケンス番号に基づいて計算されます
平均ギャップ	受信したハートビートの平均時間
ポーリング数	このカウンタが3になると、ユニットはクラスタから削除されます。ポーリングクエリ間隔はハートビート間隔と同じですが、個別に実行されます

カウンタをリセットするには、次のコマンドを使用します。

firepower# clear cluster info health details

Q.ハートビート周波数の確認方法

A.平均ギャップ値を確認します。

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

Q. FTDのクラスタ保留時間を変更するにはどうすればよいのですか。

A. FlexConfigの使用

Q.スプリットブレインの後で制御ノードになるのは誰ですか。

A.優先順位が最も高い（最も低い数値）ユニット：

firepower# show run cluster | include priority
priority 9

詳細については、HC障害シナリオ1を確認してください。

クラスタHCメカニズムの可視化

指標タイマー：最小および最大は、最後に受信したCCLパケットの到着によって異なります

Hold time	投票クエリの確認 (周波数)	最小検出時間	最大検出時間
3秒（デフォルト）	～ 1秒	～ 3.01秒	～ 3.99秒
4 秒	～ 1.33秒	～ 4.01秒	～ 5.32秒
5 秒	～ 1.66秒	～ 5.01秒	～ 6.65秒
6 秒	～ 2秒	～ 6.01秒	～ 7.99秒
7 秒	～ 2.33秒	～ 7.01秒	～ 9.32秒
8 秒	～ 2.66秒	～ 8.01秒	～ 10.65秒

クラスタHC障害シナリオ

このセクションの目的は、次の内容を実証することです。

さまざまなクラスタHC障害シナリオ
さまざまなログとコマンド出力の関連付け

トポロジ

クラスタの設定

ユニット1-1

ユニット2-1

ユニット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

クラスタステータス

ユニット1-1

ユニット2-1

ユニット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

シナリオ 1

両方向で約4秒以上のCCL通信損失

障害発生前

FTD1	Ftd2	FTD3
サイトA	サイトA	サイトB
制御ノード	データノード	データノード

回復後（ユニットの役割は変更なし）

FTD1	Ftd2	FTD3
サイトA	サイトA	サイトB
制御ノード	データノード	データノード

分析

障害（CCL通信が失われました）

ユニット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.

ユニット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).

脳の分裂

ユニット1-1

ユニット2-1

ユニット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

クラスタ履歴

ユニット1-1	ユニット2-1	ユニット3-1
イベントなし	イベントなし	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

CCL通信復旧

ユニット–1-1は現在の制御ノードを検出し、ユニット–1-1の優先度が高いため、ユニット–3-1にCLUSTER_QUIT_REASON_STRAY_MEMBERメッセージを送信し、新しい選択プロセスをトリガーします。最後に、ユニット3-1はデータノードとして再結合します。

分割パーティションがピアパーティションに再接続すると、そのデータノードは支配的な制御ノードによって迷子メンバーとして扱われ、CLUSTER_QUIT_REASON_STRAY_MEMBERという理由のCCP終了メッセージを受信します。

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

両方のユニット（ユニット1-1およびユニット3-1）が、それぞれのクラスタログに表示されます。

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

また、スプリットブレイン用に生成されるsyslogメッセージもあります。

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

クラスタ履歴

ユニット1-1

ユニット2-1

ユニット3-1

イベントなし

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

シナリオ 2

両方向で約3 ～ 4秒間のCCL通信損失

障害発生前

FTD1	Ftd2	FTD3
サイトA	サイトA	サイトB
制御ノード	データノード	データノード

回復後（ユニットの役割は変更なし）

FTD1	Ftd2	FTD3
サイトA	サイトA	サイトB
制御ノード	データノード	データノード

分析

イベント 1：制御ノードは、ユニット3-1から3つのHCを失い、ユニット3-1にメッセージを送信してクラスタを終了します。

イベント 2：CCLは非常に高速で回復し、制御ノードからCLUSTER_QUIT_REASON_STRAY_MEMBERメッセージがリモート側に送られました。ユニット3-1は直接DISABLEDモードになり、スプリットブレインはありません

ユニット1-1（コントロール）では、次のように表示されます。

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

ユニット3-1（データノード）では、次のように表示されます。

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

クラスタユニット3-1はDISABLED状態に移行し、CCL通信が復元されると、データノードとして再加入します。

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

シナリオ 3

両方向で約3 ～ 4秒間のCCL通信損失

障害発生前

FTD1	Ftd2	FTD3
サイトA	サイトA	サイトB
制御ノード	データノード	データノード

リカバリ後（制御ノードが変更された）

FTD1	Ftd2	FTD3
サイトA	サイトA	サイトB
データノード	制御ノード	データノード

分析

CCLがダウンします。
ユニット1-1は、ユニット3-1から3つのHCメッセージを取得せず、ユニット3-1にQUITメッセージを送信します。このメッセージはユニット3-1には到達しません
ユニット3-1は、ユニット2-1にQUITメッセージを送信します。このメッセージはユニット2-1には到達しません。

CCL回復

ユニット–1-1は、ユニット–3-1自体が制御ノードとしてアドバタイズされたことを認識し、ユニット–3-1にQUIT_REASON_STRAY_MEMBERメッセージを送信します。ユニット–3-1がこのメッセージを受信すると、DISABLED状態になります。同時に、ユニット–3-1はQUIT_REASON_MASTER_UNIT_HCメッセージをユニット–1-1に送信し、終了を要求します。ユニット1-1がこのメッセージを受信すると、DISABLED状態になります

クラスタ履歴

ユニット1-1

ユニット2-1

ユニット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

シナリオ 4

3 ～ 4秒のCCL通信損失

障害発生前

FTD1	Ftd2	FTD3
サイトA	サイトA	サイトB
制御ノード	データノード	データノード

リカバリ後（制御ノードがサイトを変更）

FTD1	Ftd2	FTD3
サイトA	サイトA	サイトB
データノード	データノード	制御ノード

分析

失敗

同じ失敗の異なる味。この場合、ユニット–1-1もユニット–3-1から3つのHCメッセージを受信せず、新しいキープアライブが受信されると、ユニット–3-1をSTRAYメッセージでキックアウトしようとしましたが、メッセージはユニット–3-1に到達しませんでした。

CCLは数秒間、単方向になります。ユニット3-1は、ユニット1-1から3つのHCメッセージを受信せず、制御ノードとなる
Unit-2-1がCLUSTER_QUIT_REASON_RETIREMENTメッセージ（ブロードキャスト）を送信
ユニット3-1は、ユニット2-1にQUIT_REASON_MASTER_UNIT_HCメッセージを送信します。ユニット2-1はそれを受信し、クラスタを終了します。
ユニット–3-1は、ユニット–1-1にQUIT_REASON_MASTER_UNIT_HCメッセージを送信します。ユニット–1-1はそれを受信し、クラスタを終了します。CCLが回復しました。
Units-1-1および2-1はデータノードとしてクラスタに再加入します

注

ステップ5でCCLが回復しない場合、サイトAではFTD1が新しい制御ノードになり、CCLの回復後に新しい選択に勝ちます。

ユニット1-1のsyslogメッセージ：

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

ユニット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

ユニット3-1のsyslogメッセージ：

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

クラスタ履歴

ユニット1-1

ユニット2-1

ユニット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

シナリオ 5

障害発生前

FTD1	Ftd2	FTD3
サイトA	サイトA	サイトB
制御ノード	データノード	データノード

リカバリ後（変更なし）

FTD1	Ftd2	FTD3
サイトA	サイトA	サイトB
制御ノード	データノード	データノード

失敗

ユニット3-1はユニット1-1とユニット2-1の両方にQUITメッセージを送信しましたが、接続の問題によりユニット2-1のみがQUITメッセージを受信しました。

ユニット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

ユニット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

クラスタ履歴

ユニット1-1

ユニット2-1

ユニット3-1

イベントなし

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

クラスタデータプレーン接続の確立

NGFWキャプチャポイント

NGFWは、次の点でキャプチャ機能を提供します。

シャーシ内部スイッチ(FXOS)
FTDデータプレーンエンジン
FTD Snortエンジン

クラスタでデータパスの問題をトラブルシューティングする場合、ほとんどの場合、使用されるキャプチャポイントはFXOSおよびFTDデータプレーンエンジンのキャプチャです。

物理インターフェイスでのFXOS入力キャプチャ
データプレーンエンジンでのFTD入力キャプチャ
データプレーンエンジンでのFTD出力キャプチャ
バックプレーンインターフェイスでのFXOS入力キャプチャ

NGFWキャプチャの詳細については、次のドキュメントを参照してください。

クラスタユニットフローの役割の基本

接続は、次のような要因に応じて、複数の方法でクラスタを介して確立できます。

トラフィックのタイプ（TCP、UDPなど）
隣接スイッチに設定されたロードバランシングアルゴリズム
ファイアウォールに設定された機能
ネットワーク状態（IPフラグメンテーション、ネットワーク遅延など）

フローロール	説明	フラグ
主催者（Owner）	通常、最初に接続を受信するユニット	UIO
Director	フォワーダーからの所有者検索要求を処理する単位。	Y
バックアップ所有者	ディレクタがオーナーと同じユニットでない限り、ディレクタはバックアップオーナーでもあります。オーナーが自身をダイレクタとして選択すると、別のバックアップ・オーナーが選択されます。	Y（ダイレクタがバックアップ・オーナーでもある場合） y（ダイレクタがバックアップ・オーナーでない場合）
フォワーダ	所有者にパケットを転送するユニット	z
フラグメント所有者	フラグメント化されたトラフィックを処理するユニット	-
シャーシバックアップ	シャーシ間クラスタでは、ディレクタ/バックアップとオーナーフローの両方が同じシャーシのユニットによって所有されている場合、他方のシャーシ内のユニットがセカンダリバックアップ/ディレクタになります。このロールは、1台以上のブレードを搭載したFirepower 9300シリーズのシャーシ間クラスタに固有です。	w

詳細については、『構成ガイド』の関連セクション（『関連情報』のリンクを参照）を参照してください
特定のシナリオ（ケーススタディのセクションを参照）では、一部のフラグが表示されない場合があります

クラスタ接続確立のケーススタディ

次のセクションでは、クラスタを介して接続を確立する方法の一部を示すさまざまなケーススタディについて説明します。目標は次のとおりです。

さまざまなユニットの役割について理解する
さまざまなコマンド出力を関連付ける方法を示す

トポロジ

クラスタユニットとID:

ユニット1-1

ユニット2-1

ユニット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 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

注：これらのテストは、クラスタを通過するトラフィックが最小限のラボ環境で実行されました。実稼働環境では、キャプチャの「ノイズ」を最小限に抑えるために、特定のキャプチャフィルタ（宛先ポートや送信元ポートなど）をできるだけ使用します。

ケーススタディ1.対称トラフィック（オーナーもディレクタ）

観測1.再隠蔽キャプチャは、ユニット–1-1でのみパケットを表示します。これは、両方向のフローがユニット–1-1（対称トラフィック）を通過したことを意味します。

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

観測2.送信元ポート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

ユニット	フラグ	注
ユニット1-1	UIO	・ Flow Owner：ユニットがフローを処理します・ Director - unit-3-1には「y」があり、「Y」ではないため、このフローのディレクタとしてユニット–1-1が選択されたことを意味します。したがって、これは所有者でもあるので、別のユニット（この場合はユニット3-1）がバックアップオーナーとして選出されました
ユニット2-1	-	-
ユニット3-1	y	ユニットはバックアップ所有者です

それを図で示します。

TCP SYNパケットがホストAからユニット1-1に到着します。ユニット1-1がフローオーナーになります
ユニット1-1もフローディレクタとして選出されます。したがって、バックアップオーナーとしてユニット3-1も選択されます(クラスタのアドメッセージ)
TCP SYN/ACKパケットがホストBからユニット3-1に到着します。フローは対称です
接続が終了すると、所有者はバックアップ所有者からフロー情報を削除するクラスタ削除メッセージを送信します

観測3.トレースによるキャプチャは、両方向がユニット–1-1のみを通過することを示します

ステップ1：送信元ポートに基づいて、すべてのクラスタユニットで対象となるフローとパケットを特定します。

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

ステップ2：これはTCPフローであるため、3ウェイハンドシェイクパケットをトレースします。この出力からわかるように、unit-1-1が所有者です。わかりやすくするために、関連性のないトレースフェーズは省略されています。

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

リターントラフィック(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

観察4. FTDデータプレーンのsyslogには、すべてのユニットでの接続の作成と終了が表示されます。

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

ケーススタディ2.対称トラフィック（ディレクタとは異なるオーナー）

ケーススタディ#1と同じですが、このケーススタディでは、フローオーナーはディレクタとは異なるユニットです。
すべての出力はケーススタディ#1に似ています。ケーススタディ#1と主に異なるのは、シナリオ1の「y」フラグを置き換える「Y」フラグです。

観察1.オーナーとディレクターが違う

送信元ポート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

ユニット	フラグ	注
ユニット1-1	UIO	・ Flow Owner：ユニットがフローを処理します
ユニット2-1	-	-
ユニット3-1	Y	・ DirectorとBackup owner - Unit 3-1にはフラグY(Director)があります。

それを図で示します。

TCP SYNパケットがホストAからユニット1-1に到着します。ユニット1-1がフローオーナーになります
ユニット3-1はフローディレクタとして選出されます。Unit-3-1はバックアップ所有者でもあります（CCL上のUDP 4193で「cluster add」メッセージ）
TCP SYN/ACKパケットがホストBからユニット3-1に到着します。フローは対称です
接続が終了すると、オーナーはCCLを介してUDP 4193で「cluster delete」メッセージを送信し、フロー情報をバックアップのオーナーから削除します

観測2.トレースによるキャプチャは、両方向がユニット–1-1のみを通過することを示します

ステップ1：ケーススタディ1と同じアプローチを使用して、送信元ポートに基づいてすべてのクラスタユニットで対象となるフローとパケットを特定します。

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#

OUTSIDEインターフェイスでのキャプチャ：


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#

ステップ2：入力パケット（TCP SYNおよび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

ユニット1-1のSYN/ACKをトレースします。

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

観察3. FTDデータプレーンのsyslogには、オーナーとバックアップオーナーの接続の作成と終了が表示されます。

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

ケーススタディ3：非対称トラフィック（ディレクタがトラフィックを転送）

観察1.再提示の捕捉は、ユニット1-1とユニット2-1（非対称フロー）のパケットを示します。

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

観測2.送信元ポート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

ユニット	フラグ	注
ユニット1-1	UIO	・ Flow Owner：ユニットがフローを処理します
ユニット2-1	Y	・ Director：ユニット2-1にはフラグ「Y」があるため、このフローのディレクタとしてユニット2-1が選択されたことを意味します。・バックアップ所有者・最後に、この出力からは明らかではありませんが、show captureおよびshow logの出力からは、このフローをオーナーに転送していることがわかります（技術的には、このシナリオではフォワーダとはみなされていませんが）注：ユニットはダイレクタ（Yフロー）とフォワーダ（zフロー）の両方を使用することはできません。これら2つのロールは相互に排他的です。ダイレクタ（Yフロー）は引き続きトラフィックを転送できます。このケーススタディの後の方で、show logの出力を参照してください。
ユニット3-1	-	-

それを図で示します。

TCP SYNパケットがホストAからユニット1-1に到着します。ユニット1-1がフローオーナーになります
ユニット2-1は、フローディレクタとバックアップオーナーに選出されます。フロー所有者はUDP 4193で「cluster add」ユニキャストメッセージを送信し、フローについてバックアップ所有者に通知します
ホストBからユニット2-1にTCP SYN/ACKパケットが到着します。フローは非対称です
ユニット2-1は、CCLを介してパケットを所有者に転送します（TCP SYN Cookieが原因）。
オーナーはインターフェイスOUTSIDEにパケットを再注入し、ホストAにパケットを転送します
接続が終了すると、所有者はバックアップ所有者からフロー情報を削除するクラスタ削除メッセージを送信します

観測3.トレースによるキャプチャは、ユニット2-1からユニット1-1への非対称トラフィックとリダイレクションを示しています

ステップ1：対象のフロー（ポート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:*************************************************************

戻り方向：

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

ステップ2：パケットをトレースします。デフォルトでは、最初の50個の入力パケットだけがトレースされることに注意してください。わかりやすくするために、関連性のないトレースフェーズは省略されています。

ユニット1-1（所有者）:

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

ユニット2-1（フォワーダ）

リターントラフィック(TCP SYN/ACK)。対象ユニットはユニット2-1で、これはディレクタ/バックアップオーナーであり、トラフィックをオーナーに転送します。

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

観察4. FTDデータプレーンのsyslogには、すべてのユニットでの接続の作成と終了が表示されます。

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#

ケーススタディ4.非対称トラフィック（オーナーがディレクタ）

観察1.再提示の捕捉は、ユニット1-1とユニット2-1（非対称フロー）のパケットを示します。

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

観測2.送信元ポート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

ユニット	フラグ	注
ユニット1-1	UIO	・ Flow Owner：ユニットがフローを処理します・ Director - unit-3-1には「y」があり、「Y」ではないため、このフローのディレクタとしてユニット–1-1が選択されたことを意味します。したがって、これは所有者でもあるので、別のユニット（この場合はユニット3-1）がバックアップオーナーとして選出されました
ユニット2-1	z	・フォワーダー
ユニット3-1	y	– バックアップ所有者

それを図で示します。

TCP SYNパケットがホストAからユニット1-1に到着します。ユニット1-1がフローオーナーになり、ディレクタとして選出されます
ユニット3-1はバックアップオーナーとして選出されます。フロー所有者がUDP 4193でcluster add unicastメッセージを送信し、フローについてバックアップ所有者に通知します
ホストBからユニット2-1にTCP SYN/ACKパケットが到着します。フローは非対称です
ユニット2-1は、CCLを介してパケットを所有者に転送します（TCP SYN Cookieが原因）。
オーナーはインターフェイスOUTSIDEにパケットを再注入し、ホストAにパケットを転送します
接続が終了すると、所有者はバックアップ所有者からフロー情報を削除するクラスタ削除メッセージを送信します

観測3.トレースによるキャプチャは、ユニット2-1からユニット1-1への非対称トラフィックとリダイレクションを示しています

ユニット2-1（フォワーダ）

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

観察4. FTDデータプレーンのsyslogには、すべてのユニットでの接続の作成と終了が表示されます。

ユニット1-1（所有者）
ユニット2-1（フォワーダ）
ユニット3-1（バックアップオーナー）

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

ケーススタディ5.非対称トラフィック（所有者がディレクタと異なる）

観察1.再提示の捕捉は、ユニット1-1とユニット2-1（非対称フロー）のパケットを示します。

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

観測2.送信元ポート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

ユニット	フラグ	注
ユニット1-1	UIO	・ Flow Owner：ユニットがフローを処理します
ユニット2-1	z	・フォワーダー
ユニット3-1	Y	・バックアップ所有者 ·Director

それを図で示します。

TCP SYNパケットがホストAからユニット1-1に到着します。ユニット1-1がフローオーナーになります
ユニット3-1は、ディレクタおよびバックアップオーナーとして選出されます。フロー所有者はUDP 4193で「cluster add」ユニキャストメッセージを送信し、フローについてバックアップ所有者に通知します
ホストBからユニット2-1にTCP SYN/ACKパケットが到着します。フローは非対称です
ユニット2-1は、CCLを介してパケットを所有者に転送します（TCP SYN Cookieが原因）。
オーナーはインターフェイスOUTSIDEにパケットを再注入し、ホストAにパケットを転送します
接続が終了すると、所有者はバックアップ所有者からフロー情報を削除するクラスタ削除メッセージを送信します

観測3.トレースによるキャプチャは、ユニット2-1からユニット1-1への非対称トラフィックとリダイレクションを示しています

ユニット1-1（所有者）

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

ユニット2-1（フォワーダ）

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

観察4. FTDデータプレーンのsyslogには、すべてのユニットでの接続の作成と終了が表示されます。

ユニット1-1（所有者）
ユニット2-1（フォワーダ）
ユニット3-1（バックアップ・オーナー/ダイレクタ）

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

次のケーススタディでは、使用されるトポロジはインラインセットを持つクラスタに基づいています。

ケーススタディ6：非対称トラフィック（インラインセット、オーナーがディレクタ）

観察1.再提示の捕捉は、ユニット1-1とユニット2-1（非対称フロー）のパケットを示します。さらに、オーナーはユニット2-1です（reinject-hideキャプチャのパケットは内部インターフェイスと外部インターフェイスの両方に存在し、ユニット1-1は外部インターフェイスにのみ存在します）。

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

観測2.送信元ポート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

ユニット	フラグ	注
ユニット1-1	z	・フォワーダー
ユニット2-1	b N	・ Flow Owner：ユニットがフローを処理します
ユニット3-1	y	・バックアップ所有者

それを図で示します。

TCP SYNパケットがホストAからユニット2-1に到着します。ユニット2-1がフローオーナーになり、ディレクタとして選出されます
ユニット3-1はバックアップの所有者として選出されます。フロー所有者はUDP 4193で「cluster add」ユニキャストメッセージを送信し、フローについてバックアップ所有者に通知します
ホストBからユニット1-1にTCP SYN/ACKパケットが到着します。フローは非対称です
ユニット1-1は、CCLを介してパケットをダイレクタ（ユニット2-1）に転送します
ユニット2-1も所有者であり、インターフェイスOUTSIDEにパケットを再注入します
ユニット2-1はパケットをホストAに転送します
接続が終了すると、所有者はバックアップ所有者からフロー情報を削除するクラスタ削除メッセージを送信します

観測3.トレースによるキャプチャは、ユニット1-1からユニット2-1への非対称トラフィックとリダイレクションを示しています

ユニット2-1（オーナー/ディレクタ）

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

ユニット1-1（フォワーダ）

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

リターントラフィック(TCP SYN/ACK)

ユニット2-1（オーナー/ディレクタ）

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

観察4. FTDデータプレーンのsyslogには、すべてのユニットでの接続の作成と終了が表示されます。

ユニット1-1（所有者）
ユニット2-1（フォワーダ）
ユニット3-1（バックアップ・オーナー/ダイレクタ）

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

ケーススタディ7：非対称トラフィック（インラインセット、オーナーがディレクタと異なる）

オーナーはユニット2-1（reinject-hideキャプチャのパケットは内部インターフェイスと外部インターフェイスの両方に存在し、ユニット3-1は外部インターフェイスにのみ存在します）。

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

観測2.送信元ポート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

ユニット	フラグ	注
ユニット1-1	Y	・ディレクタ/バックアップ・オーナー
ユニット2-1	b N	・ Flow Owner：ユニットがフローを処理します
ユニット3-1	z	・フォワーダー

それを図で示します。

ホストAからユニット2-1にTCP SYNパケットが到着します。ユニット2-1がフローオーナーになり、ユニット1-1がディレクタとして選出されます
ユニット1-1は、バックアップの所有者として選出されます（これはディレクタであるため）。フロー所有者はUDP 4193で「cluster add」ユニキャストメッセージを送信し、フローについてバックアップ所有者に通知します
ホストBからユニット3-1にTCP SYN/ACKパケットが到着します。フローは非対称です
ユニット3-1は、CCLを介してパケットをダイレクタ（ユニット1-1）に転送します
ユニット1-1（ディレクタ）は、所有者がユニット2-1であることを認識し、パケットをフォワーダ（ユニット3-1）に返信し、所有者がユニット2-1であることを通知します
ユニット3-1は、ユニット2-1（所有者）にパケットを送信します
ユニット2-1は、インターフェイスOUTSIDEにパケットを再注入します
ユニット2-1はパケットをホストAに転送します
接続が終了すると、所有者はバックアップ所有者からフロー情報を削除するクラスタ削除メッセージを送信します

注：ステップ2（CCLを通過するパケット）は、ステップ4（データトラフィック）の前に行うことが重要です。別のケース（競合状態など）では、ディレクタはフローを認識しません。したがって、インラインセットであるため、パケットを宛先に転送します。インターフェイスがインラインセットにない場合、データパケットはドロップされます。

観察3：トレースによるキャプチャは、非対称トラフィックとCCL上の交換を示します。

転送トラフィック(TCP SYN)

ユニット2-1（所有者）

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

リターントラフィック(TCP SYN/ACK)

ユニット3-1（ID 2 – フォワーダ）は、CCLを介してユニット1-1（ID 0 – ディレクタ）にパケットを送信します

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

ユニット1-1（ディレクタ）：ユニット1-1(ID 0)は、フローの所有者がユニット2-1(ID 1)であることを認識し、CCL経由でユニット3-1（ID 2 – フォワーダ）にパケットを送信します

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

ユニット3-1（ID 2 – フォワーダ）は、CCLを通じてパケットを取得し、ユニット2-1（ID 1 – オーナー）に送信します

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

所有者はパケットを再送し、宛先に転送します。

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

観察4. FTDデータプレーンのsyslogには、すべてのユニットでの接続の作成と終了が表示されます。

ユニット1-1（ダイレクタ/バックアップ・オーナー）
ユニット2-1（所有者）
ユニット3-1（フォワーダ）

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

トラブルシュート

クラスタのトラブルシューティングの概要

クラスタの問題は次のように分類できます。

コントロールプレーンの問題（クラスタの安定性に関する問題）
データプレーンの問題（中継トラフィックに関連する問題）

クラスタデータプレーンの問題

NAT/PATの一般的な問題

設定に関する重要な考慮事項

Port Address Translation（PAT；ポートアドレス変換）プールには、クラスタ内のユニットの数と同じ数のIPが少なくとも必要です。できれば、クラスタノードよりも多くのIPが必要です。
デフォルトのxlate per-sessionコマンドは、無効にする特定の理由がない限り、そのまま使用する必要があります。xlate per-sessionが無効になっている接続に対して構築されたPAT xlateは、常にクラスタ内の制御ノードユニットによって処理され、パフォーマンスが低下する可能性があります。

クラスタIPの不均衡を引き起こす低ポートからのトラフィックによる高PATプール範囲の使用

FTDはPAT IPを「範囲」に分割し、同じソース範囲でxlateを維持しようとします。次の表に、送信元ポートが同じソース範囲内のグローバルポートにどのように変換されるかを示します。

元の送信元ポート	変換された送信元ポート
1-511	1-511
512-1023	512-1023
1024-65535	1024-65535

送信元ポート範囲がいっぱいになり、その範囲から新しいPAT xlateを割り当てる必要がある場合、FTDは次のIPに移動して、その送信元ポート範囲に新しい変換を割り当てます。

症状

クラスタを通過するNAT変換トラフィックの接続問題

確認

# show nat pool

FTDデータプレーンログにPATプールの枯渇が示されます。

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

緩和策

NATフラットポート範囲とポート予約を設定します。

さらに、6.7/9.15.1以降では、ノードがPATの対象となる膨大なバックグラウンドトラフィックを持つクラスタを出入りする場合にのみ、不均衡なポートブロック分散が発生します。ポートのブロックが解放されてノード間で再配布される場合は、ポート自体で回復する唯一の方法です。

ポートブロックベースの配布では、ノードにpb-1、pb-2 ... pb-10などの10個のポートブロックが割り当てられると、ノードは常に最初の使用可能なポートブロックから開始し、枯渇するまでランダムポートを割り当てます。割り当ては、そのポイントまでの全ポートブロックが枯渇した場合にのみ、次のポートブロックに移動します。

たとえば、ホストが512の接続を確立すると、ユニットはマッピングされたポートをすべての512接続に対してpb-1からランダムに割り当てます。これで、これらの512接続がすべてアクティブになった状態で、pb-1が使い果たされてホストが513番目の接続を確立すると、pb-2に移動し、そこからランダムなポートを割り当てます。この時点で、ホストが514番目の接続を確立すると、pb-1に空きポート（10番目の接続削除の一部としてリリースされたポート）があるため、クラスタユニットはpb-1からマッピングされたポートを割り当てます。

注意すべき重要な点は、割り当てが空きポートを持つ最初の使用可能なポートブロックから行われるため、最後のポートブロックは常に正常にロードされたシステムでの再配布に使用できます。また、PATは通常、短寿命接続に使用されます。短時間でポートブロックが使用可能になる確率は非常に高くなります。したがって、プール分散のバランスを取るために必要な時間は、ポートブロックベースのプール分散によって改善できます。

ただし、pb-1からpb-10までのすべてのポートブロックが枯渇した場合、または各ポートブロックが長寿命接続用のポートを保持している場合、ポートブロックは迅速に解放されて再配送されることはありません。このような場合、最も中断の少ないアプローチは次のとおりです。

過剰なポートブロックがあるノードを特定します(show nat pool cluster summary)。
そのノードで最も使用されていないポートブロックを特定します(show nat pool ip <addr> detail)。
このようなポートブロックのxlateをクリアします(clear xlate global <addr> gport 'start-end')。

警告：これにより、関連する接続が中断されます。

別の宛先へのリダイレクトが発生すると、デュアルチャネルWebサイト（Webメール、バンキングなど）、またはSSO Webサイトを参照できない

症状

デュアルチャネルWebサイト（Webメール、銀行Webサイトなど）を参照できません。ユーザが第2ソケット/接続を開くことを要求するWebサイトに接続し、第2接続がハッシュされた第1接続とは異なるクラスタメンバーにハッシュされ、トラフィックがIP PATプールを使用すると、別のパブリックIPアドレスから接続を受けてリセットする。

確認

データプレーンクラスタキャプチャを取得して、影響を受けるトランジットフローの処理方法を確認します。この場合、TCPリセットは宛先Webサイトから行われます。

緩和策(6.7/9.15.1以前)

マルチセッションアプリケーションで複数のマッピングされたIPアドレスが使用されているかどうかを確認します。
show nat pool cluster summaryコマンドを使用して、プールが均等に分散されているかどうかを確認します。
cluster exec show connコマンドを使用して、トラフィックが正しくロードバランスされているかどうかを確認します。
show nat pool cluster ip <address> detailコマンドを使用してスティッキIPのプール使用率を確認します。
syslog 305021(6.7/9.15)を有効にして、スティッキIPを使用できなかった接続を確認します。
PATプールへのIPの追加や、接続されたスイッチのロードバランスアルゴリズムの微調整を行うために必要です。

イーサチャネルのロードバランシングアルゴリズムについて：

FP9300以外の場合、および1台のサーバで認証が発生した場合：隣接するスイッチのイーサチャネルロードバランシングアルゴリズムを、送信元IP/ポートと宛先IP/ポートから送信元IPと宛先IPに調整します。
FP9300以外の場合、および認証が複数のサーバ経由で発生する場合：隣接するスイッチのイーサチャネルロードバランシングアルゴリズムを、送信元IP/ポートと宛先IP/ポートから送信元IPに調整します。
FP9300の場合：FP9300シャーシでは、ロードバランシングアルゴリズムはsource-dest-port source-dest-ip source-dest-macとして固定されており、変更できません。この場合の回避策は、FlexConfigを使用してxlate per-session denyコマンドをFTD設定に追加し、特定の宛先IPアドレス（問題のある/互換性のないアプリケーション）のトラフィックをシャーシ内クラスタの制御ノードだけで処理するようにします。この回避策には、次の副作用があります。
- 変換が異なるトラフィックのロードバランシングは行われない（すべてが制御ノードに送信される）。
- xlateスロットが枯渇する可能性があります（コントロールノード上の他のトラフィックのNAT変換に悪影響を与えます）。
- シャーシ内クラスタの拡張性の低下

プール内の十分なPAT IPがないため、すべてのトラフィックが制御ノードに送信されるため、クラスタパフォーマンスが低下する

症状

クラスタ内に十分なPAT IPがないため、空きIPをデータノードに割り当てることができません。したがって、PAT設定の対象となるすべてのトラフィックは、処理のために制御ノードに転送されます。

確認

show nat pool clusterコマンドを使用して、各ユニットの割り当てを確認し、すべてのユニットがプール内の少なくとも1つのIPを所有していることを確認します。

緩和策

6.7/9.15.1より前のバージョンでは、クラスタ内のノード数と少なくとも同じサイズのPATプールがあることを確認します。PATプールを使用する6.7/9.15.1以降では、すべてのPATプールIPからポートブロックを割り当てます。PATプールの使用率が実際に高く、プールが頻繁に枯渇する場合は、PATプールサイズを大きくする必要があります（FAQセクションを参照）

xlateがセッション単位で有効になっていないため、制御ノードに送信されるすべてのトラフィックによるパフォーマンスが低下する

症状

多くの高速UDPバックアップフローがクラスタ制御ノードを介して処理されるため、パフォーマンスに影響する可能性があります。

背景

セッションごとに有効になっているxlateを使用する接続だけが、PATを使用するデータノードによって処理できます。show run all xlateコマンドを使用して、xlate per-session config

セッション単位で有効にすると、関連付けられた接続が切断されるとすぐにxlateが解除されます。これにより、接続がPATを受けている場合の1秒あたりの接続性能が向上します。セッションごとの非xlatesは、関連する接続が切断されてから30秒間継続し、接続レートが十分に高い場合は、各グローバルIPで使用可能な65k TCP/UDPポートが短時間で使用される可能性があります。

デフォルトでは、すべてのTCPトラフィックはxlateごとに有効になっており、UDP DNSトラフィックのみがセッションごとに有効になっています。これは、すべての非DNS UDPトラフィックが処理のために制御ノードに転送されることを意味します。

確認

次のコマンドを使用して、クラスタユニット間の接続とパケットの分散を確認します。

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

cluster exec show connコマンドを使用して、どのクラスターノードがUDP接続を所有しているかを確認します。

firepower# cluster exec show conn

このコマンドを使用して、クラスタノード間のプール使用率を理解します。

firepower# cluster exec show nat pool ip 
     
     
       | in UDP

緩和策

対象のトラフィック(UDPなど)に対してセッションごとのPAT（per-session permit udpコマンド）を設定します。 ICMPでは、デフォルトのマルチセッションPATから変更できないため、PATが設定されている場合、IMCPトラフィックは常に制御ノードによって処理されます。

ノードがクラスタに出入りすると、PATプールの分散が不均衡になります。

症状

クラスタを出入りするユニットによって、PAT IP割り当てが時間の経過とともに不均衡になる可能性があるため、接続の問題が発生します。
ポスト6.7/9.15.1では、新しく参加したノードが十分なポートブロックを取得できない場合があります。ポートブロックがないノードは、トラフィックを制御ノードにリダイレクトします。少なくとも1つのポートブロックを持つノードがトラフィックを処理し、プールが使い果たされるとドロップを開始します。

確認

データプレーンsyslogには、次のようなメッセージが表示されます。

%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

show nat pool cluster summaryコマンドを使用して、プールの分散を特定します。
cluster exec show nat pool ip <addr> detailコマンドを使用して、クラスタノード間でのプールの使用状況を確認します。

緩和策

6.7/9.15.1より前のバージョンの場合は、https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvd10530で回避策を説明します
post-6.7/9.15.1では、clear xlate global <ip> gport <start-end>コマンドを使用して、必要なノードへの再配布のために他のノードのポートブロックの一部を手動でクリアします。

症状

クラスタによってPATされるトラフィックの主な接続問題。これは、FTDデータプレーンが、設計ごとに、グローバルNATアドレスのGARPを送信しないためです。

確認

直接接続されたデバイスのARPテーブルには、制御ノードの変更後にクラスタデータインターフェイスの異なるMACアドレスが表示されます。

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

緩和策

クラスタのデータインターフェイスにスタティック（仮想）MACを設定します。

PATを受けた接続が失敗する

症状

クラスタによってPATされるトラフィックの接続の問題。

検証/緩和

設定が正しく複製されていることを確認します。
プールが均等に分散されていることを確認します。
プールの所有権が有効であることを確認します。
show asp clusterカウンタでエラーカウンタは増加しません。
適切な情報を使用してダイレクタ/フォワーダ・フローが作成されていることを確認します。
バックアップxlateが正常に作成、更新、クリーンアップされているかどうかを確認します。
xlateが作成され、「セッション単位」の動作に従って終了されているかどうかを検証します。
エラーを表示するには、「debug nat 2」を有効にします。この出力は非常にノイズが多い場合があります。たとえば、

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

デバッグを停止するには：

firepower# un all

接続およびNAT関連のsyslogを有効にして、情報を失敗した接続に関連付けます。

ASAおよびFTDクラスタリングPATの改善（9.15以降および6.7）

何が変更されたのですか。

PATの動作が再設計されました。個々のIPが各クラスタメンバーに分散されることはありません。代わりに、PAT IPはポートブロックに分割され、IPスティッキネス操作と組み合わせて、これらのポートブロックを可能な限りクラスタメンバ間で均等に（可能な限り）分散します。

新しい設計では、次の制限に対処します（前の項を参照）。

マルチセッションアプリケーションは、クラスタ全体のIPスティッキ性の欠如により影響を受けます。
クラスタ内のノードの数と少なくとも同じサイズのPATプールが必要です。
ノードがクラスタに出入りすると、PATプールの分散が不均衡になります。
PATプールの不均衡を示すsyslogはありません。

技術的には、デフォルトの1-511、512-1023、および1024-65535ポート範囲の代わりに、PATのデフォルトのポート範囲として1024-65535があります。通常のPATでは、このデフォルト範囲を1 ～ 1023の特権ポート範囲に拡張できます（「include-reserve」オプション）。

FTD 6.7でのPATプールの設定例を次に示します。詳細については、『Configuration Guide:

PATに関するその他のトラブルシューティング情報

FTDデータプレーンsyslog(6.7/9.15.1以降)

スティッキ性無効化syslogは、クラスタノード上のスティッキIPですべてのポートが使い果たされ、割り当てが空きポートを持つ次に使用可能なIPに移動すると生成されます。たとえば、

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

プールの不均衡syslogは、クラスタに参加したときにノードで生成され、ポートブロックのシェアまたは不等のシェアを取得しません(例：

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

Show コマンド

プール配布ステータス

show nat pool cluster summaryの出力では、各PAT IPアドレスについて、バランスのとれた分散シナリオにおいて、ノード間で1つ以上のポートブロックの差があってはなりません。平衡型および不平衡型ポートブロックの配布の例。

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)

不均衡な分布：

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)

プール所有権の状態

show nat pool clusterの出力には、ownerまたはbackupを「UNKNOWN」とする単一のポートブロックを指定しないでください。ある場合は、プール所有通信に問題があることを示します。例：

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>

ポートブロック内のポート割り当てのアカウンティング

show nat poolコマンドは、詳細な情報とフィルタされた出力を表示する追加オプションで拡張されました。例：

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 *

注：'*'は、バックアップポートブロックであることを示します

この問題を解決するには、clear xlate global <ip> gport <start-end>コマンドを使用して、必要なノードへの再配布のために、他のノードのポートブロックの一部を手動でクリアします。

手動でトリガーされたポートブロックの再配布

トラフィックが一定の実稼働ネットワークでは、ノードが（おそらくトレースバックが原因で）クラスタを離れて再接続すると、プールの均等な共有を得られない場合や、最悪の場合はポートブロックを取得できない場合があります。
show nat pool cluster summaryコマンドを使用して、どのノードが必要以上のポートブロックを所有しているかを特定します。
より多くのポートブロックを所有しているノードでは、show nat pool ip <addr> detailコマンドを使用して、割り当て数が最も少ないポートブロックを特定します。
clear xlate global <address> gport <start-end>コマンドを使用して、これらのポートブロックから作成された変換をクリアし、必要なノード(たとえば、

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

ポスト6.7/9.15.1 PATに関するFAQ

Q.クラスタ内の使用可能なユニットの数に使用可能なIPの数がある場合、オプションとしてユニットごとに1つのIPを使用できます

A. IPアドレスベースとポートブロックベースのプール分散方式を切り替えるトグルがなくなりました。

IPアドレスベースのプール分散の古い方式では、マルチセッションアプリケーションの障害が発生しました。ホストからの複数の接続（単一のアプリケーショントランザクションの一部）がクラスタの異なるノードにロードバランシングされ、異なるエンティティから送信されます。

また、新しいポートブロックベースの分散方式では、1つのPAT IPアドレスで作業できるようになったとしても、PATの実行に必要な接続数に基づいて十分なPAT IPアドレスを設定することが常に推奨されます。

Q.クラスタのPATプールのIPアドレスのプールを保持できますか。

A.はい、できます。すべてのPATプールIPからのポートブロックは、クラスタノード間で分散されます。

Q. PATプールに多数のIPアドレスを使用する場合、各IPアドレスごとに各メンバに割り当てられるポートの同じブロックが割り当てられますか。

A.いいえ。各IPは個別に分散されます。

Q.すべてのクラスタノードには、すべてのパブリックIPがありますが、ポートのサブセットだけがありますか。この場合、送信元IPが同じパブリックIPを使用するたびに保証されますか。

A.正解です。各PAT IPは、各ノードによって部分的に所有されます。選択したパブリックIPがノード上で枯渇すると、スティッキIPを保持できないことを示すsyslogが生成され、割り当ては次に使用可能なパブリックIPに移動します。スタンドアロン、HA、またはクラスタ環境の場合、IPスティッキ性は常にベストエフォート方式でプールの可用性に依存します。

Q. PATプール内の単一のIPアドレスに基づくものはすべて存在しますが、PATプール内で複数のIPアドレスを使用する場合は適用されません。

A. PATプール内の複数のIPアドレスにも適用されます。PATプール内のすべてのIPからのポートブロックは、クラスタノード間で分散されます。PATプール内のすべてのIPアドレスは、クラスタ内のすべてのメンバに分割されます。したがって、PATプールにアドレスのクラスCがある場合、すべてのクラスタメンバーには、すべてのPATプールアドレスからのポートプールがあります。

Q. CGNATで動作しますか。

A.はい、CGNATもサポートされています。CGNAT、「ブロック割り当て」とも呼ばれるPATのデフォルトのブロックサイズは「512」で、xlateのブロック割り当てサイズCLIで変更できます。通常のダイナミックPAT（非CGNAT）の場合、ブロックサイズは常に「512」であり、固定で設定は不可能です。

Q.ユニットがクラスタから離れる場合、制御ノードは他のユニットにポートブロック範囲を割り当てるか、それ自体に保持するか。

A.各ポートブロックには所有者とバックアップがあります。xlateは、ポートブロックから作成されるたびに、ポートブロックのバックアップノードにも複製されます。ノードがクラスタを離れると、バックアップノードはすべてのポートブロックと現在のすべての接続を所有します。バックアップノードは、これらの追加ポートブロックの所有者になったため、新しいバックアップを選択し、現在のすべてのxlateをそのノードに複製して障害シナリオを処理します。

Q.このアラートに基づいて、スティッキ性を強化するために実行できるアクションは何ですか。

A.スティッキ性を保持できない理由として、2つの理由が考えられます。

理由1:特定のスティッキIP枯渇につながる他のノードよりも多くの接続が検出されるため、トラフィックのロードバランスが誤っています。これは、トラフィックがクラスタノード間で均等に分散されている場合に対処できます。たとえば、FPR41xxクラスタでは、接続されたスイッチのロードバランシングアルゴリズムを調整します。FPR9300クラスタでは、シャーシ全体でブレードの数が同じであることを確認します。

理由2:PATプールの使用率が非常に高いため、プールが頻繁に枯渇します。これを解決するには、PATプールサイズを大きくします。

Q. extendedキーワードのサポートはどのように処理されるのですか。エラーが表示され、アップグレード中にNATコマンド全体が追加されないか、拡張キーワードが削除されて警告が表示されるか。

A. ASA 9.15.1/FP 6.7以降のクラスタでは、PATの「拡張」オプションはサポートされていません。設定オプションは、CLI/ASDM/CSM/FMCからは削除されません。設定すると（直接または間接的にアップグレードを通じて）、警告メッセージが通知され、設定が受け入れられますが、PATの拡張機能が動作していません。

Q.同時接続と同じ数の変換ですか。

A. 6.7/9.15.1より前では、1 ～ 65535でしたが、1 ～ 1024の範囲では送信元ポートが多く使用されないため、1024 ～ 65535（64512の接続）になります。「flat」をデフォルト動作とする6.7/9.15.1以降の実装では、1024-65535ですが、1-1024を使用する場合は、"include-reserve"オプションを使用できます。

Q.ノードがクラスタに戻ると、古いバックアップノードが「バックアップ」になり、バックアップノードが古いポートブロックを提供しますか。

A.その時点でのポートブロックの可用性によって異なります。ノードがクラスタを離れると、そのノードのすべてのポートブロックがバックアップノードに移動します。次に、フリーポートブロックを蓄積し、必要なノードに分配する制御ノードです。

Q.制御ノードの状態に変化がある場合、選択された新しい制御ノード、PATブロック割り当ては維持されますか。それとも、新しい制御ノードに基づいてポートブロックが再割り当てされますか。

A.新しい制御ノードは、どのブロックが割り当てられ、どのブロックが解放され、そこから始まるのかを理解しています。

Q.xlateの最大数は、この新しい動作の同時接続数の最大数と同じですか。

A.はい。xlateの最大数は、PATポートのアベイラビリティによって異なります。同時接続の最大数とは関係ありません。1つのアドレスだけを許可すると、65535の接続が可能になります。さらに多くのIPアドレスを割り当てる必要があります。十分なアドレス/ポートがある場合は、最大同時接続数に到達できます。

Q.新しいクラスタメンバーを追加するときのポートブロック割り当てのプロセスは何ですか。再起動によってクラスタメンバーが追加された場合はどうなりますか。

A.ポートブロックは常に制御ノードによって分散されます。ポートブロックが新しいノードに割り当てられるのは、ポートブロックが空いている場合だけです。「空きポートブロック」とは、ポートブロック内のマッピングされたポートを介して接続が提供されないことを意味します。

さらに、再結合時に、各ノードが所有できるブロック数を再計算します。あるノードが想定より多くのブロックを保持している場合、その追加のポートブロックを制御ノードに解放し、使用可能になった時点で解放します。次に、制御ノードは、新たに加入したデータノードに割り当てる。

Q. TCPおよびUDPプロトコルまたはSCTPのみがサポートされていますか。

A. SCTPはダイナミックPATではサポートされませんでした。SCTPトラフィックの場合、スタティックネットワークオブジェクトNATのみを使用することを推奨します。

Q.あるノードでブロックポートが使い果たされると、パケットはドロップされ、次に使用可能なIPブロックは使用されないのですか。

A.いいえ、すぐに落ちることはありません。次のPAT IPから利用可能なポートブロックを使用するすべてのPAT IPを通過するすべてのポートブロックが枯渇すると、トラフィックがドロップされます。

Q.クラスタのアップグレードウィンドウで制御ノードの過負荷を回避するには、制御ノードですべての接続が処理されるまで待たずに、新しい制御を手動で（4ユニットのクラスタのアップグレードの途中で）選択する方が良いですか。

A.コントロールは最後に更新する必要があります。これは、制御ノードが新しいバージョンを実行する場合、すべてのノードが新しいバージョンを実行しない限り、プールの配布は開始されないためです。また、アップグレードを実行すると、新しいバージョンのすべてのデータノードが古いバージョンを実行している場合、制御ノードからのプール配布メッセージを無視します。

これを詳細に説明するには、Aを制御する4つのノードA、B、C、およびDを持つクラスタ導入を検討します。次に、ヒットレスアップグレードの一般的な手順を示します。

各ノードに新しいバージョンをダウンロードします。
ユニット「D」をリロードします。すべての接続、xlateはバックアップノードに移動されます。
ユニット「D」が起動し、次の操作を行います。

a.PAT設定を処理します。

b.各PAT IPをポートブロックに分割する

c.すべてのポートブロックが未割り当て状態になっている

d.制御から受信した古いバージョンのクラスタPATメッセージを無視

e.すべてのPAT接続をマスターにリダイレクトします

4.同様に、新しいバージョンで他のノードを起動します。

5.ユニット「A」コントロールをリロードします。制御のためのバックアップがないため、既存のすべての接続がドロップされます

6.新しいコントロールは、新しい形式でポートブロックの配布を開始します

7.ユニット「A」が再び参加し、ポートブロックの配信メッセージを受け入れて処理できる

フラグメント処理

症状

1つの特定のサイト（サイトローカルトラフィック）で処理する必要があるフラグメント化されたパケットは、サイト間クラスタ展開では、他のサイトのユニットに送信できます。これは、これらのサイトの1つがフラグメント所有者を持つためです。

クラスタロジックでは、フラグメント化されたパケットを使用する接続に対して追加の役割が定義されています。フラグメント所有者。

フラグメント化されたパケットの場合、フラグメントを受信するクラスタユニットは、フラグメントの送信元IPアドレス、宛先IPアドレス、およびパケットIDのハッシュに基づいてフラグメントの所有者を決定します。その後、すべてのフラグメントは、クラスタ制御リンクを介してフラグメント所有者に転送されます。最初のフラグメントにのみスイッチのロードバランスハッシュで使用される5タプルが含まれるため、フラグメントは異なるクラスタユニットにロードバランシングできます。その他のフラグメントには送信元ポートと宛先ポートが含まれず、他のクラスタユニットにロードバランシングできます。フラグメント所有者は、送信元/宛先IPアドレスとポートのハッシュに基づいてダイレクタを決定できるように、パケットを一時的に再構成します。新しい接続の場合、フラグメント所有者が接続所有者になります。既存の接続の場合、フラグメント所有者は、すべてのフラグメントをクラスタ制御リンク経由で接続所有者に転送します。その後、接続オーナーはすべてのフラグメントを再構成します。

クライアントからサーバへのフラグメント化されたICMPエコー要求のフローを使用して、次のトポロジを検討します。

操作の順序を理解するために、内部、外部、クラスタ制御リンクインターフェイスでトレースオプションが設定されたクラスタ全体のパケットキャプチャがあります。さらに、内部インターフェイスでreject-hideオプションが設定されています。

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

クラスタ内の操作順序：

1. サイト1のユニット1-1は、フラグメント化されたICMPエコー要求パケットを受信します。

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.ユニット1-1は、サイト2のユニット2-2をフラグメントの所有者として選択し、フラグメント化されたパケットを送信します。
ユニット1-1からユニット2-2に送信されるパケットの宛先MACアドレスは、ユニット2-2のCCLリンクのMACアドレスです。

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

を選択します。ユニット2-2は、フラグメント化されたパケットを受信して再構成し、フローの所有者になります。

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.ユニット2-2は、セキュリティポリシーに基づいてパケットを許可し、サイト2からサイト1に外部インターフェイス経由で送信します。

firepower# cluster exec unit unit-2-2 show cap capo

2 packets captured

1: 20:13:58.232058 802.1Q vlan#20 P0 192.0.2.10 > 203.0.113.10 icmp: echo request 
2: 20:13:58.232058 802.1Q vlan#20 P0

観察/注意

ディレクタロールとは異なり、フラグメント所有者は特定のサイト内でローカライズできません。フラグメントオーナーは、新しい接続のフラグメント化されたパケットを最初に受信し、任意のサイトに配置できるユニットによって決定されます。
フラグメントの所有者も接続所有者になることができるため、パケットを宛先ホストに転送するには、出力インターフェイスを解決し、宛先ホストまたはネクストホップのIPアドレスとMACアドレスを見つける必要があります。これは、ネクストホップにも宛先ホストへの到達可能性があることを前提としています。
フラグメント化されたパケットを再構成するために、ASA/FTDは各名前付きインターフェイスのIPフラグメント再構成モジュールを維持します。IPフラグメント再構成モジュールの動作データを表示するには、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
```
クラスタ展開では、フラグメント所有者または接続所有者が、フラグメント化されたパケットをフラグメントキューに入れます。フラグメントキューのサイズは、fragment size <size> <nameif>コマンドで設定されているSizeカウンタ（デフォルトでは200）の値によって制限されます。フラグメントキューサイズがSizeの2/3に達すると、フラグメントキューのしきい値を超えていると見なされ、現在のフラグメントチェーンの一部ではない新しいフラグメントがドロップされます。この場合、[Fragment queue threshold exceeded]が増加し、syslogメッセージFTD-3-209006が生成されます。

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.

回避策として、[Firepower Management Center] > [Devices] > [Device Management] > [Edit Device] > [Interfaces] > [Advanced] > [Security Configuration] > [Override Default Fragment Setting]のサイズを増やし、設定を保存し、ポリシーを展開します。次に、show fragmentコマンド出力のキューカウンタと、syslogメッセージFTD-3-209006の発生を監視します。

ACIの問題

ACIポッドでのアクティブなL4チェックサム検証により、クラスタを通じて断続的な接続問題が発生する

症状

ACIポッドに導入されたASA/FTDクラスタを介して断続的な接続の問題。
クラスタ内に1ユニットしかない場合は、接続の問題は発生しません。
クラスタ内の1つのクラスタユニットから1つ以上の他のユニットに送信されたパケットは、FXOSおよびターゲットユニットのデータプレーンキャプチャには表示されません。

緩和策

クラスタ制御リンクを介してリダイレクトされたトラフィックには正しいL4チェックサムが含まれないため、これは正常な動作です。クラスタ制御リンクパス上のスイッチは、L4チェックサムを確認できません。L4チェックサムを確認するスイッチは、トラフィックをドロップする可能性があります。ACIファブリックスイッチの設定を確認し、クラスタ制御リンクを介して送受信されたパケットに対してL4チェックサムが実行されていないことを確認します。

クラスタコントロールプレーンの問題

ユニットがクラスタに参加できない

CCLのMTUサイズ

症状

ユニットがクラスタに参加できず、次のメッセージが表示されます。

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.

検証/緩和

FTDでshow interfaceコマンドを使用し、クラスタ制御リンクインターフェイスのMTUが、データインターフェイスのMTUよりも少なくとも100バイト高いことを確認します。

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.

CCLでsizeオプションを指定してpingを実行し、CCL MTUに設定されているデバイスがパス内のすべてのデバイスで正しく設定されていることを確認します。

firepower# ping 127.2.1.1 size 9184

スイッチでshow interfaceコマンドを使用して、MTU設定を確認します

Switch# show interface
port-channel12 is up
admin state is up,
  Hardware: Port-Channel, address: 7069.5a3a.7976 (bia 7069.5a3a.7976)
  MTU 9084 bytes, BW 40000000 Kbit , DLY 10 usec
port-channel13 is up
admin state is up,
  Hardware: Port-Channel, address: 7069.5a3a.7967 (bia 7069.5a3a.7967)
  MTU 9084 bytes, BW 40000000 Kbit , DLY 10 use

クラスタユニット間のインターフェイスの不一致

症状

ユニットがクラスタに参加できず、次のメッセージが表示されます。

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.

検証/緩和

各シャーシのFCM GUIにログインし、[Interfaces] タブに移動して、すべてのクラスタメンバーが同じインターフェイス設定であるかどうかを確認します。

論理デバイスに割り当てられたインターフェイス
インターフェイスの管理速度
インターフェイスの管理デュプレックス
インターフェイスのステータス

データ/ポートチャネルインターフェイスの問題

CCLでの到達可能性の問題によるスプリットブレイン

症状

クラスタには複数の制御ユニットがあります。このトポロジを参照してください。

シャーシ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

シャーシ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

確認

pingコマンドを使用して、制御ユニットのクラスタ制御リンク(CCL)IPアドレス間の接続を確認します。

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)

ARPテーブルを確認します。

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

制御ユニットで、CCLインターフェイスのキャプチャを設定および確認します。

firepower# capture capccl interface cluster
firepower# show capture capccl | i 127.2.1.1
2: 12:10:57.652310 arp who-has 127.2.1.1 tell 127.2.2.1 
41: 12:11:02.652859 arp who-has 127.2.1.1 tell 127.2.2.1 
74: 12:11:07.653439 arp who-has 127.2.1.1 tell 127.2.2.1 
97: 12:11:12.654018 arp who-has 127.2.1.1 tell 127.2.2.1 
126: 12:11:17.654568 arp who-has 127.2.1.1 tell 127.2.2.1 
151: 12:11:22.655148 arp who-has 127.2.1.1 tell 127.2.2.1 
174: 12:11:27.655697 arp who-has 127.2.1.1 tell 127.2.2.1

緩和策

CCLポートチャネルインターフェイスが、スイッチ上の別のポートチャネルインターフェイスに接続されていることを確認します。
Nexusスイッチで仮想ポートチャネル(vPC)を使用する場合は、CCLポートチャネルインターフェイスが別のvPCに接続されており、vPC設定に失敗した整合性ステータスがないことを確認します。
CCLポートチャネルインターフェイスが同じブロードキャストドメインにあり、CCL VLANが作成され、インターフェイスで許可されていることを確認します。

スイッチの設定例を次に示します。

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

データポートチャネルインターフェイスの中断によりクラスタが無効になりました

症状

1つ以上のデータポートチャネルインターフェイスが中断されています。管理可能なデータインターフェイスが一時停止されると、インターフェイスのヘルスチェックの失敗により、同じシャーシ内のすべてのクラスタユニットがクラスタから取り出されます。

このトポロジを参照してください。

確認

コントロールユニットのコンソールを確認します。

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.

影響を受けるユニットでshow cluster historyコマンドとshow cluster info trace module hcコマンドの出力を確認します。

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

fxosコマンドシェルでshow port-channel summaryコマンドの出力を確認してください。

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)

緩和策

すべてのシャーシに同じクラスタグループ名とパスワードが設定されていることを確認します。
すべてのシャーシとスイッチで、ポートチャネルインターフェイスの物理メンバーインターフェイスが、同じデュプレックス/速度設定で管理上イネーブルになっていることを確認します。
サイト内クラスタでは、すべてのシャーシで同じデータポートチャネルインターフェイスがスイッチの同じポートチャネルインターフェイスに接続されていることを確認します。
Nexusスイッチで仮想ポートチャネル(vPC)を使用する場合は、vPCの設定に失敗した整合性ステータスがないことを確認します。
サイト内クラスタでは、すべてのシャーシで同じデータポートチャネルインターフェイスが同じvPCに接続されていることを確認します。

クラスタの安定性の問題

FXOSトレースバック

症状

ユニットはクラスタから離脱します。

検証/緩和

show cluster historyコマンドを使用して、ユニットがクラスタから出たタイミングを確認します

firepower# show cluster history

次のコマンドを使用して、FXOSにトレースバックがあるかどうかを確認します

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

ユニットがクラスタを離れた時刻に生成されたコアファイルを収集し、TACに提供します。

ディスクがいっぱいです

クラスタユニットの/ngfwパーティション内のディスク使用率が94%に達した場合、そのユニットはクラスタを終了します。ディスク使用率チェックは3秒ごとに行われます。

> 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

この場合、show cluster historyの出力は次のようになります。

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

または

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

障害を確認するもう1つの方法は次のとおりです。

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

また、ディスクが100%以下の場合、ディスク領域が解放されるまでクラスタへの接続が困難になる可能性があります。

オーバーフロー保護

各クラスタユニットは5分ごとに、ローカルおよびピアユニットのCPU使用率とメモリ使用率をチェックします。使用率がシステムしきい値（LINA CPU 50 %またはLINAメモリ59 %）を超えると、情報メッセージが次のように表示されます。

syslog(FTD-6-748008)
ファイルlog/cluster_trace.log

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.

このメッセージは、ユニットに障害が発生した場合、残りのユニットのリソースがオーバーサブスクライブされる可能性があることを示しています。

簡易モード

6.3 FMCより前のリリースでの動作

各クラスタノードは、FMCで個別に登録します。
次に、FMCで論理クラスタを形成します。
新しいクラスタノードを追加するたびに、ノードを手動で登録する必要があります。

ポスト6.3 FMC

簡易モード機能を使用すると、FMC上のクラスタ全体を1ステップで登録できます（クラスタの任意の1つのノードのみを登録できます）。

サポートされる最小マネージャ	管理対象デバイス	サポートされる最小管理対象デバイスバージョンが必要	注意事項
FMC 6.3	FP9300およびFP4100上のFTDクラスタのみ	6.2.0	これはFMC機能のみです

警告：クラスタがFTDで形成されたら、自動登録が開始されるまで待つ必要があります。クラスタノードを手動で登録するのではなく、[Reconcile]オプションを使用してください。

症状

ノード登録の失敗

何らかの理由で制御ノードの登録が失敗すると、クラスタはFMCから削除されます。

緩和策

何らかの理由でデータノードの登録が失敗した場合、次の2つのオプションがあります。

FMCは、クラスタへの展開ごとに、登録が必要なクラスタノードがあるかどうかを確認し、これらのノードの自動登録を開始します。
クラスタのサマリータブの下に[Reconcile]オプション([Devices] > [Device Management] > [Cluster]タブ> [View Cluster Status]リンク)があります。 Reconcileアクションがトリガーされると、登録が必要なノードの自動登録が開始されます。

Firepower Threat Defense(FTD)クラスタのトラブルシューティング

ダウンロードオプション

偏向のない言語

翻訳について

内容

概要

前提条件

要件

使用するコンポーネント

設定

クラスタの基本

NGFWアーキテクチャ

クラスタキャプチャ

Cluster Control Link(CCL)メッセージ

クラスタ制御ポイント(CCP)メッセージ

クラスタヘルスチェック(HC)メカニズム

クラスタHC障害シナリオ

クラスタデータプレーン接続の確立

トラブルシュート

クラスタデータプレーンの問題

NAT/PATの一般的な問題

フラグメント処理

ACIの問題

クラスタコントロールプレーンの問題

ユニットがクラスタに参加できない

CCLのMTUサイズ

クラスタユニット間のインターフェイスの不一致

データ/ポートチャネルインターフェイスの問題

CCLでの到達可能性の問題によるスプリットブレイン

データポートチャネルインターフェイスの中断によりクラスタが無効になりました

クラスタの安定性の問題

FXOSトレースバック

ディスクがいっぱいです

オーバーフロー保護

簡易モード

関連情報

シスコエンジニア提供

このドキュメントは役に立ちましたか?

シスコに問い合わせ

このドキュメントは次の製品に対応しています

Firepower Threat Defense(FTD)クラスタのトラブルシューティング

ダウンロード オプション

偏向のない言語

翻訳について

内容

概要

前提条件

要件

使用するコンポーネント

設定

クラスタの基本

NGFWアーキテクチャ

クラスタキャプチャ

Cluster Control Link(CCL)メッセージ

クラスタ制御ポイント(CCP)メッセージ

クラスタヘルスチェック(HC)メカニズム

クラスタHC障害シナリオ

クラスタデータプレーン接続の確立

トラブルシュート

クラスタデータプレーンの問題

NAT/PATの一般的な問題

フラグメント処理

ACIの問題

クラスタコントロールプレーンの問題

ユニットがクラスタに参加できない

CCLのMTUサイズ

クラスタユニット間のインターフェイスの不一致

データ/ポートチャネルインターフェイスの問題

CCLでの到達可能性の問題によるスプリットブレイン

データポートチャネルインターフェイスの中断によりクラスタが無効になりました

クラスタの安定性の問題

FXOSトレースバック

ディスクがいっぱいです

オーバーフロー保護

簡易モード

関連情報

シスコ エンジニア提供

このドキュメントは役に立ちましたか?

シスコに問い合わせ

このドキュメントは次の製品に対応しています

ダウンロードオプション

シスコエンジニア提供