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

• 同じモデルであること。

• Firepower 4100/9300 シャーシ では、高可用性/ ペアの両方のユニットで同じインターフェイスが 高可用性/ 論理デバイスに割り当てられている必要があります。

• インターフェイスの数とタイプが同じであること。 Firepower 4100/9300 シャーシ では、高可用性/ を有効にする前に、すべてのインターフェイスが FXOS で同一に事前構成されている必要があります。

• スイッチを介して、10 GHz の光ファイバ ケーブルを使用して 2 つのユニットを接続することをお勧めします。

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

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

• ファイアウォール モードが同じであること（ルーテッドまたは透過）。

• ソフトウェア バージョンが、メジャー（最初の番号）、マイナー（2 番目の番号）およびメンテナンス（3 番目の番号）が同じであること。

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

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

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

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

ハイ アベイラビリティ構成での 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 接続状態

• Snort 接続状態

• 厳密な TCP の適用

• ARP テーブル

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

• HTTP 接続テーブル

• ISAKMP および IPSec SA テーブル

• SIP シグナリング セッション

• Snort インスペクション

• スタティック ルート

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

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

• DHCP サーバ（DHCP Server）

• ARP インスペクション

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

• URL

• 位置情報（GeoLocation）

• URL フィルタリング

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

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

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

• 復号されていない TLS セッション

• TLS URL

• ユーザ エージェント

• ISE のセッション ディレクトリ

• アイデンティティ/キャプティブ ポータル：既存のユーザ セッションは、フェールオーバー後に正しく動作します。フェールオーバーが発生した場合の進行中の認証には、キャプティブ ポータル フローとフェールオーバー スイッチの間の競合状態によって、2 つの起こりうる結果があります。

  • フェールオーバーが発生する前に、ユーザは認証していません。この場合、ブラウザ セッションは失敗します。更新の際、セッションは新しいアクティブ ユニットに移動し、キャプティブ ポータルの設定ページに戻されます。

  • ユーザはすでに元のアクティブ ユニットと認証されましたが、フェールオーバーが発生し、ブラウザ セッションが失敗します。更新の際、新しいアクティブ ユニットでもう一度認証するために、キャプティブ ポータルの設定ページに戻されます。

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

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

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

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

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

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

• IP レピュテーション

• URL レピュテーション

• DNS シンクホール

• フラグメント設定

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

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

• プレーン テキスト トンネル内のセッション

• 復号後のインスペクション

• TLS 復号状態

• DHCP クライアント

• DHCP サーバ アドレスのリース

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

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

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

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

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

装置が、2 回のポーリング期間中にモニタ対象のインターフェイス上で hello メッセージを受信しない場合、インターフェイス テストを実行します。1 つのインターフェイスに対するすべてのインターフェイス テストがすべて失敗したが、相手装置のこの同じインターフェイスが正常にトラフィックを渡し続けている場合、そのインターフェイスは故障していると見なされます。故障したインターフェイスがしきい値を超えている場合は、フェールオーバーが行われます。相手装置のインターフェイスでもすべてのネットワーク テストに失敗した場合、両方のインターフェイスは「Unknown」状態になり、フェールオーバーの限界値に向けてのカウントは行われません。

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

インターフェイスに IPv4 および IPv6 アドレスが設定されている場合、デバイスは IPv4 を使用してヘルス モニタリングを実行します。

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

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

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

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

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

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

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

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

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

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

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

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