ハイ アベイラビリティ コンフィギュレーションの 2 台の装置は、次の条件を満たしている必要があります。

• 同じモデルであること。 さらに、コンテナ インスタンスでは、同じリソース プロファイル属性を使用する必要があります。

  ハイ アベイラビリティ ペアを FMC に追加した後にリソース プロファイルを変更する場合は、[Devices] > [Device Management] > [Device] > [System] > [Inventory] ダイアログ ボックスで各ユニットのインベントリを更新します。

• インターフェイスの数とタイプが同じであること。

  プラットフォーム モード では、ハイ アベイラビリティ を有効にする前に、すべてのインターフェイスが FXOS で同一に事前構成されている必要があります。ハイ アベイラビリティを有効にした後でインターフェイスを変更する場合は、スタンバイ ユニットの FXOS でインターフェイスを変更し、アクティブ ユニットで同じ変更を行います。

ハイ アベイラビリティ コンフィギュレーションで装置に異なるサイズのフラッシュ メモリを使用している場合、小さい方のフラッシュ メモリを取り付けた装置に、ソフトウェア イメージ ファイルおよびコンフィギュレーション ファイルを格納できる十分な容量があることを確認してください。十分な容量がない場合、フラッシュ メモリの大きい装置からフラッシュ メモリの小さい装置にコンフィギュレーションの同期が行われると、失敗します。

ハイ アベイラビリティ コンフィギュレーションの 2 台の装置は、次の条件を満たしている必要があります。

• 同じファイアウォール モードにあること（ルーテッドまたはトランスペアレント）。

• ソフトウェア バージョンが同じであること。

• Firepower Management Center 上で、同じドメインまたはグループに入っていること。

• NTP 設定が同じであること。脅威に対する防御のための NTP 時刻同期の設定を参照してください。

• 非コミットの変更で、Firepower Management Center 上で完全に展開していること。

• どのインターフェイスでも、DHCP または PPPoE は変更していないこと。

• （Firepower 4100/9300）同じフロー オフロード モードを使用し、両方とも有効または無効になっている。

ハイ アベイラビリティ構成での Firepower Threat Defense デバイスは、すべて同じライセンスである必要があります。ハイ アベイラビリティを確立する前に、どのライセンスがセカンダリ/スタンバイ デバイスに割り当てられているかどうかは問題にはなりません。ハイ アベイラビリティの設定中に、Firepower Management Center はスタンバイに割り当てられている不要なライセンスをすべて削除し、プライマリ/アクティブ デバイスに割り当てられているのと同じライセンスで置き換えます。たとえば、アクティブ デバイスは基本ライセンスと Threat ライセンスであり、スタンバイ デバイスは基本ライセンスだけの場合、Firepower Management Center は Cisco Smart Software Manager と通信して、アカウントからスタンバイ デバイス用に使用可能な Threat ラインセンスを取得します。スマート ライセンス アカウントで十分な数の資格が購入されていなければ、正しい数のライセンスを購入するまで、アカウントは非準拠の状態になります。ハイ アベイラビリティ構成には、2 つのスマート ライセンス資格（ペアを構成するデバイスごとに 1 つ）が必要です。

フェールオーバー ペアの 2 台の装置は、フェールオーバー リンク経由で常に通信して、各装置の動作ステータスを確認しています。

すべてのインターフェイスで同時に障害が発生する可能性を減らすために、フェールオーバー リンクとデータ インターフェイスは異なるパスを通すことを推奨します。フェールオーバー リンクがダウンした場合、フェールオーバーが必要かどうかの決定に、Firepower Threat Defense デバイスはデータ インターフェイスを使用できます。その後、フェールオーバー動作は、フェールオーバー リンクの正常性が復元されるまで停止されます。

耐障害性フェールオーバー ネットワークの設計については、次の接続シナリオを参照してください。

シナリオ 1：非推奨

2 つの Firepower Threat Defense デバイス間のフェールオーバーとデータ インターフェイスの両方を接続するために 1 つのスイッチまたは一連のスイッチを使用している場合、スイッチまたはスイッチ間リンクがダウンしていると、両方の Firepower Threat Defense デバイスがアクティブになります。したがって、次の図で示されている 2 つの接続方式は推奨しません。

シナリオ 2：推奨

フェールオーバー リンクには、データ インターフェイスと同じスイッチを使用しないことを推奨します。代わりに、次の図に示すように、別のスイッチを使用するか直接ケーブルを使用して、フェールオーバー リンクを接続します。

シナリオ 3：推奨

Firepower Threat Defense データ インターフェイスが複数セットのスイッチに接続されている場合、フェールオーバー リンクはいずれかのスイッチに接続できます。できれば、次の図に示すように、ネットワークのセキュアな側（内側）のスイッチに接続します。

シナリオ 4：推奨

最も信頼性の高いフェールオーバー構成では、次の図に示すように、フェールオーバー リンクに冗長インターフェイスを使用します。

ステートフル フェールオーバーでは、次のステート情報がスタンバイ Firepower Threat Defense デバイスに渡されます。

• NAT 変換テーブル

• TCP 接続と UDP 接続、および HTTP 接続状態を含む状態。他のタイプの IP プロトコルおよび ICMP は、新しいパケットが到着したときに新しいアクティブ ユニットで確立されるため、アクティブ装置によって解析されません。

• 厳密な TCP 強制を含む、Snort の接続状態、インスペクション結果、およびピンホール情報。

• ARP テーブル

• レイヤ 2 ブリッジ テーブル（ブリッジ グループ用）

• ISAKMP および IPSec SA テーブル

• GTP PDP 接続データベース

• SIP シグナリング セッションとピンホール。

• スタティックおよびダイナミック ルーティング テーブル：ステートフル フェールオーバーはダイナミック ルーティング プロトコル（OSPF や EIGRP など）に参加するため、アクティブ装置上のダイナミック ルーティング プロトコルによる学習ルートが、スタンバイ装置のルーティング情報ベース（RIB）テーブルに維持されます。フェールオーバー イベントで、アクティブなセカンダリ ユニットには最初にプライマリ ユニットをミラーリングするルールがあるため、パケットは通常は最小限の中断でトラフィックに移動します。フェールオーバーの直後に、新しくアクティブになった装置で再コンバージェンス タイマーが開始されます。次に、RIB テーブルのエポック番号が増加します。再コンバージェンス中に、OSPF および EIGRP ルートは新しいエポック番号で更新されます。タイマーが期限切れになると、失効したルート エントリ（エポック番号によって決定される）はテーブルから削除されます。これで、RIB には新しくアクティブになった装置での最新のルーティング プロトコル転送情報が含まれています。

  （注）	ルートは、アクティブ装置上のリンクアップまたはリンクダウン イベントの場合のみ同期されます。スタンバイ装置上でリンクがアップまたはダウンすると、アクティブ装置から送信されたダイナミック ルートが失われることがあります。これは正常な予期された動作です。

• DHCP サーバ：DHCP アドレス リースは複製されません。ただし、インターフェイスで設定された DHCP サーバは、DHCP クライアントにアドレスを付与する前にアドレスが使用されていないことを確認するために ping を送信するため、サービスに影響はありません。ステート情報は、DHCP リレーまたは DDNS とは関連性がありません。

• アクセス コントロール ポリシーの判断：フェールオーバー時には、トラフィックの照合（URL、URL カテゴリ、地理位置情報など）、侵入検知、マルウェア、ファイル タイプに関する判断が保持されます。ただし、フェールオーバーの時点で評価される接続には、次のような注意事項があります。

  • AVC：App-ID 判定は複製されますが、検出状態は複製されません。フェールオーバーが発生する前に、App-ID 判定が完了および同期されていれば、正常に同期は行われます。

  • 侵入検知状態：フェールオーバーの際、フロー中にピックアップが発生すると、新しいインスペクションは完了しますが、古い状態は失われます。

  • ファイル マルウェア ブロッキング：ファイルの処分は、フェールオーバー前にできるようになる必要があります。

  • ファイル タイプ検出とブロッキング：ファイル タイプは、フェールオーバー前に特定される必要があります。元のアクティブ デバイスでファイルを特定している間にフェールオーバーが発生すると、ファイル タイプの同期は失われます。ファイル ポリシーでそのファイル タイプがブロックされている場合でも、新しいアクティブ デバイスはファイルをダウンロードします。

• ユーザ エージェントと ISE セッション ディレクトリを介してパッシブに収集されたユーザと IP アドレスのマッピングを含むアイデンティティ ポリシーや、キャプティブ ポータルを介したアクティブ認証の、ユーザ識別の判断。フェールオーバーの時点でアクティブ認証していたユーザには、再度認証を求めるプロンプトが表示されることがあります。

• ネットワーク AMP：クラウド ルックアップは各デバイスから独立しているため、一般的に、フェールオーバーはこの機能には影響しません。具体的には次のとおりです。

  • 署名ルックアップ：ファイルの送信中にフェールオーバーが発生した場合、ファイル イベントは生成されず、検出も発生しません。

  • ファイル ストレージ：ファイルの保存中にフェールオーバーが発生した場合、元のアクティブ デバイスに保存されます。ファイルの保存中に元のアクティブなデバイスがダウンした場合、ファイルは保存されません。

  • ファイルの事前分類（ローカル分析）：事前分類中にフェールオーバーが発生した場合、検出は失敗します。

  • ファイル ダイナミック分析（クラウドとの接続性）：フェールオーバーが発生しても、システムはクラウドにファイルを提出できます。

  • アーカイブ ファイル サポート：分析中にフェールオーバーが発生した場合、システムはファイル/アーカイブ内の可視性を失います。

  • カスタム ブラックリスト：フェールオーバーが発生した場合、イベントは生成されません。

• セキュリティ インテリジェンス判断。ただし、フェールオーバーの時点で処理されていた DNS ベースの判断は完了しません。

• RA VPN：リモート アクセス VPN エンド ユーザは、フェールオーバー後に VPN セッションを再認証または再接続する必要はありません。ただし、VPN 接続上で動作するアプリケーションは、フェールオーバー プロセス中にパケットを失って、パケット損失から回復できない可能性があります。

ステートフル フェールオーバーでは、次のステート情報はスタンバイ Firepower Threat Defense デバイスに渡されません。

• GRE や IP-in-IP などのプレーン テキスト トンネル内のセッション。トンネル内のセッションは複製されず、新しいアクティブ ノードは、既存のインスペクションの判定を再利用して、正しいポリシー ルールを照合することができません。

• SSL 復号ポリシーにより復号された接続：復号状態は同期されず、現在の復号された接続はリセットされ、ブロックされます。新しい接続が適切に機能します。（復号しないルールと一致する）復号されない接続は影響を受けず、他の TCP 接続と同様に正しく複製されます。

• TCP ステート バイパス接続

• マルチキャスト ルーティング。

Firepower Threat Defense デバイスは、hello メッセージでフェールオーバー リンクをモニタして相手装置のヘルスを判断します。フェールオーバー リンクで 3 回連続して hello メッセージを受信しなかったときは、フェールオーバー リンクを含む各データ インターフェイスで LANTEST メッセージを送信し、ピアが応答するかどうかを確認します。Firepower Threat Defense デバイスが行うアクションは、相手装置からの応答によって決まります。次の可能なアクションを参照してください。

• Firepower Threat Defense デバイスがフェールオーバー リンクで応答を受信した場合、フェールオーバーは行われません。

• Firepower Threat Defense デバイスがフェールオーバー リンクで応答を受信せず、データ インターフェイスで応答を受信した場合、装置のフェールオーバーは行われません。フェールオーバー リンクは故障とマークされます。フェールオーバー リンクがダウンしている間、装置はスタンバイにフェールオーバーできないため、できるだけ早くフェールオーバー リンクを復元する必要があります。

• Firepower Threat Defense デバイスがどのインターフェイスでも応答を受信しなかった場合、スタンバイ装置がアクティブ モードに切り替わり、相手装置を故障に分類します。

ユニットは、モニタ対象のインターフェイス上で 15 秒間 hello メッセージを受信しなかった場合に、インターフェイス テストを実行します。1 つのインターフェイスに対するインターフェイス テストのいずれかが失敗したものの、他のユニット上のこの同じインターフェイスが正常にトラフィックを渡し続けている場合は、そのインターフェイスに障害があるものと見なされ、デバイスはテストの実行を停止します。

障害が発生したインターフェイスの数に対して定義したしきい値が満たされ（[デバイス（Devices）] > [デバイス管理（Device Management）] > [ハイアベイラビリティ（High Availability）] > [フェールオーバートリガー条件（Failover Trigger Criteria）] を参照）、さらに、アクティブ ユニットでスタンバイ装置よりも多くの障害が発生した場合は、フェールオーバーが発生します。両方のユニット上のインターフェイスに障害が発生した場合は、両方のインターフェイスが「未知」状態になり、フェールオーバー インターフェイス ポリシーで定義されているフェールオーバー限界値に向けてのカウントは行われません。

インターフェイスは、何らかのトラフィックを受信すると、再度動作状態になります。故障したデバイスは、インターフェイス障害しきい値が満たされなくなった場合、スタンバイ モードに戻ります。

インターフェイスに IPv4 および IPv6 アドレスが設定されている場合、デバイスは IPv4 を使用してヘルス モニタリングを実行します。インターフェイスに IPv6 アドレスだけが設定されている場合、 デバイスは ARP ではなく IPv6 ネイバー探索を使用してヘルス モニタリング テストを実行します。ブロードキャスト ping テストの場合、デバイスは IPv6 全ノード アドレス（FE02::1）を使用します。

アクティブ/スタンバイ フェールオーバーを設定する場合、1 つのユニットをプライマリとして設定し、もう 1 つのユニットをセカンダリとして設定します。設定中に、プライマリ ユニットのポリシーは、セカンダリ ユニットに同期化されます。この時点で、2 つのユニットは、デバイスおよびポリシー設定に関して単一のデバイスとして機能します。ただし、イベント、ダッシュボード、レポートおよびヘルス モニタリングに関しては、別々のデバイスとして引き続き表示されます。

フェールオーバー ペアの 2 つのユニットの主な相違点は、どちらのユニットがアクティブでどちらのユニットがスタンバイであるか、つまりどちらの IP アドレスを使用するか、およびどちらのユニットがアクティブにトラフィックを渡すかということに関連します。

しかし、プライマリ ユニット（設定で指定）とセカンダリ ユニットとの間には、いくつかの相違点があります。

• 両方のユニットが同時にスタート アップした場合（さらに動作ヘルスが等しい場合）、プライマリ ユニットが常にアクティブ ユニットになります。

• プライマリ ユニットの MAC アドレスは常に、アクティブ IP アドレスと結び付けられています。このルールの例外は、セカンダリ ユニットがアクティブであり、フェールオーバー リンク経由でプライマリ ユニットの MAC アドレスを取得できない場合に発生します。この場合、セカンダリ ユニットの MAC アドレスが使用されます。

アクティブ装置は、次の条件で判別されます。

• 装置がブートされ、ピアがすでにアクティブとして動作中であることを検出すると、その装置はスタンバイ装置になります。

• 装置がブートされてピアを検出できないと、その装置はアクティブ装置になります。

• 両方の装置が同時に起動された場合は、プライマリ装置がアクティブ装置になり、セカンダリ装置がスタンバイ装置になります。

アクティブ/スタンバイ フェールオーバーでは、フェールオーバーはユニットごとに行われます。

次の表に、各障害イベントに対するフェールオーバー アクションを示します。この表には、各フェールオーバー イベントに対して、フェールオーバー ポリシー（フェールオーバーまたはフェールオーバーなし）、アクティブ ユニットが行うアクション、スタンバイ ユニットが行うアクション、およびフェールオーバー条件とアクションに関する特別な注意事項を示します。