Firepower 4100/9300 シャーシでのクラスタリングについて
クラスタは、1 つの論理ユニットとして機能する複数のデバイスから構成されます。クラスタを Firepower 4100/9300 シャーシ に展開すると、以下の処理が実行されます。
-
ユニット間通信用のクラスタ制御リンク(デフォルトではポート チャネル 48)を作成します。シャーシ内クラスタリングでは(Firepower 9300のみ)、このリンクは、クラスタ通信に Firepower 9300 バックプレーンを使用します。シャーシ間クラスタリングでは、シャーシ間通信用にこの EtherChannel に物理インターフェイスを手動で割り当てる必要があります。
-
アプリケーション内のクラスタ ブートストラップ コンフィギュレーションを作成します。
クラスタを展開すると、クラスタ名、クラスタ制御リンク インターフェイス、およびその他のクラスタ設定を含む各ユニットに対して、最小限のブートストラップ コンフィギュレーションが Firepower 4100/9300 シャーシ スーパバイザからプッシュされます。
-
スパンド インターフェイスとして、クラスタにデータ インターフェイスを割り当てます。
シャーシ内クラスタリングでは、スパンド インターフェイスは、シャーシ間クラスタリングのように EtherChannel に制限されません。Firepower 9300 スーパーバイザは共有インターフェイスの複数のモジュールにトラフィックをロードバランシングするために内部で EtherChannel テクノロジーを使用するため、スパンド モードではあらゆるタイプのデータ インターフェイスが機能します。シャーシ間クラスタリングでは、すべてのデータ インターフェイスでスパンド EtherChannel を使用します。
(注)
管理インターフェイス以外の個々のインターフェイスはサポートされていません。
-
管理インターフェイスをクラスタ内のすべてのユニットに指定します。
ここでは、クラスタリングの概念と実装について詳しく説明します。
パフォーマンス スケーリング係数
複数のユニットをクラスタに結合した場合、期待できる合計クラスタ パフォーマンスの概算値は次のようになります。
-
TCP または CPS の合計スループットの 80 %
-
合計 UDP スループットの 90 %
-
トラフィックの組み合わせに応じて、イーサネット MIX(EMIX)の合計スループットの 60 %
たとえば、TCP スループットについては、3 つのモジュールを備えた Firepower 9300 が処理できる実際のファイアウォール トラフィックは、単独動作時は約 135 Gbps となります。2 シャーシの場合、合計スループットの最大値は約 270 Gbps(2 シャーシ × 135 Gbps)の 80 %、つまり 216 Gbps となります。
ブートストラップ コンフィギュレーション
クラスタを展開すると、クラスタ名、クラスタ制御リンク インターフェイス、およびその他のクラスタ設定を含む最小限のブートストラップ コンフィギュレーションが Firepower 4100/9300 シャーシ スーパバイザから各ユニットに対してプッシュされます。
クラスタ メンバー
クラスタ メンバーは連携して動作し、セキュリティ ポリシーおよびトラフィック フローの共有を達成します。ここでは、各メンバーのロールの特長について説明します。
マスターおよびスレーブ ユニットのロール
クラスタ内のメンバの 1 つがマスター ユニットです。マスター ユニットは自動的に決定されます。他のすべてのメンバはスレーブ ユニットです。
すべてのコンフィギュレーション作業はマスター ユニット上でのみ実行する必要があります。コンフィギュレーションはその後、スレーブ ユニットに複製されます。
機能によっては、クラスタ内でスケーリングしないものがあり、そのような機能についてはマスター ユニットがすべてのトラフィックを処理します。クラスタリングの中央集中型機能を参照してください。
マスター ユニット選定
クラスタのメンバは、クラスタ制御リンクを介して通信してマスター ユニットを選定します。方法は次のとおりです。
-
クラスタを展開すると、各ユニットは選定要求を 3 秒ごとにブロードキャストします。
-
プライオリティの高い他のユニットがこの選定要求に応答します。プライオリティはクラスタの展開時に設定され、設定の変更はできません。
-
45 秒経過しても、プライオリティの高い他のユニットからの応答を受信していない場合は、そのユニットがマスターになります。
-
後からクラスタに参加したユニットのプライオリティの方が高い場合でも、そのユニットが自動的にマスター ユニットになることはありません。既存のマスター ユニットは常にマスターのままです。ただし、マスター ユニットが応答を停止すると、その時点で新しいマスター ユニットが選定されます。
(注) |
特定のユニットを手動で強制的にマスターにすることができます。中央集中型機能については、マスター ユニット変更を強制するとすべての接続がドロップされるので、新しいマスター ユニット上で接続を再確立する必要があります。 |
クラスタ制御リンク
クラスタ制御リンクは、ポートチャネル 48 インターフェイスを使用して自動的に作成されます。シャーシ内クラスタリングでは、このインターフェイスにメンバ インターフェイスはありません。このクラスタ タイプの EtherChannel は、シャーシ内クラスタリング用のクラスタ通信に Firepower 9300 バックプレーンを使用します。
クラスタ制御リンク トラフィックには、制御とデータの両方のトラフィックが含まれます。
シャーシ間クラスタリングのクラスタ制御リンクのサイズ
可能であれば、各シャーシの予想されるスループットに合わせてクラスタ制御リンクをサイジングする必要があります。そうすれば、クラスタ制御リンクが最悪のシナリオを処理できます。
クラスタ制御リンク トラフィックの内容は主に、状態アップデートや転送されたパケットです。クラスタ制御リンクでのトラフィックの量は常に変化します。転送されるトラフィックの量は、ロード バランシングの有効性、または中央集中型機能のための十分なトラフィックがあるかどうかによって決まります。次に例を示します。
-
NAT では接続のロード バランシングが低下するので、すべてのリターン トラフィックを正しいユニットに再分散する必要があります。
-
メンバーシップが変更されると、クラスタは大量の接続の再分散を必要とするため、一時的にクラスタ制御リンクの帯域幅を大量に使用します。
クラスタ制御リンクの帯域幅を大きくすると、メンバーシップが変更されたときの収束が高速になり、スループットのボトルネックを回避できます。
(注) |
クラスタに大量の非対称(再分散された)トラフィックがある場合は、クラスタ制御リンクのサイズを大きくする必要があります。 |
シャーシ間クラスタリングのクラスタ制御リンク冗長性
次の図は、仮想スイッチング システム(VSS)または仮想ポート チャネル(vPC)環境でクラスタ制御リンクとして EtherChannel を使用する方法を示します。EtherChannel のすべてのリンクがアクティブです。スイッチが VSS または vPC の一部である場合は、同じ EtherChannel 内の Firepower 9300 シャーシ インターフェイスをそれぞれ、VSS または vPC 内の異なるスイッチに接続できます。スイッチ インターフェイスは同じ EtherChannel ポートチャネル インターフェイスのメンバです。複数の個別のスイッチが単一のスイッチのように動作するからです。この EtherChannel は、スパンド EtherChannel ではなく、デバイス ローカルであることに注意してください。
シャーシ間クラスタリングのクラスタ制御リンクの信頼性
クラスタ制御リンクの機能を保証するには、ユニット間のラウンドトリップ時間(RTT)が 20 ms 未満になるようにします。この最大遅延により、異なる地理的サイトにインストールされたクラスタ メンバとの互換性が向上します。遅延を調べるには、ユニット間のクラスタ制御リンクで ping を実行します。
クラスタ制御リンクは、順序の異常やパケットのドロップがない信頼性の高いものである必要があります。たとえば、サイト間の導入の場合、専用リンクを使用する必要があります。
クラスタ制御リンク ネットワーク
Firepower 4100/9300 シャーシは、シャーシ ID とスロット ID(127.2.chassis_id.slot_id)に基づいて、各ユニットのクラスタ制御リンク インターフェイスの IP アドレスを自動生成します。 この IP アドレスは、FXOS でもアプリケーション内でも手動で設定できません。クラスタ制御リンク ネットワークでは、ユニット間にルータを含めることはできません。レイヤ 2 スイッチングだけが許可されています。
管理ネットワーク
すべてのユニットを単一の管理ネットワークに接続することを推奨します。このネットワークは、クラスタ制御リンクとは別のものです。
管理インターフェイス
管理タイプのインターフェイスをクラスタに割り当てる必要があります。このインターフェイスはスパンド インターフェイスではなく、特別な個別インターフェイスです。管理インターフェイスによって各ユニットに直接接続できます。この管理論理インターフェイスはデバイスの他のインターフェイスから切り離されています。これは、Firepower Management Center にデバイスを設定し、登録するために使用されます。管理インターフェイスは、独自のローカル認証、IP アドレス、およびスタティック ルーティングを使用します。クラスタの各メンバーは、管理ネットワーク上で、それぞれに異なる IP アドレスを使用します。これらの IP アドレスは、ブートストラップ構成の一部としてユーザが設定します。
管理インターフェイスは、管理論理インターフェイスと診断論理インターフェイスの間で共有されます。診断論理インターフェイスはオプションであり、ブートストラップ構成の一部としては設定されません。診断インターフェイスは、他のデータ インターフェイスと併せて設定できます。診断インターフェイスを設定する場合、メイン クラスタ IP アドレスを、そのクラスタの固定アドレス(常に現在のマスター ユニットに属するアドレス)として設定します。アドレス範囲も設定して、現在のマスターを含む各ユニットがその範囲内のローカル アドレスを使用できるようにします。このメイン クラスタ IP アドレスによって、診断アクセスのアドレスが一本化されます。マスター ユニットが変更されると、メイン クラスタ IP アドレスは新しいマスター ユニットに移動するので、クラスタへのアクセスをシームレスに続行できます。TFTP や syslog などの発信管理トラフィックの場合、マスター ユニットを含む各ユニットは、ローカル IP アドレスを使用してサーバに接続します。
クラスタ インターフェイス
シャーシ内クラスタリングでは、物理インターフェイスと EtherChannel(ポート チャネルとも呼ばれる)の両方を割り当てることができます。クラスタに割り当てられたインターフェイスはクラスタ内のすべてのメンバーのトラフィックのロード バランシングを行うスパンド インターフェイスです。
シャーシ間クラスタリングでは、データ EtherChannel のみをクラスタに割り当てできます。これらのスパンド EtherChannel は、各シャーシの同じメンバー インターフェイスを含みます。上流に位置するスイッチでは、これらのインターフェイスはすべて単一の EtherChannel に含まれ、スイッチは複数のデバイスに接続されていることを察知しません。
管理インターフェイス以外の個々のインターフェイスはサポートされていません。
スパンド EtherChannel
シャーシあたり 1 つ以上のインターフェイスをグループ化して、クラスタのすべてのシャーシに広がる EtherChannel とすることができます。EtherChannel によって、チャネル内の使用可能なすべてのアクティブ インターフェイスのトラフィックが集約されます。スパンド EtherChannel は、ルーテッドとトランスペアレントのどちらのファイアウォール モードでも設定できます。ルーテッド モードでは、EtherChannel は単一の IP アドレスを持つルーテッド インターフェイスとして設定されます。トランスペアレント モードでは、IP アドレスはブリッジ グループ メンバのインターフェイスではなく BVI に割り当てられます。EtherChannel は初めから、ロード バランシング機能を基本的動作の一部として備えています。
VSS または vPC への接続
インターフェイスの冗長性を確保するため、EtherChannel を VSS または vPC に接続することを推奨します。
クラスタ内のハイ アベイラビリティ
クラスタリングは、シャーシ、ユニットとインターフェイスの正常性を監視し、ユニット間で接続状態を複製することにより、ハイ アベイラビリティを提供します。
シャーシ アプリケーションのモニタリング
シャーシ アプリケーションのヘルス モニタリングは常に有効になっています。Firepower 4100/9300 シャーシ スーパバイザは、Firepower Threat Defense アプリケーションを定期的に確認します(毎秒)。Firepower Threat Defense デバイス が作動中で、Firepower 4100/9300 シャーシ スーパバイザと 3 秒間通信できなければ、Firepower Threat Defense デバイス は syslog メッセージを生成して、クラスタを離れます。
Firepower 4100/9300 シャーシ スーパバイザが 45 秒後にアプリケーションと通信できなければ、Firepower Threat Defense デバイス をリロードします。Firepower Threat Defense デバイス がスーパバイザと通信できなければ、自身をクラスタから削除します。
装置のヘルス モニタリング
マスター ユニットは、各スレーブ ユニットをモニタするために、クラスタ制御リンク経由でキープアライブ メッセージを定期的に送信します。各スレーブ ユニットは、同じメカニズムを使用してマスター ユニットをモニタします。装置のヘルス チェックが不合格になると、その装置はクラスタから削除されます。
インターフェイス モニタリング
各ユニットは、使用中のすべてのハードウェア インターフェイスのリンク ステータスをモニタし、ステータス変更をマスター ユニットに報告します。シャーシ間クラスタリングでは、スパンド EtherChannel はクラスタ Link Aggregation Control Protocol(cLACP)を使用します。各シャーシは、EtherChannel でポートがアクティブかどうかを判断するためにリンク ステータスと cLACP プロトコル メッセージをモニタします。インターフェイスがダウンしている場合は、Firepower Threat Defense アプリケーションに通知します。ヘルス モニタリングを有効にすると、デフォルトですべての物理インターフェイスがモニタされます(EtherChannel インターフェイスの主要な EtherChannel を含む)。アップ状態の名前付きインターフェイスのみモニタできます。たとえば、名前付き EtherChannel がクラスタから削除されるまでは、EtherChannel のすべてのメンバー ポートは失敗しなければなりません。
あるモニタ対象のインターフェイスが、特定のユニット上では障害が発生したが、別のユニットではアクティブの場合は、そのユニットはクラスタから削除されます。Firepower Threat Defense デバイス がメンバーをクラスタから削除するまでの時間は、そのユニットが確立済みメンバーであるか、またはクラスタに参加しようとしているかによって異なります。Firepower Threat Defense デバイス は、ユニットがクラスタに参加する最初の 90 秒間はインターフェイスを監視しません。この間にインターフェイスのステータスが変化しても、Firepower Threat Defense デバイス はクラスタから削除されません。設定済みのメンバーの場合は、500 ミリ秒後にユニットが削除されます。
シャーシ間クラスタリングでは、クラスタから EtherChannel を追加または削除した場合、各シャーシに変更を加えられるように、インターフェイス ヘルス モニタリングは 95 秒間中断されます。
デコレータ アプリケーションのモニタリング
インターフェイスに Radware DefensePro アプリケーションなどのデコレータ アプリケーションをインストールした場合、ユニットがクラスタ内にとどまるには Firepower Threat Defense デバイス、デコレータ アプリケーションの両方が動作している必要があります。両方のアプリケーションが動作状態になるまで、ユニットはクラスタに参加しません。いったんクラスタに参加すると、ユニットはデコレータ アプリケーションが正しく動作しているか 3 秒ごとにモニタします。デコレータ アプリケーションがダウンすると、ユニットはクラスタから削除されます。
障害後のステータス
クラスタ内のユニットで障害が発生したときに、そのユニットでホスティングされている接続は他のユニットにシームレスに移管されます。トラフィック フローの状態情報は、クラスタ制御リンクを介して共有されます。
マスター ユニットで障害が発生した場合は、そのクラスタの他のメンバのうち、プライオリティが最高(番号が最小)のものがマスター ユニットになります。
障害イベントに応じて、Firepower Threat Defense デバイス は自動的にクラスタへの再参加を試みます。
(注) |
Firepower Threat Defense デバイス が非アクティブになり、クラスタへの自動再参加に失敗すると、すべてのデータ インターフェイスがシャットダウンされます。管理/診断インターフェイスのみがトラフィックを送受信できます。 |
クラスタへの再参加
クラスタ メンバがクラスタから削除された後、クラスタに再参加するための方法は、削除された理由によって異なります。
-
クラスタ制御リンクの障害:クラスタ制御リンクの問題を解決した後、クラスタリングを再び有効にして、手動でクラスタに再参加する必要があります。
-
データ インターフェイスの障害:Firepower Threat Defense アプリケーションは自動的に最初は 5 分後、次に 10 分後、最終的に 20 分後に再参加を試みます。20 分後に参加できない場合、Firepower Threat Defense アプリケーションはクラスタリングを無効にします。データ インターフェイスの問題を解決した後、手動でクラスタリングを有効にする必要があります。
-
ユニットの障害:ユニットがヘルス チェック失敗のためクラスタから削除された場合、クラスタへの再参加は失敗の原因によって異なります。たとえば、一時的な電源障害の場合は、クラスタ制御リンクが稼働している限り、ユニットは再起動するとクラスタに再参加します。Firepower Threat Defense アプリケーションは 5 秒ごとにクラスタへの再参加を試みます。
-
シャーシ アプリケーション通信の障害:Firepower Threat Defense アプリケーションはシャーシ アプリケーションの状態が回復したことを検出すると、自動的にクラスタへの再参加を試みます。
-
内部エラー:内部エラーには、アプリケーション同期のタイムアウト、一貫性のないアプリケーション ステータスなどがあります。問題の解決後、クラスタリングを再度有効にして手動でクラスタに再参加する必要があります。
データ パス接続状態の複製
どの接続にも、1 つのオーナーおよび少なくとも 1 つのバックアップ オーナーがクラスタ内にあります。バックアップ オーナーは、障害が発生しても接続を引き継ぎません。代わりに、TCP/UDP の状態情報を保存します。これは、障害発生時に接続が新しいオーナーにシームレスに移管されるようにするためです。バックアップ オーナーは通常ディレクタでもあります。
トラフィックの中には、TCP または UDP レイヤよりも上の状態情報を必要とするものがあります。この種類のトラフィックに対するクラスタリングのサポートの可否については、次の表を参照してください。
トラフィック |
状態のサポート |
注記(Notes) |
---|---|---|
アップ タイム |
○ |
システム アップ タイムをトラッキングします。 |
ARP テーブル |
○ |
— |
MAC アドレス テーブル |
○ |
— |
ユーザ ID |
○ |
— |
IPv6 ネイバー データベース |
○ |
— |
ダイナミック ルーティング |
○ |
— |
SNMP エンジン ID |
× |
— |
中央集中型 VPN(サイト間) |
× |
VPN セッションは、マスター ユニットで障害が発生すると切断されます。 |
コンフィギュレーションの複製
クラスタ内のすべてのユニットは、単一の設定を共有します。設定変更を加えることができるのはマスター ユニット上だけであり、変更は自動的にクラスタ内の他のすべてのユニットに同期されます。
クラスタが接続を管理する方法
接続をクラスタの複数のメンバーにロードバランスできます。接続のロールにより、通常動作時とハイ アベイラビリティ状況時の接続の処理方法が決まります。
接続ロール
各接続に定義されている次のロールを参照してください。
-
オーナー:通常、最初に接続を受信するユニット。オーナーは、TCP 状態を保持し、パケットを処理します。1 つの接続に対してオーナーは 1 つだけです。最初のオーナーに障害が発生すると、新しいユニットがその接続からパケットを受信したときに、ディレクタがそれらのユニットの中から新しいオーナーを選択します。
-
バックアップ オーナー:オーナーから受信した TCP/UDP 状態情報を保存して、障害発生時に接続を新しいオーナーにシームレスに転送できるようにするユニット。バックアップ オーナーは、障害発生時に接続を引き継ぎません。オーナーが使用不可能になった場合は、その接続からパケットを受け取る最初のユニット(ロード バランシングに基づく)がバックアップ オーナーに問い合わせて、関連する状態情報を取得します。これでそのユニットが新しいオーナーになることができます。
ディレクタ(下記参照)がオーナーと同じユニットでないかぎり、ディレクタもバックアップ オーナーです。オーナーが自分をディレクタとして選択した場合は、別のバックアップ オーナーが選択されます。
1 つのシャーシに最大で 3 つのクラスタ ユニットを格納できる Firepower 9300 でのシャーシ間クラスタリングでは、バックアップ オーナーがオーナーと同じシャーシに配置されている場合、シャーシの障害からフローを保護するために、別のシャーシから追加のバックアップ オーナーが選択されます。
-
ディレクタ:フォワーダからのオーナー ルックアップ要求を処理するユニット。オーナーが新しい接続を受信すると、オーナーは、送信元/宛先 IP アドレスおよびポートのハッシュに基づいてディレクタを選択し、新しい接続を登録するためにメッセージをそのディレクタに送信します。パケットがオーナー以外のユニットに到着した場合は、そのユニットはどのユニットがオーナーかをディレクタに問い合わせます。これで、パケットを転送できるようになります。1 つの接続に対してディレクタは 1 つだけです。ディレクタに障害が発生すると、オーナーは新しいディレクタを選択します。
ディレクタがオーナーと同じユニットでないかぎり、ディレクタもバックアップ オーナーです(上記参照)。オーナーが自分をディレクタとして選択した場合は、別のバックアップ オーナーが選択されます。
-
フォワーダ:パケットをオーナーに転送するユニット。フォワーダが接続のパケットを受信したときに、その接続のオーナーが自分ではない場合は、フォワーダはディレクタにオーナーを問い合わせてから、そのオーナーへのフローを確立します。これは、この接続に関してフォワーダが受信するその他のパケット用です。ディレクタは、フォワーダにもなることができます。フォワーダが SYN-ACK パケットを受信した場合、フォワーダはパケットの SYN クッキーからオーナーを直接取得できるので、ディレクタに問い合わせる必要がないことに注意してください。(TCP シーケンスのランダム化を無効にした場合は、SYN Cookie は使用されないので、ディレクタへの問い合わせが必要です)。存続期間が短いフロー(たとえば DNS や ICMP)の場合は、フォワーダは問い合わせの代わりにパケットを即座にディレクタに送信し、ディレクタがそのパケットをオーナーに送信します。1 つの接続に対して、複数のフォワーダが存在できます。最も効率的なスループットを実現できるのは、フォワーダが 1 つもなく、接続のすべてのパケットをオーナーが受信するという、優れたロードバランシング方法が使用されている場合です。
新しい接続の所有権
新しい接続がロード バランシング経由でクラスタのメンバに送信される場合は、そのユニットがその接続の両方向のオーナーとなります。接続のパケットが別のユニットに到着した場合は、そのパケットはクラスタ制御リンクを介してオーナー ユニットに転送されます。逆方向のフローが別のユニットに到着した場合は、元のユニットにリダイレクトされます。
サンプル データ フロー
次の例は、新しい接続の確立を示します。
-
SYN パケットがクライアントから発信され、Firepower Threat Defense デバイス の 1 つ(ロード バランシング方法に基づく)に配信されます。これがオーナーとなります。オーナーはフローを作成し、オーナー情報をエンコードして SYN Cookie を生成し、パケットをサーバに転送します。
-
SYN-ACK パケットがサーバから発信され、別の Firepower Threat Defense デバイス(ロード バランシング方法に基づく)に配信されます。この Firepower Threat Defense デバイス はフォワーダです。
-
フォワーダはこの接続を所有してはいないので、オーナー情報を SYN Cookie からデコードし、オーナーへの転送フローを作成し、SYN-ACK をオーナーに転送します。
-
オーナーはディレクタに状態アップデートを送信し、SYN-ACK をクライアントに転送します。
-
ディレクタは状態アップデートをオーナーから受信し、オーナーへのフローを作成し、オーナーと同様に TCP 状態情報を記録します。ディレクタは、この接続のバックアップ オーナーとしての役割を持ちます。
-
これ以降、フォワーダに配信されたパケットはすべて、オーナーに転送されます。
-
パケットがその他のユニットに配信された場合は、そのユニットはディレクタに問い合わせてオーナーを特定し、フローを確立します。
-
フローの状態が変化した場合は、状態アップデートがオーナーからディレクタに送信されます。
Firepower Threat Defense の機能とクラスタリング
Firepower Threat Defense の一部の機能はクラスタリングではサポートされず、一部はマスター ユニットのみでサポートされます。その他の機能については適切な使用に関する警告がある場合があります。
クラスタリングでサポートされない機能
これらの機能は、クラスタリングが有効なときは設定できず、コマンドは拒否されます。
-
サイト間 VPN
-
DHCP クライアント、サーバ、およびプロキシ。DHCP リレーはサポートされています。
-
高可用性
-
統合ルーティングおよびブリッジング
クラスタリングの中央集中型機能
次の機能は、マスター ユニット上だけでサポートされます。クラスタの場合もスケーリングされません。
(注) |
中央集中型機能のトラフィックは、クラスタ制御リンク経由でメンバ ユニットからマスター ユニットに転送されます。 再分散機能を使用する場合は、中央集中型機能のトラフィックが中央集中型機能として分類される前に再分散が行われて、マスター以外のユニットに転送されることがあります。この場合は、トラフィックがマスター ユニットに送り返されます。 中央集中型機能については、マスター ユニットで障害が発生するとすべての接続がドロップされるので、新しいマスター ユニット上で接続を再確立する必要があります。 |
-
次のアプリケーション インスペクション:
-
DCERPC
-
NetBIOS
-
RSH
-
SUNRPC
-
TFTP
-
XDMCP
-
-
ダイナミック ルーティング
-
スタティック ルート モニタリング
ダイナミック ルーティングとクラスタリング
ルーティング プロセスはマスター ユニット上だけで実行されます。ルートはマスター ユニットを介して学習され、セカンダリに複製されます。ルーティング パケットがスレーブに到着した場合は、マスター ユニットにリダイレクトされます。
スレーブ メンバがマスター ユニットからルートを学習した後は、各ユニットが個別に転送に関する判断を行います。
OSPF LSA データベースは、マスター ユニットからスレーブ ユニットに同期されません。マスター ユニットのスイッチオーバーが発生した場合は、隣接ルータが再起動を検出します。スイッチオーバーは透過的ではありません。OSPF プロセスが IP アドレスの 1 つをルータ ID として選択します。必須ではありませんが、スタティック ルータ ID を割り当てることができます。これで、同じルータ ID がクラスタ全体で使用されるようになります。割り込みを解決するには、OSPF ノンストップ フォワーディング機能を参照してください。
NAT とクラスタリング
NAT は、クラスタの全体的なスループットに影響を与えることがあります。インバウンドおよびアウトバウンドの NAT パケットが、クラスタ内のそれぞれ別の Firepower Threat Defense デバイス に送信されることがあります。ロード バランシング アルゴリズムは IP アドレスとポートに依存していますが、NAT が使用されるときは、インバウンドとアウトバウンドとで、パケットの IP アドレスやポートが異なるからです。接続のオーナーではない Firepower Threat Defense デバイス に到着したパケットは、クラスタ制御リンクを介してオーナーに転送されるので、大量のトラフィックがクラスタ制御リンク上で発生します。
それでもクラスタリングで NAT を使用する場合は、次のガイドラインを考慮してください。
-
ダイナミック PAT 用 NAT プール アドレス分散:マスター ユニットは、アドレスをクラスタ全体に均等に分配します。接続を受信したメンバーにアドレスが 1 つも残っていない場合、他のメンバーには使用可能なアドレスがまだ残っていても、接続はドロップされます。最低でも、クラスタ内のユニットと同数の NAT アドレスが含まれていることを確認してください。各ユニットが確実に 1 つのアドレスを受け取るようにするためです。
-
ラウンドロビンなし:PAT プールのラウンドロビンは、クラスタリングではサポートされません。
-
マスター ユニットによって管理されるダイナミック NAT xlate:マスター ユニットが xlate テーブルを維持し、スレーブ ユニットに複製します。ダイナミック NAT を必要とする接続をスレーブ ユニットが受信したときに、その xlate がテーブル内にない場合は、スレーブはマスター ユニットに xlate を要求します。スレーブ ユニットが接続を所有します。
-
次のインスペクション用のスタティック PAT はありません。
-
FTP
-
RSH
-
SQLNET
-
TFTP
-
XDMCP
-
SIP
-
SIP インスペクションとクラスタリング
制御フローは、任意のユニットで作成できますが(ロード バランシングのため)、その子データ フローは同じユニットに存在する必要があります。
syslog とクラスタリング
-
クラスタの各ユニットは自身の syslog メッセージを生成します。各ユニットの syslog メッセージ ヘッダー フィールドで使用されるデバイス ID を同一にするか、別にするかを設定できます。たとえば、ホスト名設定はクラスタ内のすべてのユニットに複製されて共有されます。ホスト名をデバイス ID として使用するようにロギングを設定した場合は、どのユニットで生成された syslog メッセージも 1 つのユニットからのように見えます。クラスタ ブートストラップ設定で割り当てられたローカル ユニット名をデバイス ID として使用するようにロギングを設定した場合は、syslog メッセージはそれぞれ別のユニットからのように見えます。
SNMP とクラスタリング
SNMP エージェントは、個々の Firepower Threat Defense デバイス を、その診断インターフェイスのローカル IP アドレスによってポーリングします。クラスタの統合データをポーリングすることはできません。
SNMP ポーリングには、メイン クラスタ IP アドレスではなく、常にローカル アドレスを使用してください。SNMP エージェントがメイン クラスタ IP アドレスをポーリングする場合は、新しいマスターが選定されたときに、新しいマスター ユニットのポーリングに失敗します。
FTP とクラスタリング
-
FTP D チャネルとコントロール チャネルのフローがそれぞれ別のクラスタ メンバーによって所有されている場合は、D チャネルのオーナーは定期的にアイドル タイムアウト アップデートをコントロール チャネルのオーナーに送信し、アイドル タイムアウト値を更新します。ただし、コントロール フローのオーナーがリロードされて、コントロール フローが再ホスティングされた場合は、親子フロー関係は維持されなくなります。したがって、コントロール フローのアイドル タイムアウトは更新されません。
Cisco TrustSec とクラスタリング
マスター ユニットだけがセキュリティ グループ タグ(SGT)情報を学習します。マスター ユニットからこの SGT がスレーブに渡されるので、スレーブは、セキュリティ ポリシーに基づいて SGT の一致決定を下せます。