高可用性 コンフィギュレーションの 2 台の装置は、次の条件を満たしている必要があります。

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

  Firepower 9300 の場合、高可用性は同じタイプのモジュール間でのみサポートされていますが、2 台のシャーシにモジュールを混在させることができます。たとえば、各シャーシには SM-56、SM-48、および SM-40 があります。SM-56 モジュール間、SM-48 モジュール間、および SM-40 モジュール間にハイアベイラビリティペアを作成できます。

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

  両方のユニットでプロファイルを同じにする必要がある確立されたハイアベイラビリティペアのインスタンスに異なるプロファイルを割り当てる場合、次の手順を実行する必要があります。

  1. ハイ アベイラビリティを解除します。

  2. 両方のユニットに新しいプロファイルを割り当てます。

  3. ハイアベイラビリティを再確立します。

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

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

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

高可用性 コンフィギュレーションの 2 台の装置は、次の条件を満たしている必要があります。

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

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

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

• 同じ NTP コンフィギュレーションであること。脅威に対する防御のための NTP 時刻同期の設定を参照してください。

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

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

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

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

ステートフル フェールオーバーを使用するには、接続ステート情報を渡すためのステートフル フェールオーバー リンク（ステート リンクとも呼ばれる）を設定する必要があります。

すべてのインターフェイスで同時に障害が発生する可能性を減らすために、フェールオーバー リンクとデータ インターフェイスは異なるパスを通すことを推奨します。フェールオーバー リンクがダウンしている場合、フェールオーバー動作は、フェールオーバー リンクが正常化するまで停止されます。

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

シナリオ 1：非推奨

単一のスイッチまたはスイッチ セットが 2 つの Firewall Threat Defense デバイス間のフェールオーバー インターフェイスとデータ インターフェイスの両方の接続に使用される場合、スイッチまたは Inter-Switch Link（ISL）がダウンすると、両方の Firewall Threat Defense デバイスがアクティブになります。したがって、次の図で示されている 2 つの接続方式は推奨しません。

シナリオ 2：推奨

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

シナリオ 3：推奨

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

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

• NAT 変換テーブル

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

• Snort 接続状態、インスペクションの結果、およびピン ホールに関する情報（TCP の厳密な適用を含む）。

• 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 接続上で動作するアプリケーションは、フェールオーバー プロセス中にパケットを失って、パケット損失から回復できない可能性があります。

• すべての接続から、確立された接続だけがスタンバイ デバイスに複製されます。

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

• GREv0 および IPv4-in-IP 以外のプレーンテキストトンネル内のセッション。トンネル内のセッションは複製されません。新しいアクティブ ノードでは、正しいポリシー ルールを照合するために既存のインスペクション判定を再利用することはできません。

• 復号された TLS/SSL 接続：復号状態は同期されず、アクティブユニットに障害が発生すると、復号された接続がリセットされます。新しいアクティブユニットへの新しい接続を確立する必要があります。復号されていない接続（つまり、TLS/SSL[復号しない（Do Not Decrypt）] ルールアクションに一致する）は影響を受けず、正しく複製されます。

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

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

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

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

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

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

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

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

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

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

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

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

しかし、プライマリである装置（コンフィギュレーションで指定）とセカンダリである装置との間で、いくつかの相違点があります。

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

• プライマリ装置の MAC アドレスは常にアクティブ IP アドレスと組み合わされます。このルールの例外は、セカンダリ装置がアクティブになり、フェールオーバー リンク経由でプライマリ装置の MAC アドレスを取得できない場合に発生します。この場合、セカンダリ装置の MAC アドレスが使用されます。

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

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

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

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

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

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