論理デバイスについて
論理デバイスでは、1 つのアプリケーション インスタンス(ASA または Firepower Threat Defense のいずれか)および 1 つのオプション デコレータ アプリケーション(Radware DefensePro)を実行し、サービス チェーンを形成できます。
論理デバイスを追加する場合は、アプリケーション インスタンス タイプとバージョンを定義し、インターフェイスを割り当て、アプリケーション設定に送信されるブートストラップ設定を構成することもできます。
(注) |
Firepower 9300 の場合、シャーシ内のすべてのモジュールに同じアプリケーション インスタンス タイプ(ASA または Firepower Threat Defense)をインストールする必要があります。現時点では、他のタイプはサポートされていません。モジュールでは、異なるバージョンのアプリケーション インスタンス タイプを実行できます。 |
スタンドアロン論理デバイスとクラスタ化論理デバイス
次の論理デバイス タイプを追加することができます。
-
スタンドアロン:スタンドアロン論理デバイスはスタンドアロン ユニットまたはハイ アベイラビリティ ペアのユニットとして動作します。
-
クラスタ:クラスタ化論理デバイスを使用すると複数のユニットをグループ化することで、単一デバイスのすべての利便性(管理、ネットワークへの統合)を提供し、同時に複数デバイスによるスループットの向上と冗長性を実現できます。Firepower 9300 などの複数のモジュール デバイスが、シャーシ内クラスタリングをサポートします。Firepower 9300 のすべての 3 つのモジュール アプリケーション インスタンスは、1 つの論理デバイスに属しています。
(注)
Firepower 9300 の場合、すべてのモジュールがクラスタに属している必要があります。1 つのセキュリティ モジュールにスタンドアロン論理デバイスを作成し、残り 2 つのセキュリティ モジュールを使用してクラスタを作成することはできません。
コンテナ インスタンスとネイティブ インスタンス
アプリケーション インスタンスは次の展開タイプで実行します。
-
ネイティブ インスタンス:ネイティブ インスタンスはセキュリティモジュール/エンジンのすべてのリソース(CPU、RAM、およびディスク容量)を使用するため、ネイティブ インスタンスを 1 つのみインストールできます。
-
コンテナ インスタンス:コンテナ インスタンスでは、セキュリティモジュール/エンジンのリソースのサブセットを使用するため、複数のコンテナ インスタンスをインストールできます。マルチインスタンス機能は、Firepower Threat Defense でのみサポートされています。ASA ではサポートされていません。
(注)
マルチインスタンス機能は、実装は異なりますが、ASA マルチ コンテキスト モードに似ています。マルチ コンテキスト モードでは、単一のアプリケーション インスタンスがパーティション化されますが、マルチインスタンス機能では、独立したコンテナ インスタンスを使用できます。コンテナ インスタンスでは、ハード リソースの分離、個別の構成管理、個別のリロード、個別のソフトウェア アップデート、および Firepower Threat Defense のフル機能のサポートが可能です。マルチ コンテキスト モードでは、共有リソースのおかげで、特定のプラットフォームでより多くのコンテキストをサポートできます。マルチ コンテキスト モードは Firepower Threat Defense では利用できません。
Firepower 9300 の場合、一部のモジュールでネイティブ インスタンスを使用し、他のモジュールではコンテナ インスタンスを使用することができます。
コンテナ インスタンス インターフェイス
コンテナ インスタンスに対して柔軟な物理インターフェイスの使用を可能にするため、FXOS で VLAN サブインターフェイスを作成し、複数のインスタンス間でインターフェイス(VLAN または物理)を共有することもできます。ネイティブ インスタンスは VLAN サブインターフェイスまたは共有インターフェイスを使用できません。共有インターフェイスの拡張性およびコンテナ インスタンスの VLAN サブインターフェイスの追加を参照してください。
シャーシがパケットを分類する方法
シャーシに入ってくるパケットはいずれも分類する必要があります。その結果、シャーシは、どのインスタンスにパケットを送信するかを決定できます。
-
一意のインターフェイス:入力インターフェイスと関連付けられているインスタンスが 1 つのみの場合、シャーシはパケットをそのインスタンスに分類します。ブリッジ グループ メンバ インターフェイス(トランスペアレント モードまたはルーテッド モード)、インライン セット、またはパッシブ インターフェイスの場合は、この方法を常にパケットの分類に使用します。
-
一意の MAC アドレス:シャーシは、共有インターフェイスを含むすべてのインターフェイスに一意の MAC アドレスを自動的に生成します。複数のインスタンスが同じインターフェイスを共有している場合、分類子には各インスタンスでそのインターフェイスに割り当てられた一意の MAC アドレスが使用されます。一意の MAC アドレスがないと、アップストリーム ルータはインスタンスに直接ルーティングできません。アプリケーション内で各インターフェイスを設定するときに、手動で MAC アドレスを設定することもできます。ただし、MAC アドレスを手動で設定すると、サブインターフェイスを共有していない場合でも、分類が正しく行われるように、同じ親インターフェイス上のすべてのサブインターフェイスで一意の MAC アドレスを使用します。
(注) |
宛先 MAC アドレスがマルチキャストまたはブロードキャスト MAC アドレスの場合、パケットが複製されて各インスタンスに送信されます。 |
分類例
次の図に、外部インターフェイスを共有する複数のインスタンスを示します。インスタンス B にはルータがパケットを送信する MAC アドレスが含まれているため、分類子はパケットをインスタンス B に割り当てます。
内部ネットワークからのものを含め、新たに着信するトラフィックすべてが分類される点に注意してください。次の図に、インターネットにアクセスするネットワーク内のインスタンス C のホストを示します。分類子は、パケットをインスタンス C に割り当てます。これは、入力インターフェイスがイーサネット 1/2.3 で、このイーサネットがインスタンス C に割り当てられているためです。
トランスペアレント ファイアウォールでは、固有のインターフェイスを使用する必要があります。次の図に、ネットワーク内のインスタンス C のホストに向けられたインターネットからのパケットを示します。分類子は、パケットをインスタンス C に割り当てます。これは、入力インターフェイスがイーサネット 1/2.3 で、このイーサネットがインスタンス C に割り当てられているためです。
インライン セットの場合、一意のインターフェイスを使用する必要があり、そのインターフェイスは物理インターフェイスまたは Etherchannel である必要があります。次の図に、ネットワーク内のインスタンス C のホストに向けられたインターネットからのパケットを示します。分類子は、パケットをインスタンス C に割り当てます。これは、入力インターフェイスがイーサネット 1/5 で、このイーサネットがインスタンス C に割り当てられているためです。
コンテナ インスタンスのカスケード
コンテナ インスタンスを別のインスタンスの前に直接配置することをカスケード コンテナ インスタンスと呼びます。あるインスタンスの外部インターフェイスは別のインスタンスの内部インターフェイスと同じです。いくつかのインスタンスの設定を単純化する場合、最上位のインスタンスの共有パラメータを設定することで、インスタンスをカスケードできます。
次の図に、ゲートウェイの背後に 2 つのインスタンスがあるゲートウェイ インスタンスを示します。
一般的な複数インスタンス展開
次の例には、ルーテッド ファイアウォール モードでの 3 つのコンテナ インスタンスが含まれています。これには次のインターフェイスが含まれます。
-
管理:すべてのインスタンスがポートチャネル 1 インターフェイス(管理タイプ)を使用します。この EtherChannel には 2 つの 10 ギガビット イーサネット インターフェイスが含まれます。各アプリケーション内で、インターフェイスは同じ管理ネットワークで一意の IP アドレスを使用します。
-
内部:各インスタンスがポートチャネル 2(データ タイプ)のサブインターフェイスを使用します。この EtherChannel には 2 つの 10 ギガビット イーサネット インターフェイスが含まれます。各サブインターフェイスは別々のネットワーク上に存在します。
-
外部:すべてのインスタンスがポートチャネル 3 インターフェイス(データ共有タイプ)を使用します。この EtherChannel には 2 つの 10 ギガビット イーサネット インターフェイスが含まれます。各アプリケーション内で、インターフェイスは同じ管理ネットワークで一意の IP アドレスを使用します。
-
フェールオーバー:各インスタンスがポートチャネル 4(データ タイプ)のサブインターフェイスを使用します。この EtherChannel には 2 つの 10 ギガビット イーサネット インターフェイスが含まれます。各サブインターフェイスは別々のネットワーク上に存在します。
コンテナ インスタンス インターフェイスの自動 MAC アドレス
FXOS シャーシは、各インスタンスの共有インターフェイスが一意の MAC アドレスを使用するように、コンテナ インスタンス インターフェイスの MAC アドレスを自動的に生成します。
アプリケーション内の共有インターフェイスに MAC アドレスを手動で割り当てると、手動で割り当てられた MAC アドレスが使用されます。後で手動 MAC アドレスを削除すると、自動生成されたアドレスが使用されます。生成した MAC アドレスがネットワーク内の別のプライベート MAC アドレスと競合することがまれにあります。この場合は、アプリケーション内のインターフェイスの MAC アドレスを手動で設定してください。
自動生成されたアドレスは A2 で始まるため、アドレスが重複するリスクがあることから手動 MAC アドレスを A2 で始めることはできません。
(注) |
MAC アドレスを手動で設定すると、サブインターフェイスを共有していない場合でも、分類が正しく行われるように、同じ親インターフェイス上のすべてのサブインターフェイスで一意の MAC アドレスを使用します。 |
FXOS シャーシは、次の形式を使用して MAC アドレスを生成します。
A2xx.yyzz.zzzz
xx.yy はユーザ定義のプレフィックスまたはシステム定義のプレフィックスであり、zz.zzzz はシャーシが生成した内部カウンタです。システム定義のプレフィックスは、IDPROM にプログラムされている Burned-In MAC アドレス プール内の最初の MAC アドレスの下部 2 バイトと一致します。connect fxos を使用し、次に show module を使用して、MAC アドレス プールを表示します。たとえば、モジュール 1 について示されている MAC アドレスの範囲が b0aa.772f.f0b0 ~ b0aa.772f.f0bf の場合、システム プレフィックスは f0b0 になります。
ユーザ定義のプレフィックスは、16 進数に変換される整数です。ユーザ定義のプレフィックスの使用方法を示す例の場合、プレフィックス 77 を設定すると、シャーシは 77 を 16 進数値 004D(yyxx)に変換します。MAC アドレスで使用すると、プレフィックスはシャーシ ネイティブ形式に一致するように逆にされます(xxyy)。
A24D.00zz.zzzz
プレフィックス 1009(03F1)の場合、MAC アドレスは次のようになります。
A2F1.03zz.zzzz
コンテナ インスタンスのリソース管理
コンテナ インスタンスごとのリソース使用率を指定するには、FXOS で 1 つまたは複数のリソース プロファイルを作成します。論理デバイス/アプリケーション インスタンスを展開する場合は、使用するリソースのプロファイルを指定します。リソース プロファイルは CPU コアの数を設定します。RAM およびディスク容量はコアの数に従って動的に割り当てられます。モデルごとの使用可能なリソースを表示するには、コンテナ インスタンスの要件と前提条件を参照してください。リソース プロファイルを追加するには、コンテナ インスタンスのリソース プロファイルの追加を参照してください。
コンテナ インスタンスおよびハイ アベイラビリティ
2 つの個別のシャーシでコンテナ インスタンスを使用してハイ アベイラビリティを使用できます。たとえば、10 個のインスタンスを持つシャーシを 2 つ使用する場合は、10 個のハイ アベイラビリティ ペアを作成できます。FXOS では、ハイ アベイラビリティは設定されていないことに注意してください。アプリケーション マネージャで各ハイ アベイラビリティ ペアを設定します。
各ユニットで同じリソース プロファイル属性を使用する必要があります。
各ハイ アベイラビリティ ペアには専用のフェールオーバー リンクが必要です。データ共有インターフェイスを使用することはできません。親インターフェイスでサブインターフェイスを作成し、各インスタンスのサブインターフェイスを割り当てて、フェールオーバー リンクとして使用することをお勧めします。
(注) |
クラスタリングはサポートされません。 |