Firepower 4100/9300 シャーシの ASA クラスタ

クラスタリングを利用すると、複数のFirepower 4100/9300 シャーシ ASA をグループ化して、1 つの論理デバイスにすることができます。Firepower 4100/9300 シャーシシリーズには、Firepower 9300 および Firepower 4100 シリーズが含まれます。クラスタは、単一デバイスのすべての利便性（管理、ネットワークへの統合）を備える一方で、複数デバイスによって高いスループットおよび冗長性を達成します。

（注）

一部の機能は、クラスタリングを使用する場合、サポートされません。「クラスタリングでサポートされない機能」を参照してください。

Firepower 4100/9300 シャーシでのクラスタリングについて

クラスタは、単一の論理ユニットとして機能する複数のデバイスから構成されます。Firepower 4100/9300 シャーシにクラスタを展開すると、以下の処理が実行されます。

ユニット間通信用のクラスタ制御リンク（デフォルトのポートチャネル 48）を作成します。シャーシ内クラスタリングでは（Firepower 9300のみ）、このリンクは、クラスタ通信に Firepower 9300 バックプレーンを使用します。シャーシ間クラスタリングでは、シャーシ間通信のために、この EtherChannel に物理インターフェイスを手動で割り当てる必要があります。
アプリケーション内のクラスタブートストラップコンフィギュレーションを作成します。

クラスタを展開すると、クラスタ名、クラスタ制御リンクインターフェイス、およびその他のクラスタ設定を含む各ユニットに対して、最小限のブートストラップ構成が Firepower 4100/9300 シャーシスーパーバイザからプッシュされます。クラスタリング環境をカスタマイズする場合、ブートストラップコンフィギュレーションの一部は、アプリケーション内でユーザが設定できます。

スパンド インターフェイスとして、クラスタにデータインターフェイスを割り当てます。

シャーシ内クラスタリングでは、スパンドインターフェイスは、シャーシ間クラスタリングのように EtherChannel に制限されません。Firepower 9300 スーパーバイザは共有インターフェイスの複数のモジュールにトラフィックをロードバランシングするために内部で EtherChannel テクノロジーを使用するため、スパンドモードではあらゆるタイプのデータインターフェイスが機能します。シャーシ間クラスタリングでは、すべてのデータインターフェイスでスパンド EtherChannel を使用します。

（注）

管理インターフェイス以外の個々のインターフェイスはサポートされていません。

管理インターフェイスをクラスタ内のすべてのユニットに指定します。

ここでは、クラスタリングの概念と実装について詳しく説明します。クラスタリングの参考資料も参照してください。

ブートストラップコンフィギュレーション

クラスタを展開すると、クラスタ名、クラスタ制御リンクインターフェイス、およびその他のクラスタ設定を含む各ユニットに対して、最小限のブートストラップ構成が Firepower 4100/9300 シャーシスーパーバイザからプッシュされます。クラスタリング環境をカスタマイズする場合、ブートストラップコンフィギュレーションの一部はユーザが設定できます。

クラスタメンバー

クラスタメンバーは連携して動作し、セキュリティポリシーおよびトラフィックフローの共有を達成します。

クラスタ内のメンバの 1 つがマスター ユニットです。マスターユニットは自動的に決定されます。他のすべてのメンバはスレーブ ユニットです。

すべてのコンフィギュレーション作業はマスターユニット上でのみ実行する必要があります。コンフィギュレーションはその後、スレーブユニットに複製されます。

機能によっては、クラスタ内でスケーリングしないものがあり、そのような機能についてはマスターユニットがすべてのトラフィックを処理します。クラスタリングの中央集中型機能を参照してください。。

マスターおよびスレーブユニットの役割

クラスタ内のメンバの 1 つがマスターユニットです。マスターユニットは自動的に決定されます。他のすべてのメンバはスレーブユニットです。

クラスタ制御リンク

クラスタ制御リンクはユニット間通信用の EtherChannel（ポートチャネル 48）です。シャーシ内クラスタリングでは、このリンクは、クラスタ通信に Firepower 9300 バックプレーンを使用します。シャーシ間クラスタリングでは、シャーシ間通信のために、Firepower 4100/9300 シャーシのこの EtherChannel に物理インターフェイスを手動で割り当てる必要があります。

2 シャーシのシャーシ間クラスタの場合、シャーシと他のシャーシの間をクラスタ制御リンクで直接接続しないでください。インターフェイスを直接接続した場合、一方のユニットで障害が発生すると、クラスタ制御リンクが機能せず、他の正常なユニットも動作しなくなります。スイッチを介してクラスタ制御リンクを接続した場合は、正常なユニットについてはクラスタ制御リンクは動作を維持します。

クラスタ制御リンクトラフィックには、制御とデータの両方のトラフィックが含まれます。

制御トラフィックには次のものが含まれます。

マスター選定。
コンフィギュレーションの複製
ヘルスモニタリング。

データトラフィックには次のものが含まれます。

ステート複製。
接続所有権クエリおよびデータパケット転送。

クラスタ制御リンクのサイズ

可能であれば、各シャーシの予想されるスループットに合わせてクラスタ制御リンクをサイジングする必要があります。そうすれば、クラスタ制御リンクが最悪のシナリオを処理できます。たとえば、ASA 5585-X と SSP-60 を使用する場合は、クラスタのユニットあたり最大 14 Gbps を通過させることができるので、クラスタ制御リンクに割り当てるインターフェイスも、最低 14 Gbps の通過が可能となるようにしてください。この場合は、たとえば 10 ギガビットイーサネットインターフェイス 2 つを EtherChannel としてクラスタ制御リンクに使用し、残りのインターフェイスを必要に応じてデータリンクに使用します。

クラスタ制御リンクトラフィックの内容は主に、状態アップデートや転送されたパケットです。クラスタ制御リンクでのトラフィックの量は常に変化します。転送されるトラフィックの量は、ロードバランシングの有効性、または中央集中型機能のための十分なトラフィックがあるかどうかによって決まります。次に例を示します。

NAT では接続のロードバランシングが低下するので、すべてのリターントラフィックを正しいユニットに再分散する必要があります。
ネットワークアクセスに対する AAA は一元的な機能であるため、すべてのトラフィックがマスターユニットに転送されます。
メンバーシップが変更されると、クラスタは大量の接続の再分散を必要とするため、一時的にクラスタ制御リンクの帯域幅を大量に使用します。

クラスタ制御リンクの帯域幅を大きくすると、メンバーシップが変更されたときの収束が高速になり、スループットのボトルネックを回避できます。

（注）

クラスタに大量の非対称（再分散された）トラフィックがある場合は、クラスタ制御リンクのサイズを大きくする必要があります。

クラスタ制御リンク冗長性

クラスタ制御リンクには EtherChannel を使用することを推奨します。冗長性を実現しながら、EtherChannel 内の複数のリンクにトラフィックを渡すことができます。

次の図は、仮想スイッチングシステム（VSS）または仮想ポートチャネル（vPC）環境でクラスタ制御リンクとして EtherChannel を使用する方法を示します。EtherChannel のすべてのリンクがアクティブです。スイッチが VSS または vPC の一部である場合は、同じ EtherChannel 内の ASA インターフェイスをそれぞれ、VSS または vPC 内の異なるスイッチに接続できます。スイッチインターフェイスは同じ EtherChannel ポートチャネルインターフェイスのメンバです。複数の個別のスイッチが単一のスイッチのように動作するからです。この EtherChannel は、スパンド EtherChannel ではなく、デバイスローカルであることに注意してください。

クラスタ制御リンクの信頼性

クラスタ制御リンクの機能を保証するには、ユニット間のラウンドトリップ時間（RTT）が 20 ms 未満になるようにします。この最大遅延により、異なる地理的サイトにインストールされたクラスタメンバとの互換性が向上します。遅延を調べるには、ユニット間のクラスタ制御リンクで ping を実行します。

クラスタ制御リンクは、順序の異常やパケットのドロップがない信頼性の高いものである必要があります。たとえば、サイト間の導入の場合、専用リンクを使用する必要があります。

クラスタ制御リンクネットワーク

Firepower 4100/9300 シャーシは、シャーシ ID およびスロット ID（127.2.chassis_id.slot_id）に基づいて、各ユニットのクラスタ制御リンクインターフェイス IP アドレスを自動生成します。クラスタを展開する場合にこの IP アドレスをカスタマイズできます。クラスタ制御リンクネットワークには、ユニット間のルータを含めることはできません。レイヤ 2 スイッチングのみが許可されます。サイト間トラフィックには、オーバーレイトランスポート仮想化（OTV）を使用することをお勧めします。

クラスタインターフェイス

シャーシ内クラスタリングでは、物理インターフェイス、EtherChannel （ポートチャネルとも呼ばれる）の両方を割り当てることができます。クラスタに割り当てられたインターフェイスはクラスタ内のすべてのメンバーのトラフィックのロードバランシングを行うスパンドインターフェイスです。

シャーシ間クラスタリングでは、データ EtherChannel のみをクラスタに割り当てできます。これらのスパンド EtherChannel は、各シャーシの同じメンバーインターフェイスを含みます。アップストリームスイッチでは、これらのインターフェイスはすべて単一の EtherChannel に含まれ、スイッチは複数のデバイスに接続されていることを察知しません。

管理インターフェイス以外の個々のインターフェイスはサポートされていません。

VSS または vPC への接続

インターフェイスに冗長性を確保するため、EtherChannel を VSS または vPC に接続することを推奨します。

設定の複製

クラスタ内のすべてのユニットは、単一のコンフィギュレーションを共有します。コンフィギュレーション変更を加えることができるのはマスターユニット上だけであり、変更は自動的にクラスタ内の他のすべてのユニットに同期されます。

ASA クラスタの管理

ASA クラスタリングを使用することの利点の 1 つは、管理のしやすさです。ここでは、クラスタを管理する方法について説明します。

管理ネットワーク

すべてのユニットを単一の管理ネットワークに接続することを推奨します。このネットワークは、クラスタ制御リンクとは別のものです。

管理インターフェイス

管理タイプのインターフェイスをクラスタに割り当てる必要があります。このインターフェイスはスパンドインターフェイスではなく、特別な個別インターフェイスです。管理インターフェイスによって各単位に直接接続できます。

メインクラスタ IP アドレスは、そのクラスタのための固定アドレスであり、常に現在のマスターユニットに属します。アドレス範囲も設定して、現在のマスターを含む各ユニットがその範囲内のローカルアドレスを使用できるようにします。このメインクラスタ IP アドレスによって、管理アクセスのアドレスが一本化されます。マスターユニットが変更されると、メインクラスタ IP アドレスは新しいマスターユニットに移動するので、クラスタの管理をシームレスに続行できます。

たとえば、クラスタを管理するにはメインクラスタ IP アドレスに接続します。このアドレスは常に、現在のマスターユニットに関連付けられています。個々のメンバを管理するには、ローカル IP アドレスに接続します。

TFTP や syslog などの発信管理トラフィックの場合、マスターユニットを含む各ユニットは、ローカル IP アドレスを使用してサーバに接続します。

マスターユニット管理とスレーブユニット管理

すべての管理とモニタリングはマスターユニットで実行できます。マスターユニットから、すべてのユニットの実行時統計情報やリソース使用状況などのモニタリング情報を調べることができます。また、クラスタ内のすべてのユニットに対してコマンドを発行することや、コンソールメッセージをスレーブユニットからマスターユニットに複製することもできます。

必要に応じて、スレーブユニットを直接モニタできます。マスターユニットからでもできますが、ファイル管理をスレーブユニット上で実行できます（コンフィギュレーションのバックアップや、イメージの更新など）。次の機能は、マスターユニットからは使用できません。

ユニットごとのクラスタ固有統計情報のモニタリング。
ユニットごとの Syslog モニタリング（コンソールレプリケーションが有効な場合にコンソールに送信される syslog を除く）。
SNMP
NetFlow

RSA キー複製

マスターユニット上で RSA キーを作成すると、そのキーはすべてのスレーブユニットに複製されます。メインクラスタ IP アドレスへの SSH セッションがある場合に、マスターユニットで障害が発生すると接続が切断されます。新しいマスターユニットは、SSH 接続に対して同じキーを使用するので、新しいマスターユニットに再接続するときに、キャッシュ済みの SSH ホストキーを更新する必要はありません。

ASDM 接続証明書 IP アドレス不一致

デフォルトでは、自己署名証明書は、ローカル IP アドレスに基づいて ASDM 接続に使用されます。ASDM を使用してメインクラスタ IP アドレスに接続する場合は、IP アドレス不一致に関する警告メッセージが表示されます。これは、証明書で使用されているのがローカル IP アドレスであり、メインクラスタ IP アドレスではないからです。このメッセージは無視して、ASDM 接続を確立できます。ただし、この種の警告を回避するには、新しい証明書を登録し、この中でメインクラスタ IP アドレスと、IP アドレスプールからのすべてのローカル IP アドレスを指定します。この証明書を各クラスタメンバに使用します。

スパンド EtherChannel（推奨）

シャーシあたり 1 つ以上のインターフェイスをグループ化して、クラスタのすべてのシャーシに広がる EtherChannel とすることができます。EtherChannel によって、チャネル内の使用可能なすべてのアクティブインターフェイスのトラフィックが集約されます。スパンド EtherChannel は、ルーテッドとトランスペアレントのどちらのファイアウォールモードでも設定できます。ルーテッドモードでは、EtherChannel は単一の IP アドレスを持つルーテッドインターフェイスとして設定されます。トランスペアレントモードでは、IP アドレスはブリッジグループメンバーではなく BVI に割り当てられます。EtherChannel は初めから、ロードバランシング機能を基本的動作の一部として備えています。

サイト間クラスタリング

サイト間インストールの場合、推奨されるガイドラインに従っていれば、ASA クラスタリングを活用できます。

各クラスタシャーシを個別のサイト ID に属するように設定できます。

サイト ID は、サイト固有の MAC アドレスおよび IP アドレスと連動します。クラスタから送信されたパケットは、サイト固有の MAC アドレスおよび IP アドレスを使用するのに対し、クラスタで受信したパケットは、グローバル MAC アドレスおよび IP アドレスを使用します。この機能により、MAC フラッピングの原因となる 2 つの異なるポートで両方のサイトから同じグローバル MAC アドレスをスイッチが学習するのを防止します。代わりに、スイッチはサイトの MAC アドレスのみを学習します。サイト固有の MAC アドレスおよび IP アドレスは、スパンド EtherChannel のみを使用したルーテッドモードでサポートされます。

サイト ID は、LISP インスペクションを使用したフローモビリティの有効化、データセンターのサイト間クラスタリングのパフォーマンス向上とラウンドトリップ時間の遅延短縮のためのディレクタローカリゼーションの有効化、およびトラフィックフローのバックアップオーナーが常にオーナーとは異なるサイトに存在する接続に対するサイト冗長性の有効化のためにも使用されます。

サイト間クラスタリングの詳細については、以下の項を参照してください。

クラスタフローモビリティの設定：クラスタフローモビリティの設定
ディレクタローカリゼーションの有効化：ディレクタローカリゼーションの有効化
サイト冗長性の有効化：ディレクタローカリゼーションの有効化

ASA の各機能とクラスタリング

ASA の一部の機能は ASA クラスタリングではサポートされず、一部はマスターユニットだけでサポートされます。その他の機能については適切な使用に関する警告がある場合があります。

クラスタリングでサポートされない機能

これらの機能は、クラスタリングがイネーブルのときは設定できず、コマンドは拒否されます。

TLS プロキシを使用するユニファイドコミュニケーション機能
リモートアクセス VPN（SSL VPN および IPSec VPN）
IS-IS ルーティング
次のアプリケーションインスペクション：
- CTIQBE
- H323、H225、および RAS
- IPsec パススルー
- MGCP
- MMP
- RTSP
- SCCP（Skinny）
- WAAS
- WCCP
Botnet Traffic Filter
Auto Update Server
DHCP クライアント、サーバ、およびプロキシDHCP リレーがサポートされている。
VPN ロードバランシング
フェールオーバー
Integrated Routing and Bridging（IRB）
デッド接続検出（DCD）

クラスタリングの中央集中型機能

次の機能は、マスターユニット上だけでサポートされます。クラスタの場合もスケーリングされません。

（注）

中央集中型機能のトラフィックは、クラスタ制御リンク経由でメンバユニットからマスターユニットに転送されます。

再分散機能を使用する場合は、中央集中型機能のトラフィックが中央集中型機能として分類される前に再分散が行われて、マスター以外のユニットに転送されることがあります。この場合は、トラフィックがマスターユニットに送り返されます。

中央集中型機能については、マスターユニットで障害が発生するとすべての接続がドロップされるので、新しいマスターユニット上で接続を再確立する必要があります。

次のアプリケーションインスペクション：
- DCERPC
- NetBIOS
- PPTP
- RADIUS
- RSH
- SUNRPC
- TFTP
- XDMCP
ダイナミックルーティング
スタティックルートモニタリング
IGMP マルチキャストコントロールプレーンプロトコル処理（データプレーンフォワーディングはクラスタ全体に分散されます）
PIM マルチキャストコントロールプレーンプロトコル処理（データプレーン転送はクラスタ全体に分散されます）
ネットワークアクセスの認証および許可。アカウンティングは非集中型です。
フィルタリングサービス
サイト間 IKEv1/IKEv2 VPN

集中モードでは、VPN 接続はクラスタのマスターとのみ確立されます。これは、VPN クラスタリングのデフォルトモードです。サイト間 VPN は、S2S IKEv2 VPN 接続がメンバー間で分散される分散型 VPN モードでも展開できます。

個々のユニットに適用される機能

これらの機能は、クラスタ全体またはマスターユニットではなく、各 ASA ユニットに適用されます。

QoS：QoS ポリシーは、コンフィギュレーション複製の一部としてクラスタ全体で同期されます。ただし、ポリシーは、各ユニットに対して個別に適用されます。たとえば、出力に対してポリシングを設定する場合は、適合レートおよび適合バースト値は、特定の ASA から出て行くトラフィックに適用されます。3 ユニットから成るクラスタがあり、トラフィックが均等に分散している場合は、適合レートは実際にクラスタのレートの 3 倍になります。
脅威検出：脅威検出は、各ユニットに対して個別に機能します。たとえば、上位統計情報は、ユニット別です。たとえば、ポートスキャン検出が機能しないのは、スキャントラフィックが全ユニット間で分散されるので、1 つのユニットがすべてのトラフィックを読み取ることはないからです。
リソース管理：マルチコンテキストモードでのリソース管理は、ローカル使用状況に基づいて各ユニットに個別に適用されます。
LISP トラフィック：UDP ポート 4342 上の LISP トラフィックは、各受信ユニットによって検査されますが、ディレクタは割り当てられません。各ユニットは、クラスタ間で共有される EID テーブルに追加されますが、LISP トラフィック自体はクラスタ状態の共有に参加しません。

ネットワークアクセス用の AAA とクラスタリング

ネットワークアクセス用の AAA は、認証、許可、アカウンティングの 3 つのコンポーネントで構成されます。認証および許可は、クラスタリングマスター上で中央集中型機能として実装されており、データ構造がクラスタスレーブに複製されます。マスターが選定されたときは、確立済みの認証済みユーザおよびユーザに関連付けられた許可を引き続き中断なく運用するのに必要なすべての情報を、新しいマスターが保有します。ユーザ認証のアイドルおよび絶対タイムアウトは、マスターユニット変更が発生したときも維持されます。

アカウンティングは、クラスタ内の分散型機能として実装されています。アカウンティングはフロー単位で実行されるので、フローを所有するクラスタユニットがアカウンティング開始と停止のメッセージを AAA サーバに送信します（フローに対するアカウンティングが設定されているとき）。

FTP とクラスタリング

FTP データチャネルとコントロールチャネルのフローがそれぞれ別のクラスタメンバよって所有されている場合は、データチャネルのオーナーは定期的にアイドルタイムアウトアップデートをコントロールチャネルのオーナーに送信し、アイドルタイムアウト値を更新します。ただし、コントロールフローのオーナーがリロードされて、コントロールフローが再ホスティングされた場合は、親子フロー関係は維持されなくなります。したがって、コントロールフローのアイドルタイムアウトは更新されません。
FTP アクセスに AAA を使用している場合、制御チャネルのフローはマスターユニットに集中化されます。

アイデンティティファイアウォールとクラスタリング

マスターユニットのみが AD から user-group を取得し、AD エージェントから user-ip マッピングを取得します。マスターユニットからユーザ情報がスレーブに渡されるので、スレーブは、セキュリティポリシーに基づいてユーザ ID の一致の決定を行うことができます。

マルチキャストルーティングとクラスタリング

ファーストパス転送が確立されるまでの間、マスターユニットがすべてのマルチキャストルーティングパケットとデータパケットを処理します。接続が確立された後は、各スレーブがマルチキャストデータパケットを転送できます。

NAT とクラスタリング

NAT は、クラスタの全体的なスループットに影響を与えることがあります。着信および発信の NAT パケットが、クラスタ内のそれぞれ別の ASA に送信されることがあります。ロードバランシングアルゴリズムは IP アドレスとポートに依存していますが、NAT が使用されるときは、着信と発信とで、パケットの IP アドレスやポートが異なるからです。NAT オーナーではない ASA に到着したパケットは、クラスタ制御リンクを介してオーナーに転送されるため、クラスタ制御リンクに大量のトラフィックが発生します。NAT オーナーはセキュリティおよびポリシーチェックの結果に応じてパケットの接続を作成するため、受信側ユニットは転送フローをオーナーに作成しません。

それでもクラスタリングで NAT を使用する場合は、次のガイドラインを考慮してください。

ポートブロック割り当てによる PAT なし：この機能はクラスタではサポートされていません。
ポートブロック割り当てによる PAT：この機能については、次のガイドラインを参照してください。
- ホストあたりの最大制限は、クラスタ全体の制限ではなく、各ユニットで個別に適用されます。したがって、ホストあたりの最大制限が 1 に設定されている 3 つのノードを持つクラスタにおいて、ホストからのトラフィックが 3 つすべてのユニットでロードバランシングされる場合、そのクラスタには 3 つのブロック（各ユニットに 1 つずつ）を割り当てることができます。
- バックアッププールからバックアップユニットに作成されたポートブロックは、ホストあたりの最大制限の適用時には含まれません。
- PAT IP アドレスのオーナーがダウンすると、バックアップユニットが PAT IP アドレス、対応するポートブロック、および xlate を所有します。ただし、新しい要求を処理するためにこれらのブロックは使用されません。接続が最終的にタイムアウトすると、ブロックは解放されます。
- PAT プールが完全に新しい IP アドレスの範囲で変更される On-the-fly PAT ルールの変更では、新しいプールが有効になっていてもいまだ送信中の xlate バックアップ要求に対する xlate バックアップの作成が失敗します。この動作はポートのブロック割り当て機能に固有なものではなく、プールが分散されトラフィックがクラスタユニット間でロードバランシングされるクラスタ展開でのみ見られる一時的な PAT プールの問題です。
ダイナミック PAT 用 NAT プールアドレス分散：マスターユニットは、アドレスをクラスタ全体に均等に分配します。メンバーが接続を受信したときに、そのメンバーのアドレスが 1 つも残っていない場合は、接続はドロップされます（他のメンバーにはまだ使用可能なアドレスがある場合でも）。最低でも、クラスタ内のユニットと同数の NAT アドレスが含まれていることを確認してください。各ユニットが確実に 1 つのアドレスを受け取るようにするためです。アドレス割り当てを表示するには、show nat pool cluster コマンドを使用します。
ラウンドロビンなし：PAT プールのラウンドロビンは、クラスタリングではサポートされません。
マスターユニットによって管理されるダイナミック NAT xlate：マスターユニットが xlate テーブルを維持し、スレーブユニットに複製します。ダイナミック NAT を必要とする接続をスレーブユニットが受信したときに、その xlate がテーブル内にない場合は、スレーブはマスターユニットに xlate を要求します。スレーブユニットが接続を所有します。
Per-session PAT 機能：クラスタリングに限りませんが、Per-session PAT 機能によって PAT のスケーラビリティが向上します。クラスタリングの場合は、各スレーブユニットが独自の PAT 接続を持てるようになります。対照的に、Multi-Session PAT 接続はマスターユニットに転送する必要があり、マスターユニットがオーナーとなります。デフォルトでは、すべての TCP トラフィックおよび UDP DNS トラフィックは per-session PAT xlate を使用します。これに対し、ICMP および他のすべての UDP トラフィックは multi-session を使用します。TCP および UDP に対しこれらのデフォルトを変更するように per-session NAT ルールを設定できますが、ICMP に per-session PAT を設定することはできません。H.323、SIP、または Skinny などの multi-session PAT のメリットを活用できるトラフィックでは、関連付けられている TCP ポートに対し per-session PAT を無効にできます（それらの H.323 および SIP の UDP ポートはデフォルトですでに multi-session になっています）。per-session PAT の詳細については、『ファイアウォールの構成ガイド』を参照してください。
次のインスペクション用のスタティック PAT はありません。
- FTP
- PPTP
- RSH
- SQLNET
- TFTP
- XDMCP
- SIP

ダイナミックルーティングおよびクラスタリング

ルーティングプロセスはマスターユニット上だけで実行されます。ルートはマスターユニットを介して学習され、セカンダリに複製されます。ルーティングパケットがスレーブに到着した場合は、マスターユニットにリダイレクトされます。

スレーブメンバがマスターユニットからルートを学習した後は、各ユニットが個別に転送に関する判断を行います。

OSPF LSA データベースは、マスターユニットからスレーブユニットに同期されません。マスターユニットのスイッチオーバーが発生した場合は、隣接ルータが再起動を検出します。スイッチオーバーは透過的ではありません。OSPF プロセスが IP アドレスの 1 つをルータ ID として選択します必須ではありませんが、スタティックルータ ID を割り当てることができます。これで、同じルータ ID がクラスタ全体で使用されるようになります。割り込みを解決するには、OSPF ノンストップフォワーディング機能を参照してください。

SCTP とクラスタリング

SCTP 関連付けは、任意のユニットで作成できます（ロードバランシングのため）。そのマルチホーミング接続は同じユニットに存在する必要があります。

SIP インスペクションとクラスタリング

制御フローは、任意のユニットで作成できます（ロードバランシングのため）。その子データフローは同じユニットに存在する必要があります。

TLS プロキシ設定はサポートされていません。

SNMP とクラスタリング

SNMP エージェントは、個々の ASA を、そのローカル IP アドレスによってポーリングします。クラスタの統合データをポーリングすることはできません。

SNMP ポーリングには、メインクラスタ IP アドレスではなく、常にローカルアドレスを使用してください。SNMP エージェントがメインクラスタ IP アドレスをポーリングする場合は、新しいマスターが選定されたときに、新しいマスターユニットのポーリングに失敗します。

STUN とクラスタリング

ピンホールが複製されるとき、STUN インスペクションはフェールオーバーモードとクラスタモードでサポートされます。ただし、トランザクション ID はユニット間で複製されません。STUN 要求の受信後にユニットに障害が発生し、別のユニットが STUN 応答を受信した場合、STUN 応答はドロップされます。

syslog および NetFlow とクラスタリング

Syslog：クラスタの各ユニットは自身の syslog メッセージを生成します。各ユニットの syslog メッセージヘッダーフィールドで使用されるデバイス ID を同一にするか、別にするかを設定できます。たとえば、ホスト名コンフィギュレーションはクラスタ内のすべてのユニットに複製されて共有されます。ホスト名をデバイス ID として使用するようにロギングを設定した場合は、どのユニットで生成された syslog メッセージも 1 つのユニットからのように見えます。クラスタブートストラップコンフィギュレーションで割り当てられたローカルユニット名をデバイス ID として使用するようにロギングを設定した場合は、syslog メッセージはそれぞれ別のユニットからのように見えます。
NetFlow：クラスタの各ユニットは自身の NetFlow ストリームを生成します。NetFlow コレクタは、各 ASA を独立した NetFlow エクスポータとしてのみ扱うことができます。

Cisco TrustSec とクラスタリング

マスターユニットだけがセキュリティグループタグ（SGT）情報を学習します。マスターユニットからこの SGT がスレーブに渡されるので、スレーブは、セキュリティポリシーに基づいて SGT の一致決定を下せます。

FXOS シャーシ上の VPN とクラスタリング

ASA FXOS クラスタは、S2S VPN に対する相互排他的な 2 つのモード（集中型または分散型）のいずれかをサポートしています。

集中型 VPN モード。デフォルトモードです。集中モードでは、VPN 接続はクラスタのマスターとのみ確立されます。

VPN 機能を使用できるのはマスターユニットだけであり、クラスタのハイアベイラビリティ能力は活用されません。マスターユニットで障害が発生した場合は、すべての既存の VPN 接続が失われ、VPN 接続されたユーザにとってはサービスの中断となります。新しいマスターが選定されたときに、VPN 接続を再確立する必要があります。

VPN トンネルをスパンドインターフェイスのアドレスに接続すると、接続が自動的にマスターユニットに転送されます。VPN 関連のキーと証明書は、すべてのユニットに複製されます。
分散型 VPN モード。このモードでは、S2S IPsec IKEv2 VPN 接続が ASA クラスタのメンバー全体に分散され、拡張性が提供されます。クラスタのメンバー全体に VPN 接続を分散することで、クラスタの容量とスループットの両方を最大限に活用できるため、集中型 VPN の機能を超えて大幅に VPN サポートを拡張できます。

（注）

集中型 VPN クラスタリングモードは、S2S IKEv1 と S2S IKEv2 をサポートしています。

分散型 VPN クラスタリングモードは、S2S IKEv2 のみをサポートしています。

分散型 VPN クラスタリングモードは、Firepower 9300 でのみサポートされています。

リモートアクセス VPN は、集中型または分散型の VPN クラスタリングモードではサポートされていません。

Firepower 4100/9300 シャーシでのクラスタリングの要件と前提条件

モデルあたりの最大クラスタリングユニット

Firepower 4100：16 シャーシ
Firepower 9300：16 モジュール。たとえば、16 のシャーシで 1 つのモジュールを使用したり、8 つのシャーシで 2 つのモジュールを使用して、最大 16 のモジュールを組み合わせることができます。

インターシャーシクラスタ化に関するハードウェアおよびソフトウェアの要件

クラスタ内のすべてのシャーシ：

Firepower4100シリーズ：すべてのシャーシが同一モデルである必要があります。Firepower 9300：すべてのセキュリティモジュールは同じタイプである必要があります。たとえば、クラスタリングを使用する場合は、Firepower 9300 のすべてのモジュールは SM-40 である必要があります。各シャーシに異なる数のセキュリティモジュールをインストールできますが、すべての空のスロットを含め、シャーシのすべてのモジュールをクラスタに含める必要があります。
イメージアップグレード時を除き、同じ FXOS ソフトウェアを実行する必要があります。
クラスタに割り当てるインターフェイスは、管理インターフェイス、EtherChannel、アクティブインターフェイス、スピード、デュプレックスなど、同じインターフェイス構成を含める必要があります。同じインターフェイス ID の容量が一致し、インターフェイスが同じスパンド EtherChannel に内に問題なくバンドルできる限り、シャーシに異なるタイプのネットワークモジュールを使用できます。シャーシ間クラスタリングでは、すべてのデータインターフェイスを EtherChannel とする必要があります。（インターフェイスモジュールの追加または削除、あるいは EtherChannel の設定などにより）クラスタリングを有効にした後に FXOS でインターフェイスを変更した場合は、各シャーシで同じ変更を行います（スレーブユニットから始めて、マスターで終わります）。 FXOS でインターフェイスを削除した場合、必要な調整を行うことができるように、ASA 設定では関連するコマンドが保持されます。設定からインターフェイスを削除すると、幅広い影響が出る可能性があります。古いインターフェイス設定は手動で削除することができます。
同じ NTP サーバを使用する必要があります。手動で時間を設定しないでください。
ASA：各 FXOS シャーシは、License Authority またはサテライトサーバに登録されている必要があります。スレーブユニットに追加費用はかかりません。永続ライセンスを予約するには、シャーシごとに個別のライセンスを購入する必要があります。Firepower Threat Defense では、すべてのライセンスは Firepower Management Center で処理されます。

スイッチ要件

Firepower 4100/9300 シャーシのクラスタリングを設定する前に、スイッチの設定を完了し、シャーシからスイッチまですべての EtherChannel を良好に接続してください。
サポートされているスイッチのリストについては、「Cisco FXOS Compatibility」を参照してください。

上のクラスタリングのライセンス Firepower 4100/9300 シャーシ

各 Firepower 4100/9300 シャーシは、License Authority またはサテライトサーバに登録されている必要があります。スレーブユニットに追加費用はかかりません。永続ライセンスを予約するには、シャーシごとに個別のライセンスを購入する必要があります。

高度暗号化ライセンスは、登録トークンを適用すると、対象となるお客様の場合自動的に有効化されます。トークンを使用している場合、各シャーシに同じ暗号化ライセンスが必要です。ASA 設定で有効になっているオプションの高度暗号化（3DES/AES）機能のライセンスについては、以下を参照してください。

ASA ライセンス設定では、マスターユニットに対するスマートライセンスの設定のみを行えます。設定はスレーブユニットに複製されますが、一部のライセンスに対しては、スレーブユニットはこの設定を使用しません。この設定はキャッシュ状態のままになり、マスターユニットのみがこのライセンスを要求します。ライセンスは単一のクラスタライセンスにまとめられ、クラスタの各ユニットで共有されます。この集約ライセンスはスレーブユニットにもキャッシュされ、その中の 1 つが将来マスターユニットとなったときに使用されます。各ライセンスタイプは次のように処理されます:

標準：マスターユニットのみがサーバから標準ライセンスを要求します。スレーブユニットにはデフォルトで有効になっている標準ライセンスがあります。そのライセンスを使用するため、サーバに登録を行う必要はありません。
コンテキスト：マスターユニットのみがサーバからコンテキストライセンスを要求します。デフォルトで標準ライセンスは 10 のコンテキストを含み、すべてのクラスタメンバー上に存在します。各ユニットの標準ライセンスの値と、マスターユニットのコンテキストライセンスの値は、集約されたクラスタライセンスでのプラットフォーム制限まで統合されます。次に例を示します。
- クラスタに 6 台の Firepower9300 モジュールがある場合を考えます。標準ライセンスは 10 のコンテキストを含みます。6 つユニットの場合、合計で 60 のコンテキストが加算されます。マスターユニット上で追加の 20 コンテキストライセンスを設定します。したがって、集約されたクラスタライセンスは 80 のコンテキストを含みます。モジュールごとのプラットフォーム制限は 250 であるため、統合されたライセンスに最大 250 のコンテキストが許容されます。80 のコンテキストは制限範囲内です。したがって、マスターユニット上で最大 80 コンテキストを設定できます。各スレーブユニットも、コンフィギュレーションの複製を介して 80 コンテキストを持つことになります。
- クラスタに Firepower4110 が 3 台あるとします。標準ライセンスは 10 のコンテキストを含みます。3 つユニットの場合、合計で 30 のコンテキストが加算されます。マスターユニット上で追加の 250 コンテキストライセンスを設定します。したがって、集約されたクラスタライセンスは 280 のコンテキストを含みます。ユニットごとのプラットフォームの制限が 250 であるため、統合されたライセンスでは最大 250 のコンテキストが許容されます。280 コンテキストは制限を超えています。したがって、マスターユニット上で最大 250 のコンテキストのみを設定できます。各スレーブユニットも、コンフィギュレーションの複製を介して 250 のコンテキストを持つことになります。この場合では、マスターのコンテキストライセンスとして 220 のコンテキストのみを設定する必要があります。
キャリア：分散型 S2S VPN に必要。このライセンスはユニットごとの権限付与であり、各ユニットはサーバから各自のライセンスを要求します。このライセンスの設定はスレーブユニットに複製されます。
高度暗号化（3DES）（2.3.0 以前の Cisco Smart Software Manager サテライト導入の場合、または追跡目的の場合）：このライセンスはユニットごとの権限付与であり、各ユニットはサーバから各自のライセンスを要求します。

新しいマスターユニットが選定されると、このユニットが集約ライセンスを引き続き使用します。また、マスターライセンスを再要求するために、キャッシュされたライセンス設定も使用します。古いマスターユニットがスレーブユニットとしてクラスタに再度参加すると、マスターユニットのライセンス権限付与が解放されます。アカウントに利用可能なライセンスがない場合、スレーブユニットがライセンスを解放する前に、マスターユニットのライセンスがコンプライアンス違反状態になることがあります。保持されたライセンスは 30 日間有効ですが、この猶予期間以降もコンプライアンス違反となる場合、特別なライセンスを必要とする機能の設定変更を行なえません。ただし、動作には影響ありません。新しいアクティブユニットは、ライセンスのコンプライアンスが確保されるまで 12 時間ごとに権限承認更新要求を送信します。ライセンス要求が完全に処理されるまで、設定の変更を控えてください。ユニットがクラスタから離れた場合、キャッシュされたマスター設定は削除されます。一方で、ユニットごとの権限は保持されます。この場合、クラスタ外のユニットのコンテキストライセンスを再要求する必要があります。

分散型 S2S VPN のライセンス

キャリアライセンスは、クラスタの各メンバーで、分散型 S2S VPN に必要です。

各 VPN 接続には、2 つの Other VPN ライセンス済みセッションが必要です（Other VPN ライセンスは基本ライセンスの一部です）。1 つはアクティブセッション用、もう 1 つはバックアップセッション用です。クラスタの最大 VPN セッション容量は、セッションごとに 2 つのライセンスを使用するため、ライセンス済み容量の半分以下にすることができます。

クラスタリングガイドラインと制限事項

シャーシ間クラスタリングのスイッチ

ASR 9006 では、非デフォルト MTU を設定する場合は、ASR インターフェイス MTU をクラスタデバイス MTU より 14 バイト大きく設定します。そうしないと、mtu-ignore オプションを使用しない限り、OSPF 隣接関係（アジャセンシー）ピアリングの試行が失敗する可能性があります。クラスタデバイス MTU は、ASR IPv4 MTU と一致する必要があります。
クラスタ制御リンクインターフェイスのスイッチでは、クラスタユニットに接続されるスイッチポートに対してスパニングツリー PortFast をイネーブルにすることもできます。このようにすると、新規ユニットの参加プロセスを高速化できます。
スイッチ上のスパンド EtherChannel のバンドリングが遅いときは、スイッチの個別インターフェイスに対して LACP 高速レートをイネーブルにできます。Nexus シリーズなど一部のスイッチでは、インサービスソフトウェアアップグレード（ISSU）を実行する際に LACP 高速レートがサポートされないことに注意してください。そのため、クラスタリングで ISSU を使用することは推奨されません。
スイッチでは、EtherChannel ロードバランシングアルゴリズム source-dest-ip または source-dest-ip-port（Cisco Nexus OS および Cisco IOS の port-channel load-balance コマンドを参照）を使用することをお勧めします。クラスタのデバイスにトラフィックを不均一に配分する場合があるので、ロードバランスアルゴリズムでは vlan キーワードを使用しないでください。クラスタデバイスのデフォルトのロードバランシングアルゴリズムは変更しないでください。
スイッチの EtherChannel ロードバランシングアルゴリズムを変更すると、スイッチの EtherChannel インターフェイスは一時的にトラフィックの転送を停止し、スパニングツリープロトコルが再始動します。トラフィックが再び流れ出すまでに、少し時間がかかります。
一部のスイッチは、LACP でのダイナミックポートプライオリティをサポートしていません（アクティブおよびスタンバイリンク）。ダイナミックポートのプライオリティを無効にすることで、スパンド EtherChannel との互換性を高めることができます。
クラスタ制御リンクパスのスイッチでは、L4 チェックサムを検証しないようにする必要があります。クラスタ制御リンク経由でリダイレクトされたトラフィックには、正しい L4 チェックサムが設定されていません。L4 チェックサムを検証するスイッチにより、トラフィックがドロップされる可能性があります。
ポートチャネルバンドルのダウンタイムは、設定されているキープアライブインターバルを超えてはなりません。
Supervisor 2T EtherChannel では、デフォルトのハッシュ配信アルゴリズムは適応型です。VSS 設計での非対称トラフィックを避けるには、クラスタデバイスに接続されているポートチャネルでのハッシュアルゴリズムを固定に変更します。

router(config)# port-channel id hash-distribution fixed

アルゴリズムをグローバルに変更しないでください。VSS ピアリンクに対しては適応型アルゴリズムを使用できます。

シャーシ間クラスタリングの EtherChannel

スイッチ接続用に、EtherChannel モードをアクティブに設定します。クラスタ制御リンクであっても、Firepower 4100/9300 シャーシではオンモードはサポートされません。
FXOS EtherChannel にはデフォルトで [fast] に設定されている LACP レートがあります。Nexus シリーズなど一部のスイッチでは、インサービスソフトウェアアップグレード（ISSU）を実行する際に LACP 高速レートがサポートされないため、クラスタリングで ISSU を使用することは推奨されません。

15.1(1)S2 より前の Catalyst 3750-X Cisco IOS ソフトウェアバージョンでは、クラスタユニットはスイッチスタックに EtherChannel を接続することをサポートしていませんでした。デフォルトのスイッチ設定では、クラスタユニット EtherChannel がクロススタックに接続されている場合、マスタースイッチの電源がオフになると、残りのスイッチに接続されている EtherChannel は起動しません。互換性を高めるため、stack-mac persistent timer コマンドを設定して、十分なリロード時間を確保できる大きな値、たとえば 8 分、0 （無制限）などを設定します。または、15.1(1)S2 など、より安定したスイッチソフトウェアバージョンにアップグレードできます。
スパンド EtherChannel とデバイスローカル EtherChannel のコンフィギュレーション：スパンド EtherChannel とデバイスローカル EtherChannel に対してスイッチを適切に設定します。
- スパンド EtherChannel：クラスタユニット スパンド EtherChannel（クラスタのすべてのメンバに広がる）の場合は、複数のインターフェイスが結合されてスイッチ上の単一の EtherChannel となります。各インターフェイスがスイッチ上の同じチャネルグループ内にあることを確認してください。
- デバイスローカル EtherChannel：クラスタユニット デバイスローカル EtherChannel（クラスタ制御リンク用に設定された EtherChannel もこれに含まれます）は、それぞれ独立した EtherChannel としてスイッチ上で設定してください。スイッチ上で複数のクラスタユニット EtherChannel を結合して 1 つの EtherChannel としないでください。

サイト間クラスタリング

サイト間クラスタリングについては、次のガイドラインを参照してください。

クラスタ制御リンクの遅延が、ラウンドトリップ時間（RTT）20 ms 未満である必要があります。
クラスタ制御リンクは、順序の異常やパケットのドロップがない信頼性の高いものである必要があります。たとえば、専用リンクを使用する必要があります。
接続の再分散を設定しないでください。異なるサイトのクラスタメンバには接続を再分散できません。
クラスタの実装では、着信接続用の複数のサイトでメンバが区別されません。したがって、特定の接続に対する接続のロールが複数のサイトにまたがる場合があります。これは想定されている動作です。ただし、ディレクタローカリゼーションを有効にすると、接続オーナーと同じサイトからローカルディレクタ権限が常に選択されます（サイト ID に応じて）。また、元のオーナーに障害が発生するとローカルディレクタは同じサイトの新しいオーナーを選択します（注：サイト間でトラフィックが非対称で、元のオーナーに障害が発生した後もリモートサイトから継続的なトラフィックがある場合、リモートサイトのユニットが re-hosting ウィンドウ内でデータパケットを受信する場合はこのリモートサイトのユニットが新しいオーナーとなることがあります）。
ディレクタローカリゼーションでは、次のトラフィックタイプのローカリゼーションをサポートしていません。NAT または PAT のトラフィック、SCTP がインスペクションを行うトラフィック、オーナーのフラグメンテーションクエリ。
トランスペアレントモードの場合、内部ルータと外部ルータのペア間にクラスタを配置すると（AKA ノースサウス挿入）、両方の内部ルータが同じ MAC アドレスを共有し、両方の外部ルータが同じ MAC アドレスを共有する必要があります。サイト 1 のクラスタメンバがサイト 2 のメンバに接続を転送するとき、宛先 MAC アドレスは維持されます。MAC アドレスがサイト 1 のルータと同じである場合にのみ、パケットはサイト 2 のルータに到達します。
トランスペアレントモードの場合、内部ネットワーク間のファイル用に各サイトのデータネットワークとゲートウェイルータ間にクラスタを配置すると（AKA イーストウェスト挿入）、各ゲートウェイルータは、HSRP などの First Hop Redundancy Protocol（FHRP）を使用して、各サイトで同じ仮想 IP および MAC アドレスの宛先を提供します。データ VLAN は、オーバーレイトランスポート仮想化（OTV）または同様のものを使用してサイト全体にわたって拡張されます。ローカルゲートウェイルータ宛てのトラフィックが DCI 経由で他のサイトに送信されないようにするには、フィルタを作成する必要があります。ゲートウェイルータが 1 つのサイトで到達不能になった場合、トラフィックが正常に他のサイトのゲートウェイに到達できるようにフィルタを削除する必要があります。
スパンド EtherChannel を使用したルーテッドモードでは、サイト固有の MAC アドレスを設定します。OTV または同様のものを使用してサイト全体にデータ VLAN を拡張します。グローバル MAC アドレス宛てのトラフィックが DCI 経由で他のサイトに送信されないようにするには、フィルタを作成する必要があります。クラスタが 1 つのサイトで到達不能になった場合、トラフィックが正常に他のサイトのクラスタユニットに到達できるようにフィルタを削除する必要があります。ダイナミックルーティングは、サイト間クラスタが拡張セグメントのファーストホップルータとして機能する場合はサポートされません。

その他のガイドライン

大々的なトポロジ変更が発生する場合（EtherChannel インターフェイスの追加または削除、Firepower 4100/9300 シャーシ上でのインターフェイスまたはスイッチの有効化または無効化、VSS または vPC を形成するための追加スイッチの追加など）、ヘルスチェック機能や無効なインターフェイスのインターフェイスモニタリングを無効にする必要があります。トポロジの変更が完了して、コンフィギュレーション変更がすべてのユニットに同期されたら、ヘルスチェック機能を再度イネーブルにできます。
ユニットを既存のクラスタに追加したときや、ユニットをリロードしたときは、一時的に、限定的なパケット/接続ドロップが発生します。これは予定どおりの動作です。場合によっては、ドロップされたパケットが原因で接続がハングすることがあります。たとえば、FTP 接続の FIN/ACK パケットがドロップされると、FTP クライアントがハングします。この場合は、FTP 接続を再確立する必要があります。
スパンド EtherChannel インターフェイスに接続された Windows 2003 Server を使用している場合、syslog サーバポートがダウンしたときにサーバが ICMP エラーメッセージを抑制しないと、多数の ICMP メッセージがクラスタに送信されることになります。このようなメッセージにより、クラスタの一部のユニットで CPU 使用率が高くなり、パフォーマンスに影響する可能性があります。ICMP エラーメッセージを調節することを推奨します。
冗長性を持たせるため、VSS または vPC に EtherChannel を接続することを推奨します。
シャーシ内では、スタンドアロンモードで一部のシャーシセキュリティモジュールをクラスタ化し、他のセキュリティモジュールを実行することはできません。クラスタ内にすべてのセキュリティモジュールを含める必要があります。

デフォルト

クラスタのヘルスチェック機能は、デフォルトでイネーブルになり、ホールド時間は 3 秒です。デフォルトでは、すべてのインターフェイスでインターネットヘルスモニタリングがイネーブルになっています。
接続再分散は、デフォルトでは無効になっています。接続再分散を有効にした場合の、デフォルトの負荷情報交換間隔は 5 秒です。
失敗したクラスタ制御リンクのクラスタ自動再結合機能は、5 分おきに無制限に試行されるように設定されています。
失敗したデータインターフェイスのクラスタ自動再結合機能は、5 分後と、2 に設定された増加間隔で合計で 3 回試行されるように設定されています。
HTTP トラフィックは、5 秒間の接続レプリケーション遅延がデフォルトで有効になっています。

クラスタリングの設定 Firepower 4100/9300 シャーシ

クラスタは、Firepower 4100/9300 シャーシスーパバイザから簡単に展開できます。すべての初期設定が各ユニットに自動的に生成されます。このセクションでは、デフォルトのブートストラップ設定と ASA で実行できるオプションのカスタマイズについて説明します。また、ASA 内からクラスタメンバーを管理する方法についても説明します。クラスタメンバーシップは Firepower 4100/9300 シャーシからも管理できます。詳細については、Firepower 4100/9300 シャーシのマニュアルを参照してください。

手順

ステップ 1	FXOS：ASA クラスタの追加
ステップ 2	ASA：ファイアウォールモードとコンテキストモードの変更
ステップ 3	ASA：データインターフェイスの設定
ステップ 4	ASA：クラスタ設定のカスタマイズ
ステップ 5	ASA：クラスタメンバの管理

FXOS：ASA クラスタの追加

単独の Firepower 9300 シャーシをシャーシ内クラスタとして追加することも、複数のシャーシをシャーシ間クラスタリングに追加することもできます。シャーシ間クラスタリングでは、各シャーシを別々に設定します。1 つのシャーシにクラスタを追加したら、次のシャーシにほぼ同じ設定を入力します。

ASA クラスタの作成

クラスタは、Firepower 4100/9300 シャーシスーパバイザから簡単に展開できます。すべての初期設定が各ユニットに自動的に生成されます。

シャーシ間クラスタリングでは、各シャーシを別々に設定します。導入を容易にするために、1 つのシャーシにクラスタを導入し、その後、最初のシャーシから次のシャーシにブートストラップコンフィギュレーションをコピーできます。

モジュールがインストールされていない場合でも、Firepower 9300 シャーシの 3 つすべてのモジュールスロットでクラスタリングを有効にする必要があります。3 つすべてのモジュールを設定していないと、クラスタは機能しません。

マルチコンテキストモードの場合、最初に論理デバイスを展開してから、ASA アプリケーションでマルチコンテキストモードを有効にする必要があります。

クラスタを導入すると、Firepower 4100/9300 シャーシスーパバイザが次のブートストラップコンフィギュレーションで各 ASA アプリケーションを設定します。ブートストラップコンフィギュレーションの一部（太字のテキストで示されている部分）は、後から必要に応じて ASA から変更できます。


interface Port-channel48
   description Clustering Interface
cluster group <service_type_name>
   key <secret>
   local-unit unit-<chassis#-module#>
   site-id <number>
   cluster-interface port-channel48 ip 127.2.<chassis#>.<module#> 255.255.255.0
   priority <auto>
   health-check holdtime 3
   health-check data-interface auto-rejoin 3 5 2
   health-check cluster-interface auto-rejoin unlimited 5 1
   enable

ip local pool cluster_ipv4_pool <ip_address>-<ip_address> mask <mask>

interface <management_ifc>
   management-only individual
   nameif management
   security-level 0
   ip address <ip_address> <mask> cluster-pool cluster_ipv4_pool   
   no shutdown

http server enable
http 0.0.0.0 0.0.0.0 management 
route management <management_host_ip> <mask> <gateway_ip> 1

（注）

local-unit 名は、クラスタリングを無効化した場合にのみ変更できます。

始める前に

論理デバイスに使用するアプリケーションイメージを Cisco.com からダウンロードして、そのイメージを Firepower 4100/9300 シャーシにアップロードします。
次の情報を用意します。
- 管理インターフェイス ID、IP アドレス、およびネットワークマスク
- ゲートウェイ IP アドレス

手順

ステップ 1	インターフェイスを設定します。クラスタを展開する前に、1 つ以上のデータタイプのインターフェイスまたは EtherChannel（ポートチャネルとも呼ばれる）を追加します。EtherChannel（ポートチャネル）の追加または物理インターフェイスの設定を参照してください。シャーシ間クラスタリングでは、すべてのデータインターフェイスが 1 つ以上のメンバーインターフェイスを持つスパンド EtherChannel である必要があります。各シャーシに同じ EtherChannel を追加します。スイッチ上で、すべてのクラスタユニットからメンバーインターフェイスを 1 つの EtherChannel へと結合します。シャーシ間クラスタリングの EtherChannel についての詳細は、クラスタリングガイドラインと制限事項を参照してください。デフォルトでは、すべてのインターフェイスがクラスタに割り当てられます。シャーシ間クラスタリングでは、EtherChannel のみが割り当てられます。他のインターフェイスタイプを割り当てることはできません。導入後にもクラスタにデータインターフェイスを追加できます。管理タイプのインターフェイスまたは EtherChannel を追加します。EtherChannel（ポートチャネル）の追加または物理インターフェイスの設定を参照してください。管理インターフェイスが必要です。この管理インターフェイスは、シャーシの管理のみに使用されるシャーシ管理インターフェイスと同じではありません（FXOS では、シャーシ管理インターフェイスは MGMT、management0 のような名前で表示されます）。シャーシ間クラスタリングの場合、各シャーシに同じ管理インターフェイスを追加します。シャーシ間クラスタリングでは、ポートチャネル 48 にメンバーインターフェイスを追加し、クラスタ制御リンクとして使用します。シャーシ内クラスタリングのメンバーインターフェイスを追加しないでください。メンバーを追加すると、シャーシはこのクラスタがシャーシ間であると見なし、例えばスパンド Etherchannel のみを使用できるようになります。各シャーシに同じメンバインターフェイスを追加します。クラスタ制御リンクは、各シャーシのデバイスローカル EtherChannel です。デバイスごとにスイッチで個別の EtherChannel を使用します。シャーシ間クラスタリングの EtherChannel についての詳細は、クラスタリングガイドラインと制限事項を参照してください。
ステップ 2	セキュリティサービスモードを開始します。 scope ssa 例: `Firepower# scope ssa Firepower /ssa #`
ステップ 3	デフォルトのイメージバージョンを設定します。使用可能なイメージを表示します。使用するバージョン番号に注意してください。 show app 例: `Firepower /ssa # show app Name Version Author Supported Deploy Types CSP Type Is Default App ---------- --------------- ---------- ---------------------- ----------- -------------- asa 9.9.1 cisco Native Application No asa 9.10.1 cisco Native Application Yes ftd 6.2.3 cisco Native Application Yes` 範囲をイメージバージョンに設定します。 scope app asa `application_version` 例: `Firepower /ssa # scope asa ftd 9.10.1 Firepower /ssa/app #` このバージョンをデフォルトとして設定します。 set-default 例: `Firepower /ssa/app # set-default Firepower /ssa/app* #` 終了して ssa モードを開始します。 exit 例: `Firepower /ssa/app* # exit Firepower /ssa* #` 例: `Firepower /ssa # scope app asa 9.12.1 Firepower /ssa/app # set-default Firepower /ssa/app* # exit Firepower /ssa* #`
ステップ 4	クラスタを作成します。 enter logical-device `device_name` asa `slots` clustered `device_name` ：Firepower 4100/9300 シャーシスーパーバイザがクラスタリングを設定してインターフェイスを割り当てるために使用します。この名前は、セキュリティモジュール設定で使用されるクラスタ名ではありません。まだハードウェアをインストールしていなくても、3 つのセキュリティモジュールすべてを指定する必要があります。 `スロット` : シャーシモジュールをクラスタに割り当てます。Firepower 4100 の場合は、1 を指定します。Firepower 9300 の場合は、1、2、3 を指定します。モジュールがインストールされていない場合でも、Firepower 9300 シャーシの 3 つすべてのモジュールスロットでクラスタリングを有効にする必要があります。3 つすべてのモジュールを設定していないと、クラスタは機能しません。例: `Firepower /ssa # enter logical-device ASA1 asa 1,2,3 clustered Firepower /ssa/logical-device* #`
ステップ 5	クラスタブートストラップパラメータを設定します。これらの設定は、初期導入専用、またはディザスタリカバリ用です。通常の運用では、後でアプリケーション CCLI 設定のほとんどの値を変更できます。クラスタブートストラップオブジェクトを作成します。 enter cluster-bootstrap 例: `Firepower /ssa/logical-device* # enter cluster-bootstrap Firepower /ssa/logical-device/cluster-bootstrap* #` シャーシ ID を設定します。 set chassis-id `id` クラスタの各シャーシは一意の ID が必要です。サイト間クラスタリングの場合、サイト ID は 1 ～ 8 の範囲で設定します。 set site-id `number`. サイト ID を削除するには、値を 0 に設定します。例: `Firepower /ssa/logical-device/cluster-bootstrap* # set site-id 1 Firepower /ssa/logical-device/cluster-bootstrap* #` クラスタ制御リンクの制御トラフィックの認証キーを設定します。 set key 例: `Firepower /ssa/logical-device/cluster-bootstrap* # set key Key: diamonddogs` 共有秘密を入力するように求められます。共有秘密は、1 ～ 63 文字の ASCII 文字列です。共有秘密は、キーを生成するために使用されます。このオプションは、データパストラフィック（接続状態アップデートや転送されるパケットなど）には影響しません。データパストラフィックは、常にクリアテキストとして送信されます。クラスタインターフェイスモードを設定します。 set mode spanned-etherchannel スパンド EtherChannel モードは、サポートされている唯一のモードです。例: `Firepower /ssa/logical-device/cluster-bootstrap* # set mode spanned-etherchannel Firepower /ssa/logical-device/cluster-bootstrap* #` セキュリティモジュール設定のクラスタグループ名を設定します。 set service-type `cluster_name` 名前は 1 ～ 38 文字の ASCII 文字列であることが必要です。例: `Firepower /ssa/logical-device/cluster-bootstrap* # set service-type cluster1 Firepower /ssa/logical-device/cluster-bootstrap* #` （任意） Cluster Control Link IP ネットワークを設定します。 set cluster-control-link network `a`.`b`.0.0 クラスタ制御リンクのデフォルトでは 127.2.0.0/16 ネットワークが使用されます。ただし、一部のネットワーク展開では、127.2.0.0/16 トラフィックはパスできません。この場合、クラスタの固有ネットワークに任意の /16 ネットワークアドレスを指定できます。 `a`.`b`.0.0 ：任意の /16 ネットワークアドレスを指定します（ループバック（127.0.0.0/8）およびマルチキャスト（224.0.0.0/4）のアドレスを除く）。値を 0.0.0.0 に設定すると、デフォルトのネットワーク（127.2.0.0）が使用されます。シャーシは、シャーシ ID とスロット ID（a.b.chassis_id.slot_id）に基づいて、各ユニットのクラスタ制御リンクインターフェイスの IP アドレスを自動生成します。例: `Firepower /ssa/logical-device/cluster-bootstrap* # set cluster-control-link network 10.10.0.0` 管理 IP アドレス情報を設定します。この情報は、セキュリティモジュール設定で管理インターフェイスを設定するために使用されます。ローカル IP アドレスのプールを設定します。このアドレスの 1 つがインターフェイス用に各クラスタユニットに割り当てられます。 set ipv4 pool `start_ip end_ip` set ipv6 pool `start_ip end_ip` 最低でも、クラスタ内のユニット数と同じ数のアドレスが含まれるようにしてください。Firepower 9300 の場合、すべてのモジュールスロットが埋まっていないとしても、シャーシごとに 3 つのアドレスを含める必要があることに注意してください。クラスタを拡張する予定の場合は、アドレスを増やします。現在のマスターユニットに属する仮想 IP アドレス（メインクラスタ IP アドレスと呼ばれる）は、このプールの一部ではありません。必ず、同じネットワークの IP アドレスの 1 つをメインクラスタ IP アドレス用に確保してください。IPv4 アドレスと IPv6 アドレス（どちらか一方も可）を使用できます。管理インターフェイスのメインクラスタの IP アドレスを設定します。 set virtual ipv4 `ip_address` mask `mask` set virtual ipv6 `ip_address` prefix-length `prefix` この IP アドレスは、クラスタプールアドレスと同じネットワーク上に存在している必要がありますが、プールに含まれていてはなりません。ネットワークゲートウェイアドレスを入力します。 set ipv4 gateway `ip_address` set ipv6 gateway `ip_address` 例: Firepower /ssa/logical-device/cluster-bootstrap* # set ipv4 gateway 10.1.1.254 Firepower /ssa/logical-device/cluster-bootstrap* # set ipv4 pool 10.1.1.11 10.1.1.27 Firepower /ssa/logical-device/cluster-bootstrap* # set ipv6 gateway 2001:DB8::AA Firepower /ssa/logical-device/cluster-bootstrap* # set ipv6 pool 2001:DB8::11 2001:DB8::27 Firepower /ssa/logical-device/cluster-bootstrap* # set virtual ipv4 10.1.1.1 mask 255.255.255.0 Firepower /ssa/logical-device/cluster-bootstrap* # set virtual ipv6 2001:DB8::1 prefix-length 64 クラスタブートストラップモードを終了します。 exit 例: `Firepower /ssa/logical-device* # enter cluster-bootstrap Firepower /ssa/logical-device/cluster-bootstrap* # set chassis-id 1 Firepower /ssa/logical-device/cluster-bootstrap* # set key Key: f@arscape Firepower /ssa/logical-device/cluster-bootstrap* # set mode spanned-etherchannel Firepower /ssa/logical-device/cluster-bootstrap* # set service-type cluster1 Firepower /ssa/logical-device/cluster-bootstrap* # exit Firepower /ssa/logical-device/* #`
ステップ 6	管理ブートストラップパラメータを設定します。これらの設定は、初期導入専用、またはディザスタリカバリ用です。通常の運用では、後でアプリケーション CCLI 設定のほとんどの値を変更できます。管理ブートストラップオブジェクトを作成します。 enter mgmt-bootstrap asa 例: `Firepower /ssa/logical-device* # enter mgmt-bootstrap asa Firepower /ssa/logical-device/mgmt-bootstrap* #` admin とイネーブルパスワードを指定します。 create bootstrap-key-secret PASSWORD set value 値の入力：`password` 値の確認：`password` exit 例: 事前設定されている ASA 管理者ユーザおよびイネーブルパスワードはパスワードの回復時に役立ちます。FXOS アクセスができる場合、管理者ユーザパスワードを忘れたときにリセットできます。例: `Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key-secret PASSWORD Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # set value Enter a value: floppylampshade Confirm the value: floppylampshade Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # exit Firepower /ssa/logical-device/mgmt-bootstrap* #` ファイアウォールモード（「ルーテッド」または「トランスペアレント」）を指定します。 create bootstrap-key FIREWALL_MODE set value {routed \| transparent} exit ルーテッドモードでは、デバイスはネットワーク内のルータホップと見なされます。ルーティングを行う各インターフェイスは異なるサブネット上にあります。これに対し、トランスペアレントファイアウォールは、「Bump In The Wire」または「ステルスファイアウォール」のように動作するレイヤ 2 ファイアウォールであり、接続されたデバイスへのルータホップとしては認識されません。ファイアウォールモードは初期展開時にのみ設定します。ブートストラップの設定を再適用する場合、この設定は使用されません。例: `Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key FIREWALL_MODE Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value routed Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit Firepower /ssa/logical-device/mgmt-bootstrap* #` 管理ブートストラップモードを終了します。 exit 例: `Firepower /ssa/logical-device/mgmt-bootstrap* # exit Firepower /ssa/logical-device* #`
ステップ 7	設定を保存します。 commit-buffer シャーシは、指定したソフトウェアバージョンをダウンロードし、アプリケーションインスタンスにブートストラップ設定と管理インターフェイス設定をプッシュすることで、論理デバイスを導入します。show app-instance コマンドを使用して、導入のステータスを確認します。[Admin State] が [Enabled] で、[Oper State] が [Online] の場合、アプリケーションインスタンスは実行中であり、使用できる状態になっています。例: Firepower /ssa/logical-device* # commit-buffer Firepower /ssa/logical-device # exit Firepower /ssa # show app-instance App Name Identifier Slot ID Admin State Oper State Running Version Startup Version Deploy Type Profile Name Cluster State Cluster Role ---------- ---------- ---------- ----------- ---------------- --------------- --------------- ----------- ------------ --------------- ------------ ftd cluster1 1 Enabled Online 6.4.0.49 6.4.0.49 Native In Cluster Slave ftd cluster1 2 Enabled Online 6.4.0.49 6.4.0.49 Native In Cluster Master ftd cluster1 3 Disabled Not Available 6.4.0.49 Native Not Applicable None
ステップ 8	クラスタに別のシャーシを追加する場合は、この手順を繰り返しますが、固有の chassis-id と正しい site-id を設定する必要があります。それ以外の場合は、両方のシャーシで同じ設定を使用します。インターフェイスコンフィギュレーションが新しいシャーシと同じであることを確認します。FXOS シャーシ設定をエクスポートおよびインポートし、このプロセスを容易にすることができます。
ステップ 9	マスターユニット ASA に接続して、クラスタリング設定をカスタマイズします。

例

シャーシ 1：


scope eth-uplink
  scope fabric a
    enter port-channel 1
      set port-type data
      enable
      enter member-port Ethernet1/1
        exit
      enter member-port Ethernet1/2
        exit
      exit
    enter port-channel 2
      set port-type data
      enable
      enter member-port Ethernet1/3
        exit
      enter member-port Ethernet1/4
        exit
      exit
    enter port-channel 3
      set port-type data
      enable
      enter member-port Ethernet1/5
        exit
      enter member-port Ethernet1/6
        exit
      exit
    enter port-channel 4
      set port-type mgmt
      enable
      enter member-port Ethernet2/1
        exit
      enter member-port Ethernet2/2
        exit
      exit
    enter port-channel 48
      set port-type cluster
      enable
      enter member-port Ethernet2/3
        exit
      exit
    exit
  exit
commit-buffer

scope ssa
  enter logical-device ASA1 asa "1,2,3" clustered
    enter cluster-bootstrap
      set chassis-id 1
      set ipv4 gateway 10.1.1.254
      set ipv4 pool 10.1.1.11 10.1.1.27
      set ipv6 gateway 2001:DB8::AA
      set ipv6 pool 2001:DB8::11 2001:DB8::27
      set key
      Key: f@arscape
      set mode spanned-etherchannel
      set service-type cluster1
      set virtual ipv4 10.1.1.1 mask 255.255.255.0
      set virtual ipv6 2001:DB8::1 prefix-length 64
      exit
    exit
  scope app asa 9.5.2.1
    set-default
    exit
  commit-buffer

シャーシ 2：


scope eth-uplink
  scope fabric a
    create port-channel 1
      set port-type data
      enable
      create member-port Ethernet1/1
        exit
      create member-port Ethernet1/2
        exit
      exit
    create port-channel 2
      set port-type data
      enable
      create member-port Ethernet1/3
        exit
      create member-port Ethernet1/4
        exit
      exit
    create port-channel 3
      set port-type data
      enable
      create member-port Ethernet1/5
        exit
      create member-port Ethernet1/6
        exit
      exit
    create port-channel 4
      set port-type mgmt
      enable
      create member-port Ethernet2/1
        exit
      create member-port Ethernet2/2
        exit
      exit
    create port-channel 48
      set port-type cluster
      enable
      create member-port Ethernet2/3
        exit
      exit
    exit
  exit
commit-buffer

scope ssa
  enter logical-device ASA1 asa "1,2,3" clustered
    enter cluster-bootstrap
      set chassis-id 2
      set ipv4 gateway 10.1.1.254
      set ipv4 pool 10.1.1.11 10.1.1.15
      set ipv6 gateway 2001:DB8::AA
      set ipv6 pool 2001:DB8::11 2001:DB8::19
      set key
      Key: f@rscape
      set mode spanned-etherchannel
      set service-type cluster1
      set virtual ipv4 10.1.1.1 mask 255.255.255.0
      set virtual ipv6 2001:DB8::1 prefix-length 64
      exit
    exit
  scope app asa 9.5.2.1
    set-default
    exit
  commit-buffer

クラスタメンバの追加

ASA クラスタメンバを追加または置き換えます。

（注）

この手順は、シャーシの追加または置換にのみ適用されます。クラスタリングがすでに有効になっている Firepower 9300 にモジュールを追加または置換する場合、モジュールは自動的に追加されます。

始める前に

既存のクラスタに、この新しいメンバ用の管理 IP アドレスプール内で十分な IP アドレスが割り当てられているようにしてください。それ以外の場合は、この新しいメンバを追加する前に、各シャーシ上の既存のクラスタブートストラップ設定を編集する必要があります。この変更により論理デバイスが再起動します。
インターフェイスの設定は、新しいシャーシでの設定と同じである必要があります。FXOS シャーシ設定をエクスポートおよびインポートし、このプロセスを容易にすることができます。
マルチコンテキストモードでは、最初のクラスタメンバの ASA アプリケーションでマルチコンテキストモードを有効にします。追加のクラスタメンバはマルチコンテキストモード設定を自動的に継承します。

手順

ステップ 1	[Copy config] チェックボックスをオンにして、[OK] をクリックします。このチェックボックスをオフにする場合は、手動で最初のシャーシの設定に一致するように設定を入力する必要があります。
ステップ 2	クラスタに別のシャーシを追加する場合は、ASA クラスタの作成の手順を繰り返しますが、一意の chassis-id と正しい site-id を設定する必要があります。それ以外の場合は、新しいシャーシに同じ設定を使用します。

ASA：ファイアウォールモードとコンテキストモードの変更

デフォルトでは、FXOS シャーシはルーテッドファイアウォールモード、およびシングルコンテキストモードでクラスタを展開します。

ファイアウォールモードの変更：展開後にモードを変更するには、マスターユニットでモードを変更します。モードは一致するようにすべてのスレーブユニットで自動的に変更されます。を参照してください。ファイアウォールモードの設定マルチコンテキストモードでは、コンテキストごとにファイアウォールモードを設定します。
マルチコンテキストモードに変更：展開後にマルチコンテキストモードに変更するには、マスターユニットのモードを変更します。これにより、すべてのスレーブユニットのモードは一致するように自動的に変更されます。マルチコンテキストモードの有効化を参照してください。

ASA：データインターフェイスの設定

この手順では、FXOS にクラスタを展開したときにクラスタに割り当てられた各データインターフェイスの基本的なパラメータを設定します。シャーシ間クラスタリングの場合、データインターフェイスは常にスパンド EtherChannel インターフェイスです。

（注）

管理インターフェイスは、クラスタを展開したときに事前設定されました。ASA で管理インターフェイスパラメータを変更することもできますが、この手順はデータインターフェイスに焦点を当てています。管理インターフェイスは、スパンドインターフェイスとは対照的に、個別のインターフェイスです。詳細については、「管理インターフェイス」を参照してください。

始める前に

マルチコンテキストモードの場合は、この手順をシステム実行スペースで開始します。まだシステムコンフィギュレーションモードに入っていない場合は、changeto system コマンドを入力します。
トランスペアレントモードの場合は、ブリッジグループを設定します。ブリッジ仮想インターフェイス（BVI）の設定を参照してください。
シャーシ間クラスタリングにスパンド EtherChannel を使用している場合、クラスタリングが完全に有効になるまで、ポートチャネルインターフェイスは起動しません。この要件により、クラスタのアクティブではないユニットにトラフィックが転送されるのが防がれます。

手順

ステップ 1	インターフェイス ID を指定します interface `id` このクラスタに割り当てられているインターフェイスの FXOS シャーシを参照してください。インターフェイス ID には、次のものがあります。 port-channel integer ethernet slot/port 例: `ciscoasa(config)# interface port-channel 1`
ステップ 2	インターフェイスをイネーブルにします。 no shutdown
ステップ 3	（オプション）このインターフェイス上に VLAN サブインターフェイスを作成する予定の場合は、この時点で作成します。例: `ciscoasa(config)# interface port-channel 1.10 ciscoasa(config-if)# vlan 10` この手順の残りの部分は、サブインターフェイスに適用されます。
ステップ 4	（マルチコンテキストモード）インターフェイスをコンテキストに割り当ててから、コンテキストに変更し、インターフェイスモードを開始します。例: `ciscoasa(config)# context admin ciscoasa(config)# allocate-interface port-channel1 ciscoasa(config)# changeto context admin ciscoasa(config-if)# interface port-channel 1` マルチコンテキストモードの場合は、インターフェイスコンフィギュレーションの残りの部分は各コンテキスト内で行われます。
ステップ 5	インターフェイスの名前を指定します。 nameif `name` 例: `ciscoasa(config-if)# nameif inside` name は最大 48 文字のテキスト文字列です。大文字と小文字は区別されません。名前を変更するには、このコマンドで新しい値を再入力します。
ステップ 6	ファイアウォールモードに応じて、次のいずれかを実行します。ルーテッドモード：IPv4 アドレスと IPv6 アドレスの一方または両方を設定します。（IPv4） ip address `ip_address` [`mask`] （IPv6） ipv6 address `ipv6-prefix`/`prefix-length` 例： `ciscoasa(config-if)# ip address 10.1.1.1 255.255.255.0 ciscoasa(config-if)# ipv6 address 2001:DB8::1001/32` DHCP、PPPoE、および IPv6 自動設定はサポートされません。ポイントツーポイント接続の場合、31 ビットのサブネットマスク（255.255.255.254）を指定できます。この場合、ネットワークまたはブロードキャストアドレス用の IP アドレスは予約されません。トランスペアレントモード：インターフェイスをブリッジグループに割り当てます。 bridge-group `number` 例： `ciscoasa(config-if)# bridge-group 1` number は、1 ～ 100 の整数です。ブリッジグループには最大 64 個のインターフェイスを割り当てることができます。同一インターフェイスを複数のブリッジグループに割り当てることはできません。BVI のコンフィギュレーションには IP アドレスが含まれていることに注意してください。
ステップ 7	セキュリティレベルを設定します。 security-level `number` 例: `ciscoasa(config-if)# security-level 50` number には、0（最下位）～ 100（最上位）の整数を指定します。
ステップ 8	（シャーシ間クラスタリング）潜在的なネットワークの接続問題を回避するために、スパンド EtherChannel のグローバル MAC アドレスを設定します。 mac-address `mac_address` mac_address：MAC アドレスは、H.H.H 形式で指定します。H は 16 ビットの 16 進数です。たとえば、MAC アドレス 00-0C-F1-42-4C-DE は、000C.F142.4CDE と入力します。自動生成された MAC アドレスも使用する場合、手動で割り当てる MAC アドレスの最初の 2 バイトには A2 を使用できません。 MAC アドレスが手動設定されている場合、その MAC アドレスは現在のマスターユニットに留まります。MAC アドレスを設定していない場合に、マスターユニットが変更された場合、新しいマスターユニットはインターフェイスに新しい MAC アドレスを使用します。これにより、一時的なネットワークの停止が発生する可能性があります。マルチコンテキストモードでは、コンテキスト間でインターフェイスを共有する場合は、MAC アドレスの自動生成を有効にして、手動で MAC アドレスを設定しなくてすむようにします。非共有インターフェイスの場合は、このコマンドを使用して MAC アドレスを手動で設定する必要があることに注意してください。例: `ciscoasa(config-if)# mac-address 000C.F142.4CDE`
ステップ 9	（シャーシ間のクラスタリング）サイトごとにサイト固有の MAC アドレスを、ルーテッドモードの場合は IP アドレスを設定します。 mac-address `mac_address` site-id `number` site-ip `ip_address` 例: `ciscoasa(config-if)# mac-address aaaa.1111.1234 ciscoasa(config-if)# mac-address aaaa.1111.aaaa site-id 1 site-ip 10.9.9.1 ciscoasa(config-if)# mac-address aaaa.1111.bbbb site-id 2 site-ip 10.9.9.2 ciscoasa(config-if)# mac-address aaaa.1111.cccc site-id 3 site-ip 10.9.9.3 ciscoasa(config-if)# mac-address aaaa.1111.dddd site-id 4 site-ip 10.9.9.4` サイト固有の IP アドレスは、グローバル IP アドレスと同じサブネット上にある必要があります。ユニットで使用するサイト固有の MAC アドレスおよび IP アドレスは、各ユニットのブートストラップコンフィギュレーションに指定したサイト ID によって異なります。

ASA：クラスタ設定のカスタマイズ

クラスタを展開した後にブートストラップ設定を変更する場合や、クラスタリングヘルスモニタリング、TCP 接続複製の遅延、フローモビリティ、およびその他の最適化など、追加のオプションを設定する場合は、マスターユニットで行うことができます。

ASA クラスタの基本パラメータの設定

マスターユニット上のクラスタ設定をカスタマイズできます。

始める前に

マルチコンテキストモードでは、マスターユニット上のシステム実行スペースで次の手順を実行します。コンテキストからシステム実行スペースに切り替えるには、changeto system コマンドを入力します。
local-unit name およびその他の複数のオプションは、FXOS シャーシでのみ設定することができます。また、それらのオプションは、クラスタリングを無効にしている場合に ASA でのみ変更できます。そのため、次の手順には含まれていません。

手順

ステップ 1	このユニットがマスターユニットであることを確認します。 show cluster info 例: asa(config)# show cluster info Cluster cluster1: On Interface mode: spanned This is "unit-1-2" in state MASTER ID : 2 Version : 9.5(2) Serial No.: FCH183770GD CCL IP : 127.2.1.2 CCL MAC : 0015.c500.019f Last join : 01:18:34 UTC Nov 4 2015 Last leave: N/A Other members in the cluster: Unit "unit-1-3" in state SLAVE ID : 4 Version : 9.5(2) Serial No.: FCH19057ML0 CCL IP : 127.2.1.3 CCL MAC : 0015.c500.018f Last join : 20:29:57 UTC Nov 4 2015 Last leave: 20:24:55 UTC Nov 4 2015 Unit "unit-1-1" in state SLAVE ID : 1 Version : 9.5(2) Serial No.: FCH19057ML0 CCL IP : 127.2.1.1 CCL MAC : 0015.c500.017f Last join : 20:20:53 UTC Nov 4 2015 Last leave: 20:18:15 UTC Nov 4 2015 Unit "unit-2-1" in state SLAVE ID : 3 Version : 9.5(2) Serial No.: FCH19057ML0 CCL IP : 127.2.2.1 CCL MAC : 0015.c500.020f Last join : 20:19:57 UTC Nov 4 2015 Last leave: 20:24:55 UTC Nov 4 2015 別のユニットがマスターユニットの場合は、接続を終了し、正しいユニットに接続します。ASA コンソールへのアクセス方法の詳細については、Cisco ASA for Firepower 4100 クイックスタートガイド [英語] または Cisco ASA for Firepower 9300 クイックスタートガイド [英語] を参照してください。
ステップ 2	クラスタ制御リンクインターフェイスの最大伝送ユニットを指定します。 mtu cluster `bytes` 例: `ciscoasa(config)# mtu cluster 9000` MTU の最大値を 9184 バイトに設定し、最小値を 1400 バイトに設定することをお勧めします。
ステップ 3	クラスタの設定モードを開始します。 cluster group `name`
ステップ 4	（任意）スレーブユニットからマスターユニットへのコンソール複製をイネーブルにします。 console-replicate この機能はデフォルトで無効に設定されています。ASA は、特定の重大イベントが発生したときに、メッセージを直接コンソールに出力します。コンソール複製をイネーブルにすると、スレーブユニットからマスターユニットにコンソールメッセージが送信されるので、モニタが必要になるのはクラスタのコンソールポート 1 つだけとなります。
ステップ 5	クラスタリングイベントの最小トレースレベルを設定します。 trace-level `level` 必要に応じて最小レベルを設定します。 critical ：クリティカルイベント（重大度 = 1） warning ：警告（重大度 = 2） informational ：情報イベント（重大度 = 3） debug ：デバッグイベント（重大度 = 4）
ステップ 6	（任意） LACP のダイナミックポートの優先順位を無効にします。 clacp static-port-priority 一部のスイッチはダイナミックポートプライオリティをサポートしていないため、このコマンドはスイッチの互換性を高めます。さらに、このコマンドは、9 ～ 32 のアクティブスパンド EtherChannel メンバーのサポートをイネーブルにします。このコマンドを使用しないと、サポートされるのは 8 個のアクティブメンバと 8 個のスタンバイメンバのみです。このコマンドをイネーブルにした場合、スタンバイメンバは使用できません。すべてのメンバがアクティブです。
ステップ 7	（任意）（Firepower 9300 のみ）シャーシ内のセキュリティモジュールがクラスタに同時に参加し、トラフィックがモジュール間で均等に分散されていることを確認します。他のモジュールよりもかなり前に参加したモジュールは、他のモジュールがまだ負荷を共有できないため、必要以上のトラフィックを受信することがあります。 unit parallel-join`num_of_units` max-bundle-delay `max_delay_time` `num_of_units` ：モジュールがクラスタに参加する前に準備する必要がある同じシャーシ内のモジュールの最小数（1 ～ 3）を指定します。デフォルトは 1 です。つまり、モジュールは他のモジュールの準備完了を待たずに、クラスタに参加することを意味します。たとえば、値を 3 に設定した場合、各モジュールは `max_delay_time` の間、または 3 つすべてのモジュールの準備が完了するまで待機してからクラスタに参加します。3 のすべてのモジュールがほぼ同時にクラスタの参加を要求し、同時期にトラフィックの受信を開始します。 `max_delay_time` ：最大遅延時間を分単位（0 ～ 30 分）で指定します。この時間が経過すると、モジュールは他のモジュールの準備が完了するのを待つことをやめて、クラスタに参加します。デフォルトは 0 です。つまり、モジュールは他のモジュールの準備完了を待たずに、クラスタに参加することを意味します。`num_of_units` を 1 に設定した場合、この値は 0 にする必要があります。`num_of_units` を 2 または 3 に設定した場合、この値は 1 以上にする必要があります。このタイマーはモジュールごとのタイマーですが、最初のモジュールがクラスタに参加すると、その他すべてのモジュールのタイマーが終了し、残りのモジュールがクラスタに参加します。たとえば、`num_of_units` を 3、`max_delay_time` を 5 分に設定します。モジュール 1 が起動すると、その 5 分間のタイマーが開始されます。モジュール 2 が 2 分後に起動すると、その 5 分間のタイマーが開始されます。モジュール 3 が 1 分後に起動し、すべてのモジュールが 4 分符号でクラスタに参加します。モジュールはタイマーが完了するまで待機しません。モジュール 3 が起動しない場合、モジュール 1 は 5 分間タイマーの終了時にクラスタに参加し、モジュール 2 も参加します。モジュール 2 はタイマーがまだ 2 分残っていますが、タイマーが完了するまで待機しません。

のヘルスモニタリングおよび自動再結合の設定

この手順では、ユニットとインターフェイスのヘルスモニタリングを設定します。

たとえば、管理インターフェイスなど、必須以外のインターフェイスのヘルスモニタリングをディセーブルにすることができます。ポートチャネル ID、または単一の物理インターフェイス ID をモニタできます。ヘルスモニタリングは VLAN サブインターフェイス、または VNI　や BVI などの仮想インターフェイスでは実行されません。クラスタ制御リンクのモニタリングは設定できません。このリンクは常にモニタされています。

手順

ステップ 1	クラスタの設定モードを開始します。 cluster group `name`
ステップ 2	クラスタユニットのヘルスチェック機能を次のようにカスタマイズします。 health-check [holdtime `timeout`] holdime は、ユニットのハートビートステータスメッセージの間隔を指定します。指定できる範囲は .3 ～ 45 秒で、デフォルトは 3 秒です。ユニットのヘルスを確認するため、ASA のクラスタユニットはクラスタ制御リンクで他のユニットにハートビートメッセージを送信します。ユニットが保留時間内にピアユニットからハートビートメッセージを受信しない場合は、そのピアユニットは応答不能またはデッド状態と見なされます。何らかのトポロジ変更（たとえばデータインターフェイスの追加/削除、ASA、Firepower 4100/9300 シャーシ、またはスイッチ上のインターフェイスの有効化/無効化、VSS または vPC を形成するスイッチの追加）を行うときには、ヘルスチェック機能を無効にし、無効化したインターフェイスのモニタリングも無効にしてください（no health-check monitor-interface ）。トポロジの変更が完了して、コンフィギュレーション変更がすべてのユニットに同期されたら、ヘルスチェック機能を再度イネーブルにできます。例: `ciscoasa(cfg-cluster)# health-check holdtime 5`
ステップ 3	インターフェイスでインターフェイスヘルスチェックを次のように無効化します。 no health-check monitor-interface [`interface_id` \| service-application] インターフェイスのヘルスチェックはリンク障害をモニタします。特定の論理インターフェイスのすべての物理ポートが、特定のユニット上では障害が発生したが、別のユニット上の同じ論理インターフェイスでアクティブポートがある場合、そのユニットはクラスタから削除されます。ASA がメンバをクラスタから削除するまでの時間は、インターフェイスのタイプと、そのユニットが確立済みメンバであるか、またはクラスタに参加しようとしているかによって異なります。デフォルトでは、ヘルスチェックはすべてのインターフェイスでイネーブルになっています。このコマンドの no 形式を使用してディセーブルにすることができます。たとえば、管理インターフェイスなど、必須以外のインターフェイスのヘルスモニタリングをディセーブルにすることができます。ヘルスモニタリングは VLAN サブインターフェイス、または VNI　や BVI などの仮想インターフェイスでは実行されません。クラスタ制御リンクのモニタリングは設定できません。このリンクは常にモニタされています。service-application を指定して、デコレータアプリケーションのモニタリングをディセーブルにします。何らかのトポロジ変更（たとえばデータインターフェイスの追加/削除、ASA、Firepower 4100/9300 シャーシ、またはスイッチ上のインターフェイスの有効化/無効化、VSS または vPC を形成するスイッチの追加）を行うときには、ヘルスチェック機能（no health-check ）を無効にし、無効化したインターフェイスのモニタリングも無効にしてください。トポロジの変更が完了して、コンフィギュレーション変更がすべてのユニットに同期されたら、ヘルスチェック機能を再度イネーブルにできます。例: `ciscoasa(cfg-cluster)# no health-check monitor-interface port-channel1`
ステップ 4	ヘルスチェック失敗後の自動再結合クラスタ設定を次のようにカスタマイズします。 health-check {data-interface \| cluster-interface \| system} auto-rejoin [unlimited \| `auto_rejoin_max`] `auto_rejoin_interval auto_rejoin_interval_variation` system ：内部エラー時の自動再結合の設定を行います。内部の障害には、アプリケーション同期のタイムアウト、矛盾したアプリケーションステータスなどがあります。 unlimited ：（cluster-interface のデフォルト）再結合の試行回数を制限しません。 `auto-rejoin-max` ：再結合の試行回数を 0 ～ 65535 の範囲の値に設定します。0 は自動再結合を無効化します。data-interface と system のデフォルトは 3 です。 `auto_rejoin_interval` ：再結合試行の間隔を 2 ～ 60 の範囲の分単位で定義します。デフォルト値は 5 分です。クラスタへの再結合をユニットが試行する最大合計時間は、最後の失敗から 14,400 分に限られています。 `auto_rejoin_interval_variation` ：間隔を増加させるかどうかを定義します。1 ～ 3 の範囲で値を設定します（1 ：変更なし、2 ：直前の間隔の 2 倍、3 ：直前の間隔の 3 倍）。たとえば、間隔を 5 分に設定し、変分を 2 に設定した場合は、最初の試行が 5 分後、2 回目の試行が 10 分後（2 x 5）、3 階目の試行が 20 分後（2 x 10）となります。デフォルト値は、クラスタインターフェイスの場合は 1 、データインターフェイスおよびシステムの場合は 2 です。例: `ciscoasa(cfg-cluster)# health-check data-interface auto-rejoin 10 3 3`
ステップ 5	ASA がインターフェイスを障害が発生していると見なし、クラスタからユニットが削除されるまでのデバウンス時間を設定します。 health-check monitor-interface debounce-time `ms` デバウンス時間は 300 ～ 9000 ms の範囲の値を設定します。デフォルトは 500 ms です。値を小さくすると、インターフェイスの障害をより迅速に検出できます。デバウンス時間を短くすると、誤検出の可能性が高くなることに注意してください。インターフェイスのステータス更新が発生すると、ASA はインターフェイスを障害としてマークし、クラスタからユニットを削除するまで指定されたミリ秒数待機します。ダウン状態から稼働状態に移行している EtherChannel の場合（スイッチがリロードされた、またはスイッチが有効になっている EtherChannel など）、デバウンス時間を長くすることで、他のクラスタユニットの方がポートのバンドルが速いという理由だけで、クラスタユニット上でインターフェイスがエラー表示されるのを防ぐことができます。例: `ciscoasa(cfg-cluster)# health-check monitor-interface debounce-time 300`
ステップ 6	シャーシのヘルスチェック間隔を設定します。 app-agent heartbeat [ interval `ms`] [ retry-count `number`] interval `ms` ：ハートビートの時間間隔を 100 ～ 6000 ms の範囲の 100 の倍数単位で設定します。デフォルトは 1000 ms です。 retry-count `number` ：再試行の回数を 1 ～ 30 の範囲の値に設定します。デフォルトの試行回数は 3 回です。 ASA はホストの Firepower シャーシとのバックプレーンを介して通信できるかどうかをチェックします。最小の結合時間（interval x retry-count）は、600 ミリ秒未満にすることはできません。たとえば、間隔を 100 に、再試行回数を 3 に設定した場合、合計結合時間は 300 ミリ秒になりますが、これはサポートされていません。たとえば、間隔を 100 に設定し、再試行回数を 6 に設定して最小時間（600 ms）を満たすことができます。例: `ciscoasa(cfg-cluster)# app-agent heartbeat interval 300`

接続の再分散およびクラスタ TCP 複製の遅延の設定

接続の再分散を設定できます。 TCP 接続のクラスタ複製の遅延を有効化して、ディレクタ/バックアップフロー作成の遅延による存続期間が短いフローに関連する「不要な作業」を排除できます。ディレクタ/バックアップフローが作成される前にユニットが失敗する場合は、それらのフローを回復することはできません。同様に、フローを作成する前にトラフィックが別のユニットに再調整される場合、流れを回復することはできません。TCP のランダム化を無効化するトラフィックの TCP の複製の遅延を有効化しないようにする必要があります。

手順

ステップ 1

クラスタの設定モードを開始します。

cluster group name

ステップ 2

（オプション）TCP トラフィックの接続の再分散を有効化します。

conn-rebalance [frequency seconds]

例:


ciscoasa(cfg-cluster)# conn-rebalance frequency 60

このコマンドは、デフォルトでディセーブルになっています。有効化されている場合は、ASA は負荷情報を定期的に交換し、新しい接続の負荷を高負荷のデバイスから低負荷のデバイスに移動します。負荷情報を交換する間隔を、1 ～ 360 秒の範囲内で指定します。デフォルトは 5 秒です。

サイト間トポロジに対しては接続の再分散を設定しないでください。異なるサイトのクラスタメンバには接続を再分散できません。

ステップ 3

TCP 接続のクラスタ複製の遅延を有効化します。

cluster replication delay seconds { http | match tcp {host ip_address | ip_address mask | any | any4 | any6} [{eq | lt | gt} port] { host ip_address | ip_address mask | any | any4 | any6} [{eq | lt | gt} port]}

例:


ciscoasa(config)# cluster replication delay 15 match tcp any any eq ftp
ciscoasa(config)# cluster replication delay 15 http

1 ～ 15 の範囲で秒数 を設定します。http 遅延はデフォルトで 5 秒間有効になります。

サイト間機能の設定

サイト間クラスタリングの場合、冗長性と安定性を高めるために、設定をカスタマイズできます。

ディレクタローカリゼーションの有効化

データセンターのサイト間クラスタリングのパフォーマンスを向上させ、ラウンドトリップ時間を短縮するために、ディレクターローカリゼーションをイネーブルにすることができます。通常、新しい接続は特定のサイト内のクラスタメンバーによってロードバランスされ、所有されています。しかし、ASA は任意のサイトのメンバーにディレクタロールを割り当てます。ディレクタローカリゼーションにより、所有者と同じサイトのローカルディレクタ、どのサイトにも存在可能なグローバルディレクタという追加のディレクタロールが有効になります。所有者とディレクタが同一サイトに存在すると、パフォーマンスが向上します。また、元の所有者が失敗した場合、ローカルなディレクタは同じサイトで新しい接続の所有者を選択します。グローバルなディレクタは、クラスタメンバーが別のサイトで所有される接続のパケットを受信する場合に使用されます。

始める前に

Firepower 4100/9300 シャーシスーパバイザ上のシャーシのサイト ID を設定します。
次のトラフィックタイプは、ローカリゼーションをサポートしていません：NAT および PAT トラフィック、SCTP 検査されたトラフィック、フラグメンテーション所有クエリ。

手順

ステップ 1

クラスタの設定モードを開始します。

cluster group name

例:


ciscoasa(config)# cluster group cluster1
ciscoasa(cfg-cluster)#

ステップ 2

次のようにディレクタローカリゼーションをイネーブルにします。

director-localization

サイト冗長性の有効化

サイトの障害からフローを保護するために、サイトの冗長性を有効にできます。接続バックアップオーナーがオーナーと同じサイトにある場合は、サイトの障害からフローを保護するために、追加のバックアップオーナーが別のサイトから選択されます。

始める前に

Firepower 4100/9300 シャーシスーパバイザ上のシャーシのサイト ID を設定します。

手順

ステップ 1

クラスタの設定モードを開始します。

cluster group name

例:


ciscoasa(config)# cluster group cluster1
ciscoasa(cfg-cluster)#

ステップ 2

サイトの冗長性を有効にします。

site-redundancy

サイトごとの Gratuitous ARP の設定

ASA では、Gratuitous ARP（GARP）パケットを生成してスイッチングインフラストラクチャを常に最新の状態に保ちます。各サイトの優先順位値が最も高いメンバによって、グローバル MAC/IP アドレスの GARP トラフィックが定期的に生成されます。

クラスタから送信されたサイトごとの MAC および IP アドレスとパケットがサイト固有の MAC アドレスおよび IP アドレスを使用するのに対し、クラスタで受信したパケットは、グローバル MAC アドレスおよび IP アドレスを使用します。トラフィックがグローバル MAC アドレスから定期的に生成されない場合、グローバル MAC アドレスのスイッチで MAC アドレスのタイムアウトが発生する可能性があります。タイムアウト後にグローバル MAC アドレスへのトラフィックがスイッチングインフラストラクチャ全体にわたりフラッディングされ、これによりパフォーマンスおよびセキュリティ上の問題が発生することがあります。

各スパンド EtherChannel のユニットおよびサイト MAC アドレスごとにサイト ID を設定すると、GARP がデフォルトで有効になります。GARP 間隔をカスタマイズするか、または GARP を無効にすることができます。

始める前に

ブートストラップ設定でクラスタメンバーのサイト ID を設定します。
マスターユニット設定では、スパンド EtherChannel のサイトごとの MAC アドレスを設定します。

手順

ステップ 1

クラスタの設定モードを開始します。

cluster group name

例:


ciscoasa(config)# cluster group cluster1
ciscoasa(cfg-cluster)#

ステップ 2

GARP 間隔をカスタマイズします。

site-periodic-garp interval seconds

seconds： GARP 生成の間隔を 1 ～ 1000000 秒間の秒単位で設定します。デフォルトは 290 秒です。

GARP を無効にするには、no site-periodic-garp interval を入力します。

例:


ciscoasa(cfg-cluster)# site-periodic-garp interval 500

クラスタフローモビリティの設定

LISP のトラフィックを検査して、サーバがサイト間を移動する時にフローモビリティを有効にできます。

LISP インスペクションについて

LISP トラフィックを検査することで、サイト間のフローのモビリティを有効にできます。

LISP について

VMware VMotion などのデータセンター仮想マシンのモビリティによって、サーバはクライアントへの接続を維持すると同時に、データセンター間を移動できます。このようなデータセンターサーバモビリティをサポートするには、サーバの移動時にサーバへの入力ルートをルータが更新できる必要があります。Cisco Locator/ID Separation Protocol（LISP）のアーキテクチャは、デバイス ID、つまりエンドポイント ID（EID）をその場所、つまりルーティングロケータ（RLOC）から 2 つの異なるナンバリングスペースに分離し、サーバの移行をクライアントに対して透過的にします。たとえば、サーバが新しい場所に移動し、クライアントがサーバにトラフィックを送信すると、ルータは新しい場所にトラフィックをリダイレクトします。

LISP では、LISP の出力トンネルルータ（ETR）、入力トンネルルータ（ITR）、ファーストホップルータ、マップリゾルバ（MR）、およびマップサーバ（MS）などのある一定のロールにおいてルータとサーバが必要です。サーバが別のルータに接続されていることをサーバのファーストホップルータが感知すると、そのルータは他のすべてのルータとデータベースを更新し、クライアントに接続されている ITR がトラフィックを代行受信してカプセル化し、新しいサーバの場所に送信できるようにします。

ASA LISP のサポート

ASA は LISP 自体を実行しませんが、場所の変更に関する LISP トラフィックを検査し、シームレスなクラスタリング操作のためにこの情報を使用できます。LISP の統合を行わない場合、サーバが新しいサイトに移動すると、トラフィックは元のフローオーナーの代わりに、新しいサイトで ASA クラスタメンバーになります。新しい ASA が古いサイトの ASA にトラフィックを転送した後、古い ASA は、サーバに到達するためにトラフィックを新しいサイトに送り返す必要があります。このトラフィックフローは最適ではなく、「トロンボーニング」または「ヘアピニング」と呼ばれます。

LISP 統合により、ASA クラスタメンバーは、最初のホップルータと ETR または ITR 間でやり取りされる LISP トラフィックを検査し、フローの所有者を新しいサイトに変更できます。

LISP のガイドライン

ASA クラスタメンバーは、サイトのファーストホップルータと ITR または ETR の間に存在している必要があります。ASA クラスタ自体を拡張セグメントのファーストホップルータにすることはできません。
完全分散されたフローのみがサポートされます。一元化されたフロー、半分散されたフロー、または個々のユニットに属しているフローは新しいオーナーに移動されません。半分散されたフローには SIP などのアプリケーションが含まれており、親フローとそのすべての子フローが同じ ASA によって所有されます。
クラスタはレイヤ 3 および 4 のフロー状態を移動させるだけです。一部のアプリケーションデータが失われる可能性があります。
短時間のフローまたはビジネスに不可欠でないフローの場合、オーナーの移動は有用でない可能性があります。インスペクションポリシーを設定するときに、この機能でサポートされるトラフィックのタイプを制御できます。また、フローモビリティを不可欠なトラフィックに制限する必要があります。

ASA LISP の実装

この機能には、複数の相互に関係する設定が含まれています（それらについてはすべてこの章で説明します）。

（任意）ホストまたはサーバ IP アドレスに基づく検査対象 EID の制限：ファーストホップルータは、ASA クラスタが関与していないホストまたはネットワークに EID 通知メッセージを送信する場合があります。このため、クラスタに関連するサーバまたはネットワークのみに EID を制限できます。たとえば、クラスタが 2 つのサイトのみに関与しているが、LISP が 3 つのサイトで実行されている場合は、クラスタに関与している 2 つのサイトに対してのみ EID を含める必要があります。
LISP トラフィックのインスペクション：ASAは、ファーストホップルータと ITR または ETR の間で送信される EID 通知メッセージにおいて、UDP ポート 4342 上の LISP トラフィックを検査します。ASA は、EID とサイト ID を関連付ける EID テーブルを保持します。たとえば、ファーストホップルータの送信元 IP アドレスと ITR または ETR の宛先アドレスで LISP トラフィックを検査する必要があります。LISP トラフィックにはディレクタが割り当てられておらず、LISP トラフィック自体はクラスタ状態の共有に参加しないことに注意してください。
指定されたトラフィックでのフローモビリティを有効にするサービスポリシー：ビジネスクリティカルなトラフィックでフローモビリティを有効にする必要があります。たとえば、フローモビリティを、HTTPS トラフィックのみに制限したり、特定のサーバとの間でやり取りされるトラフィックのみに制限したりできます。
サイト ID：ASAは、各クラスタユニットのサイト ID を使用して新しい所有者を特定します。
フローモビリティを有効にするクラスタレベルの設定：クラスタレベルでもフローモビリティを有効にする必要があります。このオン/オフの切り替えを使用することで、特定のクラスのトラフィックまたはアプリケーションに対してフローモビリティを簡単に有効または無効にできます。

LISP インスペクションの設定

LISP のトラフィックを検査して、サーバがサイト間を移動する時にフローモビリティを有効にできます。

始める前に

Firepower 4100/9300 シャーシスーパバイザ上のシャーシのサイト ID を設定します。
LISP のトラフィックはデフォルトインスペクショントラフィッククラスに含まれないため、この手順の一部として LISP のトラフィック用に別のクラスを設定する必要があります。

手順

ステップ 1	（任意） LISP インスペクションマップを設定して、IP アドレスに基づいて検査済みの EID を制限し、LISP の事前共有キーを設定します。拡張 ACL を作成します。宛先 IP アドレスのみが EID 組み込みアドレスと照合されます。 access list `eid_acl_name` extended permit ip `source_address mask destination_address mask` IPv4 ACL および IPv6 ACL のどちらにも対応しています。厳密な access-list extended の構文については、コマンドリファレンスを参照してください。 LISP インスペクションマップを作成し、パラメータモードに移行します。 policy-map type inspect lisp `inspect_map_name` parameters 作成した ACL を識別して、許可された EID を定義します。 allowed-eid access-list `eid_acl_name` ファーストホップルータまたは ITR/ETR は、ASA クラスタが関与していないホストまたはネットワークに EID 通知メッセージを送信することがあります。このため、クラスタに関連するサーバまたはネットワークのみに EID を制限できます。たとえば、クラスタが 2 つのサイトのみに関与しているが、LISP が 3 つのサイトで実行されている場合は、クラスタに関与している 2 つのサイトに対してのみ EID を含める必要があります。必要に応じて、事前共有キーを入力します。 validate-key `key` 例: `ciscoasa(config)# access-list TRACKED_EID_LISP extended permit ip any 10.10.10.0 255.255.255.0 ciscoasa(config)# policy-map type inspect lisp LISP_EID_INSPECT ciscoasa(config-pmap)# parameters ciscoasa(config-pmap-p)# allowed-eid access-list TRACKED_EID_LISP ciscoasa(config-pmap-p)# validate-key MadMaxShinyandChrome`
ステップ 2	ファーストホップルータとポート 4342 の ITR または ETR の間の UDP トラフィックの LISP インスペクションの設定。拡張 ACL を設定して LISP のトラフィックを特定します。 access list `inspect_acl_name` extended permit udp `source_address mask destination_address mask` eq 4342 UDP ポート 4342 を指定する必要があります。IPv4 ACL および IPv6 ACL のどちらにも対応しています。厳密な access-list extended の構文については、コマンドリファレンスを参照してください。 ACL のクラスマップを作成します。 class-map `inspect_class_name` match access-list `inspect_acl_name` ポリシーマップ、クラスマップを指定し、オプションの LISP インスペクションマップを使用してインスペクションを有効化し、サービスポリシーをインターフェイスに適用します（新規であれば）。 policy-map `policy_map_name` class `inspect_class_name` inspect lisp [`inspect_map_name`] service-policy `policy_map_name` {global \| interface `ifc_name`} 既存のサービスポリシーある場合は、既存のポリシーマップ名を指定します。デフォルトで、ASA には global_policy と呼ばれるグローバルポリシーが含まれているため、グローバルポリシーの名前を指定します。ポリシーをグローバルに適用しない場合は、インターフェイスごとに 1 つのサービスポリシーを作成することもできます。LISP インスペクションは、双方向にトラフィックに適用するため、送信元と宛先の両方のインターフェイスにサービスポリシーを適用する必要はありません。トラフィックが両方向のクラスマップに一致する場合、ポリシーマップを適用するインターフェイスに入るまたは存在するトラフィックのすべてが影響を受けます。例: `ciscoasa(config)# access-list LISP_ACL extended permit udp host 192.168.50.89 host 192.168.10.8 eq 4342 ciscoasa(config)# class-map LISP_CLASS ciscoasa(config-cmap)# match access-list LISP_ACL ciscoasa(config-cmap)# policy-map INSIDE_POLICY ciscoasa(config-pmap)# class LISP_CLASS ciscoasa(config-pmap-c)# inspect lisp LISP_EID_INSPECT ciscoasa(config)# service-policy INSIDE_POLICY interface inside` ASAは、ファーストホップルータと ITR または ETR の間で送信される EID 通知メッセージの LISP トラフィックを検査します。ASA は、EID とサイト ID を関連付ける EID テーブルを保持します。
ステップ 3	トラフィッククラスのフローモビリティを有効化します。拡張 ACL を設定して、サーバがサイトを変更するときに、最適なサイトに再割り当てするビジネスクリティカルなトラフィックを特定します。 access list `flow_acl_name` extended permit udp `source_address mask destination_address mask` eq `port` IPv4 ACL および IPv6 ACL のどちらにも対応しています。厳密な access-list extended の構文については、コマンドリファレンスを参照してください。フローモビリティは、ビジネスクリティカルなトラフィックに対してイネーブルにする必要があります。たとえば、フローモビリティを HTTPS トラフィックのみ、または特定のサーバへのトラフィックのみに制限できます。 ACL のクラスマップを作成します。 class-map `flow_map_name` match access-list `flow_acl_name` LISP インスペクションを有効化した同じポリシーマップ、フロークラスマップを指定して、フローモビリティを有効にします。 policy-map `policy_map_name` class `flow_map_name` cluster flow-mobility lisp 例: `ciscoasa(config)# access-list IMPORTANT-FLOWS extended permit tcp any 10.10.10.0 255.255.255.0 eq https ciscoasa(config)# class-map IMPORTANT-FLOWS-MAP ciscoasa(config)# match access-list IMPORTANT-FLOWS ciscoasa(config-cmap)# policy-map INSIDE_POLICY ciscoasa(config-pmap)# class IMPORTANT-FLOWS-MAP ciscoasa(config-pmap-c)# cluster flow-mobility lisp`
ステップ 4	クラスタグループコンフィギュレーションモードに移行し、クラスタのフローのモビリティを有効化します。 cluster group `name` flow-mobility lisp このオン/オフの切り替えにより、フローモビリティの有効化や無効化を簡単に行えます。

例

次に例を示します。

EID を 10.10.10.0/24 ネットワーク上の EID に制限します。
192.168.50.89（内部）にある LISP ルータと 192.168.10.8（別の ASA インターフェイス上）にある ITR または ETR ルータの間の LISP トラフィック（UDP 4342）を検査します。
HTTPS を使用して 10.10.10.0/24 のサーバに送信されるすべての内部トラフィックに対してフローモビリティを有効化します。
クラスタに対してフローモビリティをイネーブルにします。


access-list TRACKED_EID_LISP extended permit ip any 10.10.10.0 255.255.255.0
policy-map type inspect lisp LISP_EID_INSPECT
   parameters 
      allowed-eid access-list TRACKED_EID_LISP
      validate-key MadMaxShinyandChrome
!
access-list LISP_ACL extended permit udp host 192.168.50.89 host 192.168.10.8 eq 4342
class-map LISP_CLASS
   match access-list LISP_ACL
policy-map INSIDE_POLICY
   class LISP_CLASS
      inspect lisp LISP_EID_INSPECT
service-policy INSIDE_POLICY interface inside
!
access-list IMPORTANT-FLOWS extended permit tcp any 10.10.10.0 255.255.255.0 eq https
class-map IMPORTANT-FLOWS-MAP
   match access-list IMPORTANT-FLOWS
policy-map INSIDE_POLICY
   class IMPORTANT-FLOWS-MAP
      cluster flow-mobility lisp
!
cluster group cluster1
   flow-mobility lisp

分散型サイト間 VPN の設定

デフォルトでは、ASA クラスタは集中型サイト間 VPN モードを使用します。クラスタリングの拡張性を活用するために、分散型サイト間 VPN モードを有効にできます。このモードでは、S2S IPsec IKEv2 VPN 接続が ASA クラスタのメンバー全体に分散されます。クラスタのメンバー全体に VPN 接続を分散することで、クラスタの容量とスループットの両方を最大限に活用できるため、集中型 VPN の機能を超えて大幅に VPN サポートを拡張できます。

分散型サイト間 VPN について

分散型 VPN 接続の役割

分散型 VPN モードで実行すると、次の役割がクラスタメンバーに割り当てられます。

アクティブセッションオーナー：最初に接続を受信したユニット、またはバックアップセッションをアクティブセッションに移行したユニット。オーナーは、IKE と IPsec トンネル、およびそれらに関連付けられたすべてのトラフィックを含む、完全なセッションの状態を維持し、パケットを処理します。
バックアップセッションオーナー：既存のアクティブセッションのバックアップセッションを処理しているユニット。選択されたバックアップ戦略によっては、アクティブセッションオーナーと同じシャーシ内のユニット、または別のシャーシ内のユニットである可能性があります。アクティブセッションオーナーに障害が発生すると、バックアップセッションオーナーがアクティブセッションオーナーになり、新しいバックアップセッションが別のユニットで確立されます。
フォワーダ：VPN セッションに関連付けられたトラフィックが VPN セッションを所有していないユニットに送信された場合、そのユニットは VPN セッションを所有しているメンバーにトラフィックを転送するために Cluster Control Link（CCL）を使用します。
オーケストレータ：オーケストレータ（常にクラスタのマスターノード）は、アクティブセッションの再配布（ASR）を実行する際に、移動するセッションとその移動先を計算する役割があります。オーケストレータは、オーナーメンバー X に N セッションをメンバー Y に移動する要求を送信します。メンバー X は、完了時に移動できたセッション数を指定して、オーケストレータに応答を返します。

分散型 VPN セッションの特性

分散型 S2S VPN セッションには、次の特性があります。それ以外の場合、VPN 接続は、ASA クラスタ上にない場合に通常動作するように動作します。

VPN セッションは、セッションレベルでクラスタ全体に分散されます。つまり、1 つの VPN 接続に対し、同じクラスタメンバーが IKE および IPsec トンネルと、そのすべてのトラフィックを処理します。VPN セッショントラフィックが、その VPN セッションを所有していないクラスタメンバーに送信された場合、トラフィックは VPN セッションを所有しているクラスタメンバーに転送されます。
VPN セッションには、クラスタ全体で一意のセッション ID があります。セッション ID を使用して、トラフィックが検証され、転送の決定が行われ、IKE ネゴシエーションが完了します。
S2S VPN ハブアンドスポーク構成では、クライアントが ASA クラスタを介して接続する場合（ヘアピニングと呼ばれる）、流入するセッショントラフィックと流出するセッショントラフィックは、異なるクラスタメンバー上にある可能性があります。
バックアップセッションを別のシャーシのセキュリティモジュールに割り当てるように要求することができます。これにより、シャーシの障害を防止します。または、クラスタ内の任意のノードにバックアップセッションを割り当てることもできます。これはノードの障害のみを防止します。クラスタにシャーシが 2 つある場合は、リモートシャーシバックアップを強く推奨します。
分散型 S2S VPN モードでは IKEv2 IPsec S2S VPN のみがサポートされ、IKEv1 はサポートされていません。IKEv1 S2S は、集中型 VPN モードでサポートされています。
各セキュリティモジュールは、6 つのメンバーにわたる最大約 36,000 のセッションに対し、最大 6,000 の VPN セッションをサポートします。クラスタメンバーでサポートされる実際のセッション数は、プラットフォームの容量、割り当てられたライセンス、コンテキストごとのリソース割り当てによって決まります。使用率が制限値に近い場合、各クラスタユニットで最大容量に達していなくても、セッションの作成が失敗することがあります。これは、アクティブセッションの割り当てが外部スイッチングによって決定され、バックアップセッションの割り当てが内部クラスタアルゴリズムによって決定されるためです。顧客は、使用率を適宜調整し、不均一な配布に対するスペースを確保することが推奨されます。

クラスタイベントの分散型 VPN の処理

表 1.
イベント	分散型 VPN
メンバーの障害	この障害が発生したメンバー上のすべてのアクティブセッションに対し、（別のメンバー上の）バックアップセッションがアクティブになり、バックアップセッションはバックアップ戦略に従って別のユニットに再割り当てされます。
シャーシ障害	リモートシャーシバックアップ戦略が使用されている場合、障害が発生したシャーシ上のすべてのアクティブセッションに対し、（他のシャーシのメンバー上の）バックアップセッションがアクティブになります。ユニットが交換されると、これらの現在アクティブなセッションに対するバックアップセッションが、交換されたシャーシのメンバーに再割り当てされます。フラットバックアップ戦略が使用されている場合、アクティブセッションとバックアップセッションの両方が障害の発生したシャーシ上にあると、接続は切断されます。他のシャーシのメンバー上にバックアップセッションがあるアクティブセッションはすべて、これらのセッションにフォールバックします。新しいバックアップセッションは、残存しているシャーシ内の別のメンバーに割り当てられます。
クラスタメンバーの非アクティブ化	非アクティブになっているクラスタメンバー上のすべてのアクティブセッションに対し、（別のメンバー上の）バックアップセッションがアクティブになり、バックアップ戦略に従って別のユニットにバックアップセッションを再割り当てします。
クラスタメンバーの参加	VPN クラスタモードが分散型に設定されていない場合、マスターユニットはモード変更を要求します。 VPN モードに互換性がある場合、または以前互換性があった場合、クラスタメンバーには、通常の操作の流れでアクティブセッションとバックアップセッションが割り当てられます。

サポートされていないインスペクション

次のタイプの検査は、分散型 S2S VPN モードではサポートされていないか、または無効になっています。

CTIQBE
DCERPC
H323、H225、および RAS
IPSec パススルー
MGCP
MMP
NetBIOS
PPTP
RADIUS
RSH
RTSP
SCCP（Skinny）
SUNRPC
TFTP
WAAS
WCCP
XDMCP

IPsec IKEv2 の変更

IKEv2 は、分散型 S2S VPN モードでは次のように変更されます。

IP/ポートタプルの代わりに ID が使用されます。これにより、パケットの適切な転送の決定、および他のクラスタメンバー上にある可能性がある以前の接続のクリーンアップが可能になります。
単一の IKEv2 セッションを識別する（SPI）識別子は、ローカルで生成されたランダムな 8 バイトの値で、クラスタ全体で一意です。SPI には、タイムスタンプとクラスタメンバー ID が埋め込まれています。IKE ネゴシエーションパケットの受信時に、タイムスタンプまたはクラスタメンバー ID のチェックに失敗すると、パケットがドロップされ、理由を示すメッセージが記録されます。
NAT-T ネゴシエーションがクラスタメンバー間で分割されることによって失敗しないように IKEv2 処理が変更されました。新しい ASP 分類ドメインである cluster_isakmp_redirect、およびルールは、IKEv2 がインターフェイスで有効になっている場合に追加されます。show asp table classify domain cluster_isakmp_redirect コマンドを使用して、ルールを参照します。

サポートモデル

分散型 VPN でサポートされる唯一のデバイスは、Firepower 9300 です。分散型 VPN では、最大 2 シャーシで、最大 6 モジュールをサポートしています。各シャーシで異なる数のセキュリティモジュールを設置することができますが、均等な分配を推奨しています。

サイト間クラスタリングはサポートされていません。

ファイアウォールモード

分散型 S2S VPN は、ルーテッドモードでのみサポートされています。

コンテキストモード

分散型 S2S VPN は、シングルコンテキストモードおよびマルチコンテキストモードの両方で動作します。ただし、マルチコンテキストモードでは、アクティブセッションの再配布はコンテキストレベルではなくシステムレベルで行われます。これにより、コンテキストに関連付けられたアクティブセッションが、異なるコンテキストに関連付けられたアクティブセッションを含むクラスタメンバーに移動し、予期せずに持続不可能な負荷が発生するのを防ぎます。

ハイアベイラビリティ

次の機能により、セキュリティモジュールまたはシャーシの単一障害に対する復元力が提供されます。

任意のシャーシ上のクラスタ内にある別のセキュリティモジュールにバックアップされた VPN セッションは、セキュリティモジュールの障害に耐性があります。
別のシャーシにバックアップされた VPN セッションは、シャーシの障害に耐性があります。
クラスタマスターは、VPN S2S セッションを失うことなく変更できます。

クラスタが安定する前に追加の障害が発生すると、アクティブセッションとバックアップセッションの両方が障害の発生したユニットにある場合、接続が失われる可能性があります。

VPN クラスタモードの無効化、クラスタメンバーのリロード、およびその他の予想されるシャーシの変更など、メンバーが正常な状態でクラスタを離れるときにセッションが失われないように、すべての試行が行われます。これらのタイプの操作では、操作間でセッションのバックアップを再確立する時間がクラスタに与えられている限り、セッションは失われません。最後のクラスタメンバーで正常な終了がトリガーされた場合、既存のセッションが正常に切断されます。

ダイナミック PAT

分散型 VPN モードでは使用できません。

CMPv2

CMPv2 ID 証明書とキーペアはクラスタメンバー間で同期されます。ただし、クラスタ内のマスターのみが CMPv2 証明書を自動的に更新してキーの再生成を行います。マスターは更新時に、これらの新しい ID 証明書とキーをすべてのクラスタメンバーに同期させます。このようにして、クラスタ内のすべてのメンバーは CMPv2 証明書を利用して認証を行い、また、すべてのメンバーがマスターを継承することができます。

分散型 S2S VPN の有効化

分散型サイト間 VPN を有効にして、VPN セッションのクラスタリングの拡張性を活用します。

（注）

VPN モードを集中型と分散型の間で変更すると、既存のすべてのセッションが切断されます。バックアップモードの変更は動的で、セッションは終了しません。

始める前に

クラスタのすべてのメンバーにキャリアライセンスが設定されている必要があります。
S2S VPN 設定を行う必要があります。

手順

ステップ 1

クラスタのマスターユニットで、クラスタコンフィギュレーションモードを開始します。

cluster group name

例:


ciscoasa(config)# cluster group cluster1
ciscoasa(cfg-cluster)#

ステップ 2

分散型 S2S VPN を有効にします。

vpn-mode distributed backup flat

または

vpn-mode distributed backup remote-chassis

フラットバックアップモードでは、他のクラスタメンバーにスタンバイセッションが確立されます。これにより、ユーザはブレード障害から保護されますが、シャーシ障害の保護は保証されません。

リモートシャーシバックアップモードでは、クラスタ内の別のシャーシのメンバーにスタンバイセッションが確立されます。これにより、ユーザはブレード障害とシャーシ障害の両方から保護されます。

リモートシャーシが単一のシャーシ環境（意図的に構成されたものまたは障害の結果）で構成されている場合、別のシャーシが結合されるまでバックアップは作成されません。

例:


ciscoasa(cfg-cluster)# vpn-mode distributed backup remote-chassis

分散型 S2S VPN セッションの再配布

アクティブセッションの再配布（ASR）では、アクティブな VPN セッションの負荷がクラスタメンバー全体に再配布されます。セッションの開始と終了の動的な性質のため、ASR は、すべてのクラスタメンバー間でセッションのバランスを取るためのベストエフォートです。繰り返される再配布アクションによってバランスが最適化されます。

再配布はいつでも実行でき、クラスタ内のトポロジ変更後に実行する必要があります。また、新しいメンバーがクラスタに参加した後に実行することを推奨します。再配布の目的は、安定した VPN クラスタを作成することです。安定した VPN クラスタには、ノード間でほぼ同数のアクティブセッションとバックアップセッションがあります。

セッションを移動するには、バックアップセッションがアクティブセッションになり、別のノードが新しいバックアップセッションをホストするように選択されます。移動セッションは、アクティブセッションのバックアップの場所と、その特定のバックアップノード上にすでに存在するアクティブセッションの数に依存します。何らかの理由でバックアップセッションノードがアクティブセッションをホストできない場合、元のノードはセッションのオーナーのままです。

マルチコンテキストモードでは、アクティブセッションの再配布は、個々のコンテキストレベルではなくシステムレベルで行われます。コンテキストレベルで実行されない理由は、あるコンテキスト内のアクティブセッションが別のコンテキスト内のより多くのアクティブセッションを含むメンバーに移動され、そのクラスタメンバーに多くの負荷がかかるためです。

始める前に

再配布アクティビティをモニタする場合は、システムログを有効にします。
この手順は、クラスタのマスターノードで実行する必要があります。

手順

ステップ 1

クラスタ内のマスターノードで show cluster vpn-sessiondb distribution コマンドを実行して、アクティブセッションとバックアップセッションがクラスタ全体でどのように配布されているかを確認します。

例:

配布情報は次のように表示されます。

Member 0 (unit-1-1): active: 209; backups at: 1(111), 2(98)
Member 1 (unit-1-3): active: 204; backups at: 0(108), 2(96)
Member 2 (unit-1-2): active: 0

各行には、メンバー ID、メンバー名、アクティブセッション数、およびバックアップセッションが存在するメンバーが含まれています。上記の例では、次のように情報が読み取れます。

メンバー 0 には 209 のアクティブセッションがあり、111 のセッションはメンバー 1 にバックアップされ、98 のセッションはメンバー 2 にバックアップされます。
メンバー 1 には 204 のアクティブセッションがあり、108 のセッションはメンバー 0 にバックアップされ、96 のセッションはメンバー 2 にバックアップされます。
メンバー 2 にはアクティブセッションがないため、クラスタメンバーはこのノードのセッションをバックアップしていません。このメンバーは最近クラスタに参加しました。

ステップ 2

cluster redistribute vpn-sessiondb コマンドを実行します。

このコマンドは、バックグラウンドで実行中に即座に戻ります（メッセージなしで）。

再配布するセッションの数とクラスタの負荷に応じて、これには時間がかかることがあります。再配布アクティビティが発生すると、次のフレーズ（およびここには表示されていない他のシステムの詳細）を含む Syslog が提供されます。


Syslog フレーズ	注
VPN session redistribution started	マスターのみ
Sent request to move `number` sessions from `orig-member-name` to `dest-member-name`	マスターのみ
Failed to send session redistribution message to member-name	マスターのみ
Received request to move `number` sessions from `orig-member-name` to `dest-member-name`	スレーブのみ
Moved `number` sessions to `member-name`	名前付きクラスタに移動したアクティブセッションの数。
Failed to receive session move response from `dest-member-name`	マスターのみ
VPN session completed	マスターのみ
Cluster topology change detected. VPN session redistribution aborted.

ステップ 3

show cluster vpn distribution の出力を使用して、再配布アクティビティの結果を確認します。

FXOS：クラスタメンバの削除

ここでは、メンバを一時的に、またはクラスタから永続的に削除する方法について説明します。

一時的な削除

たとえば、ハードウェアまたはネットワークの障害が原因で、クラスタメンバはクラスタから自動的に削除されます。この削除は、条件が修正されるまでの一時的なものであるため、クラスタに再参加できます。また、手動でクラスタリングを無効にすることもできます。

デバイスが現在クラスタ内にあるかどうかを確認するには、show cluster info コマンドを使用してアプリケーション内のクラスタステータスを確認します。


ciscoasa# show cluster info
Clustering is not enabled

アプリケーションでのクラスタリングの無効化：アプリケーション CLI を使用してクラスタリングを無効にすることができます。cluster remove unit name コマンドを入力して、ログインしているユニット以外のすべてのユニットを削除します。ブートストラップコンフィギュレーションは変更されず、マスターユニットから最後に同期されたコンフィギュレーションもそのままであるので、コンフィギュレーションを失わずに後でそのユニットを再度追加できます。マスターユニットを削除するためにスレーブユニットでこのコマンドを入力した場合は、新しいマスターユニットが選定されます。

デバイスが非アクティブになると、すべてのデータインターフェイスがシャットダウンされます。管理専用インターフェイスのみがトラフィックを送受信できます。トラフィックフローを再開するには、クラスタリングを再度有効にします。管理インターフェイスは、そのユニットがブートストラップ設定から受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードしてもユニットがクラスタ内でまだアクティブではない場合（クラスタリングが無効な状態で設定を保存した場合など）、管理インターフェイスは無効になります。

クラスタリングを再度有効にするには、ASA で cluster group name を入力してから enable を入力します。

アプリケーションインスタンスの無効化：FXOS CLI で、次の例を参照してください。


Firepower-chassis# scope ssa
Firepower-chassis /ssa # scope slot 1
Firepower-chassis /ssa/slot # scope app-instance asa asa1
Firepower-chassis /ssa/slot/app-instance # disable
Firepower-chassis /ssa/slot/app-instance* # commit-buffer
Firepower-chassis /ssa/slot/app-instance #

再度有効にするには、次の手順を実行します。


Firepower-chassis /ssa/slot/app-instance # enable
Firepower-chassis /ssa/slot/app-instance* # commit-buffer
Firepower-chassis /ssa/slot/app-instance #

セキュリティモジュール/エンジンのシャットダウン：FXOS CLI で、次の例を参照してください。


Firepower-chassis# scope service-profile server 1/1
Firepower-chassis /org/service-profile # power down soft-shut-down
Firepower-chassis /org/service-profile* # commit-buffer
Firepower-chassis /org/service-profile #

電源を投入するには、次の手順を実行します。


Firepower-chassis /org/service-profile # power up
Firepower-chassis /org/service-profile* # commit-buffer
Firepower-chassis /org/service-profile #

シャーシのシャットダウン：FXOS CLI で、次の例を参照してください。
```
Firepower-chassis# scope chassis 1
Firepower-chassis /chassis # shutdown no-prompt
```

完全な削除

次の方法を使用して、クラスタメンバを完全に削除できます。

論理デバイスの削除：FXOS CLI で、次の例を参照してください。


Firepower-chassis# scope ssa
Firepower-chassis /ssa # delete logical-device cluster1
Firepower-chassis /ssa* # commit-buffer
Firepower-chassis /ssa #

サービスからのシャーシまたはセキュリティモジュールの削除：サービスからデバイスを削除する場合は、交換用ハードウェアをクラスタの新しいメンバーとして追加できます。

ASA：クラスタメンバの管理

クラスタを導入した後は、コンフィギュレーションを変更し、クラスタメンバを管理できます。

非アクティブなメンバーになる

クラスタの非アクティブなメンバーになるには、クラスタリングコンフィギュレーションは変更せずに、そのユニット上でクラスタリングをディセーブルにします。

（注）

ASA が（手動で、またはヘルスチェックエラーにより）非アクティブになると、すべてのデータインターフェイスがシャットダウンされます。管理専用インターフェイスのみがトラフィックを送受信できます。トラフィックフローを再開させるには、クラスタリングを再びイネーブルにします。または、そのユニットをクラスタから完全に削除します。管理インターフェイスは、そのユニットがクラスタ IP プールから受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードしてもユニットがクラスタ内でまだアクティブではない場合（クラスタリングが無効な状態で設定を保存した場合など）、管理インターフェイスは無効になります。それ以降のコンフィギュレーション作業には、コンソールポートを使用する必要があります。

始める前に

コンソールポートを使用する必要があります。クラスタリングのイネーブルまたはディセーブルを、リモート CLI 接続から行うことはできません。
マルチコンテキストモードの場合は、この手順をシステム実行スペースで実行します。まだシステムコンフィギュレーションモードに入っていない場合は、changeto system コマンドを入力します。

手順

ステップ 1

クラスタの設定モードを開始します。

cluster group name

例:


ciscoasa(config)# cluster group pod1

ステップ 2

クラスタリングをディセーブルにします。

no enable

このユニットがマスターユニットであった場合は、新しいマスターの選定が実行され、別のメンバがマスターユニットになります。

クラスタコンフィギュレーションは維持されるので、後でクラスタリングを再度イネーブルにできます。

メンバーの非アクティブ化

ログインしているユニット以外のメンバを非アクティブにするには、次のステップを実行します。

（注）

ASA が非アクティブになると、すべてのデータインターフェイスがシャットダウンされます。管理専用インターフェイスのみがトラフィックを送受信できます。トラフィックフローを再開するには、クラスタリングを再度有効にします。管理インターフェイスは、そのユニットがクラスタ IP プールから受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードしてもユニットがクラスタ内でまだアクティブではない場合（クラスタリングが無効な状態で設定を保存した場合など）、管理インターフェイスは無効になります。それ以降のコンフィギュレーション作業には、コンソールポートを使用する必要があります。

始める前に

マルチコンテキストモードの場合は、この手順をシステム実行スペースで実行します。まだシステムコンフィギュレーションモードに入っていない場合は、changeto system コマンドを入力します。

手順

ユニットをクラスタから削除します。

cluster remove unit unit_name

ブートストラップコンフィギュレーションは変更されず、マスターユニットから最後に同期されたコンフィギュレーションもそのままになるので、コンフィギュレーションを失わずに後でそのユニットを再度追加できます。マスターユニットを削除するためにスレーブユニットでこのコマンドを入力した場合は、新しいマスターユニットが選定されます。

メンバ名を一覧表示するには、cluster remove unit ? と入力するか、show cluster info コマンドを入力します。

例:


ciscoasa(config)# cluster remove unit ?

Current active units in the cluster:
asa2

ciscoasa(config)# cluster remove unit asa2
WARNING: Clustering will be disabled on unit asa2. To bring it back
to the cluster please logon to that unit and re-enable clustering

クラスタへの再参加

ユニットがクラスタから削除された場合（たとえば、障害が発生したインターフェイスの場合、またはメンバーを手動で非アクティブにした場合）は、クラスタに手動で再参加する必要があります。

始める前に

クラスタリングを再イネーブルにするには、コンソールポートを使用する必要があります。他のインターフェイスはシャットダウンされます。
マルチコンテキストモードの場合は、この手順をシステム実行スペースで実行します。まだシステムコンフィギュレーションモードに入っていない場合は、changeto system コマンドを入力します。
クラスタへの再参加を試行する前に、障害が解決されていることを確認します。

手順

ステップ 1

コンソールで、クラスタコンフィギュレーションモードを開始します。

cluster group name

例:


ciscoasa(config)# cluster group pod1

ステップ 2

クラスタリングをイネーブルにします。

enable

マスターユニットの変更

注意	マスターユニットを変更する最良の方法は、マスターユニットでクラスタリングを無効にし、新しいマスターの選択を待ってから、クラスタリングを再度有効にする方法です。マスターにするユニットを厳密に指定する必要がある場合は、この項の手順を使用します。ただし、中央集中型機能の場合は、この手順を使用してマスターユニット変更を強制するとすべての接続がドロップされるので、新しいマスターユニット上で接続を再確立する必要があります。

マスターユニットを変更するには、次の手順を実行します。

始める前に

手順

新しいユニットをマスターユニットとして設定します。

cluster master unit unit_name

例:


ciscoasa(config)# cluster master unit asa2

メインクラスタ IP アドレスへの再接続が必要になります。

メンバ名を一覧表示するには、cluster master unit ? （現在のユニットを除くすべての名前が表示される）と入力するか、show cluster info コマンドを入力します。

クラスタ全体でのコマンドの実行

コマンドをクラスタ内のすべてのメンバに、または特定のメンバに送信するには、次の手順を実行します。show コマンドをすべてのメンバーに送信すると、すべての出力が収集されて現在のユニットのコンソールに表示されます。（または、マスターユニットで show コマンドを入力するとクラスタ全体の統計情報を表示できます。）capture や copy などのその他のコマンドも、クラスタ全体での実行を活用できます。

手順

コマンドをすべてのメンバに送信します。ユニット名を指定した場合は、特定のメンバに送信されます。

cluster exec [unit unit_name] コマンド

例:


ciscoasa# cluster exec show xlate

メンバー名を表示するには、cluster exec unit ? コマンドを入力するか（現在のユニットを除くすべての名前を表示する場合）、show cluster info コマンドを入力します。

例

同じキャプチャファイルをクラスタ内のすべてのユニットから同時に TFTP サーバにコピーするには、マスターユニットで次のコマンドを入力します。


ciscoasa# cluster exec copy /pcap capture: tftp://10.1.1.56/capture1.pcap

複数の PCAP ファイル（各ユニットから 1 つずつ）が TFTP サーバにコピーされます。宛先のキャプチャファイル名には自動的にユニット名が付加され、capture1_asa1.pcap、capture1_asa2.pcap などとなります。この例では、asa1 および asa2 がクラスタユニット名です。

次の cluster exec show memory コマンドの出力例では、クラスタの各メンバーのメモリ情報が表示されています。


ciscoasa# cluster exec show memory
unit-1-1(LOCAL):******************************************************
Free memory:      108724634538 bytes (92%)
Used memory:        9410087158 bytes ( 8%)
-------------     ------------------
Total memory:     118111600640 bytes (100%)


unit-1-3:*************************************************************
Free memory:      108749922170 bytes (92%)
Used memory:        9371097334 bytes ( 8%)
-------------     ------------------
Total memory:     118111600640 bytes (100%)


unit-1-2:*************************************************************
Free memory:      108426753537 bytes (92%)
Used memory:        9697869087 bytes ( 8%)
-------------     ------------------
Total memory:     118111600640 bytes (100%)

ASA：での ASA クラスタのモニタリング Firepower 4100/9300 シャーシ

クラスタの状態と接続をモニタおよびトラブルシューティングできます。

クラスタステータスのモニタリング

クラスタの状態のモニタリングについては、次のコマンドを参照してください。

show cluster info [health], show cluster chassis info

キーワードを指定しないで show cluster info コマンドを実行すると、クラスタ内のすべてのメンバーのステータスが表示されます。

show cluster info health コマンドは、インターフェイス、ユニットおよびクラスタ全体の現在の状態を表示します。

show cluster info コマンドの次の出力を参照してください。



asa(config)# show cluster info
Cluster cluster1: On
    Interface mode: spanned
    This is "unit-1-2" in state MASTER
        ID        : 2
        Version   : 9.5(2)
        Serial No.: FCH183770GD
        CCL IP    : 127.2.1.2
        CCL MAC   : 0015.c500.019f
        Last join : 01:18:34 UTC Nov 4 2015
        Last leave: N/A
Other members in the cluster:
    Unit "unit-1-3" in state SLAVE
        ID        : 4
        Version   : 9.5(2)
        Serial No.: FCH19057ML0
        CCL IP    : 127.2.1.3
        CCL MAC   : 0015.c500.018f
        Last join : 20:29:57 UTC Nov 4 2015
        Last leave: 20:24:55 UTC Nov 4 2015
    Unit "unit-1-1" in state SLAVE
        ID        : 1
        Version   : 9.5(2)
        Serial No.: FCH19057ML0
        CCL IP    : 127.2.1.1
        CCL MAC   : 0015.c500.017f
        Last join : 20:20:53 UTC Nov 4 2015
        Last leave: 20:18:15 UTC Nov 4 2015
    Unit "unit-2-1" in state SLAVE
        ID        : 3
        Version   : 9.5(2)
        Serial No.: FCH19057ML0
        CCL IP    : 127.2.2.1
        CCL MAC   : 0015.c500.020f
        Last join : 20:19:57 UTC Nov 4 2015
        Last leave: 20:24:55 UTC Nov 4 2015

show cluster info auto-join

時間遅延後にクラスタユニットがクラスタに自動的に再参加するかどうか、および障害状態（ライセンスの待機やシャーシのヘルスチェック障害など）がクリアされたかどうかを示します。ユニットが永続的に無効になっている場合、またはユニットがすでにクラスタ内にある場合、このコマンドでは出力が表示されません。

show cluster info auto-join コマンドについては次の出力を参照してください。


ciscoasa(cfg-cluster)# show cluster info auto-join
Unit will try to join cluster in 253 seconds.
Quit reason: Received control message DISABLE
 
ciscoasa(cfg-cluster)# show cluster info auto-join       
Unit will try to join cluster when quit reason is cleared.
Quit reason: Master has application down that slave has up.
 
ciscoasa(cfg-cluster)# show cluster info auto-join        
Unit will try to join cluster when quit reason is cleared.
Quit reason: Chassis-blade health check failed.
 
ciscoasa(cfg-cluster)# show cluster info auto-join        
Unit will try to join cluster when quit reason is cleared.
Quit reason: Service chain application became down.
 
ciscoasa(cfg-cluster)# show cluster info auto-join
Unit will try to join cluster when quit reason is cleared.
Quit reason: Unit is kicked out from cluster because of Application health check failure.
 
ciscoasa(cfg-cluster)# show cluster info auto-join
Unit join is pending (waiting for the smart license entitlement: ent1)
 
ciscoasa(cfg-cluster)# show cluster info auto-join
Unit join is pending (waiting for the smart license export control flag)

show cluster info transport{asp |cp[detail]}

次のトランスポート関連の統計情報を表示します。

asp：データプレーンのトランスポート統計情報。

cp：コントロールプレーンのトランスポート統計情報。

detail キーワードを入力すると、クラスタで信頼性の高いトランスポートプロトコルの使用状況が表示され、バッファがコントロールプレーンでいっぱいになったときにパケットドロップの問題を特定できます。show cluster info transport cp detail コマンドについては次の出力を参照してください。


ciscoasa# show cluster info transport cp detail
Member ID to name mapping: 
  0 - unit-1-1   2 - unit-4-1   3 - unit-2-1 

Legend:
  U    - unreliable messages
  UE   - unreliable messages error
  SN   - sequence number
  ESN  - expecting sequence number
  R    - reliable messages
  RE   - reliable messages error
  RDC  - reliable message deliveries confirmed
  RA   - reliable ack packets received
  RFR  - reliable fast retransmits
  RTR  - reliable timer-based retransmits
  RDP  - reliable message dropped
  RDPR - reliable message drops reported
  RI   - reliable message with old sequence number
  RO   - reliable message with out of order sequence number
  ROW  - reliable message with out of window sequence number
  ROB  - out of order reliable messages buffered
  RAS  - reliable ack packets sent

This unit as a sender
--------------------------
        all       0         2         3         
  U     123301    3867966   3230662   3850381   
  UE    0         0         0         0         
  SN    1656a4ce  acb26fe   5f839f76  7b680831  
  R     733840    1042168   852285    867311    
  RE    0         0         0         0         
  RDC   699789    934969    740874    756490    
  RA    385525    281198    204021    205384    
  RFR   27626     56397     0         0         
  RTR   34051     107199    111411    110821    
  RDP   0         0         0         0         
  RDPR  0         0         0         0         

This unit as a receiver of broadcast messages
---------------------------------------------
        0         2         3         
  U     111847    121862    120029    
  R     7503      665700    749288    
  ESN   5d75b4b3  6d81d23   365ddd50  
  RI    630       34278     40291     
  RO    0         582       850       
  ROW   0         566       850       
  ROB   0         16        0         
  RAS   1571      123289    142256    

This unit as a receiver of unicast messages
---------------------------------------------
        0         2         3         
  U     1         3308122   4370233   
  R     513846    879979    1009492   
  ESN   4458903a  6d841a84  7b4e7fa7  
  RI    66024     108924    102114    
  RO    0         0         0         
  ROW   0         0         0         
  ROB   0         0         0         
  RAS   130258    218924    228303    

Gated Tx Buffered Message Statistics
-------------------------------------
    current sequence number: 0

    total:                   0
    current:                 0
    high watermark:          0

    delivered:               0
    deliver failures:        0

    buffer full drops:       0
    message truncate drops:  0

    gate close ref count:    0

    num of supported clients:45

MRT Tx of broadcast messages
=============================
Message high watermark: 3%
  Total messages buffered at high watermark: 5677
  [Per-client message usage at high watermark]
  ---------------------------------------------------------------
  Client name                          Total messages  Percentage  
  Cluster Redirect Client                        4153         73% 
  Route Cluster Client                            419          7% 
  RRI Cluster Client                             1105         19% 

Current MRT buffer usage: 0%
  Total messages buffered in real-time: 1
  [Per-client message usage in real-time]
  Legend:
        F - MRT messages sending when buffer is full
        L - MRT messages sending when cluster node leave
        R - MRT messages sending in Rx thread
  ----------------------------------------------------------------------------
  Client name                          Total messages  Percentage    F   L   R
  VPN Clustering HA Client                          1        100%    0   0   0

MRT Tx of unitcast messages(to member_id:0)
============================================
Message high watermark: 31%
  Total messages buffered at high watermark: 4059
  [Per-client message usage at high watermark]
  ---------------------------------------------------------------
  Client name                          Total messages  Percentage  
  Cluster Redirect Client                        3731         91% 
  RRI Cluster Client                              328          8% 

Current MRT buffer usage: 29%
  Total messages buffered in real-time: 3924
  [Per-client message usage in real-time]
  Legend:
        F - MRT messages sending when buffer is full
        L - MRT messages sending when cluster node leave
        R - MRT messages sending in Rx thread
  ----------------------------------------------------------------------------
  Client name                          Total messages  Percentage    F   L   R
  Cluster Redirect Client                        3607         91%    0   0   0
  RRI Cluster Client                              317          8%    0   0   0

MRT Tx of unitcast messages(to member_id:2)
============================================
Message high watermark: 14%
  Total messages buffered at high watermark: 578
  [Per-client message usage at high watermark]
  ---------------------------------------------------------------
  Client name                          Total messages  Percentage  
  VPN Clustering HA Client                        578        100% 

Current MRT buffer usage: 0%
  Total messages buffered in real-time: 0

MRT Tx of unitcast messages(to member_id:3)
============================================
Message high watermark: 12%
  Total messages buffered at high watermark: 573
  [Per-client message usage at high watermark]
  ---------------------------------------------------------------
  Client name                          Total messages  Percentage  
  VPN Clustering HA Client                        572         99% 
  Cluster VPN Unique ID Client                      1          0% 
              
Current MRT buffer usage: 0%
  Total messages buffered in real-time: 0

show cluster history

クラスタの履歴を表示します。

クラスタ全体のパケットのキャプチャ

クラスタでのパケットのキャプチャについては、次のコマンドを参照してください。

cluster exec capture

クラスタ全体のトラブルシューティングをサポートするには、cluster exec capture コマンドを使用してマスターユニット上でのクラスタ固有トラフィックのキャプチャをイネーブルにします。これで、クラスタ内のすべてのスレーブユニットでも自動的にイネーブルになります。

クラスタリソースのモニタリング

クラスタリソースのモニタリングについては、次のコマンドを参照してください。

show cluster {cpu | memory | resource} [options]、show cluster chassis [cpu | memory | resource usage]

クラスタ全体の集約データを表示します。使用可能なオプションはデータのタイプによって異なります。

クラスタトラフィックのモニタリング

クラスタトラフィックのモニタリングについては、次のコマンドを参照してください。

show conn [detail | count], cluster exec show conn

show conn コマンドは、フローがディレクタ、バックアップ、またはフォワーダフローのいずれであるかを示します。cluster exec show conn コマンドを任意のユニットで使用すると、すべての接続が表示されます。このコマンドの表示からは、1 つのフローのトラフィックがクラスタ内のさまざまな ASA にどのように到達するかがわかります。クラスタのスループットは、ロードバランシングの効率とコンフィギュレーションによって異なります。このコマンドを利用すると、ある接続のトラフィックがクラスタ内をどのように流れるかが簡単にわかります。また、ロードバランサがフローのパフォーマンスにどのように影響を与えるかを理解するのに役立ちます。

次に、show conn detail コマンドの出力例を示します。



ciscoasa/ASA2/slave# show conn detail
15 in use, 21 most used
Cluster:
        fwd connections: 0 in use, 0 most used
        dir connections: 0 in use, 0 most used
        centralized connections: 0 in use, 44 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
       B - initial SYN from outside, b - TCP state-bypass or nailed,
       C - CTIQBE media, c - cluster centralized,
       D - DNS, d - dump, E - outside back connection, e - semi-distributed,
       F - outside FIN, f - inside FIN,
       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
       i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
       k - Skinny media, L - LISP triggered flow owner mobility
       M - SMTP data, m - SIP media, n - GUP
       N - inspected by Snort
       O - outbound data, o - offloaded,
       P - inside back connection,
       Q - Diameter, q - SQL*Net data,
       R - outside acknowledged FIN,
       R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,
       V - VPN orphan, W - WAAS,
       w - secondary domain backup,
       X - inspected by service module,
       x - per session, Y - director stub flow, y - backup stub flow,
       Z - Scansafe redirection, z - forwarding stub flow

Cluster units to ID mappings:
  ID 0: unit-2-1
  ID 1: unit-1-1
  ID 2: unit-1-2
  ID 3: unit-2-2
  ID 4: unit-2-3
  ID 255: The default cluster member ID which indicates no ownership or affiliation
          with an existing cluster member

show cluster info [conn-distribution | packet-distribution | loadbalance]

show cluster info conn-distribution および show cluster info packet-distribution コマンドは、すべてのクラスタユニット間のトラフィックの分布を表示します。これらのコマンドは、外部ロードバランサを評価し、調整するのに役立ちます。

show cluster info loadbalance コマンドは、接続再分散の統計情報を表示します。

show cluster {access-list | conn [count] | traffic | user-identity | xlate} [options]、show cluster chassis {access-list | conn | traffic | user-identity | xlate count}

クラスタ全体の集約データを表示します。使用可能なオプションはデータのタイプによって異なります。

show cluster access-list コマンドの次の出力を参照してください。


ciscoasa# show cluster access-list
hitcnt display order: cluster-wide aggregated result, unit-A, unit-B,  unit-C, unit-D
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096) alert-interval 300
access-list 101; 122 elements; name hash: 0xe7d586b5
access-list 101 line 1 extended permit tcp 192.168.143.0 255.255.255.0 any eq www (hitcnt=0, 0, 0, 0, 0) 0x207a2b7d
access-list 101 line 2 extended permit tcp any 192.168.143.0 255.255.255.0 (hitcnt=0, 0, 0, 0, 0) 0xfe4f4947
access-list  101 line 3 extended permit tcp host 192.168.1.183 host 192.168.43.238 (hitcnt=1, 0, 0, 0, 1) 0x7b521307
access-list 101 line 4 extended permit tcp host 192.168.1.116 host 192.168.43.238 (hitcnt=0, 0, 0, 0, 0) 0x5795c069
access-list 101 line 5 extended permit tcp host 192.168.1.177 host 192.168.43.238 (hitcnt=1, 0, 0, 1, 0) 0x51bde7ee
access list 101 line 6 extended permit tcp host 192.168.1.177 host 192.168.43.13 (hitcnt=0, 0, 0, 0, 0) 0x1e68697c
access-list 101 line 7 extended permit tcp host 192.168.1.177 host 192.168.43.132 (hitcnt=2, 0, 0, 1, 1) 0xc1ce5c49
access-list 101 line 8 extended permit tcp host 192.168.1.177 host 192.168.43.192 (hitcnt=3, 0, 1, 1, 1) 0xb6f59512
access-list 101 line 9 extended permit tcp host 192.168.1.177 host 192.168.43.44 (hitcnt=0, 0, 0, 0, 0) 0xdc104200
access-list 101 line 10 extended permit tcp host 192.168.1.112 host 192.168.43.44 (hitcnt=429, 109, 107, 109, 104) 
0xce4f281d
access-list 101 line 11 extended permit tcp host 192.168.1.170 host 192.168.43.238 (hitcnt=3, 1, 0, 0, 2) 0x4143a818
access-list 101 line 12 extended permit tcp host 192.168.1.170 host 192.168.43.169 (hitcnt=2, 0, 1, 0, 1) 0xb18dfea4
access-list 101 line 13 extended permit tcp host 192.168.1.170 host 192.168.43.229 (hitcnt=1, 1, 0, 0, 0) 0x21557d71
access-list 101 line 14 extended permit tcp host 192.168.1.170 host 192.168.43.106 (hitcnt=0, 0, 0, 0, 0) 0x7316e016
access-list 101 line 15 extended permit tcp host 192.168.1.170 host 192.168.43.196 (hitcnt=0, 0, 0, 0, 0) 0x013fd5b8
access-list 101 line 16 extended permit tcp host 192.168.1.170 host 192.168.43.75 (hitcnt=0, 0, 0, 0, 0) 0x2c7dba0d

使用中の接続の、すべてのユニットでの合計数を表示するには、次のとおりに入力します。


ciscoasa# show cluster conn count
Usage Summary In Cluster:*********************************************
124 in use, fwd connection 0 in use, dir connection 0 in use, centralized connection
0 in use (Cluster-wide aggregated)

unit-1-1(LOCAL):******************************************************
40 in use, 48 most used, fwd connection 0 in use, 0 most used, dir connection 0 in use,
0 most used, centralized connection 0 in use, 46 most used

unit-2-2:*************************************************************
18 in use, 40 most used, fwd connection 0 in use, 0 most used, dir connection 0 in use,
0 most used, centralized connection 0 in use, 45 most used

show asp cluster counter

このコマンドは、データパスのトラブルシューティングに役立ちます。

クラスタのルーティングのモニタリング

クラスタのルーティングについては、次のコマンドを参照してください。

show route cluster
debug route cluster

クラスタのルーティング情報を表示します。

show lisp eid

EIDs とサイト ID を示す ASA EID テーブルを表示します。

cluster exec show lisp eid コマンドからの、次の出力を参照してください。


ciscoasa# cluster exec show lisp eid
L1(LOCAL):************************************************************
     LISP EID       Site ID
    33.44.33.105        2
    33.44.33.201        2
    11.22.11.1             4
    11.22.11.2             4
L2:*******************************************************************
     LISP EID       Site ID
    33.44.33.105        2
    33.44.33.201        2
    11.22.11.1 	 4
    11.22.11.2	 4

show asp table classify domain inspect-lisp

このコマンドは、トラブルシューティングに役立ちます。

分散型 S2S VPN のモニタリング

次のコマンドを使用して、VPN セッションのステータスと分布を監視します。

セッションの全体的な分布は、show cluster vpn-sessiondb distribution を使用して示されます。マルチコンテキスト環境で実行している場合は、このコマンドをシステムコンテキストで実行する必要があります。

この show コマンドを使用すると、各メンバーで show vpn-sessiondb summary を実行する必要なく、セッションのクイックビューが提供されます。
show cluster vpn-sessiondb summary コマンドを使用して、クラスタ上の VPN 接続の統一されたビューも使用できます。
show vpn-sessiondb コマンドを使用した個々のデバイスモニタリングでは、通常の VPN 情報に加えて、デバイス上のアクティブセッションとバックアップセッションの数が表示されます。

クラスタリングのロギングの設定

クラスタリングのロギングの設定については、次のコマンドを参照してください。

logging device-id

クラスタ内の各ユニットは、syslog メッセージを個別に生成します。logging device-id コマンドを使用すると、同一または異なるデバイス ID 付きで syslog メッセージを生成することができ、クラスタ内の同一または異なるユニットからのメッセージのように見せることができます。

クラスタリングのデバッグ

クラスタリングのデバッグについては、次のコマンドを参照してください。

debug cluster [ccp | datapath | fsm | general | hc | license | rpc | service-module | transport]

クラスタリングのデバッグメッセージを表示します。
debug service-module

スーパバイザとアプリケーション間のヘルスチェックの問題を含め、ブレードレベルの問題に関するデバッグメッセージを表示します。

show cluster info trace

show cluster info trace コマンドは、トラブルシューティングのためのデバッグ情報を表示します。

show cluster info trace コマンドについては次の出力を参照してください。


ciscoasa# show cluster info trace
 Feb 02 14:19:47.456 [DBUG]Receive CCP message: CCP_MSG_LOAD_BALANCE
 Feb 02 14:19:47.456 [DBUG]Receive CCP message: CCP_MSG_LOAD_BALANCE
 Feb 02 14:19:47.456 [DBUG]Send CCP message to all: CCP_MSG_KEEPALIVE from 80-1 at MASTER

分散型 S2S VPN のトラブルシューティング

分散型 VPN の通知

分散型 VPN を実行しているクラスタで、次のエラー状況が発生した場合、識別されたフレーズを含むメッセージが通知されます。


状況	通知
クラスタに参加しようとしているときに、既存のまたは参加しているクラスタスレーブが分散型 VPN モードにない場合は、次のメッセージが通知されます。	`New cluster member (member-name) rejected due to vpn mode mismatch.` および `Master (master-name) rejects enrollment request from unit (unit-name) for the reason: the vpn mode capabilities are not compatible with the master configuration`
分散型 VPN のクラスタメンバーでライセンスが正しく設定されていない場合は、次のメッセージが通知されます。	`ERROR: Master requested cluster vpn-mode change to distributed. Unable to change mode due to missing Carrier License.`
受信した IKEv2 パケットの SPI でタイムスタンプまたはメンバー ID が無効な場合は、次のメッセージが通知されます。	`Expired SPI received` または `Corrupted SPI detected`
クラスタがバックアップセッションを作成できない場合は、次のメッセージが通知されます。	`Failed to create the backup for an IKEv2 session.`
IKEv2 初期接点（IC）処理エラーの場合は、次のメッセージが通知されます。	`IKEv2 Negotiation aborted due to ERROR: Stale backup session found on backup`
再配布の問題の場合は、次のメッセージが通知されます。	`Failed to send session redistribution message to member-name` `Failed to receive session move response from member-name (master only)`
セッションの再配布中にトポロジが変更された場合は、次のメッセージが通知されます。	`Cluster topology change detected. VPN session redistribution aborted.`

次のいずれかの状況が発生している可能性があります。

port-channel load-balance src-dst l4portコマンドを使用して N7K スイッチにロードバランシングアルゴリズムとして L4port が設定されている場合、L2L VPN セッションはクラスタ内のシャーシの 1 つにのみ配布されます。. クラスタセッションの割り当ての例を次に示します。
```
SSP-Cluster/slave(cfg-cluster)# show cluster vpn-sessiondb distribution
Member 0 (unit-1-3): active: 0
Member 1 (unit-2-2): active: 13295; backups at: 0(2536), 2(2769), 3(2495), 4(2835), 5(2660)
Member 2 (unit-2-3): active: 12174; backups at: 0(2074), 1(2687), 3(2207), 4(3084), 5(2122)
Member 3 (unit-2-1): active: 13416; backups at: 0(2419), 1(3013), 2(2712), 4(2771), 5(2501)
Member 4 (unit-1-1): active: 0
Member 5 (unit-1-2): active: 0
```
L2L IKEv2 VPN は送信元ポートと宛先ポートの両方にポート 500 を使用するため、IKE パケットは N7K とシャーシ間に接続されたポートチャネル内のリンクの 1 つにのみ送信されます。

port-channel load-balance src-dst ip-l4port を使用して、N7K ロードバランシングアルゴリズムを IP および L4 ポートに変更します。その後、IKE パケットはすべてのリンクに送信されるので、両方の Firepower9300 シャーシに送信されます。

より即座に調整するには、ASA クラスタのマスターで cluster redistribute vpn-sessiondb を実行することで、アクティブな VPN セッションを他のシャーシのクラスタメンバーに再配布できます。

クラスタリングの参考資料

このセクションには、クラスタリングの動作に関する詳細情報が含まれます。

パフォーマンススケーリング係数

複数のユニットをクラスタに結合した場合、期待できる合計クラスタパフォーマンスの概算値は次のようになります。

TCP または CPS の合計スループットの 80 %
UDP の合計スループットの 90 %
トラフィックの混在に応じて、イーサネット MIX（EMIX）の合計スループットの 60 %。

たとえば、TCP スループットについては、3 つのモジュールを備えた Firepower 9300 は、単独で動作している場合、約 135 Gbps の実際のファイアウォールトラフィックを処理できます。2 シャーシの場合、最大スループットの合計は 270 Gbps（2 シャーシ X 135 Gbps）の約 80 %、つまり 216 Gbps です。

マスターユニット選定

クラスタのメンバは、クラスタ制御リンクを介して通信してマスターユニットを選定します。方法は次のとおりです。

クラスタを展開すると、各ユニットは選定要求を 3 秒ごとにブロードキャストします。
プライオリティの高い他のユニットがこの選定要求に応答します。プライオリティはクラスタの展開時に設定され、設定の変更はできません。
45 秒経過しても、プライオリティの高い他のユニットからの応答を受信していない場合は、そのユニットがマスターになります。
後からクラスタに参加したユニットのプライオリティの方が高い場合でも、そのユニットが自動的にマスターユニットになることはありません。既存のマスターユニットは常にマスターのままです。ただし、マスターユニットが応答を停止すると、その時点で新しいマスターユニットが選定されます。

（注）

特定のユニットを手動で強制的にマスターにすることができます。中央集中型機能については、マスターユニット変更を強制するとすべての接続がドロップされるので、新しいマスターユニット上で接続を再確立する必要があります。

クラスタ内のハイアベイラビリティ

クラスタリングは、シャーシ、ユニットとインターフェイスの正常性を監視し、ユニット間で接続状態を複製することにより、ハイアベイラビリティを提供します。

シャーシアプリケーションのモニタリング

シャーシアプリケーションのヘルスモニタリングは常に有効になっています。Firepower 4100/9300 シャーシスーパーバイザはASAアプリケーションを定期的に確認します（毎秒）。ASAが作動中で、Firepower 4100/9300 シャーシスーパーバイザと 3 秒間通信できなければASAは syslog メッセージを生成して、クラスタを離れます。

Firepower 4100/9300 シャーシスーパーバイザが 45 秒後にアプリケーションと通信できなければ、ASAをリロードします。ASAがスーパーバイザと通信できなければ、自身をクラスタから削除します。

ユニットのヘルスモニタリング

マスターユニットは、各スレーブユニットをモニタするために、クラスタ制御リンクを介してハートビートメッセージを定期的に送信します（間隔は設定可能です）。各スレーブユニットは、同じメカニズムを使用してマスターユニットをモニタします。ユニットの健全性チェックが失敗すると、ユニットはクラスタから削除されます。

インターフェイスモニタリング

各ユニットは、使用中のすべてのハードウェアインターフェイスのリンクステータスをモニタし、ステータス変更をマスターユニットに報告します。シャーシ間クラスタリングでは、スパンド EtherChannel はクラスタ Link Aggregation Control Protocol（cLACP）を使用します。各シャーシはリンクステータスと cLACP プロトコルメッセージをモニタして EtherChannel でポートがアクティブであるかどうかを判別し、インターフェイスがダウンしている場合には ASA アプリケーションに通知します。ヘルスモニタリングを有効にすると、デフォルトではすべての物理インターフェイスがモニタされます（EtherChannel インターフェイスのメイン EtherChannel を含む）。アップ状態の指名されたインターフェイスのみモニタできます。たとえば、名前付き EtherChannel がクラスタから削除される前に、EtherChannel のすべてのメンバーポートがエラーとなる必要があります（最小ポートバンドル設定に基づく）。ヘルスチェックは、インターフェイスごとに、モニタリングをオプションで無効にすることができます。

あるモニタ対象のインターフェイスが、特定のユニット上では障害が発生したが、別のユニットではアクティブの場合は、そのユニットはクラスタから削除されます。ASA がメンバーをクラスタから削除するまでの時間は、そのユニットが確立済みメンバーであるか、またはクラスタに参加しようとしているかによって異なります。ASA は、ユニットがクラスタに参加する最初の 90 秒間はインターフェイスを監視ししません。この間にインターフェイスのステータスが変化しても、ASA はクラスタから削除されません。設定済みのメンバーの場合は、500 ミリ秒後にユニットが削除されます

シャーシ間クラスタリングでは、クラスタから EtherChannel を追加または削除した場合、各シャーシに変更を加えられるように、インターフェイスヘルスモニタリングは 95 秒間中断されます。

デコレータアプリケーションのモニタリング

インターフェイスに Radware DefensePro アプリケーションなどのデコレータアプリケーションをインストールした場合、ユニットがクラスタ内にとどまるには ASA、デコレータアプリケーションの両方が動作している必要があります。両方のアプリケーションが動作状態になるまで、ユニットはクラスタに参加しません。一旦クラスタに参加すると、ユニットはデコレータアプリケーションが正しく動作しているか 3 秒ごとにモニタします。デコレータアプリケーションがダウンすると、ユニットはクラスタから削除されます。

障害後のステータス

クラスタ内のユニットで障害が発生したときに、そのユニットでホスティングされている接続は他のユニットにシームレスに移管されます。トラフィックフローのステート情報は、クラスタ制御リンクを介して共有されます。

マスターユニットで障害が発生した場合は、そのクラスタの他のメンバーのうち、プライオリティが最高（番号が最小）のものがマスターユニットになります。

障害イベントに応じて、ASA は自動的にクラスタへの再参加を試みます。

（注）

ASA が非アクティブになり、クラスタへの自動再参加に失敗すると、すべてのデータインターフェイスがシャットダウンされます。管理専用インターフェイスのみがトラフィックを送受信できます。管理インターフェイスは、そのユニットがクラスタ IP プールから受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードする場合、クラスタでユニットがまだ非アクティブになっていると、管理インターフェイスはディセーブルになります。それ以降のコンフィギュレーション作業には、コンソールポートを使用する必要があります。

クラスタへの再参加

クラスタメンバがクラスタから削除された後、クラスタに再参加できる方法は、削除された理由によって異なります。

クラスタ制御リンクの障害（最初の参加時）：クラスタ制御リンクの問題を解決した後、ASA コンソールポートで cluster group name と入力してから enable と入力して、クラスタリングを再びイネーブルにすることによって、手動でクラスタに再参加する必要があります。
クラスタに参加した後に障害が発生したクラスタ制御リンク：ASA は、無限に 5 分ごとに自動的に再参加を試みます。この動作は設定可能です。
データインターフェイスの障害：ASA は自動的に最初は 5 分後、次に 10 分後、最終的に 20 分後に再参加を試みます。20 分後に参加できない場合、ASA はクラスタリングをディセーブルにします。データインターフェイスの問題を解決した後、ASA コンソールポートで cluster group name と入力してから enable と入力して、クラスタリングを手動でイネーブルにする必要があります。この動作は設定可能です。
ユニットの障害：ユニットがヘルスチェック失敗のためクラスタから削除された場合、クラスタへの再参加は失敗の原因によって異なります。たとえば、一時的な電源障害の場合は、クラスタ制御リンクが稼働している限り、ユニットは再起動するとクラスタに再参加します。ユニットは 5 秒ごとにクラスタへの再参加を試みます。
シャーシアプリケーション通信の障害：ASA がシャーシアプリケーションの状態が回復したことを検出すると、ASA は自動的にクラスタの再参加を試みます。
デコレータアプリケーションの障害：ASA はデコレータアプリケーションが復帰したことを確認すると、クラスタへ再参加します。
内部エラー：内部の障害には、アプリケーション同期のタイムアウト、矛盾したアプリケーションステータスなどがあります。ユニットは 5 分、10 分、および 20 分の間隔でクラスタに自動的に再参加を試行します。この動作は設定可能です。

データパス接続状態の複製

どの接続にも、1 つのオーナーおよび少なくとも 1 つのバックアップオーナーがクラスタ内にあります。バックアップオーナーは、障害が発生しても接続を引き継ぎません。代わりに、TCP/UDP のステート情報を保存します。これは、障害発生時に接続が新しいオーナーにシームレスに移管されるようにするためです。バックアップオーナーは通常ディレクタでもあります。

トラフィックの中には、TCP または UDP レイヤよりも上のステート情報を必要とするものがあります。この種類のトラフィックに対するクラスタリングのサポートの可否については、次の表を参照してください。

表 2. クラスタ全体で複製される機能
Traffic	状態のサポート	注意
Up time	Yes	システムアップタイムをトラッキングします。
ARP Table	Yes	—
MAC アドレステーブル	Yes	—
ユーザアイデンティティ	Yes	AAA ルール（uauth）とアイデンティティファイアウォールが含まれます。
IPv6 ネイバーデータベース	Yes	—
ダイナミックルーティング	Yes	—
SNMP エンジン ID	なし	—
集中型 VPN（サイト間）	なし	VPN セッションは、マスターユニットで障害が発生すると切断されます。
分散型 VPN（サイト間）	Yes	バックアップセッションがアクティブセッションになると、新しいバックアップセッションが作成されます。

クラスタが接続を管理する方法

接続をクラスタの複数のメンバにロードバランスできます。接続のロールにより、通常動作時とハイアベイラビリティ状況時の接続の処理方法が決まります。

接続のロール

接続ごとに定義された次のロールを参照してください。

オーナー：通常、最初に接続を受信するユニット。オーナーは、TCP 状態を保持し、パケットを処理します。1 つの接続に対してオーナーは 1 つだけです。元のオーナーに障害が発生すると、新しいユニットが接続からパケットを受信したときにディレクタがこれらのユニットの新しいオーナーを選択します。
バックアップオーナー：オーナーから受信した TCP/UDP ステート情報を格納するユニット。これにより、障害が発生した場合に新しいオーナーにシームレスに接続を転送できます。バックアップオーナーは、障害発生時に接続を引き継ぎません。オーナーが使用不可能になった場合は、その接続からパケットを受け取る最初のユニット（ロードバランシングに基づく）がバックアップオーナーに問い合わせて、関連するステート情報を取得し、これでそのユニットが新しいオーナーになることができます。

ディレクタ（下記参照）がオーナーと同じユニットでない限り、ディレクタはバックアップオーナーでもあります。オーナーがディレクタとして自分自身を選択すると、別のバックアップオーナーが選択されます。

1 台のシャーシに最大 3 つのクラスタユニットを搭載できる Firepower 9300 のシャーシ間クラスタリングでは、バックアップオーナーがオーナーと同じシャーシにある場合、シャーシ障害からフローを保護するために、別のシャーシから追加のバックアップオーナーが選択されます。

サイト間クラスタリングのディレクタローカリゼーションを有効にすると、ローカルバックアップとグローバルバックアップの 2 つのバックアップオーナー権限があります。オーナーは、常に同じサイトのローカルバックアップをオーナー自身として選択します（サイト ID に基づいて）。グローバルバックアップはどのサイトにあってもよく、ローカルバックアップと同一のユニットとすることもできます。オーナーは、両方のバックアップへ接続ステート情報を送信します。

サイトの冗長性を有効にし、バックアップオーナーがオーナーと同じサイトにある場合は、サイトの障害からフローを保護するために、追加のバックアップオーナーが別のサイトから選択されます。シャーシバックアップとサイトバックアップは独立しているため、フローにはシャーシバックアップとサイトバックアップの両方が含まれている場合があります。
ディレクタ：フォワーダからのオーナールックアップ要求を処理するユニット。オーナーが新しい接続を受信すると、オーナーは、送信元/宛先 IP アドレスおよびポートのハッシュに基づいてディレクタを選択し、新しい接続を登録するためにメッセージをそのディレクタに送信します。パケットがオーナー以外のユニットに到着した場合は、そのユニットはどのユニットがオーナーかをディレクタに問い合わせます。これで、パケットを転送できるようになります。1 つの接続に対してディレクタは 1 つだけです。ディレクタが失敗すると、オーナーは新しいディレクタを選択します。

ディレクタがオーナーと同じユニットでない限り、ディレクタはバックアップオーナーでもあります（上記参照）。オーナーがディレクタとして自分自身を選択すると、別のバックアップオーナーが選択されます。

サイト間クラスタリングのディレクタローカリゼーションを有効にすると、ローカルディレクタとグローバルディレクタの 2 つのディレクタ権限が区別されます。オーナーは、同一サイト（Site Id に基づき）のローカルディレクタとして、常にオーナー自身を選択します。グローバルディレクタはどのサイトにあってもよく、ローカルディレクタと同一のユニットとすることもできます。元のオーナーに障害が発生すると、ローカルディレクタはこのサイトで新しい接続オーナーを選択します。
フォワーダ：パケットをオーナーに転送するユニット。フォワーダが接続のパケットを受信したときに、その接続のオーナーが自分ではない場合は、フォワーダはディレクタにオーナーを問い合わせてから、そのオーナーへのフローを確立します。これは、この接続に関してフォワーダが受信するその他のパケット用です。ディレクタは、フォワーダにもなることができます。ディレクタローカリゼーションを有効にすると、フォワーダは常にローカルディレクタに問い合わせを行います。フォワーダがグローバルディレクタに問い合わせを行うのは、ローカルディレクタがオーナーを認識していない場合だけです。たとえば、別のサイトで所有されている接続のパケットをクラスタメンバーが受信する場合などです。フォワーダが SYN-ACK パケットを受信した場合、フォワーダはパケットの SYN クッキーからオーナーを直接取得できるので、ディレクタに問い合わせる必要がないことに注意してください（TCP シーケンスのランダム化をディセーブルにした場合は、SYN Cookie は使用されないので、ディレクタへの問い合わせが必要です）。存続期間が短いフロー（たとえば DNS や ICMP）の場合は、フォワーダは問い合わせの代わりにパケットを即座にディレクタに送信し、ディレクタがそのパケットをオーナーに送信します。1 つの接続に対して、複数のフォワーダが存在できます。最も効率的なスループットを実現できるのは、フォワーダが 1 つもなく、接続のすべてのパケットをオーナーが受信するという、優れたロードバランシング方法が使用されている場合です。

接続でポートアドレス変換（PAT）を使用すると、PAT のタイプ（per-session または multi-session）が、クラスタのどのメンバが新しい接続のオーナーになるかに影響します。

Per-session PAT：オーナーは、接続の最初のパケットを受信するユニットです。

デフォルトでは、TCP および DNS UDP トラフィックは per-session PAT を使用します。
Multi-session PAT：オーナーは常にマスターユニットです。multi-session PAT 接続がスレーブユニットで最初に受信される場合、スレーブユニットはその接続をマスターユニットに転送します。

デフォルトでは、UDP（DNS UDP を除く）および ICMP トラフィックは multi-session PAT を使用するので、これらの接続は常にマスターユニットによって所有されています。

TCP および UDP の per-session PAT デフォルトを変更できるので、これらのプロトコルの接続は、その設定に応じて per-session または multi-session で処理されます。ICMP の場合は、デフォルトの multi-session PAT から変更することはできません。per-session PAT の詳細については、『ファイアウォールの構成ガイド』を参照してください。

新しい接続の所有権

新しい接続がロードバランシング経由でクラスタのメンバに送信される場合は、そのユニットがその接続の両方向のオーナーとなります。接続のパケットが別のユニットに到着した場合は、そのパケットはクラスタ制御リンクを介してオーナーユニットに転送されます。逆方向のフローが別のユニットに到着した場合は、元のユニットにリダイレクトされます。

サンプルデータフロー

次の例は、新しい接続の確立を示します。

SYN パケットがクライアントから発信され、ASA の 1 つ（ロードバランシング方法に基づく）に配信されます。これがオーナーとなります。オーナーはフローを作成し、オーナー情報をエンコードして SYN Cookie を生成し、パケットをサーバに転送します。
SYN-ACK パケットがサーバから発信され、別の ASA（ロードバランシング方法に基づく）に配信されます。この ASA はフォワーダです。
フォワーダはこの接続を所有してはいないので、オーナー情報を SYN Cookie からデコードし、オーナーへの転送フローを作成し、SYN-ACK をオーナーに転送します。
オーナーはディレクタに状態アップデートを送信し、SYN-ACK をクライアントに転送します。
ディレクタは状態アップデートをオーナーから受信し、オーナーへのフローを作成し、オーナーと同様に TCP ステート情報を記録します。ディレクタは、この接続のバックアップオーナーとしての役割を持ちます。
これ以降、フォワーダに配信されたパケットはすべて、オーナーに転送されます。
パケットがその他のユニットに配信された場合は、そのユニットはディレクタに問い合わせてオーナーを特定し、フローを確立します。
フローの状態が変化した場合は、状態アップデートがオーナーからディレクタに送信されます。

Firepower 4100/9300 シャーシ上の ASA クラスタリングの履歴


機能名	バージョン	機能情報
サイトごとのクラスタリング用 Gratuitous ARP	9.12(1)	ASA では、Gratuitous ARP（GARP）パケットを生成してスイッチングインフラストラクチャを常に最新の状態に保つようになりました。各サイトの優先順位値が最も高いメンバによって、グローバル MAC/IP アドレスの GARP トラフィックが定期的に生成されます。クラスタから送信されたサイトごとの MAC および IP アドレスとパケットがサイト固有の MAC アドレスおよび IP アドレスを使用するのに対し、クラスタで受信したパケットは、グローバル MAC アドレスおよび IP アドレスを使用します。トラフィックがグローバル MAC アドレスから定期的に生成されない場合、グローバル MAC アドレスのスイッチで MAC アドレスのタイムアウトが発生する可能性があります。タイムアウト後にグローバル MAC アドレスへのトラフィックがスイッチングインフラストラクチャ全体にわたりフラッディングされ、これによりパフォーマンスおよびセキュリティ上の問題が発生することがあります。各スパンド EtherChannel のユニットおよびサイト MAC アドレスごとにサイト ID を設定すると、GARP がデフォルトで有効になります。新規/変更されたコマンド： site-periodic-garp interval
Firepower 9300 シャーシごとのユニットのパラレルクラスタ参加	9.10(1)	Firepower 9300 の場合、この機能により、シャーシ内のセキュリティモジュールがクラスタに同時に参加し、トラフィックがモジュール間で均等に分散されるようになります。他のモジュールよりもかなり前に参加したモジュールは、他のモジュールがまだ負荷を共有できないため、必要以上のトラフィックを受信することがあります。新規/変更されたコマンド： unit parallel-join
Firepower 4100/9300 の Cluster Control Link のカスタマイズ可能な IP アドレス	9.10(1)	クラスタ制御リンクのデフォルトでは 127.2.0.0/16 ネットワークが使用されます。FXOS にクラスタを展開する際にネットワークを設定できるようになりました。シャーシは、シャーシ ID およびスロット ID（127.2.chassis_id.slot_id）に基づいて、各ユニットのクラスタ制御リンクインターフェイス IP アドレスを自動生成します。ただし、一部のネットワーク展開では、127.2.0.0/16 トラフィックはパスできません。そのため、ループバック（127.0.0.0/8）およびマルチキャスト（224.0.0.0/4）アドレスを除き、FXOS にクラスタ制御リンクのカスタム /16 サブネットを作成できるようになりました。新規/変更された FXOS コマンド： set cluster-control-link network
クラスタインターフェイスデバウンス時間は、ダウン状態から稼働状態に変更するインターフェイスに適用されるようになりました。	9.10(1)	インターフェイスのステータス更新が発生すると、ASA はインターフェイスを障害としてマークし、クラスタからユニットを削除するまで health-check monitor-interface debounce-time コマンドまたは ASDM [Configuration] > [Device Management] > [High Availability and Scalability] > [ASA Cluster] 画面で指定されたミリ秒数待機します。この機能は、ダウン状態から稼働状態に変更するインターフェイスに適用されるようになりました。たとえば、ダウン状態から稼働状態に移行している EtherChannel の場合（スイッチがリロードされた、またはスイッチが有効になっている EtherChannel など）、デバウンス時間を長くすることで、他のクラスタユニットの方がポートのバンドルが速いという理由だけで、クラスタユニット上でインターフェイスがエラー表示されるのを防ぐことができます。変更されたコマンドはありません。
内部障害発生後に自動的にクラスタに再参加する	9.9(2)	以前は、多くのエラー状態によりクラスタユニットがクラスタから削除されていました。この問題を解決した後、手動でクラスタに再参加する必要がありました。現在は、ユニットはデフォルトで 5 分、10 分、および 20 分の間隔でクラスタに自動的に再参加を試行します。これらの値は設定できます。内部の障害には、アプリケーション同期のタイムアウト、矛盾したアプリケーションステータスなどがあります。新規または変更されたコマンド：health-check system auto-rejoin、show cluster info auto-join
クラスタの信頼性の高いトランスポートプロトコルメッセージのトランスポートに関連する統計情報の表示	9.9(2)	ユニットごとのクラスタの信頼性の高いトランスポートバッファ使用率を確認して、バッファがコントロールプレーンでいっぱいになったときにパケットドロップの問題を特定できるようになりました。新規または変更されたコマンド：show cluster info transport cp detail
Firepower シャーシのシャーシヘルスチェックの障害検出の向上	9.9(1)	シャーシヘルスチェックの保留時間をより低い値（100 ms）に設定できるようになりました。以前の最小値は 300 ms でした。最小の結合時間（interval x retry-count）は、600 ミリ秒未満にすることはできないことに注意してください。新規または変更されたコマンド：app-agent heartbeat interval
クラスタリングのサイト間冗長性	9.9(1)	サイト間の冗長性により、トラフィックフローのバックアップオーナーは常にオーナーとは別のサイトに置かれます。この機能によって、サイトの障害から保護されます。新規または変更されたコマンド：site-redundancy、show asp cluster counter change、show asp table cluster chash-table、show conn flag
Firepower 9300 上のクラスタリングによる分散型サイト間 VPN	9.9(1)	Firepower 9300 上の ASA クラスタは、分散モードでサイト間 VPN をサポートします。分散モードでは、（集中モードなどの）マスターユニットだけでなく、ASA クラスタのメンバー間で多数のサイト間 IPsec IKEv2 VPN 接続を分散させることができます。これにより、集中型 VPN の機能を超えて VPN サポートが大幅に拡張され、高可用性が実現します。分散型 S2S VPN は、それぞれ最大 3 つのモジュールを含む最大 2 つのシャーシのクラスタ（合計 6 つのクラスタメンバー）上で動作し、各モジュールは最大約 36,000 のアクティブセッション（合計 72,000)に対し、最大 6,000 のアクティブセッション（合計 12,000）をサポートします。新規または変更されたコマンド：cluster redistribute vpn-sessiondb、show cluster vpn-sessiondb、vpn mode、show cluster resource usage、show vpn-sessiondb、show connection detail、show crypto ikev2
クラスタユニットヘルスチェック障害検出の改善	9.8(1)	ユニットヘルスチェックの保留時間をより低めの値に設定できます（最小値は .3 秒）以前の最小値は .8 秒でした。この機能は、ユニットヘルスチェックメッセージングスキームを、コントロールプレーンのキープアライブからデータプレーンのハートビートに変更します。ハートビートを使用すると、コントロールプレーン CPU のホッギングやスケジューリングの遅延の影響を受けないため、クラスタリングの信頼性と応答性が向上します。保留時間を短く設定すると、クラスタ制御リンクのメッセージングアクティビティが増加することに注意してください。保留時間を短く設定する前にネットワークを分析することをお勧めします。たとえば、ある保留時間間隔の間に 3 つのハートビートメッセージが存在するため、クラスタ制御リンクを介してあるユニットから別のユニットへの ping が保留時間/3 以内に戻ることを確認します。保留時間を 0.3 ～ 0.7 に設定した後に ASA ソフトウェアをダウングレードした場合、新しい設定がサポートされていないので、この設定はデフォルトの 3 秒に戻ります。次のコマンドを変更しました。health-check holdtime、show asp drop cluster counter、show cluster info health details
に対してインターフェイスを障害としてマークするために設定可能なデバウンス時間 Firepower 4100/9300 シャーシ	9.8(1)	ASA がインターフェイスを障害が発生していると見なし、クラスタからユニットが削除されるまでのデバウンス時間を設定できるようになりました。この機能により、インターフェイスの障害をより迅速に検出できます。デバウンス時間を短くすると、誤検出の可能性が高くなることに注意してください。インターフェイスのステータス更新が発生すると、ASA はインターフェイスを障害としてマークし、クラスタからユニットを削除するまで指定されたミリ秒数待機します。デフォルトのデバウンス時間は 500 ms で、有効な値の範囲は 300 ms ～ 9 秒です。新規または変更されたコマンド：health-check monitor-interface debounce-time
Firepower 4100/9300 シャーシ上の ASA のサイト間クラスタリングの改良	9.7(1)	ASA クラスタを展開すると、それぞれの Firepower 4100/9300 シャーシのサイト ID を設定できます。以前は、ASA アプリケーション内でサイト ID を設定する必要がありました。この新機能により初期展開が簡単になります。ASA 構成内でサイト ID を設定することはできないことに注意してください。また、サイト間クラスタリングとの互換性を高めるために、安定性とパフォーマンスに関する複数の改善が含まれる ASA 9.7(1) および FXOS 2.1.1 にアップグレードすることを推奨します。次のコマンドが変更されました。site-id
ディレクタローカリゼーション：データセンターのサイト間クラスタリングの改善	9.7(1)	データセンターのパフォーマンスを向上し、サイト間クラスタリングのトラフィックを維持するために、ディレクタローカリゼーションを有効にできます。通常、新しい接続は特定のサイト内のクラスタメンバーによってロードバランスされ、所有されています。しかし、ASA は任意のサイトのメンバーにディレクタロールを割り当てます。ディレクタローカリゼーションにより、所有者と同じサイトのローカルディレクタ、どのサイトにも存在可能なグローバルディレクタという追加のディレクタロールが有効になります。所有者とディレクタが同一サイトに存在すると、パフォーマンスが向上します。また、元の所有者が失敗した場合、ローカルなディレクタは同じサイトで新しい接続の所有者を選択します。グローバルなディレクタは、クラスタメンバーが別のサイトで所有される接続のパケットを受信する場合に使用されます。次のコマンドが導入または変更されました。director-localization、show asp table cluster chash、show conn、show conn detail
の 16 個のシャーシのサポート Firepower 4100 シリーズ	9.6(2)	Firepower 4100 シリーズでは最大 16 個のシャーシをクラスタに追加できるようになりました。変更されたコマンドはありません。
Firepower 4100 シリーズのサポート	9.6(1)	FXOS 1.1.4 では、ASA は最大 6 個のシャーシの Firepower 4100 シリーズでサイト間クラスタリングをサポートします。変更されたコマンドはありません。
ルーテッドおよびスパンド EtherChannel モードのサイト固有の IP アドレスのポート	9.6(1)	スパンド EtherChannel のルーテッドモードでのサイト間クラスタリングの場合、サイト個別の MAC アドレスに加えて、サイト個別の IP アドレスを設定できるようになりました。サイト IP アドレスを追加することにより、グローバル MAC アドレスからの ARP 応答を防止するために、ルーティング問題の原因になりかねない Data Center Interconnect（DCI）経由の移動によるオーバーレイトランスポート仮想化（OTV）デバイスの ARP 検査を使用することができます。MAC アドレスをフィルタ処理するために VACL を使用できないスイッチには、ARP 検査が必要です。次のコマンドが変更されました。mac-address、show interface
16 のモジュールのシャーシ間クラスタリング、および Firepower 9300 ASA アプリケーションのサイト間クラスタリング	9.5(2.1)	FXOS 1.1.3 では、シャーシ間、さらにサイト間クラスタリングを有効にできます。最大 16 のモジュールを搭載することができます。たとえば、16 のシャーシで 1 つのモジュールを使用したり、8 つのシャーシで 2 つのモジュールを使用して、最大 16 のモジュールを組み合わせることができます。変更されたコマンドはありません。
ルーテッドファイアウォールモードのスパンド EtherChannel のサイト間クラスタリングサポートのサイト別 MAC アドレス	9.5(2)	ルーテッドモードでは、スパンド EtherChannel サイト間クラスタリングを使用することができます。MAC アドレスのフラッピングを防ぐには、各インターフェイスのサイト別の MAC アドレスがサイトのユニット上で共有できるように、各クラスタメンバーのサイト ID を設定します。次のコマンドを導入または変更しました。site-id、mac-address site-id、show cluster info、show interface
インターフェイスまたはクラスタ制御リンクが失敗した場合の auto-rejoin 動作の ASA クラスタのカスタマイズ	9.5(2)	インターフェイスまたはクラスタ制御リンクが失敗した場合、auto-rejoin 動作をカスタマイズできます。次のコマンドを導入しました。 health-check auto-rejoin
ASA クラスタは、GTPv1 と GTPv2 をサポートします	9.5(2)	ASA クラスタは、GTPv1 および GTPv2 インスペクションをサポートします。変更されたコマンドはありません。
TCP 接続のクラスタ複製遅延	9.5(2)	この機能で、ディレクタ/バックアップフロー作成の遅延による存続期間が短いフローに関連する「不要な作業」を排除できます。次のコマンドを導入しました。cluster replication delay
サイト間フローモビリティの LISP インスペクション	9.5(2)	Cisco Locator/ID Separation Protocol（LISP）のアーキテクチャは、デバイス ID をその場所から 2 つの異なるナンバリングスペースに分離し、サーバの移行をクライアントに対して透過的にします。ASA は、場所変更の LISP トラフィックを検査し、その情報をシームレスなクラスタリング運用に活用できます。ASA クラスタメンバーは、最初のホップルータと出力トンネルルータまたは入力トンネルルータの間の LISP トラフィックを検査し、フローオーナーの所在場所を新規サイトに変更します。次のコマンドが導入または変更されました。allowed-eid、clear cluster info flow-mobility counters、clear lisp eid、cluster flow-mobility lisp、debug cluster flow-mobility、debug lisp eid-notify-intercept、flow-mobility lisp、inspect lisp、policy-map type inspect lisp、site-id、show asp table classify domain inspect-lisp、show cluster info flow-mobility counters、show conn、show lisp eid、show service-policy、validate-key
キャリアグレード NAT の強化は、フェールオーバーおよび ASA クラスタリングでサポートされます。	9.5(2)	キャリアグレードまたは大規模 PAT では、NAT に 1 度に 1 つのポート変換を割り当てさせるのではなく、各ホストにポートのブロックを割り当てることができます（RFC 6888 を参照してください）。この機能は、フェールオーバーおよび ASA クラスタの導入でサポートされます。次のコマンドが変更されました。show local-host
クラスタリングトレースエントリの設定可能なレベル	9.5(2)	デフォルトで、すべてのレベルクラスタリングイベントは、多くの下位レベルのイベント以外に、トレースバッファに含まれます。より上位レベルのイベントへのトレースを制限するために、クラスタの最小トレースレベルを設定できます。次のコマンドが導入されました。trace-level
Firepower 9300 用シャーシ内 ASA クラスタリング	9.4（1.150）	FirePOWER 9300 シャーシ内では、最大 3 つセキュリティモジュールをクラスタ化できます。シャーシ内のすべてのモジュールは、クラスタに属している必要があります。次のコマンドを導入しました。cluster replication delay、debug service-module、management-only individual、show cluster chassis

CLI ブック 1：Cisco ASA シリーズ 9.12 CLI コンフィギュレーション ガイド（一般的な操作）

偏向のない言語

翻訳について

検索結果

章のタイトル： Firepower 4100/9300 シャーシ の ASA クラスタ

Firepower 4100/9300 シャーシ の ASA クラスタ

Firepower 4100/9300 シャーシでのクラスタリングについて

ブートストラップ コンフィギュレーション

クラスタ メンバー

マスターおよびスレーブ ユニットの役割

クラスタ制御リンク

クラスタ制御リンクのサイズ

クラスタ制御リンク冗長性

クラスタ制御リンクの信頼性

クラスタ制御リンク ネットワーク

クラスタ インターフェイス

VSS または vPC への接続

設定の複製

ASA クラスタの管理

管理ネットワーク

管理インターフェイス

マスター ユニット管理とスレーブ ユニット管理

RSA キー複製

ASDM 接続証明書 IP アドレス不一致

スパンド EtherChannel（推奨）

サイト間クラスタリング

ASA の各機能とクラスタリング

クラスタリングでサポートされない機能

クラスタリングの中央集中型機能

個々のユニットに適用される機能

ネットワーク アクセス用の AAA とクラスタリング

FTP とクラスタリング

アイデンティティ ファイアウォールとクラスタリング

マルチキャスト ルーティングとクラスタリング

NAT とクラスタリング

ダイナミック ルーティングおよびクラスタリング

SCTP とクラスタリング

SIP インスペクションとクラスタリング

SNMP とクラスタリング

STUN とクラスタリング

syslog および NetFlow とクラスタリング

Cisco TrustSec とクラスタリング

FXOS シャーシ上の VPN とクラスタリング

Firepower 4100/9300 シャーシでのクラスタリングの要件と前提条件

モデルあたりの最大クラスタリング ユニット

インター シャーシ クラスタ化に関するハードウェアおよびソフトウェアの要件

スイッチ要件

上のクラスタリングのライセンス Firepower 4100/9300 シャーシ

分散型 S2S VPN のライセンス

クラスタリング ガイドラインと制限事項

シャーシ間クラスタリングのスイッチ

シャーシ間クラスタリングの EtherChannel

サイト間クラスタリング

その他のガイドライン

デフォルト

クラスタリングの設定 Firepower 4100/9300 シャーシ

手順

FXOS：ASA クラスタの追加

ASA クラスタの作成

始める前に

手順

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

例:

CLI ブック 1：Cisco ASA シリーズ 9.12 CLI コンフィギュレーションガイド（一般的な操作）

章のタイトル： Firepower 4100/9300 シャーシの ASA クラスタ

Firepower 4100/9300 シャーシの ASA クラスタ

ブートストラップコンフィギュレーション

クラスタメンバー

マスターおよびスレーブユニットの役割

クラスタ制御リンクネットワーク

クラスタインターフェイス

マスターユニット管理とスレーブユニット管理

ネットワークアクセス用の AAA とクラスタリング

アイデンティティファイアウォールとクラスタリング

マルチキャストルーティングとクラスタリング

ダイナミックルーティングおよびクラスタリング

モデルあたりの最大クラスタリングユニット

インターシャーシクラスタ化に関するハードウェアおよびソフトウェアの要件

クラスタリングガイドラインと制限事項

クラスタメンバの追加

ASA：ファイアウォールモードとコンテキストモードの変更

ASA：データインターフェイスの設定

のヘルスモニタリングおよび自動再結合の設定

ディレクタローカリゼーションの有効化

クラスタフローモビリティの設定

クラスタイベントの分散型 VPN の処理