ASA クラスタ

クラスタリングを利用すると、複数の ASA をグループ化して 1 つの論理デバイスとすることができます。クラスタは、単一デバイスのすべての利便性（管理、ネットワークへの統合）を備える一方で、複数デバイスによって高いスループットおよび冗長性を達成します。

（注）

一部の機能は、クラスタリングを使用する場合、サポートされません。クラスタリングでサポートされない機能を参照してください。

ASA クラスタリングの概要

ここでは、クラスタリングアーキテクチャとその動作について説明します。

ASA クラスタをネットワークに適合させる方法

クラスタは、1 つのユニットとして機能する複数の ASA から構成されます。ASA をクラスタとして機能させるには、次のインフラストラクチャが必要です。

クラスタ内通信用の、隔離された高速バックプレーンネットワーク。クラスタ制御リンクと呼ばれます。
各 ASA への管理アクセス（コンフィギュレーションおよびモニタリングのため）。

クラスタをネットワーク内に配置するときは、クラスタが送受信するデータのロードバランシングを、アップストリームおよびダウンストリームのルータが次のいずれかの方法でできることが必要です。

スパンド EtherChannel（推奨）：クラスタ内の複数のメンバのインターフェイスをグループ化して 1 つの EtherChannel とします。この EtherChannel がユニット間のロードバランシングを実行します。
ポリシーベースルーティング（ルーテッドファイアウォールモードのみ）：アップストリームとダウンストリームのルータが、ルートマップと ACL を使用してユニット間のロードバランシングを実行します。
等コストマルチパスルーティング（ルーテッドファイアウォールモードのみ）：アップストリームとダウンストリームのルータが、等コストのスタティックまたはダイナミックルートを使用してユニット間のロードバランシングを実行します。

パフォーマンススケーリング係数

複数のユニットを結合して 1 つのクラスタとしたときに、期待できるパフォーマンスの概算値は次のようになります。

合計スループットの 70 %
最大接続数の 60 %
接続数/秒の 50 %

たとえば、スループットについては、ASA 5585-X と SSP-40 が処理できる実際のファイアウォールトラフィックは、単独動作時は約 10 Gbps となります。8 ユニットのクラスタでは、合計スループットの最大値は約 80 Gbps（8 ユニット x 10 Gbps）の 70 %、つまり 56 Gbps となります。

クラスタメンバー

クラスタメンバーは連携して動作し、セキュリティポリシーおよびトラフィックフローの共有を達成します。ここでは、各メンバーのロールの特長について説明します。

Bootstrap Configuration

各デバイスで、最小限のブートストラップコンフィギュレーション（クラスタ名、クラスタ制御リンクインターフェイスなどのクラスタ設定）を設定します。クラスタリングを最初にイネーブルにしたユニットが一般的にはマスター ユニットとなります。以降のユニットに対してクラスタリングをイネーブルにすると、そのユニットはスレーブとしてクラスタに参加します。

マスターおよびスレーブユニットの役割

クラスタ内のメンバの 1 つがマスターユニットです。マスターユニットは、ブートストラップコンフィギュレーション内のプライオリティ設定によって決まります。プライオリティは 1 ～ 100 の範囲内で設定され、1 が最高のプライオリティです。他のすべてのメンバはスレーブユニットです。一般的には、クラスタを作成した後で最初に追加したユニットがマスターユニットとなります。これは単に、その時点でクラスタに存在する唯一のユニットであるからです。

すべてのコンフィギュレーション作業（ブートストラップコンフィギュレーションを除く）は、マスターユニット上のみで実行する必要があります。コンフィギュレーションは、スレーブユニットに複製されます。物理的資産（たとえばインターフェイス）の場合は、マスターユニットのコンフィギュレーションがすべてのスレーブユニット上でミラーリングされます。たとえば、GigabitEthernet 0/1 を内部インターフェイスとして、GigabitEthernet 0/0 を外部インターフェイスとして設定した場合は、これらのインターフェイスはスレーブユニット上でも、内部および外部のインターフェイスとして使用されます。

機能によっては、クラスタ内でスケーリングしないものがあり、そのような機能についてはマスターユニットがすべてのトラフィックを処理します。

マスターユニット選定

クラスタのメンバは、クラスタ制御リンクを介して通信してマスターユニットを選定します。方法は次のとおりです。

ユニットに対してクラスタリングをイネーブルにしたとき（または、クラスタリングがイネーブル済みの状態でそのユニットを初めて起動したとき）に、そのユニットは選定要求を 3 秒間隔でブロードキャストします。
プライオリティの高い他のユニットがこの選定要求に応答します。プライオリティは 1 ～ 100 の範囲内で設定され、1 が最高のプライオリティです。

45 秒経過しても、プライオリティの高い他のユニットからの応答を受信していない場合は、そのユニットがマスターになります。

（注）

最高のプライオリティを持つユニットが複数ある場合は、クラスタユニット名、次にシリアル番号を使用してマスターが決定されます。

後からクラスタに参加したユニットのプライオリティの方が高い場合でも、そのユニットが自動的にマスターユニットになることはありません。既存のマスターユニットは常にマスターのままです。ただし、マスターユニットが応答を停止すると、その時点で新しいマスターユニットが選定されます。

（注）

特定のユニットを手動で強制的にマスターにすることができます。中央集中型機能については、マスターユニット変更を強制するとすべての接続がドロップされるので、新しいマスターユニット上で接続を再確立する必要があります。

クラスタインターフェイス

データインターフェイスは、スパンド EtherChannel として設定することも、個別インターフェイスとして設定することもできます。1 つのクラスタ内のすべてのデータインターフェイスのタイプが同一であることが必要です。詳細については、「クラスタインターフェイスについて」を参照してください。

クラスタ制御リンク

各ユニットの、少なくとも 1 つのハードウェアインターフェイスをクラスタ制御リンク専用とする必要があります。詳細については、「クラスタ制御リンクについて」を参照してください。

ASA クラスタ内のハイアベイラビリティ

ASA クラスタリングは、ユニットとインターフェイスの正常性を監視し、ユニット間で接続状態を複製することにより、ハイアベイラビリティを提供します。

ユニットのヘルスモニタリング

マスターユニットは、各スレーブユニットをモニタするために、クラスタ制御リンクを介してハートビートメッセージを定期的に送信します（間隔は設定可能です）。各スレーブユニットは、同じメカニズムを使用してマスターユニットをモニタします。ユニットの健全性チェックが失敗すると、ユニットはクラスタから削除されます。

インターフェイスモニタリング

各ユニットは、使用中のすべての指名されたハードウェアインターフェイスのリンクステータスをモニタし、ステータス変更をマスターユニットに報告します。

スパンド EtherChannel：クラスタ Link Aggregation Control Protocol（cLACP）を使用します。各ユニットは、リンクステータスおよび cLACP プロトコルメッセージをモニタして、ポートがまだ EtherChannel でアクティブであるかどうかを判断します。ステータスがマスターユニットに報告されます。
個別インターフェイス（ルーテッドモードのみ）：各ユニットが自身のインターフェイスを自己モニタし、インターフェイスのステータスをマスターユニットに報告します。

ヘルスモニタリングをイネーブルにすると、すべての物理インターフェイス（主要な EtherChannel インターフェイスおよび冗長インターフェイスのタイプを含む）がデフォルトでモニタされるため、オプションでインターフェイスごとのモニタリングをディセーブルにすることができます。指名されたインターフェイスのみモニタできます。たとえば、指名された EtherChannel に障害が発生したと判断される必要がある場合、つまり、EtherChannel のすべてのメンバーポートはクラスタ削除をトリガーすることに失敗する必要があります（最小ポートバンドリング設定に応じて）。

ユニットのモニタ対象のインターフェイスが失敗した場合、そのユニットはクラスタから削除されます。ASA がメンバーをクラスタから削除するまでの時間は、インターフェイスのタイプと、そのユニットが確立済みメンバーであるか、またはクラスタに参加しようとしているかによって異なります。EtherChannel の場合（スパニングかどうかを問わない）は、確立済みメンバーのインターフェイスがダウン状態のときに、ASA はそのメンバーを 9 秒後に削除します。ASA は、ユニットがクラスタに参加する最初の 90 秒間はインターフェイスを監視ししません。この間にインターフェイスのステータスが変化しても、ASA はクラスタから削除されません。非 EtherChannel の場合は、メンバー状態に関係なく、ユニットは 500 ミリ秒後に削除されます。

障害後のステータス

クラスタ内のユニットで障害が発生したときに、そのユニットでホスティングされている接続は他のユニットにシームレスに移管されます。トラフィックフローのステート情報は、クラスタ制御リンクを介して共有されます。

マスターユニットで障害が発生した場合は、そのクラスタの他のメンバのうち、プライオリティが最高（番号が最小）のものがマスターユニットになります。

障害イベントに応じて、ASA は自動的にクラスタへの再参加を試みます。

（注）

ASA が非アクティブになり、クラスタへの自動再参加に失敗すると、すべてのデータインターフェイスがシャットダウンされます。管理専用インターフェイスのみがトラフィックを送受信できます。管理インターフェイスは、そのユニットがクラスタ IP プールから受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードする場合、クラスタでユニットがまだ非アクティブになっていると、管理インターフェイスはディセーブルになります。それ以降のコンフィギュレーション作業には、コンソールポートを使用する必要があります。

クラスタへの再参加

クラスタメンバがクラスタから削除された後、クラスタに再参加できる方法は、削除された理由によって異なります。

クラスタ制御リンクの障害：（最初の参加時）クラスタ制御リンクの問題を解決した後、コンソールポートで cluster group name と入力してから enable と入力して、クラスタリングを再びイネーブルにすることによって、手動でクラスタに再参加する必要があります。
クラスタに参加した後に障害が発生したクラスタ制御リンク：ASA は、無限に 5 分ごとに自動的に再参加を試みます。この動作は設定可能です。
データインターフェイスの障害：ASA は自動的に最初は 5 分後、次に 10 分後、最終的に 20 分後に再参加を試みます。20 分後に参加できない場合、ASA はクラスタリングをディセーブルにします。データインターフェイスの問題を解決した後、コンソールポートで cluster group name と入力してから enable と入力して、クラスタリングを手動でイネーブルにする必要があります。この動作は設定可能です。
ASA 5585-X 上の ASA FirePOWER モジュールの障害：ASA は自動的に 5 分後に再参加を試行します。
ASA FirePOWE ソフトウェアモジュールの障害：モジュールの問題を解決した後、コンソールポートで cluster group name と入力してから enable と入力して、手動でクラスタリングをイネーブルにする必要があります。
ユニットの障害：ユニットがヘルスチェック失敗のためクラスタから削除された場合、クラスタへの再参加は失敗の原因によって異なります。たとえば、一時的な電源障害の場合は、クラスタ制御リンクが稼働していて、クラスタリングが enable コマンドでまだイネーブルになっているなら、ユニットは再起動するとクラスタに再参加することを意味します。ASA は 5 秒ごとにクラスタへの再参加を試みます。
内部エラー：内部の障害には、アプリケーション同期のタイムアウト、矛盾したアプリケーションステータスなどがあります。ユニットは 5 分、10 分、および 20 分の間隔でクラスタに自動的に再参加を試行します。この動作は設定可能です。

マスターユニットのブートストラップの設定を参照してください。

データパス接続状態の複製

どの接続にも、1 つのオーナーおよび少なくとも 1 つのバックアップオーナーがクラスタ内にあります。バックアップオーナーは、障害が発生しても接続を引き継ぎません。代わりに、TCP/UDP のステート情報を保存します。これは、障害発生時に接続が新しいオーナーにシームレスに移管されるようにするためです。バックアップオーナーは通常ディレクタでもあります。

トラフィックの中には、TCP または UDP レイヤよりも上のステート情報を必要とするものがあります。この種類のトラフィックに対するクラスタリングのサポートの可否については、次の表を参照してください。

表 1. クラスタ全体で複製される機能
Traffic	状態のサポート	注意
Up time	Yes	システムアップタイムをトラッキングします。
ARP Table	あり	—
MAC アドレステーブル	あり	—
ユーザアイデンティティ	Yes	AAA ルール（uauth）とアイデンティティファイアウォールが含まれます。
IPv6 ネイバーデータベース	Yes	—
ダイナミックルーティング	Yes	—
SNMP エンジン ID	なし	—
集中型 VPN（サイト間）	なし	VPN セッションは、マスターユニットで障害が発生すると切断されます。
分散型 VPN（サイト間）	Yes	バックアップセッションがアクティブセッションになると、新しいバックアップセッションが作成されます。

設定の複製

クラスタ内のすべてのユニットは、単一のコンフィギュレーションを共有します。コンフィギュレーション変更を加えることができるのはマスターユニット上だけであり、変更は自動的にクラスタ内の他のすべてのユニットに同期されます。

ASA クラスタ管理

ASA クラスタリングを使用することの利点の 1 つは、管理のしやすさです。ここでは、クラスタを管理する方法について説明します。

管理ネットワーク

すべてのユニットを単一の管理ネットワークに接続することを推奨します。このネットワークは、クラスタ制御リンクとは別のものです。

管理インターフェイス

管理インターフェイスについては、専用管理インターフェイスの 1 つを使用することを推奨します。管理インターフェイスは、個別インターフェイスとして設定することも（ルーテッドモードとトランスペアレントモードの両方）、スパンド EtherChannel インターフェイスとして設定することもできます。

管理用には、個別インターフェイスを使用することを推奨します（スパンド EtherChannel をデータインターフェイスに使用している場合でも）。個別インターフェイスならば、必要に応じて各ユニットに直接接続できますが、スパンド EtherChannel インターフェイスでは、現在のマスターユニットへのリモート接続しかできません。

（注）

スパンド EtherChannel インターフェイスモードを使用しているときに、管理インターフェイスを個別インターフェイスとして設定する場合は、管理インターフェイスに対してダイナミックルーティングをイネーブルにすることはできません。スタティックルートを使用する必要があります。

個別インターフェイスの場合は、メインクラスタ IP アドレスはそのクラスタの固定アドレスであり、常に現在のマスターユニットに属します。インターフェイスごとに、管理者はアドレス範囲も設定します。これで、各ユニット（現在のマスターも含まれます）がその範囲内のローカルアドレスを使用できるようになります。このメインクラスタ IP アドレスによって、管理アクセスのアドレスが一本化されます。マスターユニットが変更されると、メインクラスタ IP アドレスは新しいマスターユニットに移動するので、クラスタの管理をシームレスに続行できます。ローカル IP アドレスは、ルーティングに使用され、トラブルシューティングにも役立ちます。

たとえば、クラスタを管理するにはメインクラスタ IP アドレスに接続します。このアドレスは常に、現在のマスターユニットに関連付けられています。個々のメンバを管理するには、ローカル IP アドレスに接続します。

TFTP や syslog などの発信管理トラフィックの場合、マスターユニットを含む各ユニットは、ローカル IP アドレスを使用してサーバに接続します。

スパンド EtherChannel インターフェイスの場合は、IP アドレスは 1 つだけ設定でき、その IP アドレスは常にマスターユニットに関連付けられます。EtherChannel インターフェイスを使用してスレーブユニットに直接接続することはできません。管理インターフェイスは個別インターフェイスとして設定することを推奨します。各ユニットに接続できるようにするためです。デバイスローカル EtherChannel を管理に使用できます。

マスターユニット管理とスレーブユニット管理

すべての管理とモニタリングはマスターユニットで実行できます。マスターユニットから、すべてのユニットの実行時統計情報やリソース使用状況などのモニタリング情報を調べることができます。また、クラスタ内のすべてのユニットに対してコマンドを発行することや、コンソールメッセージをスレーブユニットからマスターユニットに複製することもできます。

必要に応じて、スレーブユニットを直接モニタできます。マスターユニットからでもできますが、ファイル管理をスレーブユニット上で実行できます（コンフィギュレーションのバックアップや、イメージの更新など）。次の機能は、マスターユニットからは使用できません。

ユニットごとのクラスタ固有統計情報のモニタリング。
ユニットごとの Syslog モニタリング（コンソールレプリケーションが有効な場合にコンソールに送信される syslog を除く）。
SNMP
NetFlow

RSA キー複製

マスターユニット上で RSA キーを作成すると、そのキーはすべてのスレーブユニットに複製されます。メインクラスタ IP アドレスへの SSH セッションがある場合に、マスターユニットで障害が発生すると接続が切断されます。新しいマスターユニットは、SSH 接続に対して同じキーを使用するので、新しいマスターユニットに再接続するときに、キャッシュ済みの SSH ホストキーを更新する必要はありません。

ASDM 接続証明書 IP アドレス不一致

デフォルトでは、自己署名証明書は、ローカル IP アドレスに基づいて ASDM 接続に使用されます。ASDM を使用してメインクラスタ IP アドレスに接続する場合は、IP アドレス不一致に関する警告メッセージが表示されます。これは、証明書で使用されているのがローカル IP アドレスであり、メインクラスタ IP アドレスではないからです。このメッセージは無視して、ASDM 接続を確立できます。ただし、この種の警告を回避するには、新しい証明書を登録し、この中でメインクラスタ IP アドレスと、IP アドレスプールからのすべてのローカル IP アドレスを指定します。この証明書を各クラスタメンバに使用します。

サイト間クラスタリング

サイト間インストールの場合、推奨されるガイドラインに従っていれば、ASA クラスタリングを活用できます。

各クラスタシャーシを個別のサイト ID に属するように設定できます。

サイト ID は、サイト固有の MAC アドレスおよび IP アドレスと連動します。クラスタから送信されたパケットは、サイト固有の MAC アドレスおよび IP アドレスを使用するのに対し、クラスタで受信したパケットは、グローバル MAC アドレスおよび IP アドレスを使用します。この機能により、MAC フラッピングの原因となる 2 つの異なるポートで両方のサイトから同じグローバル MAC アドレスをスイッチが学習するのを防止します。代わりに、スイッチはサイトの MAC アドレスのみを学習します。サイト固有の MAC アドレスおよび IP アドレスは、スパンド EtherChannel のみを使用したルーテッドモードでサポートされます。

サイト ID は、LISP インスペクションを使用したフローモビリティの有効化、データセンターのサイト間クラスタリングのパフォーマンス向上とラウンドトリップ時間の遅延短縮のためのディレクタローカリゼーションの有効化、およびトラフィックフローのバックアップオーナーが常にオーナーとは異なるサイトに存在する接続に対するサイト冗長性の有効化のためにも使用されます。

サイト間クラスタリングの詳細については、以下の項を参照してください。

Data Center Interconnect のサイジング：ASA クラスタリングの要件と前提条件
サイト間のガイドライン：ASA クラスタリングのガイドライン
クラスタフローモビリティの設定：クラスタフローモビリティの設定
ディレクタローカリゼーションの有効化：ディレクタローカリゼーションの有効化
サイト冗長性の有効化：ディレクタローカリゼーションの有効化
サイト間の例：サイト間クラスタリングの例

ASA クラスタが接続を管理する方法

接続をクラスタの複数のメンバにロードバランスできます。接続のロールにより、通常動作時とハイアベイラビリティ状況時の接続の処理方法が決まります。

接続のロール

接続ごとに定義された次のロールを参照してください。

オーナー：通常、最初に接続を受信するユニット。オーナーは、TCP 状態を保持し、パケットを処理します。1 つの接続に対してオーナーは 1 つだけです。元のオーナーに障害が発生すると、新しいユニットが接続からパケットを受信したときにディレクタがこれらのユニットの新しいオーナーを選択します。
バックアップオーナー：オーナーから受信した TCP/UDP ステート情報を格納するユニット。これにより、障害が発生した場合に新しいオーナーにシームレスに接続を転送できます。バックアップオーナーは、障害発生時に接続を引き継ぎません。オーナーが使用不可能になった場合は、その接続からパケットを受け取る最初のユニット（ロードバランシングに基づく）がバックアップオーナーに問い合わせて、関連するステート情報を取得し、これでそのユニットが新しいオーナーになることができます。

ディレクタ（下記参照）がオーナーと同じユニットでない限り、ディレクタはバックアップオーナーでもあります。オーナーがディレクタとして自分自身を選択すると、別のバックアップオーナーが選択されます。

1 台のシャーシに最大 3 つのクラスタユニットを搭載できる Firepower 9300 のシャーシ間クラスタリングでは、バックアップオーナーがオーナーと同じシャーシにある場合、シャーシ障害からフローを保護するために、別のシャーシから追加のバックアップオーナーが選択されます。

サイト間クラスタリングのディレクタローカリゼーションを有効にすると、ローカルバックアップとグローバルバックアップの 2 つのバックアップオーナー権限があります。オーナーは、常に同じサイトのローカルバックアップをオーナー自身として選択します（サイト ID に基づいて）。グローバルバックアップはどのサイトにあってもよく、ローカルバックアップと同一のユニットとすることもできます。オーナーは、両方のバックアップへ接続ステート情報を送信します。

サイトの冗長性を有効にし、バックアップオーナーがオーナーと同じサイトにある場合は、サイトの障害からフローを保護するために、追加のバックアップオーナーが別のサイトから選択されます。シャーシバックアップとサイトバックアップは独立しているため、フローにはシャーシバックアップとサイトバックアップの両方が含まれている場合があります。
ディレクタ：フォワーダからのオーナールックアップ要求を処理するユニット。オーナーが新しい接続を受信すると、オーナーは、送信元/宛先 IP アドレスおよびポートのハッシュに基づいてディレクタを選択し、新しい接続を登録するためにメッセージをそのディレクタに送信します。パケットがオーナー以外のユニットに到着した場合は、そのユニットはどのユニットがオーナーかをディレクタに問い合わせます。これで、パケットを転送できるようになります。1 つの接続に対してディレクタは 1 つだけです。ディレクタが失敗すると、オーナーは新しいディレクタを選択します。

ディレクタがオーナーと同じユニットでない限り、ディレクタはバックアップオーナーでもあります（上記参照）。オーナーがディレクタとして自分自身を選択すると、別のバックアップオーナーが選択されます。

サイト間クラスタリングのディレクタローカリゼーションを有効にすると、ローカルディレクタとグローバルディレクタの 2 つのディレクタ権限が区別されます。オーナーは、同一サイト（Site Id に基づき）のローカルディレクタとして、常にオーナー自身を選択します。グローバルディレクタはどのサイトにあってもよく、ローカルディレクタと同一のユニットとすることもできます。元のオーナーに障害が発生すると、ローカルディレクタはこのサイトで新しい接続オーナーを選択します。
フォワーダ：パケットをオーナーに転送するユニット。フォワーダが接続のパケットを受信したときに、その接続のオーナーが自分ではない場合は、フォワーダはディレクタにオーナーを問い合わせてから、そのオーナーへのフローを確立します。これは、この接続に関してフォワーダが受信するその他のパケット用です。ディレクタは、フォワーダにもなることができます。ディレクタローカリゼーションを有効にすると、フォワーダは常にローカルディレクタに問い合わせを行います。フォワーダがグローバルディレクタに問い合わせを行うのは、ローカルディレクタがオーナーを認識していない場合だけです。たとえば、別のサイトで所有されている接続のパケットをクラスタメンバが受信する場合などです。フォワーダが SYN-ACK パケットを受信した場合、フォワーダはパケットの SYN クッキーからオーナーを直接取得できるので、ディレクタに問い合わせる必要がないことに注意してください（TCP シーケンスのランダム化をディセーブルにした場合は、SYN Cookie は使用されないので、ディレクタへの問い合わせが必要です）。存続期間が短いフロー（たとえば DNS や ICMP）の場合は、フォワーダは問い合わせの代わりにパケットを即座にディレクタに送信し、ディレクタがそのパケットをオーナーに送信します。1 つの接続に対して、複数のフォワーダが存在できます。最も効率的なスループットを実現できるのは、フォワーダが 1 つもなく、接続のすべてのパケットをオーナーが受信するという、優れたロードバランシング方法が使用されている場合です。

接続でポートアドレス変換（PAT）を使用すると、PAT のタイプ（per-session または multi-session）が、クラスタのどのメンバが新しい接続のオーナーになるかに影響します。

Per-session PAT：オーナーは、接続の最初のパケットを受信するユニットです。

デフォルトでは、TCP および DNS UDP トラフィックは per-session PAT を使用します。
Multi-session PAT：オーナーは常にマスターユニットです。multi-session PAT 接続がスレーブユニットで最初に受信される場合、スレーブユニットはその接続をマスターユニットに転送します。

デフォルトでは、UDP（DNS UDP を除く）および ICMP トラフィックは multi-session PAT を使用するので、これらの接続は常にマスターユニットによって所有されています。

TCP および UDP の per-session PAT デフォルトを変更できるので、これらのプロトコルの接続は、その設定に応じて per-session または multi-session で処理されます。ICMP の場合は、デフォルトの multi-session PAT から変更することはできません。per-session PAT の詳細については、ファイアウォールの設定ガイドを参照してください。

新しい接続の所有権

新しい接続がロードバランシング経由でクラスタのメンバに送信される場合は、そのユニットがその接続の両方向のオーナーとなります。接続のパケットが別のユニットに到着した場合は、そのパケットはクラスタ制御リンクを介してオーナーユニットに転送されます。最適なパフォーマンスを得るには、適切な外部ロードバランシングが必要です。1 つのフローの両方向が同じユニットに到着するとともに、フローがユニット間に均等に分散されるようにするためです。逆方向のフローが別のユニットに到着した場合は、元のユニットにリダイレクトされます。

サンプルデータフロー

次の例は、新しい接続の確立を示します。

SYN パケットがクライアントから発信され、ASA の 1 つ（ロードバランシング方法に基づく）に配信されます。これがオーナーとなります。オーナーはフローを作成し、オーナー情報をエンコードして SYN Cookie を生成し、パケットをサーバに転送します。
SYN-ACK パケットがサーバから発信され、別の ASA（ロードバランシング方法に基づく）に配信されます。この ASA はフォワーダです。
フォワーダはこの接続を所有してはいないので、オーナー情報を SYN Cookie からデコードし、オーナーへの転送フローを作成し、SYN-ACK をオーナーに転送します。
オーナーはディレクタに状態アップデートを送信し、SYN-ACK をクライアントに転送します。
ディレクタは状態アップデートをオーナーから受信し、オーナーへのフローを作成し、オーナーと同様に TCP ステート情報を記録します。ディレクタは、この接続のバックアップオーナーとしての役割を持ちます。
これ以降、フォワーダに配信されたパケットはすべて、オーナーに転送されます。
パケットがその他のユニットに配信された場合は、そのユニットはディレクタに問い合わせてオーナーを特定し、フローを確立します。
フローの状態が変化した場合は、状態アップデートがオーナーからディレクタに送信されます。

新しい TCP 接続のクラスタ全体での再分散

アップストリームまたはダウンストリームルータによるロードバランシングの結果として、フロー分散に偏りが生じた場合は、新しい TCP フローを過負荷のユニットから他のユニットにリダイレクトするように設定できます。既存のフローは他のユニットには移動されません。

ASA の各機能とクラスタリング

ASA の一部の機能は ASA クラスタリングではサポートされず、一部はマスターユニットだけでサポートされます。その他の機能については適切な使用に関する警告がある場合があります。

クラスタリングでサポートされない機能

これらの機能は、クラスタリングがイネーブルのときは設定できず、コマンドは拒否されます。

TLS プロキシを使用するユニファイドコミュニケーション機能
リモートアクセス VPN（SSL VPN および IPSec VPN）
次のアプリケーションインスペクション：
- CTIQBE
- H323、H225、および RAS
- IPsec パススルー
- MGCP
- MMP
- RTSP
- SCCP（Skinny）
- WAAS
- WCCP
Botnet Traffic Filter
Auto Update Server
DHCP クライアント、サーバ、およびプロキシDHCP リレーがサポートされている。
VPN ロードバランシング
フェールオーバー
ASA CX モジュール
Integrated Routing and Bridging（IRB）

クラスタリングの中央集中型機能

次の機能は、マスターユニット上だけでサポートされます。クラスタの場合もスケーリングされません。たとえば、8 ユニット（5585-X と SSP-60）から成るクラスタがあるとします。Other VPN ライセンスでは、1 台の ASA 5585-X と SSP-60 に対して許可されるサイト間 IPsec トンネルの最大数は 10,000 です。8 ユニットクラスタ全体で使用できるトンネル数は 10,000 までです。この機能はスケーリングしません。

（注）

中央集中型機能のトラフィックは、クラスタ制御リンク経由でメンバユニットからマスターユニットに転送されます。

再分散機能を使用する場合は、中央集中型機能のトラフィックが中央集中型機能として分類される前に再分散が行われて、マスター以外のユニットに転送されることがあります。この場合は、トラフィックがマスターユニットに送り返されます。

中央集中型機能については、マスターユニットで障害が発生するとすべての接続がドロップされるので、新しいマスターユニット上で接続を再確立する必要があります。

サイト間 VPN
次のアプリケーションインスペクション：
- DCERPC
- ESMTP
- IM
- NetBIOS
- PPTP
- RADIUS
- RSH
- SNMP
- SQLNET
- SUNRPC
- TFTP
- XDMCP
ダイナミックルーティング（スパンド EtherChannel モードのみ）
マルチキャストルーティング（個別インターフェイスモードのみ）
スタティックルートモニタリング
IGMP マルチキャストコントロールプレーンプロトコル処理（データプレーンフォワーディングはクラスタ全体に分散されます）
PIM マルチキャストコントロールプレーンプロトコル処理（データプレーンフォワーディングはクラスタ全体に分散されます）
ネットワークアクセスの認証および許可。アカウンティングは非集中型です。
フィルタリングサービス

個々のユニットに適用される機能

これらの機能は、クラスタ全体またはマスターユニットではなく、各 ASA ユニットに適用されます。

QoS：QoS ポリシーは、コンフィギュレーション複製の一部としてクラスタ全体で同期されます。ただし、ポリシーは、各ユニットに対して個別に適用されます。たとえば、出力に対してポリシングを設定する場合は、適合レートおよび適合バースト値は、特定の ASA から出て行くトラフィックに適用されます。3 ユニットから成るクラスタがあり、トラフィックが均等に分散している場合は、適合レートは実際にクラスタのレートの 3 倍になります。
脅威検出：脅威検出は、各ユニットに対して個別に機能します。たとえば、上位統計情報は、ユニット別です。たとえば、ポートスキャン検出が機能しないのは、スキャントラフィックが全ユニット間で分散されるので、1 つのユニットがすべてのトラフィックを読み取ることはないからです。
リソース管理：マルチコンテキストモードでのリソース管理は、ローカル使用状況に基づいて各ユニットに個別に適用されます。
LISP トラフィック：UDP ポート 4342 上の LISP トラフィックは、各受信ユニットによって検査されますが、ディレクタは割り当てられません。各ユニットは、クラスタ間で共有される EID テーブルに追加されますが、LISP トラフィック自体はクラスタ状態の共有に参加しません。

ASA Firepower モジュール：ASA Firepower モジュール間でのコンフィギュレーションの同期や状態の共有は行われません。Firepower Management Center を使用して、クラスタ内の ASA Firepower モジュールで一貫したポリシーを保持する必要があります。クラスタ内のデバイスに異なる ASA インターフェイスベースのゾーン定義を使用しないでください。
ASA IPS モジュール：IPS モジュール間でのコンフィギュレーションの同期や状態の共有は行われません。IPS シグニチャによっては、IPS が複数の接続にわたって状態を保持することが必要になります。たとえば、ポートスキャンシグニチャが使用されるのは、同じ人物が同じサーバへの多数の接続を、それぞれ異なるポートを使用して開いていることを IPS モジュールが検出した場合です。クラスタリングでは、これらの接続は複数の ASA デバイス間で分散されます。これらのデバイスそれぞれに専用の IPS モジュールがあります。これらの IPS モジュールはステート情報を共有しないので、結果としてのポートスキャンをクラスタが検出できない場合があります。

ネットワークアクセス用の AAA とクラスタリング

ネットワークアクセス用の AAA は、認証、許可、アカウンティングの 3 つのコンポーネントで構成されます。認証および許可は、クラスタリングマスター上で中央集中型機能として実装されており、データ構造がクラスタスレーブに複製されます。マスターが選定されたときは、確立済みの認証済みユーザおよびユーザに関連付けられた許可を引き続き中断なく運用するのに必要なすべての情報を、新しいマスターが保有します。ユーザ認証のアイドルおよび絶対タイムアウトは、マスターユニット変更が発生したときも維持されます。

アカウンティングは、クラスタ内の分散型機能として実装されています。アカウンティングはフロー単位で実行されるので、フローを所有するクラスタユニットがアカウンティング開始と停止のメッセージを AAA サーバに送信します（フローに対するアカウンティングが設定されているとき）。

FTP とクラスタリング

FTP データチャネルとコントロールチャネルのフローがそれぞれ別のクラスタメンバよって所有されている場合は、データチャネルのオーナーは定期的にアイドルタイムアウトアップデートをコントロールチャネルのオーナーに送信し、アイドルタイムアウト値を更新します。ただし、コントロールフローのオーナーがリロードされて、コントロールフローが再ホスティングされた場合は、親子フロー関係は維持されなくなります。したがって、コントロールフローのアイドルタイムアウトは更新されません。
FTP アクセスに AAA を使用している場合、制御チャネルのフローはマスターユニットに集中化されます。

アイデンティティファイアウォールとクラスタリング

マスターユニットのみが AD から user-group を取得し、AD エージェントから user-ip マッピングを取得します。マスターユニットからユーザ情報がスレーブに渡されるので、スレーブは、セキュリティポリシーに基づいてユーザ ID の一致の決定を行うことができます。

マルチキャストルーティングとクラスタリング

マルチキャストルーティングは、インターフェイスモードによって動作が異なります。

スパンド EtherChannel モードでのマルチキャストルーティング

スパンド EtherChannel モードでは、ファーストパス転送が確立されるまでの間、マスターユニットがすべてのマルチキャストルーティングパケットとデータパケットを処理します。接続が確立された後は、各スレーブがマルチキャストデータパケットを転送できます。

個別インターフェイスモードでのマルチキャストルーティング

個別インターフェイスモードでは、マルチキャストに関してユニットが個別に動作することはありません。データおよびルーティングのパケットはすべてマスターユニットで処理されて転送されるので、パケットレプリケーションが回避されます。

NAT とクラスタリング

NAT は、クラスタの全体的なスループットに影響を与えることがあります。着信および発信の NAT パケットが、クラスタ内のそれぞれ別の ASA に送信されることがあります。ロードバランシングアルゴリズムは IP アドレスとポートに依存していますが、NAT が使用されるときは、着信と発信とで、パケットの IP アドレスやポートが異なるからです。NAT オーナーではない ASA に到着したパケットは、クラスタ制御リンクを介してオーナーに転送されるので、大量のトラフィックがクラスタ制御リンク上で発生します。NAT オーナーはセキュリティおよびポリシーチェックの結果に応じてパケットの接続を最終的には作成しない可能性があるため、受信側ユニットは転送フローをオーナーに作成しません。

それでもクラスタリングで NAT を使用する場合は、次のガイドラインを考慮してください。

プロキシ ARP なし：個別インターフェイスの場合は、マッピングアドレスについてプロキシ ARP 応答が送信されることはありません。これは、クラスタに存在しなくなった可能性のある ASA と隣接ルータとがピア関係を維持することを防ぐためです。アップストリームルータは、メインクラスタ IP アドレスを指すマッピングアドレスについてはスタティックルートまたは PBR とオブジェクトトラッキングを使用する必要があります。これは、スパンド EtherChannel の問題ではありません。クラスタインターフェイスには関連付けられた IP アドレスが 1 つしかないためです。
個別インターフェイスのインターフェイス PAT なし：インターフェイス PAT は、個別インターフェイスではサポートされていません。

ポートブロック割り当てによる PAT なし：この機能はクラスタではサポートされていません。
ポートブロック割り当てによる PAT：この機能については、次のガイドラインを参照してください。
- ホストあたりの最大制限は、クラスタ全体の制限ではなく、各ユニットで個別に適用されます。したがって、ホストあたりの最大制限が 1 に設定されている 3 つのノードを持つクラスタにおいて、ホストからのトラフィックが 3 つすべてのユニットでロードバランシングされる場合、そのクラスタには 3 つのブロック（各ユニットに 1 つずつ）を割り当てることができます。
- バックアッププールからバックアップユニットに作成されたポートブロックは、ホストあたりの最大制限の適用時には含まれません。
- PAT IP アドレスのオーナーがダウンすると、バックアップユニットが PAT IP アドレス、対応するポートブロック、および xlate を所有します。ただし、新しい要求を処理するためにこれらのブロックは使用されません。接続が最終的にタイムアウトすると、ブロックは解放されます。
- PAT プールが完全に新しい IP アドレスの範囲で変更される On-the-fly PAT ルールの変更では、新しいプールが有効になっていてもいまだ送信中の xlate バックアップ要求に対する xlate バックアップの作成が失敗します。この動作はポートのブロック割り当て機能に固有なものではなく、プールが分散されトラフィックがクラスタユニット間でロードバランシングされるクラスタ展開でのみ見られる一時的な PAT プールの問題です。
ダイナミック PAT 用 NAT プールアドレス分散：マスターユニットは、アドレスをクラスタ全体に均等に分配します。メンバが接続を受信したときに、そのメンバのアドレスが 1 つも残っていない場合は、接続はドロップされます（他のメンバにはまだ使用可能なアドレスがある場合でも）。最低でも、クラスタ内のユニットと同数の NAT アドレスが含まれていることを確認してください。各ユニットが確実に 1 つのアドレスを受け取るようにするためです。アドレス割り当てを表示するには、show nat pool cluster コマンドを使用します。
ラウンドロビンなし：PAT プールのラウンドロビンは、クラスタリングではサポートされません。
マスターユニットによって管理されるダイナミック NAT xlate：マスターユニットが xlate テーブルを維持し、スレーブユニットに複製します。ダイナミック NAT を必要とする接続をスレーブユニットが受信したときに、その xlate がテーブル内にない場合は、スレーブはマスターユニットに xlate を要求します。スレーブユニットが接続を所有します。
Per-session PAT 機能：クラスタリングに限りませんが、Per-session PAT 機能によって PAT のスケーラビリティが向上します。クラスタリングの場合は、各スレーブユニットが独自の PAT 接続を持てるようになります。対照的に、Multi-Session PAT 接続はマスターユニットに転送する必要があり、マスターユニットがオーナーとなります。デフォルトでは、すべての TCP トラフィックおよび UDP DNS トラフィックは per-session PAT xlate を使用します。これに対し、ICMP および他のすべての UDP トラフィックは multi-session を使用します。TCP および UDP に対しこれらのデフォルトを変更するように per-session NAT ルールを設定できますが、ICMP に per-session PAT を設定することはできません。H.323、SIP、または Skinny などの multi-session PAT のメリットを活用できるトラフィックでは、関連付けられている TCP ポートに対し per-session PAT を無効にできます（それらの H.323 および SIP の UDP ポートはデフォルトですでに multi-session になっています）。per-session PAT の詳細については、ファイアウォールの設定ガイドを参照してください。
次のインスペクション用のスタティック PAT はありません。
- FTP
- PPTP
- RSH
- SQLNET
- TFTP
- XDMCP
- SIP

ダイナミックルーティングおよびクラスタリング

ここでは、クラスタリングでダイナミックルーティングを使用する方法について説明します。

スパンド EtherChannel モードでのダイナミックルーティング

（注）

IS-IS は、スパンド EtherChannel モードではサポートされていません。

スパンド EtherChannel モード：ルーティングプロセスはマスターユニット上だけで実行されます。ルートはマスターユニットを介して学習され、スレーブに複製されます。ルーティングパケットがスレーブに到着した場合は、マスターユニットにリダイレクトされます。

図 1. スパンド EtherChannel モードでのダイナミックルーティング

スレーブメンバがマスターユニットからルートを学習した後は、各ユニットが個別に転送に関する判断を行います。

OSPF LSA データベースは、マスターユニットからスレーブユニットに同期されません。マスターユニットのスイッチオーバーが発生した場合は、隣接ルータが再起動を検出します。スイッチオーバーは透過的ではありません。OSPF プロセスが IP アドレスの 1 つをルータ ID として選択します必須ではありませんが、スタティックルータ ID を割り当てることができます。これで、同じルータ ID がクラスタ全体で使用されるようになります。割り込みを解決するには、OSPF ノンストップフォワーディング機能を参照してください。

個別インターフェイスモードでのダイナミックルーティング

個別インターフェイスモードでは、各ユニットがスタンドアロンルータとしてルーティングプロトコルを実行します。ルートの学習は、各ユニットが個別に行います。

上の図では、ルータ A はルータ B への等コストパスが 4 本あることを学習します。パスはそれぞれ 1 つの ASA を通過します。ECMP を使用して、4 パス間でトラフィックのロードバランシングを行います。各 ASA は、外部ルータと通信するときに、それぞれ異なるルータ ID を選択します。

管理者は、各ユニットが別のルータ ID を使用できるように、ルータ ID のクラスタプールを設定する必要があります。

EIGRP は、個別のインターフェイスモードのクラスタピアとのネイバー関係を形成しません。

（注）

冗長性の目的で、クラスタに同じルータへの複数の隣接関係がある場合、非対称ルーティングは許容できないトラフィック損失の原因となる可能性があります。非対称ルーティングを避けるためには、同じトラフィックゾーンにこれらすべての ASA インターフェイスをまとめます。トラフィックゾーンの設定を参照してください。

SCTP とクラスタリング

SCTP 関連付けは、任意のユニットで作成できます（ロードバランシングのため）。そのマルチホーミング接続は同じユニットに存在する必要があります。

SIP インスペクションとクラスタリング

制御フローは、任意のユニットで作成できます（ロードバランシングのため）。その子データフローは同じユニットに存在する必要があります。

TLS プロキシ設定はサポートされていません。

SNMP とクラスタリング

SNMP エージェントは、個々の ASA を、そのローカル IP アドレスによってポーリングします。クラスタの統合データをポーリングすることはできません。

SNMP ポーリングには、メインクラスタ IP アドレスではなく、常にローカルアドレスを使用してください。SNMP エージェントがメインクラスタ IP アドレスをポーリングする場合は、新しいマスターが選定されたときに、新しいマスターユニットのポーリングに失敗します。

STUN とクラスタリング

ピンホールが複製されるとき、STUN インスペクションはフェールオーバーモードとクラスタモードでサポートされます。ただし、トランザクション ID はユニット間で複製されません。STUN 要求の受信後にユニットに障害が発生し、別のユニットが STUN 応答を受信した場合、STUN 応答はドロップされます。

syslog および NetFlow とクラスタリング

Syslog：クラスタの各ユニットは自身の syslog メッセージを生成します。各ユニットの syslog メッセージヘッダーフィールドで使用されるデバイス ID を同一にするか、別にするかを設定できます。たとえば、ホスト名コンフィギュレーションはクラスタ内のすべてのユニットに複製されて共有されます。ホスト名をデバイス ID として使用するようにロギングを設定した場合は、どのユニットで生成された syslog メッセージも 1 つのユニットからのように見えます。クラスタブートストラップコンフィギュレーションで割り当てられたローカルユニット名をデバイス ID として使用するようにロギングを設定した場合は、syslog メッセージはそれぞれ別のユニットからのように見えます。
NetFlow：クラスタの各ユニットは自身の NetFlow ストリームを生成します。NetFlow コレクタは、各 ASA を独立した NetFlow エクスポータとしてのみ扱うことができます。

Cisco TrustSec とクラスタリング

マスターユニットだけがセキュリティグループタグ（SGT）情報を学習します。マスターユニットからこの SGT がスレーブに渡されるので、スレーブは、セキュリティポリシーに基づいて SGT の一致決定を下せます。

VPN とクラスタリング

サイトツーサイト VPN は、中央集中型機能です。マスターユニットだけが VPN 接続をサポートします。

（注）

リモートアクセス VPN は、クラスタリングではサポートされません。

VPN 機能を使用できるのはマスターユニットだけであり、クラスタのハイアベイラビリティ能力は活用されません。マスターユニットで障害が発生した場合は、すべての既存の VPN 接続が失われ、VPN ユーザにとってはサービスの中断となります。新しいマスターが選定されたときに、VPN 接続を再確立する必要があります。

VPN トンネルをスパンド EtherChannel アドレスに接続すると、接続が自動的にマスターユニットに転送されます。PBR または ECMP を使用するときの個別インターフェイスへの接続については、ローカルアドレスではなく、常にメインクラスタ IP アドレスに接続する必要があります。

VPN 関連のキーと証明書は、すべてのユニットに複製されます。

ASA クラスタリングのライセンス

クラスタユニットは、各ユニット上で同じライセンスを必要としません。一般的には、マスターユニット用のライセンスのみを購入します。スレーブユニットはマスターのライセンスを継承します。複数のユニットにライセンスがある場合は、これらが統合されて単一の実行 ASA クラスタライセンスとなります。

このルールには、例外があります。クラスタリングの正確なライセンス要件については、次の表を参照してください。

モデル

ライセンス要件

ASA 5585-X

クラスタライセンス、最大 16 ユニットをサポートします。

（注）

各ユニットに、同じ暗号化ライセンスが必要です。各ユニットに同じ 10 GE I/O/Security Plus ライセンスが必要です（ASA 5585-X と SSP-10 および SSP-20）。

ASA 5516-X

基本ライセンス、2 ユニットをサポートします。

（注）

各ユニットに同じ暗号化ライセンスが必要です。

ASA 5512-X

Security Plus ライセンス、2 ユニットをサポートします。

（注）

各ユニットに同じ暗号化ライセンスが必要です。

ASA 5515-X、ASA 5525-X、ASA 5545-X、ASA 5555-X

基本ライセンス、2 ユニットをサポートします。

（注）

各ユニットに同じ暗号化ライセンスが必要です。

Firepower 4100/9300 シャーシ上の ASA

Firepower 4100/9300 シャーシの ASA クラスタライセンスを参照してください。

他のすべてのモデル

サポートしない

ASA クラスタリングの要件と前提条件

モデルの要件

ASA 5516-x：最大 2 ユニット
ASA 5512-X、5515-X、5525-X、5545-X および 5555-X：最大 2 ユニット
ASA 5585 X：最大 16 ユニット

ASA 5585-X と SSP-10 および SSP-20（2 個の 10 ギガビットイーサネットインターフェイスを持つ）については、一方のインターフェイスをクラスタ制御リンクに使用し、他方をデータに使用することを推奨します（データについてはサブインターフェイスを使用できます）。この設定は、クラスタ制御リンクの冗長性には対応しませんが、クラスタ制御リンクのサイズをデータインターフェイスのサイズと一致させるという要件は満たされます。

ASA FirePOWER モジュール：ASA FirePOWER モジュールはクラスタリングを直接サポートしていませんが、クラスタ内でこれらのモジュールを使用できます。クラスタ内の ASA FirePOWER モジュールで一貫したポリシーを保持する必要があります。

（注）

ASA FirePOWER モジュールを設定する前に、クラスタを作成します。モジュールがスレーブデバイスにすでに設定されている場合、クラスタにこれらを追加する前に、デバイスのインターフェイスの設定をクリアします。CLI から clear configure interface コマンドを入力します。

ASA のハードウェアおよびソフトウェア要件

クラスタ内のすべてのユニット：

同じ DRAM を使用する同じモデルである必要があります。フラッシュメモリの容量は同一である必要はありません。
イメージアップグレード時を除き、同じソフトウェアを実行する必要があります。ヒットレスアップグレードがサポートされます。
セキュリティコンテキストモードが一致している必要があります（シングルまたはマルチ）。
（シングルコンテキストモード）ファイアウォールモードが一致している必要があります（ルーテッドまたはトランスペアレント）。
コンフィギュレーション複製前の初期クラスタ制御リンク通信のために、新しいクラスタメンバは、マスターユニットと同じ SSL 暗号化設定（ssl encryption コマンド）を使用する必要があります。
同じクラスタライセンス、暗号化ライセンス、そして ASA 5585-X の場合は 10 GE I/O ライセンスが必要です。

スイッチ要件

ASA でクラスタリングを設定する前に、スイッチのコンフィギュレーションを完了する必要があります。
サポートされているスイッチのリストについては、『Cisco ASA Compatibility』[英語] を参照してください。

ASA の要件

ユニットを管理ネットワークに追加する前に、一意の IP アドレスを各ユニットに提供します。
- ASA への接続および管理 IP アドレスの設定に関する詳細については、「使用する前に」の章を参照してください。
- マスター装置（通常は最初にクラスタに追加された装置）で使用される IP アドレスを除き、これらの管理 IP アドレスは一時的に使用されるだけです。
- スレーブがクラスタに参加すると、管理インターフェイス設定はマスター装置からの複製に置き換えられます。
クラスタ制御リンクでジャンボフレームを使用する場合は（推奨）、クラスタリングをイネーブルにする前に、ジャンボフレームの予約をイネーブルにする必要があります。

サイト間クラスタリング用の Data Center Interconnect のサイジング

次の計算と同等の帯域幅をクラスタ制御リンクトラフィック用に Data Center Interconnect（DCI）に確保する必要があります。

メンバの数が各サイトで異なる場合、計算には大きい方の値を使用します。DCI の最小帯域幅は、1 つのメンバに対するクラスタ制御リンクのサイズ未満にすることはできません。

次に例を示します。

4 サイトの 2 メンバの場合。
- 合計 4 クラスタメンバ
- 各サイト 2 メンバ
- メンバあたり 5 Gbps クラスタ制御リンク
予約する DCI 帯域幅 = 5 Gbps（2/2 x 5 Gbps）。
3 サイトの 6 メンバの場合、サイズは増加します。
- 合計 6 クラスタメンバ
- サイト 1 は 3 メンバ、サイト 2 は 2 メンバ、サイト 3 は 1 メンバ
- メンバあたり 10 Gbps クラスタ制御リンク
予約する DCI 帯域幅 = 15 Gbps（3/2 x 10 Gbps）。
2 サイトの 2 メンバの場合。
- 合計 2 クラスタメンバ
- 各サイト 1 メンバ
- メンバあたり 10 Gbps クラスタ制御リンク
予約する DCI 帯域幅 = 10 Gbps（1/2 x 10 Gbps = 5 Gbps、ただし最小帯域幅がクラスタ制御リンク（10 Gbps）のサイズ未満になってはなりません）。

その他の要件

ターミナルサーバを使用して、すべてのクラスタメンバユニットのコンソールポートにアクセスすることをお勧めします。初期設定および継続的な管理（ユニットがダウンしたときなど）では、ターミナルサーバがリモート管理に役立ちます。

ASA クラスタリングのガイドライン

コンテキストモード

モードは、各メンバーユニット上で一致している必要があります。

ファイアウォールモード

シングルモードの場合、ファイアウォールモードがすべてのユニットで一致している必要があります。

フェールオーバー

フェールオーバーは、クラスタリングではサポートされません。

IPv6

クラスタ制御リンクは、IPv4 のみを使用してサポートされます。

スイッチ

ASR 9006 では、非デフォルト MTU を設定する場合は、ASR インターフェイス MTU をクラスタデバイス MTU より 14 バイト大きく設定します。そうしないと、mtu-ignore オプションを使用しない限り、OSPF 隣接関係（アジャセンシー）ピアリングの試行が失敗する可能性があります。クラスタデバイス MTU は、ASR IPv4 MTU と一致する必要があります。
クラスタ制御リンクインターフェイスのスイッチでは、クラスタユニットに接続されるスイッチポートに対してスパニングツリー PortFast をイネーブルにすることもできます。このようにすると、新規ユニットの参加プロセスを高速化できます。
スイッチ上のスパンド EtherChannel のバンドリングが遅いときは、スイッチの個別インターフェイスに対して LACP 高速レートをイネーブルにできます。Nexus シリーズなど一部のスイッチでは、インサービスソフトウェアアップグレード（ISSU）を実行する際に LACP 高速レートがサポートされないことに注意してください。そのため、クラスタリングで ISSU を使用することは推奨されません。
スイッチでは、EtherChannel ロードバランシングアルゴリズム source-dest-ip または source-dest-ip-port（Cisco Nexus OS および Cisco IOS の port-channel load-balance コマンドを参照）を使用することをお勧めします。クラスタのデバイスにトラフィックを不均一に配分する場合があるので、ロードバランスアルゴリズムでは vlan キーワードを使用しないでください。クラスタデバイスのデフォルトのロードバランシングアルゴリズムは変更しないでください。
スイッチの EtherChannel ロードバランシングアルゴリズムを変更すると、スイッチの EtherChannel インターフェイスは一時的にトラフィックの転送を停止し、スパニングツリープロトコルが再始動します。トラフィックが再び流れ出すまでに、少し時間がかかります。
一部のスイッチは、LACP でのダイナミックポートプライオリティをサポートしていません（アクティブおよびスタンバイリンク）。ダイナミックポートプライオリティをディセーブルにすることで、スパンド EtherChannel との互換性を高めることができます。
クラスタ制御リンクパスのスイッチでは、L4 チェックサムを検証しないようにする必要があります。クラスタ制御リンク経由でリダイレクトされたトラフィックには、正しい L4 チェックサムが設定されていません。L4 チェックサムを検証するスイッチにより、トラフィックがドロップされる可能性があります。
ポートチャネルバンドルのダウンタイムは、設定されているキープアライブインターバルを超えてはなりません。
Supervisor 2T EtherChannel では、デフォルトのハッシュ配信アルゴリズムは適応型です。VSS 設計での非対称トラフィックを避けるには、クラスタデバイスに接続されているポートチャネルでのハッシュアルゴリズムを固定に変更します。

router(config)# port-channel id hash-distribution fixed

アルゴリズムをグローバルに変更しないでください。VSS ピアリンクに対しては適応型アルゴリズムを使用できます。

Cisco Nexus スイッチのクラスタに接続されたすべての EtherChannel インターフェイスで、LACP グレースフルコンバージェンス機能をディセーブルにする必要があります。

EtherChannel

15.1(1)S2 より前の Catalyst 3750-X Cisco IOS ソフトウェアバージョンでは、クラスタユニットはスイッチスタックに EtherChannel を接続することをサポートしていませんでした。デフォルトのスイッチ設定では、クラスタユニット EtherChannel がクロススタックに接続されている場合、マスタースイッチの電源がオフになると、残りのスイッチに接続されている EtherChannel は起動しません。互換性を高めるため、stack-mac persistent timer コマンドを設定して、十分なリロード時間を確保できる大きな値、たとえば 8 分、0（無制限）などを設定します。または、15.1(1)S2 など、より安定したスイッチソフトウェアバージョンにアップグレードできます。
スパンド EtherChannel とデバイスローカル EtherChannel のコンフィギュレーション：スパンド EtherChannel とデバイスローカル EtherChannel に対してスイッチを適切に設定します。
- スパンド EtherChannel：クラスタユニット スパンド EtherChannel（クラスタのすべてのメンバに広がる）の場合は、複数のインターフェイスが結合されてスイッチ上の単一の EtherChannel となります。各インターフェイスがスイッチ上の同じチャネルグループ内にあることを確認してください。
- デバイスローカル EtherChannel：クラスタユニット デバイスローカル EtherChannel（クラスタ制御リンク用に設定された EtherChannel もこれに含まれます）は、それぞれ独立した EtherChannel としてスイッチ上で設定してください。スイッチ上で複数のクラスタユニット EtherChannel を結合して 1 つの EtherChannel としないでください。

サイト間のガイドライン

サイト間クラスタリングについては、次のガイドラインを参照してください。

次のインターフェイスおよびファイアウォールモードで Inter-Site クラスタリングをサポートします。


インターフェイスモード	ファイアウォールモード
インターフェイスモード	ルーテッド	Transparent
個別インターフェイス	〇	該当なし
スパンド EtherChannel	〇	〇

個別インターフェイスモードでは、マルチキャストランデブーポイント（RP）に向けて ECMP を使用する場合、ネクストホップとしてメインクラスタ IP アドレスを使用する RP IP アドレスのスタティックルートを使用することをお勧めします。このスタティックルートは、スレーブユニットにユニキャスト PIM 登録パケットが送信されるのを防ぎます。スレーブユニットが PIM 登録パケットを受け取った場合、パケットはドロップされ、マルチキャストストリームは登録できません。

クラスタ制御リンクの遅延が、ラウンドトリップ時間（RTT）20 ms 未満である必要があります。
クラスタ制御リンクは、順序の異常やパケットのドロップがない信頼性の高いものである必要があります。たとえば、専用リンクを使用する必要があります。
接続の再分散を設定しないでください。異なるサイトのクラスタメンバには接続を再分散できません。
クラスタの実装では、着信接続用の複数のサイトでメンバが区別されません。したがって、特定の接続に対する接続のロールが複数のサイトにまたがる場合があります。これは想定されている動作です。ただし、ディレクタローカリゼーションを有効にすると、接続オーナーと同じサイトからローカルディレクタ権限が常に選択されます（サイト ID に応じて）。また、元のオーナーに障害が発生するとローカルディレクタは同じサイトの新しいオーナーを選択します（注：サイト間でトラフィックが非対称で、元のオーナーに障害が発生した後もリモートサイトから継続的なトラフィックがある場合、リモートサイトのユニットが re-hosting ウィンドウ内でデータパケットを受信する場合はこのリモートサイトのユニットが新しいオーナーとなることがあります）。
ディレクタローカリゼーションでは、次のトラフィックタイプのローカリゼーションをサポートしていません。NAT または PAT のトラフィック、SCTP がインスペクションを行うトラフィック、オーナーのフラグメンテーションクエリ。
トランスペアレントモードの場合、内部ルータと外部ルータのペア間にクラスタを配置すると（AKA ノースサウス挿入）、両方の内部ルータが同じ MAC アドレスを共有し、両方の外部ルータが同じ MAC アドレスを共有する必要があります。サイト 1 のクラスタメンバがサイト 2 のメンバに接続を転送するとき、宛先 MAC アドレスは維持されます。MAC アドレスがサイト 1 のルータと同じである場合にのみ、パケットはサイト 2 のルータに到達します。
トランスペアレントモードの場合、内部ネットワーク間のファイル用に各サイトのデータネットワークとゲートウェイルータ間にクラスタを配置すると（AKA イーストウェスト挿入）、各ゲートウェイルータは、HSRP などの First Hop Redundancy Protocol（FHRP）を使用して、各サイトで同じ仮想 IP および MAC アドレスの宛先を提供します。データ VLAN は、オーバーレイトランスポート仮想化（OTV）または同様のものを使用してサイト全体にわたって拡張されます。ローカルゲートウェイルータ宛てのトラフィックが DCI 経由で他のサイトに送信されないようにするには、フィルタを作成する必要があります。ゲートウェイルータが 1 つのサイトで到達不能になった場合、トラフィックが正常に他のサイトのゲートウェイに到達できるようにフィルタを削除する必要があります。
スパンド EtherChannel を使用したルーテッドモードでは、サイト固有の MAC アドレスを設定します。OTV または同様のものを使用してサイト全体にデータ VLAN を拡張します。グローバル MAC アドレス宛てのトラフィックが DCI 経由で他のサイトに送信されないようにするには、フィルタを作成する必要があります。クラスタが 1 つのサイトで到達不能になった場合、トラフィックが正常に他のサイトのクラスタユニットに到達できるようにフィルタを削除する必要があります。ダイナミックルーティングは、サイト間クラスタが拡張セグメントのファーストホップルータとして機能する場合はサポートされません。

その他のガイドライン

大々的なトポロジ変更が発生する場合（EtherChannel インターフェイスの追加または削除、ASA 上でのインターフェイスまたはスイッチの有効化または無効化、VSS または vPC を形成するための追加スイッチの追加など）、ヘルスチェック機能や無効なインターフェイスのインターフェイスモニタリングを無効にする必要があります。トポロジの変更が完了して、コンフィギュレーション変更がすべてのユニットに同期されたら、インターフェイスのヘルスチェック機能を再度有効にできます。
ユニットを既存のクラスタに追加したときや、ユニットをリロードしたときは、一時的に、限定的なパケット/接続ドロップが発生します。これは予定どおりの動作です。場合によっては、ドロップされたパケットが原因で接続がハングすることがあります。たとえば、FTP 接続の FIN/ACK パケットがドロップされると、FTP クライアントがハングします。この場合は、FTP 接続を再確立する必要があります。
スパンド EtherChannel に接続された Windows 2003 Server を使用している場合、syslog サーバポートがダウンし、サーバが ICMP エラーメッセージを調整しないと、多数の ICMP メッセージが ASA クラスタに送信されます。このようなメッセージにより、ASA クラスタの一部のユニットで CPU 使用率が高くなり、パフォーマンスに影響する可能性があります。ICMP エラーメッセージを調節することを推奨します。
個別インターフェイスモードの VXLAN はサポートされていません。スパンド EtherChannel モードでのみ VXLAN をサポートしています。
シスコは、スパンド EtherChannel モードの IS-IS をサポートしません。個別インターフェイスモードのみが IS-IS をサポートします。

ASA クラスタリングのデフォルト

スパンド EtherChannel を使用するときは、cLACP システム ID は自動生成され、システムプライオリティはデフォルトで 1 です。
クラスタのヘルスチェック機能は、デフォルトでイネーブルになり、ホールド時間は 3 秒です。デフォルトでは、すべてのインターフェイスでインターネットヘルスモニタリングがイネーブルになっています。
失敗したクラスタ制御リンクのクラスタ再結合機能が 5 分おきに無制限に試行されます。
失敗したデータインターフェイスのクラスタ自動再結合機能は、5 分後と、2 に設定された増加間隔で合計で 3 回試行されます。
接続再分散は、デフォルトではディセーブルです。接続再分散をイネーブルにした場合の、デフォルトの負荷情報交換間隔は 5 秒です。
HTTP トラフィックは、5 秒間の接続レプリケーション遅延がデフォルトで有効になっています。

ASA クラスタリングの設定

クラスタリングを設定するには、次のタスクを実行します。

（注）

クラスタリングを有効または無効にするには、コンソール接続（CLI の場合）または ASDM 接続を使用します。

ユニットのケーブル接続およびインターフェイスの設定

クラスタリングを設定する前に、クラスタ制御リンクネットワーク、管理ネットワーク、およびデータネットワークをケーブルで接続します。次に、インターフェイスを設定します。

クラスタインターフェイスについて

データインターフェイスは、スパンド EtherChannel として設定することも、個別インターフェイスとして設定することもできます。1 つのクラスタ内のすべてのデータインターフェイスのタイプが同一であることが必要です。また、各ユニットの、少なくとも 1 つのハードウェアインターフェイスをクラスタ制御リンク専用とする必要があります。

クラスタ制御リンクについて

各ユニットの、少なくとも 1 つのハードウェアインターフェイスをクラスタ制御リンク専用とする必要があります。

クラスタ制御リンクトラフィックの概要

クラスタ制御リンクトラフィックには、制御とデータの両方のトラフィックが含まれます。

制御トラフィックには次のものが含まれます。

マスター選定。
コンフィギュレーションの複製
ヘルスモニタリング。

データトラフィックには次のものが含まれます。

ステート複製。
接続所有権クエリおよびデータパケット転送。

クラスタ制御リンクインターフェイスとネットワーク

次の例外を除き、クラスタ制御リンクには任意のデータインターフェイスを使用できます。

VLAN サブインターフェイスをクラスタ制御リンクとして使用することはできません。
管理 x/x インターフェイスをクラスタ制御リンクとして使用することはできません（単独か EtherChannel かにかかわらず）。
ASA FirePOWER モジュールを搭載した ASA 5585-X では、クラスタ制御リンクに ASA FirePOWER モジュール上のインターフェイスではなく、ASA インターフェイスを使用することを推奨しています。モジュールインターフェイスは、ソフトウェアアップグレード中に発生するリロードを含め、モジュールのリロード中に最大 30 秒間トラフィックをドロップできます。ただし、必要に応じて、モジュールインターフェイスと ASA インターフェイスを同じクラスタ制御リンク EtherChannel で使用できます。モジュールインターフェイスがドロップした場合、EtherChannel の残りのインターフェイスはまだ稼働しています。ASA 5585-X ネットワークモジュールは別のオペレーティングシステムを実行しないため、この問題の影響を受けません。

モジュール上のデータインターフェイスはリロードの低下によっても影響を受けることに注意してください。シスコでは、EtherChannel 内で常に ASA インターフェイスをモジュールインターフェイスと冗長的に使用することを推奨しています。

ASA 5585-X と SSP-10 および SSP-20（2 個の 10 ギガビットイーサネットインターフェイスを持つ）については、一方のインターフェイスをクラスタ制御リンクに使用し、他方をデータに使用することを推奨します（データについてはサブインターフェイスを使用できます）。この設定は、クラスタ制御リンクの冗長性には対応しませんが、クラスタ制御リンクのサイズをデータインターフェイスのサイズと一致させるという要件は満たされます。

EtherChannel インターフェイスまたは冗長インターフェイスを使用できます。

各クラスタ制御リンクは、同じサブネット上の IP アドレスを持ちます。このサブネットは、他のすべてのトラフィックからは隔離し、ASA クラスタ制御リンクインターフェイスだけが含まれるようにしてください。

2 メンバークラスタの場合、ASA と ASA の間をクラスタ制御リンクで直接接続しないでください。インターフェイスを直接接続した場合、一方のユニットで障害が発生すると、クラスタ制御リンクが機能せず、他の正常なユニットも動作しなくなります。スイッチを介してクラスタ制御リンクを接続した場合は、正常なユニットについてはクラスタ制御リンクは動作を維持します。

クラスタ制御リンクのサイズ

可能であれば、各シャーシの予想されるスループットに合わせてクラスタ制御リンクをサイジングする必要があります。そうすれば、クラスタ制御リンクが最悪のシナリオを処理できます。たとえば、ASA 5585-X と SSP-60 を使用する場合は、クラスタのユニットあたり最大 14 Gbps を通過させることができるので、クラスタ制御リンクに割り当てるインターフェイスも、最低 14 Gbps の通過が可能となるようにしてください。この場合は、たとえば 10 ギガビットイーサネットインターフェイス 2 つを EtherChannel としてクラスタ制御リンクに使用し、残りのインターフェイスを必要に応じてデータリンクに使用します。

クラスタ制御リンクトラフィックの内容は主に、状態アップデートや転送されたパケットです。クラスタ制御リンクでのトラフィックの量は常に変化します。転送されるトラフィックの量は、ロードバランシングの有効性、または中央集中型機能のための十分なトラフィックがあるかどうかによって決まります。次に例を示します。

NAT では接続のロードバランシングが低下するので、すべてのリターントラフィックを正しいユニットに再分散する必要があります。
ネットワークアクセスに対する AAA は一元的な機能であるため、すべてのトラフィックがマスターユニットに転送されます。
メンバーシップが変更されると、クラスタは大量の接続の再分散を必要とするため、一時的にクラスタ制御リンクの帯域幅を大量に使用します。

クラスタ制御リンクの帯域幅を大きくすると、メンバーシップが変更されたときの収束が高速になり、スループットのボトルネックを回避できます。

（注）

クラスタに大量の非対称（再分散された）トラフィックがある場合は、クラスタ制御リンクのサイズを大きくする必要があります。

クラスタ制御リンク冗長性

クラスタ制御リンクには EtherChannel を使用することを推奨します。冗長性を実現しながら、EtherChannel 内の複数のリンクにトラフィックを渡すことができます。

次の図は、仮想スイッチングシステム（VSS）または仮想ポートチャネル（vPC）環境でクラスタ制御リンクとして EtherChannel を使用する方法を示します。EtherChannel のすべてのリンクがアクティブです。スイッチが VSS または vPC の一部である場合は、同じ EtherChannel 内の ASA インターフェイスをそれぞれ、VSS または vPC 内の異なるスイッチに接続できます。スイッチインターフェイスは同じ EtherChannel ポートチャネルインターフェイスのメンバです。複数の個別のスイッチが単一のスイッチのように動作するからです。この EtherChannel は、スパンド EtherChannel ではなく、デバイスローカルであることに注意してください。

クラスタ制御リンクの信頼性

クラスタ制御リンクの機能を保証するには、ユニット間のラウンドトリップ時間（RTT）が 20 ms 未満になるようにします。この最大遅延により、異なる地理的サイトにインストールされたクラスタメンバとの互換性が向上します。遅延を調べるには、ユニット間のクラスタ制御リンクで ping を実行します。

クラスタ制御リンクは、順序の異常やパケットのドロップがない信頼性の高いものである必要があります。たとえば、サイト間の導入の場合、専用リンクを使用する必要があります。

クラスタ制御リンクの障害

ユニットのクラスタ制御リンク回線プロトコルがダウンした場合、クラスタリングはディセーブルになります。データインターフェイスはシャットダウンされます。クラスタ制御リンクの修復後、クラスタリングを再度イネーブルにして手動でクラスタに再参加する必要があります。

（注）

ASA が非アクティブになると、すべてのデータインターフェイスがシャットダウンされます。管理専用インターフェイスのみがトラフィックを送受信できます。管理インターフェイスは、そのユニットがクラスタ IP プールから受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードする場合、クラスタでユニットがまだ非アクティブになっていると、管理インターフェイスはアクセスできません（マスターユニットと同じメイン IP アドレスを使用するため）。それ以降のコンフィギュレーション作業には、コンソールポートを使用する必要があります。

スパンド EtherChannel（推奨）

シャーシあたり 1 つ以上のインターフェイスをグループ化して、クラスタのすべてのシャーシに広がる EtherChannel とすることができます。EtherChannel によって、チャネル内の使用可能なすべてのアクティブインターフェイスのトラフィックが集約されます。スパンド EtherChannel は、ルーテッドとトランスペアレントのどちらのファイアウォールモードでも設定できます。ルーテッドモードでは、EtherChannel は単一の IP アドレスを持つルーテッドインターフェイスとして設定されます。トランスペアレントモードでは、IP アドレスはブリッジグループメンバーではなく BVI に割り当てられます。EtherChannel は初めから、ロードバランシング機能を基本的動作の一部として備えています。

スパンド EtherChannel の利点

EtherChannel 方式のロードバランシングは、次のような利点から、他の方式よりも推奨されます。

障害検出までの時間が短い。
コンバージェンス時間が短い。個別インターフェイスはルーティングプロトコルに基づきトラフィックをロードバランシングしますが、ルーティングプロトコルはリンク障害時にコンバージェンスが遅くなることがよくあります。
コンフィギュレーションが容易である。

最大スループットのガイドライン

最大スループットを実現するには、次のことを推奨します。

使用するロードバランシングハッシュアルゴリズムは「対称」であるようにします。つまり、どちらの方向からのパケットも同じハッシュを持たせて、スパンド EtherChannel 内の同じ ASA に送信します。送信元と宛先の IP アドレス（デフォルト）または送信元と宛先のポートをハッシュアルゴリズムとして使用することを推奨します。
ASA をスイッチに接続するときは、同じタイプのラインカードを使用します。すべてのパケットに同じハッシュアルゴリズムが適用されるようにするためです。

ロードバランシング

EtherChannel リンクは、送信元または宛先 IP アドレス、TCP ポートおよび UDP ポート番号に基づいて、専用のハッシュアルゴリズムを使用して選択されます。

（注）

ASA では、デフォルトのロードバランシングアルゴリズムを変更しないでください。スイッチでは、アルゴリズム source-dest-ip または source-dest-ip-port（Cisco Nexus OS または Cisco IOS の port-channel load-balance コマンドを参照）を使用することをお勧めします。クラスタ内の ASA へのトラフィックが均等に分散されなくなることがあるため、ロードバランシングアルゴリズムでは、vlan キーワードを使用しないでください。

EtherChannel 内のリンク数はロードバランシングに影響を及ぼします。

対称ロードバランシングは常に可能とは限りません。NAT を設定する場合は、フォワードパケットとリターンパケットとで IP アドレスやポートが異なります。リターントラフィックはハッシュに基づいて別のユニットに送信されるため、クラスタはほとんどのリターントラフィックを正しいユニットにリダイレクトする必要があります。

EtherChannel の冗長性

EtherChannel には、冗長性機能が組み込まれています。これは、すべてのリンクの回線プロトコルステータスをモニタします。リンクの 1 つで障害が発生すると、トラフィックは残りのリンク間で再分散されます。EtherChannel のすべてのリンクが特定のユニット上で停止したが、他方のユニットがまだアクティブである場合は、そのユニットはクラスタから削除されます。

VSS または vPC への接続

1 つの ASA につき複数のインターフェイスを、スパンド EtherChannel に入れることができます。1 つの ASA につき複数のインターフェイスが特に役立つのは、VSS または vPC の両方のスイッチに接続するときです。

スイッチによっては、スパンド EtherChannel に最大 32 個のアクティブリンクを設定できます。この機能では、vPC 内の両方のスイッチが、それぞれ 16 個のアクティブリンクの EtherChannel をサポートする必要があります（例：Cisco Nexus 7000 と F2 シリーズ 10 ギガビットイーサネットモジュール）。

EtherChannel で 8 個のアクティブリンクをサポートするスイッチの場合、VSS/vPC で 2 台のスイッチに接続すると、スパンド EtherChannel に最大 16 個のアクティブリンクを設定できます。

スパンド EtherChannel で 8 個より多くのアクティブリンクを使用する場合は、スタンバイリンクも使用できません。9 ～ 32 個のアクティブリンクをサポートするには、スタンバイリンクの使用を可能にする cLACP ダイナミックポートプライオリティをディセーブルにする必要があります。それでも、必要であれば、たとえば 1 台のスイッチに接続するときに、8 個のアクティブリンクと 8 個のスタンバイリンクを使用できます。

次の図では、8 ASA クラスタおよび 16 ASA クラスタでの 32 アクティブリンクのスパンド EtherChannel を示します。

次の図では、4 ASA クラスタおよび 8 ASA クラスタでの 16 アクティブリンクのスパンド EtherChannel を示します。

次の図では、4 ASA クラスタおよび 8 ASA クラスタでの従来の 8 アクティブリンク/8 スタンバイリンクのスパンド EtherChannel を示します。アクティブリンクは実線で、非アクティブリンクは点線で示しています。cLACP ロードバランシングは、EtherChannel のリンクのうち最良の 8 本を自動的に選択してアクティブにできます。つまり、cLACP は、リンクレベルでのロードバランシング実現に役立ちます。

個別インターフェイス（ルーテッドファイアウォールモードのみ）

個別インターフェイスは通常のルーテッドインターフェイスであり、それぞれが専用のローカル IP アドレスを持ちます。インターフェイスコンフィギュレーションはマスターユニット上だけで行う必要があるため、このインターフェイスコンフィギュレーションの中で IP アドレスプールを設定して、このプールのアドレスをクラスタメンバ（マスター用を含む）のインターフェイスに使用させることができます。メインクラスタ IP アドレスは、そのクラスタのための固定アドレスであり、常に現在のマスターユニットに属します。メインクラスタ IP アドレスは、マスターユニットのスレーブ IP アドレスです。ローカル IP アドレスが常にルーティングのマスターアドレスになります。このメインクラスタ IP アドレスによって、管理アクセスのアドレスが一本化されます。マスターユニットが変更されると、メインクラスタ IP アドレスは新しいマスターユニットに移動するので、クラスタの管理をシームレスに続行できます。ただし、ロードバランシングを別途する必要があります（この場合はアップストリームスイッチ上で）。

（注）

個別インターフェイスはルーティングプロトコルに基づきトラフィックをロードバランシングしますが、ルーティングプロトコルはリンク障害時にコンバージェンスが遅くなることがよくあるので、個別インターフェイスの代わりにスパンド EtherChannel を推奨します。

ポリシーベースルーティング（ルーテッドファイアウォールモードのみ）

個別インターフェイスを使用するときは、各 ASA インターフェイスが専用の IP アドレスと MAC アドレスを維持します。ロードバランシング方法の 1 つが、ポリシーベースルーティング（PBR）です。

この方法が推奨されるのは、すでに PBR を使用しており、既存のインフラストラクチャを活用したい場合です。また、この方法を使用すると、スパンド EtherChannel の場合と比べて、追加の調整オプションを利用できる場合もあります。

PBR は、ルートマップおよび ACL に基づいて、ルーティングの決定を行います。管理者は、手動でトラフィックをクラスタ内のすべての ASA 間で分ける必要があります。PBR は静的であるため、常に最適なロードバランシング結果を実現できないこともあります。最高のパフォーマンスを達成するには、PBR ポリシーを設定するときに、同じ接続のフォワードとリターンのパケットが同じ物理的 ASA に送信されるように指定することを推奨します。たとえば、Cisco ルータがある場合は、冗長性を実現するには Cisco IOS PBR をオブジェクトトラッキングとともに使用します。Cisco IOS オブジェクトトラッキングは、ICMP ping を使用して各 ASA をモニタします。これで、PBR は、特定の ASA の到達可能性に基づいてルートマップをイネーブルまたはディセーブルにできます。詳細については、次の URL を参照してください。

http://www.cisco.com/c/en/us/solutions/data-center-virtualization/intelligent-traffic-director/index.html

http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00800a4409.shtml

（注）

このロードバランシング方法を使用する場合は、デバイスローカル EtherChannel を個別インターフェイスとして使用できます。

等コストマルチパスルーティング（ルーテッドファイアウォールモードのみ）

個別インターフェイスを使用するときは、各 ASA インターフェイスが専用の IP アドレスと MAC アドレスを維持します。ロードバランシング方法の 1 つが、等コストマルチパス（ECMP）ルーティングです。

この方法が推奨されるのは、すでに ECMP を使用しており、既存のインフラストラクチャを活用したい場合です。また、この方法を使用すると、スパンド EtherChannel の場合と比べて、追加の調整オプションを利用できる場合もあります。

ECMP ルーティングでは、ルーティングメトリックが同値で最高である複数の「最適パス」を介してパケットを転送できます。EtherChannel のように、送信元および宛先の IP アドレスや送信元および宛先のポートのハッシュを使用してネクストホップの 1 つにパケットを送信できます。ECMP ルーティングにスタティックルートを使用する場合は、ASA の障害発生時に問題が起きることがあります。ルートは引き続き使用されるため、障害が発生した ASA へのトラフィックが失われるからです。スタティックルートを使用する場合は必ず、オブジェクトトラッキングなどのスタティックルートモニタリング機能を使用してください。ダイナミックルーティングプロトコルを使用してルートの追加と削除を行うことを推奨します。この場合は、ダイナミックルーティングに参加するように各 ASA を設定する必要があります。

（注）

このロードバランシング方法を使用する場合は、デバイスローカル EtherChannel を個別インターフェイスとして使用できます。

Nexus Intelligent Traffic Director（ルーテッドファイアウォールモードのみ）

個別インターフェイスを使用するときは、各 ASA インターフェイスが専用の IP アドレスと MAC アドレスを維持します。Intelligent Traffic Director（ITD）とは、Nexus 5000、6000、7000 および 9000 スイッチシリーズの高速ハードウェアロードバランシングソリューションです。従来の PBR の機能を完全に網羅していることに加え、簡略化された構成ワークフローを提供し、粒度の細かい負荷分散を実現するための複数の追加機能を備えています。

ITD は、IP スティッキ性、双方向フロー対称性のためのコンシステントハッシュ法、仮想 IP アドレッシング、ヘルスモニタリング、高度な障害処理ポリシー（N+M 冗長性）、加重ロードバランシング、およびアプリケーション IP SLA プローブ（DNS を含む）をサポートします。ロードバランシングの動的な性質により、PBR に比べて、すべてのクラスタメンバーでより均一なトラフィック分散を実現します。双方向フロー対称性を実現するために、接続のフォワードおよびリターンパケットが同じ物理 ASA に送信されるように ITD を設定することを推奨します。詳細については、次の URL を参照してください。

http://www.cisco.com/c/en/us/solutions/data-center-virtualization/intelligent-traffic-director/index.html

クラスタユニットのケーブル接続とアップストリームおよびダウンストリーム機器の設定

クラスタリングを設定する前に、クラスタ制御リンクネットワーク、管理ネットワーク、およびデータネットワークをケーブルで接続します。

手順

コマンドまたはアクション

目的

クラスタ制御リンクネットワーク、管理ネットワーク、およびデータネットワークをケーブルで接続します。

（注）

クラスタに参加するようにユニットを設定する前に、少なくとも、アクティブなクラスタ制御リンクネットワークが必要です。

アップストリームとダウンストリームの機器も設定する必要があります。たとえば、EtherChannel を使用する場合は、EtherChannel のアップストリーム/ダウンストリーム機器を設定する必要があります。

例

（注）

この例では、ロードバランシングに EtherChannel を使用します。PBR または ECMP を使用する場合は、スイッチコンフィギュレーションが異なります。

たとえば、4 台の ASA 5585-X のそれぞれにおいて、次のものを使用します。

デバイスローカル EtherChannel の 10 ギガビットイーサネットインターフェイス 2 個（クラスタ制御リンク用）。
スパンド EtherChannel の 10 ギガビットイーサネットインターフェイス 2 個（内部および外部ネットワーク用）。各インターフェイスは、EtherChannel の VLAN サブインターフェイスです。サブインターフェイスを使用すると、内部と外部の両方のインターフェイスが EtherChannel の利点を活用できます。
管理インターフェイス 1 個。

内部と外部の両方のネットワーク用に 1 台のスイッチがあります。


目的	4 台の各 ASA の接続インターフェイス	スイッチポートへ
クラスタ制御リンク	TenGigabitEthernet 0/6 および TenGigabitEthernet 0/7	合計 8 ポート TenGigabitEthernet 0/6 と TenGigabitEthernet 0/7 のペアごとに、4 個の EtherChannel（ASA ごとに 1 個の EC）を設定します。これらの EtherChannel すべてが、同一の独立クラスタ制御 VLAN 上（たとえば VLAN 101）に存在する必要があります。
内部および外部インターフェイス	TenGigabitEthernet 0/8 および TenGigabitEthernet 0/9	合計 8 ポート単一の EtherChannel を設定します（すべての ASA にまたがる）。スイッチでは、この VLAN およびネットワークをここで設定できます。たとえば、VLAN 200（内部用）および VLAN 201（外部用）が含まれるトランクを設定します。
管理インターフェイス	Management 0/0	合計 4 ポートすべてのインターフェイスを、同一の独立管理 VLAN（たとえば VLAN 100）上に置きます。

各ユニットでのクラスタインターフェイスモードの設定

クラスタリング用に設定できるインターフェイスのタイプは、スパンド EtherChannel と個別インターフェイスのいずれか一方のみです。1 つのクラスタ内でインターフェイスタイプを混在させることはできません。

始める前に

モードの設定は、クラスタに追加する各 ASA で個別に行う必要があります。
管理専用インターフェイスはいつでも、個別インターフェイス（推奨）として設定できます（スパンド EtherChannel モードのときでも）。管理インターフェイスは、個別インターフェイスとすることができます（トランスペアレントファイアウォールモードのときでも）。
スパンド EtherChannel モードでは、管理インターフェイスを個別インターフェイスとして設定すると、管理インターフェイスに対してダイナミックルーティングをイネーブルにできません。スタティックルートを使用する必要があります。
マルチコンテキストモードでは、すべてのコンテキストに対して 1 つのインターフェイスタイプを選択する必要があります。たとえば、トランスペアレントモードとルーテッドモードのコンテキストが混在している場合は、すべてのコンテキストにスパンド EtherChannel モードを使用する必要があります。これが、トランスペアレントモードで許可される唯一のインターフェイスタイプであるからです。

手順

ステップ 1

互換性のないコンフィギュレーションを表示し、強制的にインターフェイスモードにして後でコンフィギュレーションを修正できるようにします。このコマンドではモードは変更されません。

cluster interface-mode {individual | spanned } check-details

例:


ciscoasa(config)# cluster interface-mode spanned check-details

ステップ 2

クラスタリング用にインターフェイスモードを設定します。

cluster interface-mode {individual | spanned } force

例:


ciscoasa(config)# cluster interface-mode spanned force

デフォルト設定はありません。明示的にモードを選択する必要があります。モードを設定していない場合は、クラスタリングをイネーブルにできません。

force オプションを指定すると、互換性のないコンフィギュレーションの検査は行わずにモードが変更されます。コンフィギュレーションの問題がある場合は、モードを変更した後に手動で解決する必要があります。インターフェイスコンフィギュレーションの修正ができるのはモードの設定後に限られるので、force オプションを使用することを推奨します。このようにすれば、最低でも、既存のコンフィギュレーションの状態から開始できます。さらにガイダンスが必要な場合は、モードを設定した後で check-details オプションを再実行します。

force オプションを指定しないと、互換性のないコンフィギュレーションがある場合は、コンフィギュレーションをクリアしてリロードするように求められるので、コンソールポートに接続して管理アクセスを再設定する必要があります。コンフィギュレーションに互換性の問題がない場合は（まれなケース）、モードが変更され、コンフィギュレーションは維持されます。コンフィギュレーションをクリアしたくない場合は、n を入力してコマンドを終了します。

インターフェイスモードを解除するには、no cluster interface-mode コマンドを入力します。

マスターユニットでのインターフェイスの設定

クラスタリングを有効にする前に、現在 IP アドレスが設定されているインターフェイスをクラスタ対応に変更する必要があります。他のインターフェイスについては、クラスタリングをイネーブルにする前またはした後で設定できます。完全なコンフィギュレーションが新しいクラスタメンバと同期するように、すべてのインターフェイスを事前に設定することを推奨します。

ここでは、クラスタリング互換となるようにインターフェイスを設定する方法について説明します。データインターフェイスは、スパンド EtherChannel として設定することも、個別インターフェイスとして設定することもできます。各方式は別のロードバランシングメカニズムを使用します。同じコンフィギュレーションで両方のタイプを設定することはできません。ただし、管理インターフェイスは例外で、スパンド EtherChannel モードであっても個別インターフェイスにできます。

個別のインターフェイスの設定（管理インターフェイスに推奨）

個別インターフェイスは通常のルーテッドインターフェイスであり、それぞれが専用の IP アドレスを IP アドレスプールから取得します。メインクラスタ IP アドレスは、そのクラスタのための固定アドレスであり、常に現在のプライマリユニットに属します。

スパンド EtherChannel モードでは、管理インターフェイスを個別インターフェイスとして設定することを推奨します。個別管理インターフェイスならば、必要に応じて各ユニットに直接接続できますが、スパンド EtherChannel インターフェイスでは、現在のプライマリユニットへの接続しかできません。

始める前に

管理専用インターフェイスの場合を除き、個別インターフェイスモードであることが必要です。
マルチコンテキストモードの場合は、この手順を各コンテキストで実行します。まだコンテキストコンフィギュレーションモードに入っていない場合は、changeto context name コマンドを入力します。
個別インターフェイスの場合は、ネイバーデバイスでのロードバランシングを設定する必要があります。管理インターフェイスには、外部のロードバランシングは必要ありません。
（オプション）インターフェイスをデバイスローカル EtherChannel インターフェイスとして設定する、冗長インターフェイスを設定する、およびサブインターフェイスを設定する作業を必要に応じて行います。
- EtherChannel の場合、この EtherChannel はユニットに対してローカルであり、スパンド EtherChannel ではありません。
- 管理専用インターフェイスを冗長インターフェイスにすることはできません。

手順

ステップ 1	ローカル IP アドレス（IPv4 と IPv6 の一方または両方）のプールを設定します。このアドレスの 1 つが、このインターフェイス用に各クラスタユニットに割り当てられます。（IPv4） ip local pool `poolname` `first-address` — `last-address` [mask `mask`] （IPv6） ipv6 local pool `poolname` `ipv6-address`/`prefix-length` `number_of_addresses` 例: `ciscoasa(config)# ip local pool ins 192.168.1.2-192.168.1.9 ciscoasa(config-if)# ipv6 local pool insipv6 2001:DB8::1002/32 8` 最低でも、クラスタ内のユニット数と同じ数のアドレスが含まれるようにしてください。クラスタを拡張する予定の場合は、アドレスを増やします。現在のプライマリユニットに属するメインクラスタ IP アドレスは、このプールの一部ではありません。必ず、同じネットワークの IP アドレスの 1 つをメインクラスタ IP アドレス用に確保してください。各ユニットに割り当てられるローカルアドレスを、事前に正確に特定することはできません。各ユニットで使用されているアドレスを表示するには、show ip[v6] local pool poolname コマンドを入力します。各クラスタメンバには、クラスタに参加したときにメンバ ID が割り当てられます。この ID によって、プールから使用されるローカル IP が決定します。
ステップ 2	インターフェイスコンフィギュレーションモードを開始します。 interface `interface_id` 例: `ciscoasa(config)# interface tengigabitethernet 0/8`
ステップ 3	（管理インターフェイスのみ）インターフェイスを管理専用モードに設定してトラフィックが通過しないようにします。 management-only デフォルトでは、管理タイプのインターフェイスは管理専用として設定されます。トランスペアレントモードでは、このコマンドは管理タイプのインターフェイスに対して常にイネーブルになります。この設定は、クラスタインターフェイスモードがスパンドの場合に必要です。
ステップ 4	インターフェイスの名前を指定します。 nameif `name` 例: `ciscoasa(config-if)# nameif inside` name は最大 48 文字のテキスト文字列です。大文字と小文字は区別されません。名前を変更するには、このコマンドで新しい値を再入力します。
ステップ 5	メインクラスタの IP アドレスを設定し、クラスタプールを指定します。（IPv4） ip address `ip_address` [`mask`] cluster-pool `poolname` （IPv6） ipv6 address `ipv6-address`/`prefix-length` cluster-pool `poolname` 例: `ciscoasa(config-if)# ip address 192.168.1.1 255.255.255.0 cluster-pool ins ciscoasa(config-if)# ipv6 address 2001:DB8::1002/32 cluster-pool insipv6` この IP アドレスは、クラスタプールアドレスと同じネットワーク上に存在している必要がありますが、プールに含まれていてはなりません。IPv4 アドレスと IPv6 アドレスの一方または両方を設定できます。 DHCP、PPPoE、および IPv6 自動設定はサポートされません。IP アドレスを手動で設定する必要があります。
ステップ 6	セキュリティレベルを設定します。number には、0（最低）～ 100（最高）の整数を指定します。 security-level `number` 例: `ciscoasa(config-if)# security-level 100`
ステップ 7	インターフェイスをイネーブルにします。 no shutdown

例

次の例では、管理 0/0 および管理 0/1 インターフェイスをデバイスローカル EtherChannel として設定してから、この EtherChannel を個別インターフェイスとして設定します。


ip local pool mgmt 10.1.1.2-10.1.1.9
ipv6 local pool mgmtipv6 2001:DB8:45:1002/64 8
interface management 0/0

channel-group 1 mode active
no shutdown

interface management 0/1

channel-group 1 mode active
no shutdown

interface port-channel 1

nameif management
ip address 10.1.1.1 255.255.255.0 cluster-pool mgmt
ipv6 address 2001:DB8:45:1001/64 cluster-pool mgmtipv6
security-level 100
management-only

スパンド EtherChannel の設定

スパンド EtherChannel は、クラスタ内のすべての ASA に広がるものであり、EtherChannel の動作の一部としてロードバランシングを行うことができます。

始める前に

スパンド EtherChannel インターフェイスモードにする必要があります。
マルチコンテキストモードの場合は、この手順をシステム実行スペースで開始します。まだシステムコンフィギュレーションモードに入っていない場合は、changeto system コマンドを入力します。
トランスペアレントモードの場合は、ブリッジグループを設定します。ブリッジ仮想インターフェイス（BVI）の設定を参照してください。
EtherChannel には最大および最小のリンク数を指定しないでください。EtherChannel の最大および最小のリンク数の指定（lacp max-bundle コマンドと port-channel min-bundle コマンド）は、ASA とスイッチのどちらにおいても行わないことを推奨します。これらを使用する必要がある場合は、次の点に注意してください。
- ASA 上で設定されるリンクの最大数は、クラスタ全体のアクティブポートの合計数です。スイッチ上で設定された最大リンク数の値が、ASA での値を超えていないことを確認してください。
- ASA 上で設定される最小リンク数は、ポートチャネルインターフェイスを起動するための最小アクティブポート数（ユニットあたり）です。スイッチ上では、最小リンク数はクラスタ全体の最小リンク数であるため、この値は ASA での値とは一致しません。
デフォルトのロードバランシングアルゴリズムを変更しないでください（port-channel load-balance コマンドを参照）。スイッチでは、アルゴリズム source-dest-ip または source-dest-ip-port（Cisco Nexus OS および Cisco IOS の port-channel load-balance コマンドを参照）を使用することをお勧めします。クラスタ内の ASA へのトラフィックが均等に分散されなくなることがあるため、ロードバランシングアルゴリズムでは、vlan キーワードを使用しないでください。
lacp port-priority コマンドと lacp system-priority コマンドは、スパンド EtherChannel には使用されません。
スパンド EtherChannel を使用している場合、クラスタリングが完全にイネーブルになるまで、ポートチャネルインターフェイスは起動しません。この要件により、クラスタのアクティブではないユニットにトラフィックが転送されるのが防がれます。

手順

ステップ 1	チャネルグループに追加するインターフェイスを指定します。 interface `physical_interface` 例: `ciscoasa(config)# interface gigabitethernet 0/0` physical_interface ID には、タイプ、スロット、およびポート番号（type slot/ port）が含まれます。チャネルグループのこの最初のインターフェイスによって、グループ内の他のすべてのインターフェイスのタイプと速度が決まります。
ステップ 2	EtherChannel にこのインターフェイスを割り当てます。 channel-group `channel_id` mode active [vss-id {1 \| 2 }] 例: `ciscoasa(config-if)# channel-group 1 mode active` channel_id は 1 ～ 48 です。このチャネル ID のポートチャネルインターフェイスがコンフィギュレーションにまだ存在しない場合は、自動的に追加されます。 interface port-channel `channel_id` active モードだけがスパンド EtherChannel に対してサポートされます。 VSS または vPC の 2 台のスイッチに ASA を接続する場合は、このインターフェイスをどのスイッチに接続するかを指定するために vss-id キーワードを設定します（1 または 2）。また、ステップ 6 で port-channel span-cluster vss-load-balance コマンドをポートチャネルインターフェイスに対して使用する必要があります。
ステップ 3	インターフェイスをイネーブルにします。 no shutdown
ステップ 4	（オプション）EtherChannel にさらにインターフェイスを追加するには、上記のプロセスを繰り返します。例: `ciscoasa(config)# interface gigabitethernet 0/1 ciscoasa(config-if)# channel-group 1 mode active ciscoasa(config-if)# no shutdown` ユニットごとに複数のインターフェイスが EtherChannel に含まれていると、VSS または vPC のスイッチに接続する場合に役立ちます。デフォルトでは、クラスタの全メンバで最大 16 個のアクティブインターフェイスのうち、スパンド EtherChannel が使用できるのは 8 個だけであることに注意してください。残りの 8 インターフェイスはリンク障害時のためのスタンバイです。8 個より多くのアクティブインターフェイスを使用するには（ただしスタンバイインターフェイスではなく）、clacp static-port-priority コマンドを使用してダイナミックポートプライオリティをディセーブルにします。ダイナミックポートプライオリティをディセーブルにすると、クラスタ全体で最大 32 個のアクティブリンクを使用できます。たとえば、16 台の ASA から成るクラスタの場合は、各 ASA で最大 2 個のインターフェイスを使用でき、スパンド EtherChannel の合計は 32 インターフェイスとなります。
ステップ 5	ポートチャネルインターフェイスを指定します。 interface port-channel `channel_id` 例: `ciscoasa(config)# interface port-channel 1` このインターフェイスは、チャネルグループにインターフェイスを追加したときに自動的に作成されたものです。
ステップ 6	この EtherChannel をスパンド EtherChannel として設定します。 port-channel span-cluster [vss-load-balance ] 例: `ciscoasa(config-if)# port-channel span-cluster` ASA を VSS または vPC の 2 台のスイッチに接続する場合は、vss-load-balance キーワードを使用して VSS ロードバランシングをイネーブルにする必要があります。この機能を使用すると、ASA と VSS（または vPC）ペアとの間の物理リンク接続の負荷が確実に分散されます。ロードバランシングをイネーブルにする前に、各メンバーインターフェイスに対して channel-group コマンドの vss-id キーワードを設定する必要があります（ステップ 2 を参照）。
ステップ 7	（オプション）ポートチャネルインターフェイスのイーサネットプロパティを設定します。この設定は、個別インターフェイスに対して設定されたプロパティよりも優先されます。これらのパラメータはチャネルグループのすべてのインターフェイスで一致している必要があるため、この方法はこれらのパラメータを設定するショートカットになります。
ステップ 8	（オプション）この EtherChannel 上に VLAN サブインターフェイスを作成する予定の場合は、この時点で作成します。例: `ciscoasa(config)# interface port-channel 1.10 ciscoasa(config-if)# vlan 10` この手順の残りの部分は、サブインターフェイスに適用されます。
ステップ 9	（マルチコンテキストモード）コンテキストにインターフェイスを割り当てます。その後で、次のとおりに入力します。 `changeto context name interface port-channel channel_id` 例: `ciscoasa(config)# context admin ciscoasa(config)# allocate-interface port-channel1 ciscoasa(config)# changeto context admin ciscoasa(config-if)# interface port-channel 1` マルチコンテキストモードの場合は、インターフェイスコンフィギュレーションの残りの部分は各コンテキスト内で行われます。
ステップ 10	インターフェイスの名前を指定します。 nameif `name` 例: `ciscoasa(config-if)# nameif inside` name は最大 48 文字のテキスト文字列です。大文字と小文字は区別されません。名前を変更するには、このコマンドで新しい値を再入力します。
ステップ 11	ファイアウォールモードに応じて、次のいずれかを実行します。ルーテッドモード：IPv4 アドレスと IPv6 アドレスの一方または両方を設定します。（IPv4） ip address `ip_address` [`mask`] （IPv6） ipv6 address `ipv6-prefix`/`prefix-length` 例： `ciscoasa(config-if)# ip address 10.1.1.1 255.255.255.0 ciscoasa(config-if)# ipv6 address 2001:DB8::1001/32` DHCP、PPPoE、および IPv6 自動設定はサポートされません。ポイントツーポイント接続の場合、31 ビットのサブネットマスク（255.255.255.254）を指定できます。この場合、ネットワークまたはブロードキャストアドレス用の IP アドレスは予約されません。トランスペアレントモード：インターフェイスをブリッジグループに割り当てます。 bridge-group `number` 例： `ciscoasa(config-if)# bridge-group 1` number は、1 ～ 100 の整数です。ブリッジグループには最大 64 個のインターフェイスを割り当てることができます。同一インターフェイスを複数のブリッジグループに割り当てることはできません。BVI のコンフィギュレーションには IP アドレスが含まれていることに注意してください。
ステップ 12	セキュリティレベルを設定します。 security-level `number` 例: `ciscoasa(config-if)# security-level 50` number には、0（最下位）～ 100（最上位）の整数を指定します。
ステップ 13	潜在的なネットワークの接続問題を回避するために、スパンド EtherChannel のグローバル MAC アドレスを設定します。 mac-address `mac_address` 例: `ciscoasa(config-if)# mac-address 000C.F142.4CDE` MAC アドレスが手動設定されている場合、その MAC アドレスは現在のマスターユニットに留まります。MAC アドレスを設定していない場合に、マスターユニットが変更された場合、新しいマスターユニットはインターフェイスに新しい MAC アドレスを使用します。これにより、一時的なネットワークの停止が発生する可能性があります。マルチコンテキストモードでは、コンテキスト間でインターフェイスを共有する場合は、MAC アドレスの自動生成を有効にして、手動で MAC アドレスを設定しなくてすむようにします。非共有インターフェイスの場合は、このコマンドを使用して MAC アドレスを手動で設定する必要があることに注意してください。 mac_address は、H.H.H 形式で指定します。H は 16 ビットの 16 進数です。たとえば、MAC アドレス 00-0C-F1-42-4C-DE は、000C.F142.4CDE と入力します。自動生成された MAC アドレスも使用する場合、手動で割り当てる MAC アドレスの最初の 2 バイトには A2 を使用できません。
ステップ 14	（ルーテッドモード）サイト間クラスタリングの場合、サイトごとにサイト固有の MAC アドレスおよび IP アドレスを設定します。 mac-address `mac_address` site-id `number` 例: `ciscoasa(config-if)# mac-address aaaa.1111.1234 ciscoasa(config-if)# mac-address aaaa.1111.aaaa site-id 1 site-ip 10.9.9.1 ciscoasa(config-if)# mac-address aaaa.1111.bbbb site-id 2 site-ip 10.9.9.2 ciscoasa(config-if)# mac-address aaaa.1111.cccc site-id 3 site-ip 10.9.9.3 ciscoasa(config-if)# mac-address aaaa.1111.dddd site-id 4 site-ip 10.9.9.4` サイト固有の IP アドレスは、グローバル IP アドレスと同じサブネット上にある必要があります。ユニットで使用するサイト固有の MAC アドレスおよび IP アドレスは、各ユニットのブートストラップコンフィギュレーションに指定したサイト ID によって異なります。

ブートストラップコンフィギュレーションの作成

クラスタ内の各ユニットがクラスタに参加するには、ブートストラップコンフィギュレーションが必要です。

マスターユニットのブートストラップの設定

クラスタ内の各ユニットがクラスタに参加するには、ブートストラップコンフィギュレーションが必要です。一般的には、クラスタに参加するように最初に設定したユニットがマスターユニットとなります。クラスタリングをイネーブルにした後で、選定期間が経過すると、クラスタのマスターユニットが選定されます。最初はクラスタ内のユニットが 1 つだけであるため、そのユニットがマスターユニットになります。それ以降クラスタに追加されるユニットは、スレーブユニットとなります。

始める前に

コンフィギュレーションをバックアップします。後でクラスタから脱退する必要が生じたときに備えて、コンフィギュレーションを復元できるようにしておくためです。
マルチコンテキストモードの場合、システム実行スペースで次の手順を実行します。コンテキストからシステム実行スペースに切り替えるには、changeto system コマンドを入力します。
クラスタ制御リンクで使用するためのジャンボフレームの予約をイネーブルにすることを推奨します。
クラスタリングをイネーブルまたはディセーブルにするには、コンソールポートを使用する必要があります。Telnet または SSH を使用することはできません。
クラスタ制御リンクを除いて、コンフィギュレーション内のインターフェイスはすべて、クラスタ IP プールを指定して設定されているか、スパンド EtherChannel として設定されている必要があります。この設定は、クラスタリングをイネーブルにする前に、インターフェイスモードに応じて行います。既存のインターフェイスコンフィギュレーションがある場合は、そのインターフェイスコンフィギュレーションをクリアすることも（clear configure interface）、インターフェイスをクラスタインターフェイスに変換することもできます。これは、クラスタリングをイネーブルにする前に行います。
稼働中のクラスタにユニットを追加すると、一時的に、限定的なパケット/接続ドロップが発生することがあります。これは予定どおりの動作です。
クラスタ制御リンクのサイズをあらかじめ決定しておきます。クラスタ制御リンクのサイズを参照してください。

手順

ステップ 1

クラスタに参加する前に、クラスタ制御リンクインターフェイスをイネーブルにします。

後でクラスタリングをイネーブルにするときに、このインターフェイスをクラスタ制御リンクとして識別します。

十分な数のインターフェイスがある場合は、複数のクラスタ制御リンクインターフェイスを結合して 1 つの EtherChannel とすることを推奨します。この EtherChannel は ASA に対してローカルであり、スパンド EtherChannel ではありません。

クラスタ制御リンクインターフェイスコンフィギュレーションは、マスターユニットからスレーブユニットには複製されませんが、同じコンフィギュレーションを各ユニットで使用する必要があります。このコンフィギュレーションは複製されないため、クラスタ制御リンクインターフェイスの設定は各ユニットで個別に行う必要があります。

VLAN サブインターフェイスをクラスタ制御リンクとして使用することはできません。
管理 x/x インターフェイスをクラスタ制御リンクとして使用することはできません（単独か EtherChannel かにかかわらず）。
ASA FirePOWER モジュールを搭載した ASA 5585-X では、クラスタ制御リンクに ASA FirePOWER モジュール上のインターフェイスではなく、ASA インターフェイスを使用することを推奨しています。モジュールインターフェイスは、ソフトウェアアップグレード中に発生するリロードを含め、モジュールのリロード中に最大 30 秒間トラフィックをドロップできます。ただし、必要に応じて、モジュールインターフェイスと ASA インターフェイスを同じクラスタ制御リンク EtherChannel で使用できます。モジュールインターフェイスがドロップした場合、EtherChannel の残りのインターフェイスはまだ稼働しています。ASA 5585-X ネットワークモジュールは別のオペレーティングシステムを実行しないため、この問題の影響を受けません。

インターフェイスコンフィギュレーションモードを開始します。

interface interface_id
例:
```
ciscoasa(config)# interface tengigabitethernet 0/6
```
（任意、EtherChannel の場合）EtherChannel にこの物理インターフェイスを割り当てます。

channel-group channel_id mode on
例:
```
ciscoasa(config-if)# channel-group 1 mode on
```
channel_id は 1 ～ 48 です。このチャネル ID のポートチャネルインターフェイスがコンフィギュレーションにまだ存在しない場合は、自動的に追加されます。

interface port-channel channel_id

クラスタ制御リンクでの不要なトラフィックを削減できるように、クラスタ制御リンクのメンバーインターフェイスに対しては On モードを使用することを推奨します。クラスタ制御リンクは LACP トラフィックのオーバーヘッドを必要としません。これは隔離された、安定したネットワークであるからです。注：データ EtherChannel を Active モードに設定することをお勧めします。
インターフェイスをイネーブルにします。

no shutdown

必要があるのはインターフェイスのイネーブル化だけです。インターフェイスの名前などのパラメータを設定しないでください。

（EtherChannel の場合）EtherChannel に追加するインターフェイスごとに繰り返します。

例:


ciscoasa(config)# interface tengigabitethernet 0/7
ciscoasa(config-if)# channel-group 1 mode on
ciscoasa(config-if)# no shutdown

ステップ 2

（オプション）クラスタ制御リンクインターフェイスの最大伝送ユニットを指定します。

mtu cluster bytes

例:


ciscoasa(config)# mtu cluster 9000

MTU を 1400 ～ 9198 バイトの間で設定します。デフォルトの MTU は 1500 バイトです。

MTU を 1600 バイト以上に設定することを推奨します。このようにするには、この手順を続ける前にジャンボフレームの予約をイネーブルにする必要があります。ジャンボフレームの予約には、ASA のリロードが必要です。

このコマンドはグローバルコンフィギュレーションコマンドですが、ユニット間で複製されないブートストラップコンフィギュレーションの一部でもあります。

ステップ 3

クラスタに名前を付け、クラスタコンフィギュレーションモードにします。

cluster group name

例:


ciscoasa(config)# cluster group pod1

名前は 1 ～ 38 文字の ASCII 文字列であることが必要です。クラスタグループはユニットあたり 1 つしか設定できません。クラスタのすべてのメンバが同じ名前を使用する必要があります。

ステップ 4

クラスタのこのメンバの名前を指定します。

local-unit unit_name

1 ～ 38 文字の一意の ASCII 文字列を使用します。各ユニットに固有の名前が必要です。クラスタ内の他のユニットと同じ名前を付けることはできません。

例:


ciscoasa(cfg-cluster)# local-unit unit1

ステップ 5

クラスタ制御リンクインターフェイス（EtherChannel を推奨）を指定します。

cluster-interface interface_id ip ip_address mask

例:


ciscoasa(cfg-cluster)# cluster-interface port-channel2 ip 192.168.1.1 255.255.255.0
INFO: Non-cluster interface config is cleared on Port-Channel2

サブインターフェイスと管理インターフェイスは許可されません。

IP アドレスには IPv4 アドレスを指定します。IPv6 は、このインターフェイスではサポートされません。このインターフェイスには、nameif を設定することはできません。

ユニットごとに、同じネットワークにある別の IP アドレスを指定します。

ステップ 6

サイト間クラスタリングを使用している場合、このユニットのサイト ID を設定し、サイト固有の MAC アドレスが使用されるようにします。

site-id number

例:


ciscoasa(cfg-cluster)# site-id 1

number には、1 ～ 8 の範囲内の値を入力します。

ステップ 7

マスターユニットの選択に対するこのユニットのプライオリティを設定します。

priority priority_number

例:


ciscoasa(cfg-cluster)# priority 1

プライオリティは 1 ～ 100 であり、1 が最高のプライオリティです。

ステップ 8

（オプション）クラスタ制御リンクの制御トラフィックの認証キーを設定します。

key shared_secret

例:


ciscoasa(cfg-cluster)# key chuntheunavoidable

共有秘密は、1 ～ 63 文字の ASCII 文字列です。共有秘密は、キーを生成するために使用されます。このコマンドは、データパストラフィック（接続状態アップデートや転送されるパケットなど）には影響しません。データパストラフィックは、常にクリアテキストとして送信されます。

ステップ 9

（オプション）LACP のダイナミックポートプライオリティをディセーブルにします。

clacp static-port-priority

一部のスイッチはダイナミックポートプライオリティをサポートしていないため、このコマンドはスイッチの互換性を高めます。さらに、このコマンドは、9 ～ 32 のアクティブスパンド EtherChannel メンバーのサポートをイネーブルにします。このコマンドを使用しないと、サポートされるのは 8 個のアクティブメンバと 8 個のスタンバイメンバのみです。このコマンドをイネーブルにした場合、スタンバイメンバは使用できません。すべてのメンバがアクティブです。

ステップ 10

（オプション）cLACP システム ID およびシステムのプライオリティを手動で指定します。

clacp system-mac {mac_address | auto } [system-priority number]

例:


ciscoasa(cfg-cluster)# clacp system-mac 000a.0000.aaaa

スパンド EtherChannel を使用するときは、ASA は cLACP を使用してネイバースイッチとの間で EtherChannel のネゴシエーションを行います。cLACP ネゴシエーションの際に、同じクラスタ内の ASA は互いに連携するため、スイッチには 1 つの（仮想）デバイスであるかのように見えます。cLACP ネゴシエーションのパラメータの 1 つであるシステム ID は、MAC アドレスの形式をとります。クラスタ内のすべての ASA が同じシステム ID を使用します。これはマスターユニットによって自動生成され（デフォルト）、すべてのセカンダリユニットに複製されます。あるいは、このコマンドに H.H.H の形式で手動で指定することもできます。H は 16 ビットの 16 進数です。（たとえば、MAC アドレス 00-0A-00-00-AA-AA は、000A.0000.AAAA と入力します）。トラブルシューティングの目的で、たとえば、識別が容易な MAC アドレスを使用できるように、手動で MAC アドレスを設定することがあります。一般的には、自動生成された MAC アドレスを使用します。

システムプライオリティ（1 ～ 65535）は、どのユニットがバンドルの決定を行うかを決めるために使用されます。デフォルトでは、ASA はプライオリティ 1（最高のプライオリティ）を使用します。このプライオリティは、スイッチのプライオリティよりも高いことが必要です。

このコマンドは、ブートストラップコンフィギュレーションの一部ではなく、マスターユニットからスレーブユニットに複製されます。ただし、クラスタリングをイネーブルにした後は、この値は変更できません。

ステップ 11

クラスタリングをイネーブルにします。

enable [noconfirm ]

例:


ciscoasa(cfg-cluster)# enable
INFO: Clustering is not compatible with following commands:
policy-map global_policy
 class inspection_default
 inspect skinny
policy-map global_policy
 class inspection_default
  inspect sip
 Would you like to remove these commands? [Y]es/[N]o:Y

INFO: Removing incompatible commands from running configuration...
Cryptochecksum (changed): f16b7fc2 a742727e e40bc0b0 cd169999
INFO: Done

enable コマンドが入力されると、ASA は実行コンフィギュレーションをスキャンして、クラスタリングに対応していない機能の非互換コマンドの有無を調べます。デフォルトコンフィギュレーションにあるコマンドも、これに該当することがあります。互換性のないコマンドを削除するように求められます。応答として No を入力した場合は、クラスタリングはイネーブルになりません。確認を省略し、互換性のないコマンドを自動的に削除するには、noconfirm キーワードを使用します。

最初にイネーブルにしたユニットについては、マスターユニット選定が発生します。最初のユニットは、その時点でクラスタの唯一のメンバーであるため、そのユニットがマスターユニットになります。この期間中にコンフィギュレーション変更を実行しないでください。

クラスタリングをディセーブルにするには、no enable コマンドを入力します。

（注）

クラスタリングをディセーブルにした場合は、すべてのデータインターフェイスがシャットダウンされ、管理専用インターフェイスだけがアクティブになります。

例

次の例では、管理インターフェイスを設定し、クラスタ制御リンク用のデバイスローカル EtherChannel を設定し、その後で、「unit1」という名前の ASA のクラスタリングをイネーブルにします。これは最初にクラスタに追加されるユニットであるため、マスターユニットになります。


ip local pool mgmt 10.1.1.2-10.1.1.9
ipv6 local pool mgmtipv6 2001:DB8::1002/32 8
interface management 0/0
   nameif management
   ip address 10.1.1.1 255.255.255.0 cluster-pool mgmt
   ipv6 address 2001:DB8::1001/32 cluster-pool mgmtipv6
   security-level 100
   management-only
   no shutdown

interface tengigabitethernet 0/6
   channel-group 1 mode on
   no shutdown

interface tengigabitethernet 0/7
   channel-group 1 mode on
   no shutdown

cluster group pod1
   local-unit unit1
   cluster-interface port-channel1 ip 192.168.1.1 255.255.255.0
   priority 1
   key chuntheunavoidable
   enable noconfirm

スレーブユニットのブートストラップの設定

スレーブユニットを設定するには、次の手順に従います。

始める前に

クラスタリングをイネーブルまたはディセーブルにするには、コンソールポートを使用する必要があります。Telnet または SSH を使用することはできません。
コンフィギュレーションをバックアップします。後でクラスタから脱退する必要が生じたときに備えて、コンフィギュレーションを復元できるようにしておくためです。
マルチコンテキストモードでは、システム実行スペースで次の手順を実行します。コンテキストからシステム実行スペースに切り替えるには、changeto system コマンドを入力します。
クラスタ制御リンクで使用するためのジャンボフレームの予約をイネーブルにすることを推奨します。
コンフィギュレーション内に、クラスタリング用として設定されていないインターフェイスがある場合は（たとえば、デフォルトコンフィギュレーションの管理 0/0 インターフェイス）、スレーブユニットとしてクラスタに参加させることができます（現在の選定でマスターになる可能性はありません）。
稼働中のクラスタにユニットを追加すると、一時的に、限定的なパケット/接続ドロップが発生することがあります。これは予定どおりの動作です。

手順

ステップ 1

マスターユニットに設定したものと同じクラスタ制御リンクインターフェイスを設定します。

例:


ciscoasa(config)# interface tengigabitethernet 0/6
ciscoasa(config-if)# channel-group 1 mode on
ciscoasa(config-if)# no shutdown
ciscoasa(config)# interface tengigabitethernet 0/7
ciscoasa(config-if)# channel-group 1 mode on
ciscoasa(config-if)# no shutdown

ステップ 2

マスターユニットに設定したものと同じ MTU を指定します。

例:


ciscoasa(config)# mtu cluster 9000

ステップ 3

マスターユニットに設定したものと同じクラスタ名を指定します。

例:


ciscoasa(config)# cluster group pod1

ステップ 4

クラスタのこのメンバに一意の文字列で名前を指定します。

local-unit unit_name

例:


ciscoasa(cfg-cluster)# local-unit unit2

1 ～ 38 文字の ASCII 文字列を指定します。

各ユニットに固有の名前が必要です。クラスタ内の他のユニットと同じ名前を付けることはできません。

ステップ 5

マスターユニットに設定したものと同じクラスタ制御リンクインターフェイスを指定しますが、ユニットごとに同じネットワーク上の異なる IP アドレスを指定します。

cluster-interface interface_id ip ip_address mask

例:


ciscoasa(cfg-cluster)# cluster-interface port-channel2 ip 192.168.1.2 255.255.255.0
INFO: Non-cluster interface config is cleared on Port-Channel2

各ユニットに固有の名前が必要です。クラスタ内の他のユニットと同じ名前を付けることはできません。

ステップ 6

サイト間クラスタリングを使用している場合、このユニットのサイト ID を設定し、サイト固有の MAC アドレスが使用されるようにします。

site-id number

例:


ciscoasa(cfg-cluster)# site-id 1

number は 1 ～ 8 です。

ステップ 7

マスターユニットの選択に対するこのユニットのプライオリティを設定します。通常は、マスターユニットより高い値にします。

priority priority_number

例:


ciscoasa(cfg-cluster)# priority 2

プライオリティを 1 ～ 100 に設定します。1 が最高のプライオリティです。

ステップ 8

マスターユニットに設定したものと同じ認証キーを設定します。

例:


ciscoasa(cfg-cluster)# key chuntheunavoidable

ステップ 9

クラスタリングをイネーブルにします。

enable as-slave

enable as-slave コマンドを使用することによって、コンフィギュレーションに関するすべての非互換性（主として、クラスタリングに対してまだ設定されていないインターフェイスの存在）を回避できます。このコマンドを実行すると、クラスタに参加させるスレーブが現在の選定においてマスターとなる可能性をなくすことができます。スレーブのコンフィギュレーションは、マスターユニットから同期されたコンフィギュレーションによって上書きされます。

クラスタリングをディセーブルにするには、no enable コマンドを入力します。

（注）

クラスタリングをディセーブルにした場合は、すべてのデータインターフェイスがシャットダウンされ、管理インターフェイスだけがアクティブになります。

例

次の例には、スレーブユニット unit2 のコンフィギュレーションが含まれています。


interface tengigabitethernet 0/6

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/7

channel-group 1 mode on
no shutdown

cluster group pod1

local-unit unit2
cluster-interface port-channel1 ip 192.168.1.2 255.255.255.0
priority 2
key chuntheunavoidable
enable as-slave

クラスタリング動作のカスタマイズ

クラスタリングヘルスモニタリング、TCP 接続複製の遅延、フローのモビリティ、他の最適化をカスタマイズできます。

マスターユニットで次の手順を実行します。

ASA クラスタの基本パラメータの設定

マスターユニット上のクラスタ設定をカスタマイズできます。

始める前に

マルチコンテキストモードでは、マスターユニット上のシステム実行スペースで次の手順を実行します。コンテキストからシステム実行スペースに切り替えるには、changeto system コマンドを入力します。

手順

ステップ 1

クラスタの設定モードを開始します。

cluster group name

ステップ 2

（任意）スレーブユニットからマスターユニットへのコンソール複製をイネーブルにします。

console-replicate

この機能はデフォルトで無効に設定されています。ASA は、特定の重大イベントが発生したときに、メッセージを直接コンソールに出力します。コンソール複製をイネーブルにすると、スレーブユニットからマスターユニットにコンソールメッセージが送信されるので、モニタが必要になるのはクラスタのコンソールポート 1 つだけとなります。

ステップ 3

クラスタリングイベントの最小トレースレベルを設定します。

trace-level level

必要に応じて最小レベルを設定します。

critical ：クリティカルイベント（重大度 = 1）
warning ：警告（重大度 = 2）
informational ：情報イベント（重大度 = 3）
debug ：デバッグイベント（重大度 = 4）

のヘルスモニタリングおよび自動再結合の設定

この手順では、ユニットとインターフェイスのヘルスモニタリングを設定します。

たとえば、管理インターフェイスなど、必須以外のインターフェイスのヘルスモニタリングをディセーブルにすることができます。任意のポートチャネル ID、冗長 ID、単一の物理インターフェイス ID、または ASA Firepower モジュールなどのソフトウェア/ハードウェアモジュールをモニタできます。ヘルスモニタリングは VLAN サブインターフェイス、または VNI　や BVI などの仮想インターフェイスでは実行されません。クラスタ制御リンクのモニタリングは設定できません。このリンクは常にモニタされています。

手順

ステップ 1	クラスタの設定モードを開始します。 cluster group `name` 例: `ciscoasa(config)# cluster group test ciscoasa(cfg-cluster)#`
ステップ 2	クラスタユニットのヘルスチェック機能をカスタマイズします。 health-check [holdtime `timeout`] [vss-enabled ] ユニットのヘルスを確認するため、ASA のクラスタユニットはクラスタ制御リンクで他のユニットにハートビートメッセージを送信します。ユニットが保留時間内にピアユニットからハートビートメッセージを受信しない場合は、そのピアユニットは応答不能またはデッド状態と見なされます。 holdtime `timeout` ：ユニットのハートビートステータスメッセージの時間間隔を指定します。指定できる範囲は .3 ～ 45 秒で、デフォルトは 3 秒です。 vss-enabled ：クラスタ制御リンクのすべての EtherChannel インターフェイスでハートビートメッセージをフラッディングして、少なくとも 1 台のスイッチがそれを受信できるようにします。EtherChannel としてクラスタ制御リンクを設定し（推奨）、VSS または vPC ペアに接続している場合、vss-enabled オプションをイネーブルにする必要がある場合があります。一部のスイッチでは、VSS/vPC の 1 つのユニットがシャットダウンまたは起動すると、そのスイッチに接続された EtherChannel メンバーインターフェイスが ASA に対してアップ状態であるように見えますが、これらのインターフェイスはスイッチ側のトラフィックを通していません。ASA holdtime timeout を低い値（0.8 秒など）に設定した場合、ASA が誤ってクラスタから削除される可能性があり、ASA はキープアライブメッセージをこれらのいずれかの EtherChannel インターフェイスに送信します。何らかのトポロジ変更（たとえばデータインターフェイスの追加/削除、ASA、またはスイッチ上のインターフェイスの有効化/無効化、VSS または vPC を形成するスイッチの追加）を行うときには、ヘルスチェック機能を無効にし、無効化したインターフェイスのモニタリングも無効にしてください（no health-check monitor-interface ）。トポロジの変更が完了して、コンフィギュレーション変更がすべてのユニットに同期されたら、ヘルスチェック機能を再度イネーブルにできます。例: `ciscoasa(cfg-cluster)# health-check holdtime 5`
ステップ 3	インターフェイスでインターフェイスヘルスチェックを無効化します。 no health-check monitor-interface `[` `interface_id` \| service-module] インターフェイスのヘルスチェックはリンク障害をモニタします。特定の論理インターフェイスのすべての物理ポートが、特定のユニット上では障害が発生したが、別のユニット上の同じ論理インターフェイスでアクティブポートがある場合、そのユニットはクラスタから削除されます。ASA がメンバをクラスタから削除するまでの時間は、インターフェイスのタイプと、そのユニットが確立済みメンバであるか、またはクラスタに参加しようとしているかによって異なります。デフォルトでは、ヘルスチェックはすべてのインターフェイスでイネーブルになっています。このコマンドの no 形式を使用してディセーブル（無効）にすることができます。たとえば、管理インターフェイスなど、必須以外のインターフェイスのヘルスモニタリングをディセーブルにすることができます。 `interface_id` ：ポートチャネル ID と冗長 ID、または単一の物理インターフェイス ID のモニタリングを無効にします。ヘルスモニタリングは VLAN サブインターフェイス、または VNI　や BVI などの仮想インターフェイスでは実行されません。クラスタ制御リンクのモニタリングは設定できません。このリンクは常にモニタされています。 service-module ：ASA FirePOWER モジュールなどのハードウェアまたはソフトウェアモジュールのモニタリングを無効にします。なお、ASA 5585-X では、サービスモジュールのモニタリングを無効にする場合、個別にモニタされるモジュール上の各インターフェイスのモニタリングを無効にすることもできます。何らかのトポロジ変更（たとえばデータインターフェイスの追加/削除、ASA、またはスイッチ上のインターフェイスの有効化/無効化、VSS または vPC を形成するスイッチの追加）を行うときには、ヘルスチェック機能（no health-check ）を無効にし、無効化したインターフェイスのモニタリングも無効にしてください。トポロジの変更が完了して、コンフィギュレーション変更がすべてのユニットに同期されたら、ヘルスチェック機能を再度イネーブルにできます。例: `ciscoasa(cfg-cluster)# no health-check monitor-interface management0/0`
ステップ 4	ヘルスチェック失敗後の自動再結合クラスタ設定をカスタマイズします。 health-check {data-interface \| cluster-interface \| system } auto-rejoin [unlimited \| `auto_rejoin_max`] `auto_rejoin_interval auto_rejoin_interval_variation` system ：内部エラー時の自動再結合の設定を行います。内部の障害には、アプリケーション同期のタイムアウト、矛盾したアプリケーションステータスなどがあります。 unlimited ：（cluster-interface のデフォルト）再結合の試行回数を制限しません。 `auto-rejoin-max` ：再結合の試行回数を 0 ～ 65535 の範囲の値に設定します。0 は自動再結合を無効化します。data-interface と system のデフォルトは 3 です。 `auto_rejoin_interval` ：再結合試行の間隔を 2 ～ 60 の範囲の分単位で定義します。デフォルト値は 5 分です。クラスタへの再結合をユニットが試行する最大合計時間は、最後の失敗から 14,400 分に限られています。 `auto_rejoin_interval_variation` ：間隔を増加させるかどうかを定義します。1 ～ 3 の範囲で値を設定します（1 ：変更なし、2 ：直前の間隔の 2 倍、3 ：直前の間隔の 3 倍）。たとえば、間隔を 5 分に設定し、変分を 2 に設定した場合は、最初の試行が 5 分後、2 回目の試行が 10 分後（2 x 5）、3 階目の試行が 20 分後（2 x 10）となります。デフォルト値は、クラスタインターフェイスの場合は 1 、データインターフェイスおよびシステムの場合は 2 です。例: `ciscoasa(cfg-cluster)# health-check data-interface auto-rejoin 10 3 3`
ステップ 5	ASA がインターフェイスを障害が発生していると見なし、クラスタからユニットが削除されるまでのデバウンス時間を設定します。 health-check monitor-interface debounce-time `ms` 例: `ciscoasa(cfg-cluster)# health-check monitor-interface debounce-time 300` デバウンス時間は 300 ～ 9000 ms の範囲の値を設定します。デフォルトは 500 ms です。値を小さくすると、インターフェイスの障害をより迅速に検出できます。デバウンス時間を短くすると、誤検出の可能性が高くなることに注意してください。インターフェイスのステータス更新が発生すると、ASA はインターフェイスを障害としてマークし、クラスタからユニットを削除するまで指定されたミリ秒数待機します。ダウン状態から稼働状態に移行している EtherChannel の場合（スイッチがリロードされた、またはスイッチが有効になっている EtherChannel など）、デバウンス時間を長くすることで、他のクラスタユニットの方がポートのバンドルが速いという理由だけで、クラスタユニット上でインターフェイスがエラー表示されるのを防ぐことができます。

例

次の例では、ヘルスチェック保留時間を .3 秒に設定し、VSS を有効にし、管理に使用されるイーサネット 1/2 インターフェイスのモニタリングを無効にし、データインターフェイスの自動再結合の試行回数を 2 分から開始して前回の間隔の 3 倍増加させる計 4 回に設定し、クラスタ制御リンクの自動再結合の試行回数を 2 分おきの計 6 回に設定しています。


ciscoasa(config)# cluster group test
ciscoasa(cfg-cluster)# health-check holdtime .3 vss-enabled
ciscoasa(cfg-cluster)# no health-check monitor-interface ethernet1/2
ciscoasa(cfg-cluster)# health-check data-interface auto-rejoin 4 2 3
ciscoasa(cfg-cluster)# health-check cluster-interface auto-rejoin 6 2 1

接続の再分散およびクラスタ TCP 複製の遅延の設定

接続の再分散を設定できます。詳細については、新しい TCP 接続のクラスタ全体での再分散を参照してください。

TCP 接続のクラスタ複製の遅延を有効化して、ディレクタ/バックアップフロー作成の遅延による存続期間が短いフローに関連する「不要な作業」を排除できます。ディレクタ/バックアップフローが作成される前にユニットが失敗する場合は、それらのフローを回復することはできません。同様に、フローを作成する前にトラフィックが別のユニットに再調整される場合、流れを回復することはできません。TCP のランダム化を無効化するトラフィックの TCP の複製の遅延を有効化しないようにする必要があります。

手順

ステップ 1

TCP 接続のクラスタ複製の遅延を有効化します。

cluster replication delay seconds { http | match tcp {host ip_address | ip_address mask | any | any4 | any6} [{eq | lt | gt} port] { host ip_address | ip_address mask | any | any4 | any6} [{eq | lt | gt} port]}

例:


ciscoasa(config)# cluster replication delay 15 match tcp any any eq ftp
ciscoasa(config)# cluster replication delay 15 http

1 ～ 15 の範囲で秒数 を設定します。http 遅延はデフォルトで 5 秒間有効になります。

マルチコンテキストモードで、コンテキスト内でこの設定を行います。

ステップ 2

クラスタの設定モードを開始します。

cluster group name

ステップ 3

（オプション）TCP トラフィックの接続の再分散を有効化します。

conn-rebalance [frequency seconds]

例:


ciscoasa(cfg-cluster)# conn-rebalance frequency 60

このコマンドは、デフォルトでディセーブルになっています。有効化されている場合は、ASA は負荷情報を定期的に交換し、新しい接続の負荷を高負荷のデバイスから低負荷のデバイスに移動します。負荷情報を交換する間隔を、1 ～ 360 秒の範囲内で指定します。デフォルトは 5 秒です。

サイト間トポロジに対しては接続の再分散を設定しないでください。異なるサイトのクラスタメンバには接続を再分散できません。

サイト間機能の設定

サイト間クラスタリングの場合、冗長性と安定性を高めるために、設定をカスタマイズできます。

ディレクタローカリゼーションの有効化

データセンターのサイト間クラスタリングのパフォーマンスを向上させ、ラウンドトリップ時間を短縮するために、ディレクターローカリゼーションをイネーブルにすることができます。新しい接続は通常、特定のサイト内のクラスタメンバーによってロードバランスされ、所有されます。しかし、ASA は任意のサイトのメンバーにディレクタロールを割り当てます。ディレクタローカリゼーションにより、所有者と同じサイトのローカルディレクタ、どのサイトにも存在可能なグローバルディレクタという追加のディレクタロールが有効になります。所有者とディレクタが同一サイトに存在すると、パフォーマンスが向上します。また、元の所有者が失敗した場合、ローカルなディレクタは同じサイトで新しい接続の所有者を選択します。グローバルなディレクタは、クラスタメンバーが別のサイトで所有される接続のパケットを受信する場合に使用されます。

始める前に

ブートストラップ設定でクラスタメンバーのサイト ID を設定します。
次のトラフィックタイプは、ローカリゼーションをサポートしていません：NAT および PAT トラフィック、SCTP 検査されたトラフィック、フラグメンテーション所有クエリ。

手順

ステップ 1

クラスタの設定モードを開始します。

cluster group name

例:


ciscoasa(config)# cluster group cluster1
ciscoasa(cfg-cluster)#

ステップ 2

ディレクタローカリゼーションをイネーブルにします。

director-localization

サイト冗長性の有効化

サイトの障害からフローを保護するために、サイトの冗長性を有効にできます。接続バックアップオーナーがオーナーと同じサイトにある場合は、サイトの障害からフローを保護するために、追加のバックアップオーナーが別のサイトから選択されます。

始める前に

ブートストラップ設定でクラスタメンバーのサイト ID を設定します。

手順

ステップ 1

クラスタの設定モードを開始します。

cluster group name

例:


ciscoasa(config)# cluster group cluster1
ciscoasa(cfg-cluster)#

ステップ 2

サイトの冗長性を有効にします。

site-redundancy

クラスタフローモビリティの設定

LISP のトラフィックを検査して、サーバがサイト間を移動する時にフローモビリティを有効にできます。

LISP インスペクションについて

LISP トラフィックを検査することで、サイト間のフローのモビリティを有効にできます。

LISP について

VMware VMotion などのデータセンター仮想マシンのモビリティによって、サーバはクライアントへの接続を維持すると同時に、データセンター間を移動できます。このようなデータセンターサーバモビリティをサポートするには、サーバの移動時にサーバへの入力ルートをルータが更新できる必要があります。Cisco Locator/ID Separation Protocol（LISP）のアーキテクチャは、デバイス ID、つまりエンドポイント ID（EID）をその場所、つまりルーティングロケータ（RLOC）から 2 つの異なるナンバリングスペースに分離し、サーバの移行をクライアントに対して透過的にします。たとえば、サーバが新しい場所に移動し、クライアントがサーバにトラフィックを送信すると、ルータは新しい場所にトラフィックをリダイレクトします。

LISP では、LISP の出力トンネルルータ（ETR）、入力トンネルルータ（ITR）、ファーストホップルータ、マップリゾルバ（MR）、およびマップサーバ（MS）などのある一定のロールにおいてルータとサーバが必要です。サーバが別のルータに接続されていることをサーバのファーストホップルータが感知すると、そのルータは他のすべてのルータとデータベースを更新し、クライアントに接続されている ITR がトラフィックを代行受信してカプセル化し、新しいサーバの場所に送信できるようにします。

ASA LISP のサポート

ASA は LISP 自体を実行しませんが、場所の変更について LISP トラフィックを検査し、シームレスなクラスタリング操作のためにこの情報を使用できます。LISP の統合を行わない場合、サーバが新しいサイトに移動すると、トラフィックは元のフローオーナーの代わりに、新しいサイトで ASA クラスタメンバになります。新しい ASA は古いサイトの ASA にトラフィックを転送し、その後、古い ASA はサーバに到達するためにトラフィックを新しいサイトに送り返す必要があります。このトラフィックフローは最適ではなく、「トロンボーニング」または「ヘアピニング」と呼ばれます。

LISP 統合により、ASA クラスタメンバは、ファーストホップルータと ETR または ITR 間でやり取りされる LISP トラフィックを検査し、フローの所有者を新しいサイトに変更できます。

LISP のガイドライン

ASA クラスタメンバは、サイトのファーストホップルータと ITR または ETR の間に存在している必要があります。ASA クラスタ自体を拡張セグメントのファーストホップルータにすることはできません。
完全分散されたフローのみがサポートされます。一元化されたフロー、半分散されたフロー、または個々のユニットに属しているフローは新しいオーナーに移動されません。半分散されたフローには SIP などのアプリケーションが含まれており、そこでは親フローとそのすべての子フローが同じ ASA によって所有されます。
クラスタはレイヤ 3 および 4 のフロー状態を移動させるだけです。一部のアプリケーションデータが失われる可能性があります。
短時間のフローまたはビジネスに不可欠でないフローの場合、オーナーの移動は有用でない可能性があります。インスペクションポリシーを設定するときに、この機能でサポートされるトラフィックのタイプを制御できます。また、フローモビリティを不可欠なトラフィックに制限する必要があります。

ASA LISP の実装

この機能には、複数の相互に関係する設定が含まれています（それらについてはすべてこの章で説明します）。

（任意）ホストまたはサーバ IP アドレスに基づく検査対象 EID の制限：ファーストホップルータは、ASA クラスタが関与していないホストまたはネットワークに EID 通知メッセージを送信する場合があります。このため、クラスタに関連するサーバまたはネットワークのみに EID を制限できます。たとえば、クラスタが 2 つのサイトのみに関与しているが、LISP が 3 つのサイトで実行されている場合は、クラスタに関与している 2 つのサイトに対してのみ EID を含める必要があります。
LISP トラフィックのインスペクション：ASA は、ファーストホップルータと ITR または ETR 間で送信される EID 通知メッセージにおいて、UDP ポート 4342 上の LISP トラフィックを検査します。ASA は、EID とサイト ID を関連付ける EID テーブルを保持します。たとえば、ファーストホップルータの送信元 IP アドレスと ITR または ETR の宛先アドレスで LISP トラフィックを検査する必要があります。LISP トラフィックにはディレクタが割り当てられておらず、LISP トラフィック自体はクラスタ状態の共有に参加しないことに注意してください。
指定されたトラフィックでのフローモビリティを有効にするサービスポリシー：ビジネスクリティカルなトラフィックでフローモビリティを有効にする必要があります。たとえば、フローモビリティを HTTPS トラフィックおよび/または特定のサーバへのトラフィックのみに制限できます。
サイト ID：ASA は、各クラスタユニットのサイト ID を使用して新しい所有者を特定します。
フローモビリティをイネーブルにするためのクラスタレベル設定：フローモビリティは、クラスタレベルでも有効にする必要があります。このオン/オフの切り替えを使用することで、特定のクラスのトラフィックまたはアプリケーションに対してフローモビリティを簡単に有効または無効にできます。

LISP インスペクションの設定

LISP のトラフィックを検査して、サーバがサイト間を移動する時にフローモビリティを有効にできます。

始める前に

マスターユニットのブートストラップの設定およびスレーブユニットのブートストラップの設定に従って、各クラスタユニットをサイト ID に割り当てます。
LISP のトラフィックはデフォルトインスペクショントラフィッククラスに含まれないため、この手順の一部として LISP のトラフィック用に別のクラスを設定する必要があります。

手順

ステップ 1	（任意） LISP インスペクションマップを設定して、IP アドレスに基づいて検査済みの EID を制限し、LISP の事前共有キーを設定します。拡張 ACL を作成します。宛先 IP アドレスのみが EID 組み込みアドレスと照合されます。 access list `eid_acl_name` extended permit ip `source_address mask destination_address mask` IPv4 ACL および IPv6 ACL のどちらにも対応しています。厳密な access-list extended の構文については、コマンドリファレンスを参照してください。 LISP インスペクションマップを作成し、パラメータモードに移行します。 policy-map type inspect lisp `inspect_map_name` parameters 作成した ACL を識別して、許可された EID を定義します。 allowed-eid access-list `eid_acl_name` ファーストホップルータまたは ITR/ETR は、ASA クラスタが関与していないホストまたはネットワークに EID 通知メッセージを送信することがあります。このため、クラスタに関連するサーバまたはネットワークのみに EID を制限できます。たとえば、クラスタが 2 つのサイトのみに関与しているが、LISP が 3 つのサイトで実行されている場合は、クラスタに関与している 2 つのサイトに対してのみ EID を含める必要があります。必要に応じて、事前共有キーを入力します。 validate-key `key` 例: `ciscoasa(config)# access-list TRACKED_EID_LISP extended permit ip any 10.10.10.0 255.255.255.0 ciscoasa(config)# policy-map type inspect lisp LISP_EID_INSPECT ciscoasa(config-pmap)# parameters ciscoasa(config-pmap-p)# allowed-eid access-list TRACKED_EID_LISP ciscoasa(config-pmap-p)# validate-key MadMaxShinyandChrome`
ステップ 2	ファーストホップルータとポート 4342 の ITR または ETR の間の UDP トラフィックの LISP インスペクションの設定。拡張 ACL を設定して LISP のトラフィックを特定します。 access list `inspect_acl_name` extended permit udp `source_address mask destination_address mask` eq 4342 UDP ポート 4342 を指定する必要があります。IPv4 ACL および IPv6 ACL のどちらにも対応しています。厳密な access-list extended の構文については、コマンドリファレンスを参照してください。 ACL のクラスマップを作成します。 class-map `inspect_class_name` match access-list `inspect_acl_name` ポリシーマップ、クラスマップを指定し、オプションの LISP インスペクションマップを使用してインスペクションを有効化し、サービスポリシーをインターフェイスに適用します（新規であれば）。 policy-map `policy_map_name` class `inspect_class_name` inspect lisp [`inspect_map_name`] service-policy `policy_map_name` {global \| interface `ifc_name`} 既存のサービスポリシーある場合は、既存のポリシーマップ名を指定します。デフォルトで、ASA には global_policy と呼ばれるグローバルポリシーが含まれているため、グローバルポリシーの名前を指定します。ポリシーをグローバルに適用しない場合は、インターフェイスごとに 1 つのサービスポリシーを作成することもできます。LISP インスペクションは、双方向にトラフィックに適用するため、送信元と宛先の両方のインターフェイスにサービスポリシーを適用する必要はありません。トラフィックが両方向のクラスマップに一致する場合、ポリシーマップを適用するインターフェイスに入るまたは存在するトラフィックのすべてが影響を受けます。例: `ciscoasa(config)# access-list LISP_ACL extended permit udp host 192.168.50.89 host 192.168.10.8 eq 4342 ciscoasa(config)# class-map LISP_CLASS ciscoasa(config-cmap)# match access-list LISP_ACL ciscoasa(config-cmap)# policy-map INSIDE_POLICY ciscoasa(config-pmap)# class LISP_CLASS ciscoasa(config-pmap-c)# inspect lisp LISP_EID_INSPECT ciscoasa(config)# service-policy INSIDE_POLICY interface inside` ASAは、ファーストホップルータと ITR または ETR の間で送信される EID 通知メッセージの LISP トラフィックを検査します。ASA は、EID とサイト ID を関連付ける EID テーブルを保持します。
ステップ 3	トラフィッククラスのフローモビリティを有効化します。拡張 ACL を設定して、サーバがサイトを変更するときに、最適なサイトに再割り当てするビジネスクリティカルなトラフィックを特定します。 access list `flow_acl_name` extended permit udp `source_address mask destination_address mask` eq `port` IPv4 ACL および IPv6 ACL のどちらにも対応しています。厳密な access-list extended の構文については、コマンドリファレンスを参照してください。フローモビリティは、ビジネスクリティカルなトラフィックに対してイネーブルにする必要があります。たとえば、フローモビリティを HTTPS トラフィックのみ、または特定のサーバへのトラフィックのみに制限できます。 ACL のクラスマップを作成します。 class-map `flow_map_name` match access-list `flow_acl_name` LISP インスペクションを有効化した同じポリシーマップ、フロークラスマップを指定して、フローモビリティを有効にします。 policy-map `policy_map_name` class `flow_map_name` cluster flow-mobility lisp 例: `ciscoasa(config)# access-list IMPORTANT-FLOWS extended permit tcp any 10.10.10.0 255.255.255.0 eq https ciscoasa(config)# class-map IMPORTANT-FLOWS-MAP ciscoasa(config)# match access-list IMPORTANT-FLOWS ciscoasa(config-cmap)# policy-map INSIDE_POLICY ciscoasa(config-pmap)# class IMPORTANT-FLOWS-MAP ciscoasa(config-pmap-c)# cluster flow-mobility lisp`
ステップ 4	クラスタグループコンフィギュレーションモードに移行し、クラスタのフローのモビリティを有効化します。 cluster group `name` flow-mobility lisp このオン/オフの切り替えにより、フローモビリティの有効化や無効化を簡単に行えます。

例

次に例を示します。

EID を 10.10.10.0/24 ネットワーク上の EID に制限します。
192.168.50.89（内部）にある LISP ルータと 192.168.10.8（別の ASA インターフェイス上）にある ITR または ETR ルータの間の LISP トラフィック（UDP 4342）を検査します。
HTTPS を使用して 10.10.10.0/24 のサーバに送信されるすべての内部トラフィックに対してフローモビリティを有効化します。
クラスタに対してフローモビリティをイネーブルにします。


access-list TRACKED_EID_LISP extended permit ip any 10.10.10.0 255.255.255.0
policy-map type inspect lisp LISP_EID_INSPECT
   parameters 
      allowed-eid access-list TRACKED_EID_LISP
      validate-key MadMaxShinyandChrome
!
access-list LISP_ACL extended permit udp host 192.168.50.89 host 192.168.10.8 eq 4342
class-map LISP_CLASS
   match access-list LISP_ACL
policy-map INSIDE_POLICY
   class LISP_CLASS
      inspect lisp LISP_EID_INSPECT
service-policy INSIDE_POLICY interface inside
!
access-list IMPORTANT-FLOWS extended permit tcp any 10.10.10.0 255.255.255.0 eq https
class-map IMPORTANT-FLOWS-MAP
   match access-list IMPORTANT-FLOWS
policy-map INSIDE_POLICY
   class IMPORTANT-FLOWS-MAP
      cluster flow-mobility lisp
!
cluster group cluster1
   flow-mobility lisp

ASA クラスタメンバの管理

クラスタを導入した後は、コンフィギュレーションを変更し、クラスタメンバを管理できます。

非アクティブなメンバーになる

クラスタの非アクティブなメンバーになるには、クラスタリングコンフィギュレーションは変更せずに、そのユニット上でクラスタリングをディセーブルにします。

（注）

ASA が（手動で、またはヘルスチェックエラーにより）非アクティブになると、すべてのデータインターフェイスがシャットダウンされます。管理専用インターフェイスのみがトラフィックを送受信できます。トラフィックフローを再開させるには、クラスタリングを再びイネーブルにします。または、そのユニットをクラスタから完全に削除します。管理インターフェイスは、そのユニットがクラスタ IP プールから受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードしてもユニットがクラスタ内でまだアクティブではない場合（クラスタリングが無効な状態で設定を保存した場合など）、管理インターフェイスは無効になります。それ以降のコンフィギュレーション作業には、コンソールポートを使用する必要があります。

始める前に

コンソールポートを使用する必要があります。クラスタリングのイネーブルまたはディセーブルを、リモート CLI 接続から行うことはできません。
マルチコンテキストモードの場合は、この手順をシステム実行スペースで実行します。まだシステムコンフィギュレーションモードに入っていない場合は、changeto system コマンドを入力します。

手順

ステップ 1

クラスタの設定モードを開始します。

cluster group name

例:


ciscoasa(config)# cluster group pod1

ステップ 2

クラスタリングをディセーブルにします。

no enable

このユニットがマスターユニットであった場合は、新しいマスターの選定が実行され、別のメンバがマスターユニットになります。

クラスタコンフィギュレーションは維持されるので、後でクラスタリングを再度イネーブルにできます。

メンバーの非アクティブ化

任意のユニットからメンバーを非アクティブにするには、次の手順を実行します。

（注）

ASA が非アクティブになると、すべてのデータインターフェイスがシャットダウンされます。管理専用インターフェイスのみがトラフィックを送受信できます。トラフィックフローを再開させるには、クラスタリングを再びイネーブルにします。または、そのユニットをクラスタから完全に削除します。管理インターフェイスは、そのユニットがクラスタ IP プールから受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードしてもユニットがクラスタ内でまだアクティブではない場合（クラスタリングが無効な状態で設定を保存した場合など）、管理インターフェイスは無効になります。それ以降のコンフィギュレーション作業には、コンソールポートを使用する必要があります。

始める前に

マルチコンテキストモードの場合は、この手順をシステム実行スペースで実行します。まだシステムコンフィギュレーションモードに入っていない場合は、changeto system コマンドを入力します。

手順

ユニットをクラスタから削除します。

cluster remove unit unit_name

例:


ciscoasa(config)# cluster remove unit ?

Current active units in the cluster:
asa2

ciscoasa(config)# cluster remove unit asa2
WARNING: Clustering will be disabled on unit asa2. To bring it back
to the cluster please logon to that unit and re-enable clustering

ブートストラップコンフィギュレーションは変更されず、マスターユニットから最後に同期されたコンフィギュレーションもそのままになるので、コンフィギュレーションを失わずに後でそのユニットを再度追加できます。マスターユニットを削除するためにスレーブユニットでこのコマンドを入力した場合は、新しいマスターユニットが選定されます。

メンバ名を一覧表示するには、cluster remove unit ? と入力するか、show cluster info コマンドを入力します。

クラスタへの再参加

ユニットがクラスタから削除された場合（たとえば、障害が発生したインターフェイスの場合、またはメンバーを手動で非アクティブにした場合）は、クラスタに手動で再参加する必要があります。

始める前に

クラスタリングを再イネーブルにするには、コンソールポートを使用する必要があります。他のインターフェイスはシャットダウンされます。
マルチコンテキストモードの場合は、この手順をシステム実行スペースで実行します。まだシステムコンフィギュレーションモードに入っていない場合は、changeto system コマンドを入力します。
クラスタへの再参加を試行する前に、障害が解決されていることを確認します。

手順

ステップ 1

コンソールで、クラスタコンフィギュレーションモードを開始します。

cluster group name

例:


ciscoasa(config)# cluster group pod1

ステップ 2

クラスタリングをイネーブルにします。

enable

クラスタからの脱退

クラスタから完全に脱退するには、クラスタブートストラップコンフィギュレーション全体を削除する必要があります。各メンバの現在のコンフィギュレーションは（プライマリユニットから同期されて）同じであるため、クラスタから脱退すると、クラスタリング前のコンフィギュレーションをバックアップから復元するか、IP アドレスの競合を避けるためコンフィギュレーションを消去して初めからやり直すことも必要になります。

始める前に

コンソールポートを使用する必要があります。クラスタのコンフィギュレーションを削除すると、管理インターフェイスとクラスタ制御リンクを含むすべてのインターフェイスがシャットダウンされます。さらに、クラスタリングのイネーブルまたはディセーブルを、リモート CLI 接続から行うことはできません。

手順

ステップ 1	セカンダリユニットの場合、クラスタリングを次のようにディセーブルにします。 cluster group `cluster_name` no enable 例: `ciscoasa(config)# cluster group cluster1 ciscoasa(cfg-cluster)# no enable` クラスタリングがセカンダリユニット上でイネーブルになっている間は、コンフィギュレーション変更を行うことはできません。
ステップ 2	クラスタコンフィギュレーションをクリアします。 clear configure cluster ASA は、管理インターフェイスとクラスタ制御リンクを含むすべてのインターフェイスをシャットダウンします。
ステップ 3	クラスタインターフェイスモードをディセーブルにします。 no cluster interface-mode モードはコンフィギュレーションには保存されないため、手動でリセットする必要があります。
ステップ 4	バックアップコンフィギュレーションがある場合、実行コンフィギュレーションにバックアップコンフィギュレーションをコピーします。 copy `backup_cfg` running-config 例: `ciscoasa(config)# copy backup_cluster.cfg running-config Source filename [backup_cluster.cfg]? Destination filename [running-config]? ciscoasa(config)#`
ステップ 5	コンフィギュレーションをスタートアップに保存します。 write memory
ステップ 6	バックアップコンフィギュレーションがない場合は、管理アクセスを再設定します。たとえば、インターフェイス IP アドレスを変更し、正しいホスト名を復元します。

マスターユニットの変更

注意	マスターユニットを変更する最良の方法は、マスターユニットでクラスタリングを無効にし、新しいマスターの選択を待ってから、クラスタリングを再度有効にする方法です。マスターにするユニットを厳密に指定する必要がある場合は、この項の手順を使用します。ただし、中央集中型機能の場合は、この手順を使用してマスターユニット変更を強制するとすべての接続がドロップされるので、新しいマスターユニット上で接続を再確立する必要があります。

マスターユニットを変更するには、次の手順を実行します。

始める前に

手順

新しいユニットをマスターユニットとして設定します。

cluster master unit unit_name

例:


ciscoasa(config)# cluster master unit asa2

メインクラスタ IP アドレスへの再接続が必要になります。

メンバ名を一覧表示するには、cluster master unit ? （現在のユニットを除くすべての名前が表示される）と入力するか、show cluster info コマンドを入力します。

クラスタ全体でのコマンドの実行

コマンドをクラスタ内のすべてのメンバに、または特定のメンバに送信するには、次の手順を実行します。show コマンドをすべてのメンバに送信すると、すべての出力が収集されて現在のユニットのコンソールに表示されます。その他のコマンド、たとえば capture や copy も、クラスタ全体での実行を活用できます。

手順

コマンドをすべてのメンバに送信します。ユニット名を指定した場合は、特定のメンバに送信されます。

cluster exec [unit unit_name] command

例:


ciscoasa# cluster exec show xlate

メンバー名を一覧表示するには、cluster exec unit ? （現在のユニットを除くすべての名前が表示される）と入力するか、show cluster info コマンドを入力します。

例

同じキャプチャファイルをクラスタ内のすべてのユニットから同時に TFTP サーバにコピーするには、マスターユニットで次のコマンドを入力します。


ciscoasa# cluster exec copy /pcap capture: tftp://10.1.1.56/capture1.pcap

複数の PCAP ファイル（各ユニットから 1 つずつ）が TFTP サーバにコピーされます。宛先のキャプチャファイル名には自動的にユニット名が付加され、capture1_asa1.pcap、capture1_asa2.pcap などとなります。この例では、asa1 および asa2 がクラスタユニット名です。

次の例では、cluster exec show port-channel summary コマンドの出力に、クラスタの各メンバーの EtherChannel 情報が表示されています。


ciscoasa# cluster exec show port-channel summary
master(LOCAL):***********************************************************
 Number of channel-groups in use: 2
Group  Port-channel  Protocol  Span-cluster  Ports
------+-------------+-----------+-----------------------------------------------
1         Po1              LACP      	Yes  Gi0/0(P)
2         Po2              LACP      	Yes  Gi0/1(P)
 slave:******************************************************************
 Number of channel-groups in use: 2
Group  Port-channel  Protocol  Span-cluster   Ports
------+-------------+-----------+-----------------------------------------------
1         Po1              LACP      	Yes   Gi0/0(P)
2         Po2              LACP      	Yes   Gi0/1(P)

ASA クラスタのモニタリング

クラスタの状態と接続をモニタおよびトラブルシューティングできます。

クラスタステータスのモニタリング

クラスタの状態のモニタリングについては、次のコマンドを参照してください。

show cluster info [health [details]]

キーワードを指定しないで show cluster info コマンドを実行すると、クラスタ内のすべてのメンバのステータスが表示されます。

show cluster info health コマンドは、インターフェイス、ユニットおよびクラスタ全体の現在の状態を表示します。details キーワードは、ハートビートメッセージの失敗数を表示します。

show cluster info コマンドについては次の出力を参照してください。


ciscoasa# show cluster info
Cluster stbu: On
  This is "C" in state SLAVE
      ID        : 0
      Site ID   : 1
            Version   : 9.4(1)
      Serial No.: P3000000025
      CCL IP    : 10.0.0.3
      CCL MAC   : 000b.fcf8.c192
      Last join : 17:08:59 UTC Sep 26 2011
      Last leave: N/A
Other members in the cluster:
  Unit "D" in state SLAVE
      ID        : 1
      Site ID   : 1
            Version   : 9.4(1)
      Serial No.: P3000000001
      CCL IP    : 10.0.0.4
      CCL MAC   : 000b.fcf8.c162
      Last join : 19:13:11 UTC Sep 23 2011
      Last leave: N/A
  Unit "A" in state MASTER
      ID        : 2
      Site ID   : 2
            Version   : 9.4(1)
      Serial No.: JAB0815R0JY
      CCL IP    : 10.0.0.1
      CCL MAC   : 000f.f775.541e
      Last join : 19:13:20 UTC Sep 23 2011
      Last leave: N/A
  Unit "B" in state SLAVE
      ID        : 3
      Site ID   : 2
            Version   : 9.4(1)
      Serial No.: P3000000191
      CCL IP    : 10.0.0.2
      CCL MAC   : 000b.fcf8.c61e
      Last join : 19:13:50 UTC Sep 23 2011
      Last leave: 19:13:36 UTC Sep 23 2011

show cluster info auto-join

時間遅延後にクラスタユニットがクラスタに自動的に再参加するかどうか、および障害状態（ライセンスの待機やシャーシのヘルスチェック障害など）がクリアされたかどうかを示します。ユニットが永続的に無効になっている場合、またはユニットがすでにクラスタ内にある場合、このコマンドでは出力が表示されません。

show cluster info auto-join コマンドについては次の出力を参照してください。


ciscoasa(cfg-cluster)# show cluster info auto-join
Unit will try to join cluster in 253 seconds.
Quit reason: Received control message DISABLE
 
ciscoasa(cfg-cluster)# show cluster info auto-join       
Unit will try to join cluster when quit reason is cleared.
Quit reason: Master has application down that slave has up.
 
ciscoasa(cfg-cluster)# show cluster info auto-join        
Unit will try to join cluster when quit reason is cleared.
Quit reason: Chassis-blade health check failed.
 
ciscoasa(cfg-cluster)# show cluster info auto-join        
Unit will try to join cluster when quit reason is cleared.
Quit reason: Service chain application became down.
 
ciscoasa(cfg-cluster)# show cluster info auto-join
Unit will try to join cluster when quit reason is cleared.
Quit reason: Unit is kicked out from cluster because of Application health check failure.
 
ciscoasa(cfg-cluster)# show cluster info auto-join
Unit join is pending (waiting for the smart license entitlement: ent1)
 
ciscoasa(cfg-cluster)# show cluster info auto-join
Unit join is pending (waiting for the smart license export control flag)

show cluster info transport {asp |cp [detail ]}

次のトランスポート関連の統計情報を表示します。

asp：データプレーンのトランスポート統計情報。

cp：コントロールプレーンのトランスポート統計情報。

detail キーワードを入力すると、クラスタで信頼性の高いトランスポートプロトコルの使用状況が表示され、バッファがコントロールプレーンでいっぱいになったときにパケットドロップの問題を特定できます。show cluster info transport cp detail コマンドについては次の出力を参照してください。


ciscoasa# show cluster info transport cp detail
Member ID to name mapping: 
  0 - unit-1-1   2 - unit-4-1   3 - unit-2-1 

Legend:
  U    - unreliable messages
  UE   - unreliable messages error
  SN   - sequence number
  ESN  - expecting sequence number
  R    - reliable messages
  RE   - reliable messages error
  RDC  - reliable message deliveries confirmed
  RA   - reliable ack packets received
  RFR  - reliable fast retransmits
  RTR  - reliable timer-based retransmits
  RDP  - reliable message dropped
  RDPR - reliable message drops reported
  RI   - reliable message with old sequence number
  RO   - reliable message with out of order sequence number
  ROW  - reliable message with out of window sequence number
  ROB  - out of order reliable messages buffered
  RAS  - reliable ack packets sent

This unit as a sender
--------------------------
        all       0         2         3         
  U     123301    3867966   3230662   3850381   
  UE    0         0         0         0         
  SN    1656a4ce  acb26fe   5f839f76  7b680831  
  R     733840    1042168   852285    867311    
  RE    0         0         0         0         
  RDC   699789    934969    740874    756490    
  RA    385525    281198    204021    205384    
  RFR   27626     56397     0         0         
  RTR   34051     107199    111411    110821    
  RDP   0         0         0         0         
  RDPR  0         0         0         0         

This unit as a receiver of broadcast messages
---------------------------------------------
        0         2         3         
  U     111847    121862    120029    
  R     7503      665700    749288    
  ESN   5d75b4b3  6d81d23   365ddd50  
  RI    630       34278     40291     
  RO    0         582       850       
  ROW   0         566       850       
  ROB   0         16        0         
  RAS   1571      123289    142256    

This unit as a receiver of unicast messages
---------------------------------------------
        0         2         3         
  U     1         3308122   4370233   
  R     513846    879979    1009492   
  ESN   4458903a  6d841a84  7b4e7fa7  
  RI    66024     108924    102114    
  RO    0         0         0         
  ROW   0         0         0         
  ROB   0         0         0         
  RAS   130258    218924    228303    

Gated Tx Buffered Message Statistics
-------------------------------------
    current sequence number: 0

    total:                   0
    current:                 0
    high watermark:          0

    delivered:               0
    deliver failures:        0

    buffer full drops:       0
    message truncate drops:  0

    gate close ref count:    0

    num of supported clients:45

MRT Tx of broadcast messages
=============================
Message high watermark: 3%
  Total messages buffered at high watermark: 5677
  [Per-client message usage at high watermark]
  ---------------------------------------------------------------
  Client name                          Total messages  Percentage  
  Cluster Redirect Client                        4153         73% 
  Route Cluster Client                            419          7% 
  RRI Cluster Client                             1105         19% 

Current MRT buffer usage: 0%
  Total messages buffered in real-time: 1
  [Per-client message usage in real-time]
  Legend:
        F - MRT messages sending when buffer is full
        L - MRT messages sending when cluster node leave
        R - MRT messages sending in Rx thread
  ----------------------------------------------------------------------------
  Client name                          Total messages  Percentage    F   L   R
  VPN Clustering HA Client                          1        100%    0   0   0

MRT Tx of unitcast messages(to member_id:0)
============================================
Message high watermark: 31%
  Total messages buffered at high watermark: 4059
  [Per-client message usage at high watermark]
  ---------------------------------------------------------------
  Client name                          Total messages  Percentage  
  Cluster Redirect Client                        3731         91% 
  RRI Cluster Client                              328          8% 

Current MRT buffer usage: 29%
  Total messages buffered in real-time: 3924
  [Per-client message usage in real-time]
  Legend:
        F - MRT messages sending when buffer is full
        L - MRT messages sending when cluster node leave
        R - MRT messages sending in Rx thread
  ----------------------------------------------------------------------------
  Client name                          Total messages  Percentage    F   L   R
  Cluster Redirect Client                        3607         91%    0   0   0
  RRI Cluster Client                              317          8%    0   0   0

MRT Tx of unitcast messages(to member_id:2)
============================================
Message high watermark: 14%
  Total messages buffered at high watermark: 578
  [Per-client message usage at high watermark]
  ---------------------------------------------------------------
  Client name                          Total messages  Percentage  
  VPN Clustering HA Client                        578        100% 

Current MRT buffer usage: 0%
  Total messages buffered in real-time: 0

MRT Tx of unitcast messages(to member_id:3)
============================================
Message high watermark: 12%
  Total messages buffered at high watermark: 573
  [Per-client message usage at high watermark]
  ---------------------------------------------------------------
  Client name                          Total messages  Percentage  
  VPN Clustering HA Client                        572         99% 
  Cluster VPN Unique ID Client                      1          0% 
              
Current MRT buffer usage: 0%
  Total messages buffered in real-time: 0

show cluster history

クラスタの履歴を表示します。

クラスタ全体のパケットのキャプチャ

クラスタでのパケットのキャプチャについては、次のコマンドを参照してください。

cluster exec capture

クラスタ全体のトラブルシューティングをサポートするには、cluster exec capture コマンドを使用してマスターユニット上でのクラスタ固有トラフィックのキャプチャをイネーブルにします。これで、クラスタ内のすべてのスレーブユニットでも自動的にイネーブルになります。

クラスタリソースのモニタリング

クラスタリソースのモニタリングについては、次のコマンドを参照してください。

show cluster {cpu | memory | resource} [options]

クラスタ全体の集約データを表示します。使用可能な options はデータのタイプによって異なります。

クラスタトラフィックのモニタリング

クラスタトラフィックのモニタリングについては、次のコマンドを参照してください。

show conn [detail]、cluster exec show conn

show conn コマンドは、フローがディレクタ、バックアップ、またはフォワーダのどのフローであるかを示します。cluster exec show conn コマンドを任意のユニットで使用すると、すべての接続が表示されます。このコマンドの表示からは、1 つのフローのトラフィックがクラスタ内のさまざまな ASA にどのように到達するかがわかります。クラスタのスループットは、ロードバランシングの効率とコンフィギュレーションによって異なります。このコマンドを利用すると、ある接続のトラフィックがクラスタ内をどのように流れるかが簡単にわかります。また、ロードバランサがフローのパフォーマンスにどのように影響を与えるかを理解するのに役立ちます。

また、show conn detail コマンドはフローモビリティの影響を受けるフローを表示します。

次に、show conn detail コマンドの出力例を示します。


ciscoasa/ASA2/slave# show conn detail
12 in use, 13 most used
Cluster stub connections: 0 in use, 46 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
       B - initial SYN from outside, b - TCP state-bypass or nailed,
       C - CTIQBE media, c - cluster centralized,
       D - DNS, d - dump, E - outside back connection, e - semi-distributed,
       F - outside FIN, f - inside FIN,
       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
       i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
       k - Skinny media, L - LISP triggered flow owner mobility,
       M - SMTP data, m - SIP media, n - GUP
       O - outbound data, o - offloaded,
       P - inside back connection,
       Q - Diameter, q - SQL*Net data,
       R - outside acknowledged FIN,
       R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,
       V - VPN orphan, W - WAAS,
       w - secondary domain backup,
       X - inspected by service module,
       x - per session, Y - director stub flow, y - backup stub flow,
       Z - Scansafe redirection, z - forwarding stub flow
ESP outside: 10.1.227.1/53744 NP Identity Ifc: 10.1.226.1/30604, , flags c, idle 0s, uptime
1m21s, timeout 30s, bytes 7544, cluster sent/rcvd bytes 0/0, owners (0,255) Traffic received
at interface outside Locally received: 7544 (93 byte/s) Traffic received at interface NP
Identity Ifc Locally received: 0 (0 byte/s) UDP outside: 10.1.227.1/500 NP Identity Ifc:
10.1.226.1/500, flags -c, idle 1m22s, uptime 1m22s, timeout 2m0s, bytes 1580, cluster
sent/rcvd bytes 0/0, cluster sent/rcvd total bytes 0/0, owners (0,255) Traffic received at
interface outside Locally received: 864 (10 byte/s) Traffic received at interface NP Identity
Ifc Locally received: 716 (8 byte/s)

接続フローのトラブルシューティングを行うには、最初にすべてのユニットの接続を一覧表示します。それには、任意のユニットで cluster exec show conn コマンドを入力します。ディレクタ（Y）、バックアップ（y）、およびフォワーダ（z）のフラグを持つフローを探します。次の例には、3 つのすべての ASA での 172.18.124.187:22 から 192.168.103.131:44727 への SSH 接続が表示されています。ASA1 には z フラグがあり、この接続のフォワーダであることを表しています。ASA3 には Y フラグがあり、この接続のディレクタであることを表しています。ASA2 には特別なフラグはなく、これがオーナーであることを表しています。アウトバウンド方向では、この接続のパケットは ASA2 の内部インターフェイスに入り、外部インターフェイスから出ていきます。インバウンド方向では、この接続のパケットは ASA1 および ASA3 の外部インターフェイスに入り、クラスタ制御リンクを介して ASA2 に転送され、次に ASA2 の内部インターフェイスから出ていきます。


ciscoasa/ASA1/master# cluster exec show conn
ASA1(LOCAL):**********************************************************
18 in use, 22 most used
Cluster stub connections: 0 in use, 5 most used
TCP outside  172.18.124.187:22 inside  192.168.103.131:44727, idle 0:00:00, bytes 37240828, flags z


ASA2:*****************************************************************
12 in use, 13 most used
Cluster stub connections: 0 in use, 46 most used
TCP outside  172.18.124.187:22 inside  192.168.103.131:44727, idle 0:00:00, bytes 37240828, flags UIO


ASA3:*****************************************************************
10 in use, 12 most used
Cluster stub connections: 2 in use, 29 most used
TCP outside  172.18.124.187:22 inside  192.168.103.131:44727, idle 0:00:03, bytes 0, flags  Y

show cluster info [conn-distribution | packet-distribution | loadbalance | flow-mobility counters]

show cluster info conn-distribution コマンドと show cluster info packet-distribution コマンドは、すべてのクラスタユニットへのトラフィック分散を表示します。これらのコマンドは、外部ロードバランサを評価し、調整するのに役立ちます。

show cluster info loadbalance コマンドは、接続再分散の統計情報を表示します。

show cluster info flow-mobility counters コマンドは、EID およびフローの所有者の動作情報を表示します。show cluster info flow-mobility counters コマンドについては次の出力を参照してください。
```
ciscoasa# show cluster info flow-mobility counters
EID movement notification received  : 4
EID movement notification processed : 4
Flow owner moving requested         : 2
```

show cluster {access-list | conn | traffic | user-identity | xlate} [options]

クラスタ全体の集約データを表示します。使用可能な options はデータのタイプによって異なります。

show cluster access-list コマンドについては次の出力を参照してください。


ciscoasa# show cluster access-list
hitcnt display order: cluster-wide aggregated result, unit-A, unit-B,  unit-C, unit-D
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096) alert-interval 300
access-list 101; 122 elements; name hash: 0xe7d586b5
access-list 101 line 1 extended permit tcp 192.168.143.0 255.255.255.0 any eq www (hitcnt=0, 0, 0, 0, 0) 0x207a2b7d
access-list 101 line 2 extended permit tcp any 192.168.143.0 255.255.255.0 (hitcnt=0, 0, 0, 0, 0) 0xfe4f4947
access-list  101 line 3 extended permit tcp host 192.168.1.183 host 192.168.43.238 (hitcnt=1, 0, 0, 0, 1) 0x7b521307
access-list 101 line 4 extended permit tcp host 192.168.1.116 host 192.168.43.238 (hitcnt=0, 0, 0, 0, 0) 0x5795c069
access-list 101 line 5 extended permit tcp host 192.168.1.177 host 192.168.43.238 (hitcnt=1, 0, 0, 1, 0) 0x51bde7ee
access list 101 line 6 extended permit tcp host 192.168.1.177 host 192.168.43.13 (hitcnt=0, 0, 0, 0, 0) 0x1e68697c
access-list 101 line 7 extended permit tcp host 192.168.1.177 host 192.168.43.132 (hitcnt=2, 0, 0, 1, 1) 0xc1ce5c49
access-list 101 line 8 extended permit tcp host 192.168.1.177 host 192.168.43.192 (hitcnt=3, 0, 1, 1, 1) 0xb6f59512
access-list 101 line 9 extended permit tcp host 192.168.1.177 host 192.168.43.44 (hitcnt=0, 0, 0, 0, 0) 0xdc104200
access-list 101 line 10 extended permit tcp host 192.168.1.112 host 192.168.43.44 (hitcnt=429, 109, 107, 109, 104)
0xce4f281d
access-list 101 line 11 extended permit tcp host 192.168.1.170 host 192.168.43.238 (hitcnt=3, 1, 0, 0, 2) 0x4143a818
access-list 101 line 12 extended permit tcp host 192.168.1.170 host 192.168.43.169 (hitcnt=2, 0, 1, 0, 1) 0xb18dfea4
access-list 101 line 13 extended permit tcp host 192.168.1.170 host 192.168.43.229 (hitcnt=1, 1, 0, 0, 0) 0x21557d71
access-list 101 line 14 extended permit tcp host 192.168.1.170 host 192.168.43.106 (hitcnt=0, 0, 0, 0, 0) 0x7316e016
access-list 101 line 15 extended permit tcp host 192.168.1.170 host 192.168.43.196 (hitcnt=0, 0, 0, 0, 0) 0x013fd5b8
access-list 101 line 16 extended permit tcp host 192.168.1.170 host 192.168.43.75 (hitcnt=0, 0, 0, 0, 0) 0x2c7dba0d

使用中の接続の、すべてのユニットでの合計数を表示するには、次のとおりに入力します。


ciscoasa# show cluster conn count
Usage Summary In Cluster:*********************************************
  200 in use (cluster-wide aggregated)
     cl2(LOCAL):***********************************************************
  100 in use, 100 most used

  cl1:******************************************************************
  100 in use, 100 most used

show asp cluster counter

このコマンドは、データパスのトラブルシューティングに役立ちます。

クラスタのルーティングのモニタリング

クラスタのルーティングについては、次のコマンドを参照してください。

show route cluster
debug route cluster

クラスタのルーティング情報を表示します。

show lisp eid

EIDs とサイト ID を示す ASA EID テーブルを表示します。

cluster exec show lisp eid コマンドからの、次の出力を参照してください。


ciscoasa# cluster exec show lisp eid
L1(LOCAL):************************************************************
     LISP EID       Site ID
    33.44.33.105        2
    33.44.33.201        2
    11.22.11.1             4
    11.22.11.2             4
L2:*******************************************************************
     LISP EID       Site ID
    33.44.33.105        2
    33.44.33.201        2
    11.22.11.1 	 4
    11.22.11.2	 4

show asp table classify domain inspect-lisp

このコマンドは、トラブルシューティングに役立ちます。

クラスタリングのロギングの設定

クラスタリングのロギングの設定については、次のコマンドを参照してください。

logging device-id

クラスタ内の各ユニットは、syslog メッセージを個別に生成します。logging device-id コマンドを使用すると、同一または異なるデバイス ID 付きで syslog メッセージを生成することができ、クラスタ内の同一または異なるユニットからのメッセージのように見せることができます。

クラスタのインターフェイスのモニタリング

クラスタのインターフェイスのモニタリングについては、次のコマンドを参照してください。

show cluster interface-mode

クラスタインターフェイスのモードを表示します。
show port-channel

ポートチャネルがスパンドかどうかに関する情報が含まれます。
show lacp cluster {system-mac | system-id}

cLACP システム ID およびプライオリティを表示します。
debug lacp cluster [all | ccp | misc | protocol]

cLACP のデバッグメッセージを表示します。

show interface

MAC アドレスを使用している場合、その使用状況を表示します。


ciscoasa# show interface port-channel1.3151
Interface Port-channel1.3151 "inside", is up, line protocol is up
Hardware is EtherChannel/LACP, BW 1000 Mbps, DLY 10 usec
VLAN identifier 3151
MAC address aaaa.1111.1234, MTU 1500
Site Specific MAC address aaaa.1111.aaaa
IP address 10.3.1.1, subnet mask 255.255.255.0
Traffic Statistics for "inside":
132269 packets input, 6483425 bytes
1062 packets output, 110448 bytes
98530 packets dropped

クラスタリングのデバッグ

クラスタリングのデバッグについては、次のコマンドを参照してください。

debug cluster [ccp | datapath | fsm | general | hc | license | rpc | transport]

クラスタリングのデバッグメッセージを表示します。
debug cluster flow-mobility

クラスタリングフローモビリティ関連のイベントを表示します。
debug lisp eid-notify-intercept

EID 通知メッセージ代行受信時のイベントを表示します。

show cluster info trace

show cluster info trace コマンドは、トラブルシューティングのためのデバッグ情報を表示します。

show cluster info trace コマンドについては次の出力を参照してください。


ciscoasa# show cluster info trace
 Feb 02 14:19:47.456 [DBUG]Receive CCP message: CCP_MSG_LOAD_BALANCE
 Feb 02 14:19:47.456 [DBUG]Receive CCP message: CCP_MSG_LOAD_BALANCE
 Feb 02 14:19:47.456 [DBUG]Send CCP message to all: CCP_MSG_KEEPALIVE from 80-1 at MASTER

ASA クラスタリングの例

以下の例には、一般的な導入での ASA のクラスタ関連のすべてのコンフィギュレーションが含まれます。

ASA およびスイッチのコンフィギュレーションの例

次のコンフィギュレーション例は、ASA とスイッチ間の次のインターフェイスを接続します。


ASA インターフェイス	スイッチインターフェイス
GigabitEthernet 0/2	GigabitEthernet 1/0/15
GigabitEthernet 0/3	GigabitEthernet 1/0/16
GigabitEthernet 0/4	GigabitEthernet 1/0/17
GigabitEthernet 0/5	GigabitEthernet 1/0/18

ASA の設定

各ユニットのインターフェイスモード


cluster interface-mode spanned force

ASA1 マスターブートストラップコンフィギュレーション


interface GigabitEthernet0/0
 channel-group 1 mode on
 no shutdown
!
interface GigabitEthernet0/1
 channel-group 1 mode on
 no shutdown
!
interface Port-channel1
 description Clustering Interface
!
cluster group Moya
 local-unit A
 cluster-interface Port-channel1 ip 10.0.0.1 255.255.255.0
 priority 10
 key emphyri0
 enable noconfirm

ASA2 スレーブブートストラップコンフィギュレーション


interface GigabitEthernet0/0
 channel-group 1 mode on
 no shutdown
!
interface GigabitEthernet0/1
 channel-group 1 mode on
 no shutdown
!
interface Port-channel1
 description Clustering Interface
!
cluster group Moya
 local-unit B
 cluster-interface Port-channel1 ip 10.0.0.2 255.255.255.0
 priority 11
 key emphyri0
 enable as-slave

マスターインターフェイスコンフィギュレーション


ip local pool mgmt-pool 10.53.195.231-10.53.195.232

interface GigabitEthernet0/2
 channel-group 10 mode active
 no shutdown
!
interface GigabitEthernet0/3
 channel-group 10 mode active
 no shutdown
!
interface GigabitEthernet0/4
 channel-group 11 mode active
 no shutdown
!
interface GigabitEthernet0/5
 channel-group 11 mode active
 no shutdown
!
interface Management0/0
 management-only
 nameif management
 ip address 10.53.195.230 cluster-pool mgmt-pool
 security-level 100
 no shutdown
!
interface Port-channel10
 port-channel span-cluster
 mac-address aaaa.bbbb.cccc
 nameif inside
 security-level 100
 ip address 209.165.200.225 255.255.255.224
!
interface Port-channel11
 port-channel span-cluster
 mac-address aaaa.dddd.cccc
 nameif outside
 security-level 0
 ip address 209.165.201.1 255.255.255.224

Cisco IOS スイッチのコンフィギュレーション


interface GigabitEthernet1/0/15
 switchport access vlan 201
 switchport mode access
 spanning-tree portfast
 channel-group 10 mode active
!
interface GigabitEthernet1/0/16
 switchport access vlan 201
 switchport mode access
 spanning-tree portfast
 channel-group 10 mode active
!
interface GigabitEthernet1/0/17
 switchport access vlan 401
 switchport mode access
 spanning-tree portfast
 channel-group 11 mode active
!
interface GigabitEthernet1/0/18
 switchport access vlan 401
 switchport mode access
 spanning-tree portfast
 channel-group 11 mode active

interface Port-channel10
 switchport access vlan 201
 switchport mode access

interface Port-channel11
 switchport access vlan 401
 switchport mode access

スティック上のファイアウォール

異なるセキュリティドメインからのデータトラフィックには、異なる VLAN が関連付けられます。たとえば内部ネットワーク用には VLAN 10、外部ネットワークには VLAN 20 とします。各 ASA は単一の物理ポートがあり、外部スイッチまたはルータに接続されます。トランキングがイネーブルになっているので、物理リンク上のすべてのパケットが 802.1q カプセル化されます。ASA は、VLAN 10 と VLAN 20 の間のファイアウォールです。

スパンド EtherChannel を使用するときは、スイッチ側ですべてのデータリンクがグループ化されて 1 つの EtherChannel となります。ASA の 1 つが使用不可能になった場合は、スイッチは残りのユニット間でトラフィックを再分散します。

各ユニットのインターフェイスモード


cluster interface-mode spanned force

ASA1 マスターブートストラップコンフィギュレーション


interface tengigabitethernet 0/8

no shutdown
description CCL

cluster group cluster1

local-unit asa1
cluster-interface tengigabitethernet0/8 ip 192.168.1.1 255.255.255.0
priority 1
key chuntheunavoidable
enable noconfirm

ASA2 スレーブブートストラップコンフィギュレーション


interface tengigabitethernet 0/8

no shutdown
description CCL

cluster group cluster1

local-unit asa2
cluster-interface tengigabitethernet0/8 ip 192.168.1.2 255.255.255.0
priority 2
key chuntheunavoidable
enable as-slave

ASA3 スレーブブートストラップコンフィギュレーション


interface tengigabitethernet 0/8

no shutdown
description CCL

cluster group cluster1

local-unit asa3
cluster-interface tengigabitethernet0/8 ip 192.168.1.3 255.255.255.0
priority 3
key chuntheunavoidable
enable as-slave

マスターインターフェイスコンフィギュレーション


ip local pool mgmt 10.1.1.2-10.1.1.9
ipv6 local pool mgmtipv6 2001:DB8::1002/64 8
interface management 0/0

nameif management
ip address 10.1.1.1 255.255.255.0 cluster-pool mgmt
ipv6 address 2001:DB8::1001/32 cluster-pool mgmtipv6
security-level 100
management-only
no shutdown

interface tengigabitethernet 0/9

channel-group 2 mode active
no shutdown
interface port-channel 2
port-channel span-cluster
interface port-channel 2.10
vlan 10
nameif inside
ip address 10.10.10.5 255.255.255.0
ipv6 address 2001:DB8:1::5/64
mac-address 000C.F142.4CDE
interface port-channel 2.20
vlan 20
nameif outside
ip address 209.165.201.1 255.255.255.224
ipv6 address 2001:DB8:2::8/64
mac-address 000C.F142.5CDE

トラフィックの分離

内部ネットワークと外部ネットワークの間で、トラフィックを物理的に分離できます。

上の図に示すように、左側に一方のスパンド EtherChannel があり、内部スイッチに接続されています。他方は右側にあり、外部スイッチに接続されています。必要であれば、各 EtherChannel 上に VLAN サブインターフェイスを作成することもできます。

各ユニットのインターフェイスモード


cluster interface-mode spanned force

ASA1 マスターブートストラップコンフィギュレーション


interface tengigabitethernet 0/6

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/7

channel-group 1 mode on
no shutdown
interface port-channel 1
description CCL

cluster group cluster1

local-unit asa1
cluster-interface port-channel1 ip 192.168.1.1 255.255.255.0
priority 1
key chuntheunavoidable
enable noconfirm

ASA2 スレーブブートストラップコンフィギュレーション


interface tengigabitethernet 0/6

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/7

channel-group 1 mode on
no shutdown
interface port-channel 1
description CCL

cluster group cluster1

local-unit asa2
cluster-interface port-channel1 ip 192.168.1.2 255.255.255.0
priority 2
key chuntheunavoidable
enable as-slave

ASA3 スレーブブートストラップコンフィギュレーション


interface tengigabitethernet 0/6

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/7

channel-group 1 mode on
no shutdown
interface port-channel 1
description CCL

cluster group cluster1

local-unit asa3
cluster-interface port-channel1 ip 192.168.1.3 255.255.255.0
priority 3
key chuntheunavoidable
enable as-slave

マスターインターフェイスコンフィギュレーション


ip local pool mgmt 10.1.1.2-10.1.1.9
ipv6 local pool mgmtipv6 2001:DB8::1002/64 8
interface management 0/0

nameif management
ip address 10.1.1.1 255.255.255.0 cluster-pool mgmt
ipv6 address 2001:DB8::1001/32 cluster-pool mgmtipv6
security-level 100
management-only
no shutdown

interface tengigabitethernet 0/8

channel-group 2 mode active
no shutdown
interface port-channel 2
port-channel span-cluster
nameif inside
ip address 10.10.10.5 255.255.255.0
ipv6 address 2001:DB8:1::5/64
mac-address 000C.F142.4CDE

interface tengigabitethernet 0/9

channel-group 3 mode active
no shutdown
interface port-channel 3
port-channel span-cluster
nameif outside
ip address 209.165.201.1 255.255.255.224
ipv6 address 2001:DB8:2::8/64
mac-address 000C.F142.5CDE

スパンド EtherChannel とバックアップリンク（従来の 8 アクティブ/8 スタンバイ）

従来の EtherChannel のアクティブポートの最大数は、スイッチ側からの 8 に制限されます。8 台の ASA から成るクラスタがあり、EtherChannel にユニットあたり 2 ポートを割り当てた場合は、合計 16 ポートのうち 8 ポートをスタンバイモードにする必要があります。ASA は、どのリンクをアクティブまたはスタンバイにするかを、LACP を使用してネゴシエートします。VSS または vPC を使用してマルチスイッチ EtherChannel をイネーブルにした場合は、スイッチ間の冗長性を実現できます。ASA では、すべての物理ポートが最初にスロット番号順、次にポート番号順に並べられます。次の図では、番号の小さいポートが「マスター」ポートとなり（たとえば GigabitEthernet 0/0）、他方が「スレーブ」ポートとなります（たとえば GigabitEthernet 0/1）。ハードウェア接続の対称性を保証する必要があります。つまり、すべてのマスターリンクは 1 台のスイッチが終端となり、すべてのスレーブリンクは別のスイッチが終端となっている必要があります（VSS/vPC が使用されている場合）。次の図は、クラスタに参加するユニットが増えてリンクの総数が増加したときに、どのようになるかを示しています。

原則として、初めにチャネル内のアクティブポート数を最大化し、そのうえで、アクティブなマスターポートとアクティブなスレーブポートの数のバランスを保ちます。5 番目のユニットがクラスタに参加したときは、トラフィックがすべてのユニットに均等には分散されないことに注意してください。

リンクまたはデバイスの障害が発生したときも、同じ原則で処理されます。その結果、ロードバランシングが理想的な状態にはならないこともあります。次の図は、4 ユニットのクラスタを示しています。このユニットの 1 つで、単一リンク障害が発生しています。

ネットワーク内に複数の EtherChannel を設定することも考えられます。次の図では、EtherChannel が内部に 1 つ、外部に 1 つあります。ASA は、一方の EtherChannel でマスターとスレーブの両方のリンクが障害状態になった場合にクラスタから削除されます。これは、その ASA がすでに内部ネットワークへの接続を失っているにもかかわらず、外部ネットワークからトラフィックを受信するのを防ぐためです。

各ユニットのインターフェイスモード


cluster interface-mode spanned force

ASA1 マスターブートストラップコンフィギュレーション


interface tengigabitethernet 0/6

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/7

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/8

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/9

channel-group 1 mode on
no shutdown
interface port-channel 1
description CCL

cluster group cluster1

local-unit asa1
cluster-interface port-channel1 ip 192.168.1.1 255.255.255.0
priority 1
key chuntheunavoidable
enable noconfirm

ASA2 スレーブブートストラップコンフィギュレーション


interface tengigabitethernet 0/6

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/7

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/8

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/9

channel-group 1 mode on
no shutdown
interface port-channel 1
description CCL

cluster group cluster1

local-unit asa2
cluster-interface port-channel1 ip 192.168.1.2 255.255.255.0
priority 2
key chuntheunavoidable
enable as-slave

ASA3 スレーブブートストラップコンフィギュレーション


interface tengigabitethernet 0/6

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/7

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/8

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/9

channel-group 1 mode on
no shutdown
interface port-channel 1
description CCL

cluster group cluster1

local-unit asa3
cluster-interface port-channel1 ip 192.168.1.3 255.255.255.0
priority 3
key chuntheunavoidable
enable as-slave

ASA4 スレーブブートストラップコンフィギュレーション


interface tengigabitethernet 0/6

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/7

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/8

channel-group 1 mode on
no shutdown

interface tengigabitethernet 0/9

channel-group 1 mode on
no shutdown
interface port-channel 1
description CCL

cluster group cluster1

local-unit asa4
cluster-interface port-channel1 ip 192.168.1.4 255.255.255.0
priority 4
key chuntheunavoidable
enable as-slave

マスターインターフェイスコンフィギュレーション


ip local pool mgmt 10.1.1.2-10.1.1.9
interface management 0/0

channel-group 2 mode active
no shutdown

interface management 0/1

channel-group 2 mode active
no shutdown
interface port-channel 2
nameif management
ip address 10.1.1.1 255.255.255.0 cluster-pool mgmt
security-level 100
management-only

interface tengigabitethernet 1/6

channel-group 3 mode active vss-id 1
no shutdown

interface tengigabitethernet 1/7

channel-group 3 mode active vss-id 2
no shutdown
interface port-channel 3
port-channel span-cluster vss-load-balance
nameif inside
ip address 10.10.10.5 255.255.255.0
mac-address 000C.F142.4CDE

interface tengigabitethernet 1/8

channel-group 4 mode active vss-id 1
no shutdown

interface tengigabitethernet 1/9

channel-group 4 mode active vss-id 2
no shutdown
interface port-channel 4
port-channel span-cluster vss-load-balance
nameif outside
ip address 209.165.201.1 255.255.255.224
mac-address 000C.F142.5CDE

ルーテッドモードサイト間クラスタリングの OTV 設定

スパンド EtherChannel を使用したルーテッドモードに対するサイト間クラスタリングの成功は、OTV の適切な設定とモニタリングによって異なります。OTV は、DCI 全体にパケットを転送することで、重要な役割を果たします。OTV は、転送テーブルに MAC アドレスを学習するときにのみ、DCI 全体にユニキャストパケットを転送します。MAC アドレスが OTV 転送テーブルに学習されていない場合、ユニキャストパケットはドロップされます。

OTV 設定の例


//Sample OTV config:
//3151 – Inside VLAN, 3152 – Outside VLAN, 202 – CCL VLAN
//aaaa.1111.1234 – ASA inside interface global vMAC
//0050.56A8.3D22 – Server MAC

feature ospf
feature otv

mac access-list ALL_MACs
  10 permit any any
mac access-list HSRP_VMAC
  10 permit aaaa.1111.1234 0000.0000.0000 any
  20 permit aaaa.2222.1234 0000.0000.0000 any
  30 permit any aaaa.1111.1234 0000.0000.0000
  40 permit any aaaa.2222.1234 0000.0000.0000
vlan access-map Local 10
  match mac address HSRP_VMAC
  action drop
vlan access-map Local 20
  match mac address ALL_MACs
  action forward
vlan filter Local vlan-list 3151-3152


//To block global MAC with ARP inspection:
arp access-list HSRP_VMAC_ARP    
  10 deny aaaa.1111.1234 0000.0000.0000 any
  20 deny aaaa.2222.1234 0000.0000.0000 any
  30 deny any aaaa.1111.1234 0000.0000.0000
  40 deny any aaaa.2222.1234 0000.0000.0000
  50 permit ip any mac
ip arp inspection filter HSRP_VMAC_ARP 3151-3152

no ip igmp snooping optimise-multicast-flood
vlan 1,202,1111,2222,3151-3152

otv site-vlan 2222
mac-list GMAC_DENY seq 10 deny aaaa.aaaa.aaaa ffff.ffff.ffff
mac-list GMAC_DENY seq 20 deny aaaa.bbbb.bbbb ffff.ffff.ffff
mac-list GMAC_DENY seq 30 permit 0000.0000.0000 0000.0000.0000
route-map stop-GMAC permit 10
  match mac-list GMAC_DENY

interface Overlay1
  otv join-interface Ethernet8/1
  otv control-group 239.1.1.1
  otv data-group 232.1.1.0/28
  otv extend-vlan 202, 3151
  otv arp-nd timeout 60
  no shutdown

interface Ethernet8/1
  description uplink_to_OTV_cloud
  mtu 9198
  ip address 10.4.0.18/24
  ip igmp version 3
  no shutdown

interface Ethernet8/2

interface Ethernet8/3
  description back_to_default_vdc_e6/39
  switchport
    switchport mode trunk
    switchport trunk allowed vlan 202,2222,3151-3152
  mac packet-classify
  no shutdown

otv-isis default
  vpn Overlay1
    redistribute filter route-map stop-GMAC
otv site-identifier 0x2
//OTV flood not required for ARP inspection:
otv flood mac 0050.56A8.3D22 vlan 3151

サイト障害のために必要な OTV フィルタの変更

サイトがダウンした場合は、グローバル MAC アドレスをそれ以上ブロックしなくて済むように、フィルタを OTV から削除する必要があります。必要ないくつかの追加設定があります。

機能しているサイトで OTV スイッチ上の ASA グローバル MAC アドレスに対するスタティックエントリを追加する必要があります。このエントリによって、反対側の OTV はオーバーレイインターフェイスにこれらのエントリを追加できます。サーバとクライアントに ASA 用の ARP エントリがすでにある場合（これは既存の接続の場合です）、ARP は再送信されないので、この手順が必要になります。したがって、OTV は転送テーブルに ASA グローバル MAC アドレスを学習する機会はありません。OTV には転送テーブル内にグローバル MAC アドレスがなく、OTV の設計ごとに OTV はオーバーレイインターフェイスを介してユニキャストパケットをフラッディングしないので、ユニキャストパケットはサーバからのグローバル MAC アドレスにドロップされ、既存の接続は切断されます。


//OTV filter configs when one of the sites is down

mac-list GMAC_A seq 10 permit 0000.0000.0000 0000.0000.0000
route-map a-GMAC permit 10
  match mac-list GMAC_A

otv-isis default
  vpn Overlay1
    redistribute filter route-map a-GMAC

no vlan filter Local vlan-list 3151

//For ARP inspection, allow global MAC:
arp access-list HSRP_VMAC_ARP_Allow    
  50 permit ip any mac
ip arp inspection filter HSRP_VMAC_ARP_Allow 3151-3152

mac address-table static aaaa.1111.1234 vlan 3151 interface Ethernet8/3
//Static entry required only in the OTV in the functioning Site

他のサイトが復元した場合は、フィルタを再度追加して、OTV でこのスタティックエントリを削除する必要があります。グローバル MAC アドレスのオーバーレイエントリをクリアするには、両方の OTV でダイナミック MAC アドレステーブルをクリアすることが非常に重要です。

MAC アドレステーブルのクリア

サイトがダウンし、グローバル MAC アドレスへのスタティックエントリが OTV に追加される場合は、他の OTV がオーバーレイインターフェイスのグローバル MAC アドレスを学習できるようにする必要があります。他のサイトが起動したら、これらのエントリをクリアする必要があります。OTV の転送テーブルにこれらのエントリがないことを確認するために、MAC アドレステーブルを必ず消去してください。


cluster-N7k6-OTV# show mac address-table
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False
VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+------------------
G -    d867.d900.2e42 static  -  F F sup-eth1(R)
O 202  885a.92f6.44a5 dynamic -  F F Overlay1
* 202  885a.92f6.4b8f dynamic 5  F F Eth8/3
O 3151 0050.5660.9412 dynamic -  F F Overlay1
* 3151 aaaa.1111.1234 dynamic 50 F F Eth8/3

OTV ARP キャッシュのモニタリング

OTV は、OTV インターフェイス全体で学習した IP アドレスに対するプロキシ ARP への ARP キャッシュを維持します。


cluster-N7k6-OTV# show otv arp-nd-cache
OTV ARP/ND L3->L2 Address Mapping Cache

Overlay Interface Overlay1
VLAN MAC Address Layer-3 Address Age Expires In
3151 0050.5660.9412 10.0.0.2 1w0d 00:00:31
cluster-N7k6-OTV#

サイト間クラスタリングの例

次の例ではサポートされるクラスタの導入を示します。

個別インターフェイスルーテッドモードノースサウスサイト間の例

次の例では、内部ルータと外部ルータの間に配置された（ノースサウス挿入）2 つのデータセンターのそれぞれに 2 つの ASA クラスタメンバがある場合を示します。クラスタメンバは、DCI 経由のクラスタ制御リンクによって接続されています。各データセンターの内部ルータと外部ルータは、OSPF と PBR または ECMP を使用してクラスタメンバ間でトラフィックをロードバランスします。DCI に高コストルートを割り当てることにより、特定のサイトのすべての ASA クラスタメンバがダウンしない限り、トラフィックは各データセンター内に維持されます。1 つのサイトのすべてのクラスタメンバに障害が発生した場合、トラフィックは各ルータから DCI 経由で他のサイトの ASA クラスタメンバに送られます。

サイト固有の MAC アドレスおよび IP アドレスを使用したスパンド EtherChannel ルーテッドモードの例

次の例では、各サイトのゲートウェイルータと内部ネットワーク間に配置された（イーストウェスト挿入）2 つのデータセンターのそれぞれに 2 つのクラスタメンバがある場合を示します。クラスタメンバは、DCI 経由のクラスタ制御リンクによって接続されています。各サイトのクラスタメンバは、内部および外部両方のネットワークに対しスパンド EtherChannel を使用してローカルスイッチに接続します。各 EtherChannel は、クラスタ内のすべてのシャーシにスパンされます。

データ VLAN は、オーバーレイトランスポート仮想化（OTV）（または同様のもの）を使用してサイト間に拡張されます。トラフィックがクラスタ宛てである場合にトラフィックが DCI を通過して他のサイトに送信されないようにするには、グローバル MAC アドレスをブロックするフィルタを追加する必要があります。1 つのサイトのクラスタユニットが到達不能になった場合、トラフィックが他のサイトのクラスタユニットに送信されるようにフィルタを削除する必要があります。グローバル MAC アドレスをフィルタリングするには、VACL を使用する必要があります。F3 シリーズラインカードが搭載された Nexus などの一部のスイッチでは、グローバル MAC アドレスから ARP パケットをブロックするために ARP インスペクションも使用する必要があります。ARP インスペクションでは、ASA でサイトの MAC アドレスとサイトの IP アドレスの両方を設定する必要があります。サイトの MAC アドレスのみを設定する場合は、必ず ARP インスペクションを無効にしてください。詳細については、「ルーテッドモードサイト間クラスタリングの OTV 設定」を参照してください。

クラスタは、内部ネットワークのゲートウェイとして機能します。すべてのクラスタユニット間で共有されるグローバルな仮想 MAC は、パケットを受信するためだけに使用されます。発信パケットは、各 DC クラスタからのサイト固有の MAC アドレスを使用します。この機能により、MAC フラッピングの原因となる 2 つの異なるポートで両方のサイトから同じグローバル MAC アドレスをスイッチが学習するのを防止します。代わりに、スイッチはサイトの MAC アドレスのみを学習します。

このシナリオでは、次のようになります。

クラスタから送信されるすべての出力パケットは、サイトの MAC アドレスを使用し、データセンターでローカライズされます。
クラスタへのすべての入力パケットは、グローバル MAC アドレスを使用して送信されるため、両方のサイトでいずれかのユニットで受信できます。OTV でのフィルタによって、データセンター内のトラフィックがローカライズされます。

OTV 設定の例とベストプラクティスについては、ルーテッドモードサイト間クラスタリングの OTV 設定を参照してください。

スパンド EtherChannel トランスペアレントモードノースサウスサイト間の例

次の例では、内部ルータと外部ルータの間に配置された（ノースサウス挿入）2 つのデータセンターのそれぞれに 2 つのクラスタメンバがある場合を示します。クラスタメンバは、DCI 経由のクラスタ制御リンクによって接続されています。各サイトのクラスタメンバは、内部および外部のスパンド EtherChannels を使用してローカルスイッチに接続します。各 EtherChannel は、クラスタ内のすべてのシャーシにスパンされます。

各データセンターの内部ルータと外部ルータは OSPF を使用し、トランスペアレント ASA を通過します。MAC とは異なり、ルータの IP はすべてのルータで一意です。DCI に高コストルートを割り当てることにより、特定のサイトですべてのクラスタメンバがダウンしない限り、トラフィックは各データセンター内に維持されます。クラスタが非対称型の接続を維持するため、ASA を通過する低コストのルートは、各サイトで同じブリッジグループを横断する必要があります。1 つのサイトのすべてのクラスタメンバに障害が発生した場合、トラフィックは各ルータから DCI 経由で他のサイトのクラスタメンバに送られます。

各サイトのスイッチの実装には、次のものを含めることができます。

サイト間 VSS/vPC：このシナリオでは、データセンター 1 に 1 台のスイッチをインストールし、データセンター 2 に別のスイッチをインストールします。1 つのオプションとして、各データセンターのクラスタユニットはローカルスイッチだけに接続し、VSS/vPC トラフィックは DCI を経由します。この場合、接続のほとんどの部分は各データセンターに対してローカルに維持されます。オプションとして、DCI が余分なトラフィック量を処理できる場合、各ユニットを DCI 経由で両方のスイッチに接続できます。この場合、トラフィックは複数のデータセンターに分散されるため、DCI を非常に堅牢にするためには不可欠です。
各サイトのローカル VSS/vPC：スイッチの冗長性を高めるには、各サイトに 2 つの異なる VSS/vPC ペアをインストールできます。この場合、クラスタユニットは、両方のローカルスイッチだけに接続されたデータセンター 1 のシャーシおよびこれらのローカルスイッチに接続されたデータセンター 2 のシャーシとはスパンド EtherChannel を使用しますが、スパンド EtherChannel は基本的に「分離」しています。各ローカル VSS/vPC は、スパンド EtherChannel をサイトローカルの EtherChannel として認識します。

スパンド EtherChannel トランスペアレントモードイーストウェストサイト間の例

次の例では、各サイトのゲートウェイルータと 2 つの内部ネットワーク（アプリケーションネットワークと DB ネットワーク）間に配置された（イーストウェスト挿入）2 つのデータセンターのそれぞれに 2 つのクラスタメンバがある場合を示します。クラスタメンバは、DCI 経由のクラスタ制御リンクによって接続されています。各サイトのクラスタメンバは、内部および外部のアプリケーションネットワークと DB ネットワークの両方にスパンド EtherChannels を使用してローカルスイッチに接続します。各 EtherChannel は、クラスタ内のすべてのシャーシにスパンされます。

各サイトのゲートウェイルータは、HSRP などの FHRP を使用して、各サイトで同じ宛先の仮想 MAC アドレスと IP アドレスを提供します。予期せぬ MAC アドレスのフラッピングを避けるために推奨されている方法は mac-address-table static outside_interface mac_address コマンドを使用して、ゲートウェイルータの実際の MAC アドレスを ASA MAC アドレステーブルに静的に追加することです。これらのエントリがないと、サイト 1 のゲートウェイがサイト 2 のゲートウェイと通信する場合に、そのトラフィックが ASA を通過して、内部インターフェイスからサイト 2 に到達しようとして、問題が発生する可能性があります。データ VLAN は、オーバーレイトランスポート仮想化（OTV）（または同様のもの）を使用してサイト間に拡張されます。トラフィックがゲートウェイルータ宛てである場合にトラフィックが DCI を通過して他のサイトに送信されないようにするには、フィルタを追加する必要があります。1 つのサイトのゲートウェイルータが到達不能になった場合、トラフィックが他のサイトのゲートウェイに送信されるようにフィルタを削除する必要があります。

vPC/VSS オプションについては、スパンド EtherChannel トランスペアレントモードノースサウスサイト間の例を参照してください。

ASA クラスタリングの履歴

機能名

プラットフォームリリース

機能情報

ASA 5580 および 5585-X の ASA クラスタリング

9.0(1)

ASA クラスタリングを利用すると、最大で 8 の ASA をグループ化して、1 つの論理デバイスにすることができます。クラスタは、単一デバイスのすべての利便性（管理、ネットワークへの統合）を備える一方で、複数デバイスによって高いスループットおよび冗長性を達成します。ASA クラスタリングは、ASA 5580 および ASA 5585-X でサポートされます。1 つのクラスタ内のすべてのユニットが同一モデル、同一ハードウェア仕様であることが必要です。クラスタリングがイネーブルのときにサポートされない機能のリストについては、コンフィギュレーションガイドを参照してください。

次のコマンドを導入または変更しました。channel-group、clacp system-mac、clear cluster info、clear configure cluster、cluster exec、cluster group、cluster interface-mode、cluster-interface、conn-rebalance、console-replicate、cluster master unit、cluster remove unit、debug cluster、debug lacp cluster、enable（クラスタグループ）、health-check、ip address、ipv6 address、key（クラスタグループ）、local-unit、mac-address（インターフェイス）、mac-address pool, mtu cluster, port-channel span-cluster, priority（クラスタグループ）、prompt cluster-unit, show asp cluster counter、show asp table cluster chash-table、show cluster、show cluster info、show cluster user-identity、show lacp cluster、および show running-config cluster。

ASA 5500-X でのクラスタリングのサポート

9.1(4)

ASA 5512-X、ASA 5515-X、ASA 5525-X、ASA 5545-X および ASA 5555-X が 2 ユニットクラスタをサポートするようになりました。2 ユニットのクラスタリングは、基本ライセンスではデフォルトでイネーブルになります。ASA 5512-X では Security Plus ライセンスが必要です。

変更されたコマンドはありません。

ヘルスチェックモニタリングの VSS および vPC によるサポートの強化

9.1(4)

クラスタ制御リンクが EtherChannel として設定されていて（推奨）、VSS または vPC ペアに接続されている場合、ヘルスチェックモニタリングによって安定性を高めることができます。一部のスイッチ（Cisco Nexus 5000 など）では、VSS/vPC の 1 つのユニットがシャットダウンまたは起動すると、そのスイッチに接続されている EtherChannel メンバーインターフェイスが ASA に対してアップと認識される場合がありますが、スイッチ側にはトラフィックが渡されていません。ASA holdtime timeout を低い値（0.8 秒など）に設定した場合、ASA が誤ってクラスタから削除される可能性があり、ASA はキープアライブメッセージをこれらのいずれかの EtherChannel インターフェイスに送信します。VSS/vPC ヘルスチェック機能をイネーブルにすると、ASA はクラスタ制御リンクのすべての EtherChannel インターフェイスでキープアライブメッセージをフラッディングして、少なくとも 1 台のスイッチがそれを受信できることを確認します。

次のコマンドを変更しました。 health-check[vss-enabled]。

異なる地理的位置にあるクラスタメンバのサポート（サイト間）。個別インターフェイスモードのみ

9.1(4)

個別インターフェイスモードを使用すると、クラスタメンバを異なる地理的な場所に配置できるようになりました。

変更されたコマンドはありません。

トランスペアレントモードでの異なる地理的位置にあるクラスタメンバのサポート（サイト間）

9.2(1)

トランスペアレントファイアウォールモードでスパンド EtherChannel モードを使用すると、クラスタメンバを異なる地理的な場所に配置できるようになりました。ルーテッドファイアウォールモードのスパンド EtherChannel での Inter-Site クラスタリングはサポートされません。

変更されたコマンドはありません。

クラスタリングに対するスタティック LACP ポートプライオリティのサポート

9.2(1)

一部のスイッチは、LACP でのダイナミックポートプライオリティをサポートしていません（アクティブおよびスタンバイリンク）。ダイナミックポートプライオリティをディセーブルにすることで、スパンド EtherChannel との互換性を高めることができるようになりました。次の注意事項にも従う必要があります。

クラスタ制御リンクパスのネットワークエレメントでは、L4 チェックサムを検証しないようにする必要があります。クラスタ制御リンク経由でリダイレクトされたトラフィックには、正しい L4 チェックサムが設定されていません。L4 チェックサムを検証するスイッチにより、トラフィックがドロップされる可能性があります。
ポートチャネルバンドルのダウンタイムは、設定されているキープアライブインターバルを超えてはなりません。

clacp static-port-priority コマンドが導入されました。

スパンド EtherChannel での 32 個のアクティブリンクのサポート

9.2(1)

ASA EtherChannels は最大 16 個のアクティブリンクをサポートするようになりました。スパンド EtherChannel ではその機能が拡張されて、vPC の 2 台のスイッチで使用し、ダイナミックポートプライオリティをディセーブルにした場合、クラスタ全体で最大 32 個のアクティブリンクをサポートします。スイッチは、16 個のアクティブリンクの EtherChannel をサポートする必要があります（例：Cisco Nexus 7000 と F2 シリーズ 10 ギガビットイーサネットモジュール）。

8 個のアクティブリンクをサポートする VSS または vPC のスイッチの場合は、スパンド EtherChannel に 16 個のアクティブリンクを設定できます（各スイッチに接続された 8 個）。従来は、VSS/vPC で使用する場合であっても、スパンド EtherChannel は 8 個のアクティブリンクと 8 個のスタンバイリンクしかサポートしませんでした。

（注）

スパンド EtherChannel で 8 個より多くのアクティブリンクを使用する場合は、スタンバイリンクも使用できません。9 ～ 32 個のアクティブリンクをサポートするには、スタンバイリンクの使用を可能にする cLACP ダイナミックポートプライオリティをディセーブルにする必要があります。

clacp static-port-priority コマンドが導入されました。

ASA 5585-X の 16 のクラスタメンバのサポート

9.2(1)

ASA 5585-X が 16 ユニットクラスタをサポートするようになりました。

変更されたコマンドはありません。

ASA クラスタリングに対する BGP のサポート

9.3(1)

ASA クラスタリングに対する BGP のサポートが追加されました。

次のコマンドを導入しました。bgp router-id clusterpool。

内部ネットワーク間に ASA クラスタファイアウォールを備えたトランスペアレントモードのサイト間導入

9.3(2)

各サイトの内部ネットワークとゲートウェイルータ間にトランスペアレントモードのクラスタを導入し（AKA イーストウェスト挿入）、サイト間に内部 VLAN を拡張できます。オーバーレイトランスポート仮想化（OTV）の使用を推奨しますが、ゲートウェイルータの重複する MAC アドレスおよび IP アドレスがサイト間で漏えいしないようにする任意の方法を使用できます。HSRP などの First Hop Redundancy Protocol（FHRP）を使用して、同じ仮想 MAC アドレスおよび IP アドレスをゲートウェイルータに提供します。

インターフェイスごとの ASA クラスタのヘルスモニタリングの有効化またはディセーブル化

9.4(1)

ヘルスモニタリングは、インターフェイスごとにイネーブルまたはディセーブルにすることができます。デフォルトでは、ポートチャネル、冗長、および単一のすべての物理インターフェイスでヘルスモニタリングがイネーブルになっています。ヘルスモニタリングは VLAN サブインターフェイス、または VNI や BVI などの仮想インターフェイスでは実行されません。クラスタ制御リンクのモニタリングは設定できません。このリンクは常にモニタされています。たとえば、管理インターフェイスなど、必須以外のインターフェイスのヘルスモニタリングをディセーブルにすることができます。

次のコマンドを導入しました。 health-check monitor-interface。

DHCP リレーの ASA クラスタリングのサポート

9.4(1)

ASA クラスタで DHCP リレーを設定できます。クライアントの DHCP 要求は、クライアントの MAC アドレスのハッシュを使用してクラスタメンバにロードバランスされます。DHCP クライアントおよびサーバ機能はサポートされていません。

変更されたコマンドはありません。

ASA クラスタリングでの SIP インスペクションのサポート

9.4(1)

ASA クラスタで SIP インスペクションを設定できます。制御フローは、任意のユニットで作成できますが（ロードバランシングのため）、その子データフローは同じユニットに存在する必要があります。TLS プロキシ設定はサポートされていません。

show ssh sessions detail コマンドが導入されました。

ルーテッドファイアウォールモードのスパンド EtherChannel のサイト間クラスタリングサポートのサイト別 MAC アドレス

9.5(1)

ルーテッドモードでは、スパンド EtherChannel サイト間クラスタリングを使用することができます。MAC アドレスのフラッピングを防ぐには、各インターフェイスのサイト別の MAC アドレスがサイトのユニット上で共有できるように、各クラスタメンバーのサイト ID を設定します。

次のコマンドを導入または変更しました。site-id、mac-address site-id、show cluster info、show interface

インターフェイスまたはクラスタ制御リンクが失敗した場合の auto-rejoin 動作の ASA クラスタのカスタマイズ

9.5(1)

インターフェイスまたはクラスタ制御リンクが失敗した場合、auto-rejoin 動作をカスタマイズできます。

次のコマンドを導入しました。 health-check auto-rejoin

ASA クラスタは、GTPv1 と GTPv2 をサポートします

9.5(1)

ASA クラスタは、GTPv1 および GTPv2 インスペクションをサポートします。

変更されたコマンドはありません。

ASA クラスタリングのハードウェアモジュールのヘルスモニタリングの無効化

9.5(1)

クラスタリング使用時、ASA はデフォルトで、設置されているハードウェアモジュール（ASA FirePOWER モジュールなど）のヘルスモニタリングを行います。特定のハードウェアモジュールの障害によってフェールオーバーをトリガーすることが望ましくない場合は、モジュールのモニタリングをディセーブルにできます。

次のコマンドを変更しました。health-check monitor-interface service-module

TCP 接続のクラスタ複製遅延

9.5(1)

この機能で、ディレクタ/バックアップフロー作成の遅延による存続期間が短いフローに関連する「不要な作業」を排除できます。

次のコマンドを導入しました。cluster replication delay

ASA 5516-X でのクラスタリングのサポート

9.5(2)

ASA 5516-X が 2 ユニットクラスタをサポートするようになりました。基本ライセンスでは、2 ユニットのクラスタリングがデフォルトで有効化されています。

変更されたコマンドはありません。

サイト間フローモビリティの LISP インスペクション

9.5(2)

Cisco Locator/ID Separation Protocol（LISP）のアーキテクチャは、デバイス ID をその場所から 2 つの異なるナンバリングスペースに分離し、サーバの移行をクライアントに対して透過的にします。ASA は、場所変更の LISP トラフィックを検査し、その情報をシームレスなクラスタリング運用に活用できます。ASA クラスタメンバーは、最初のホップルータと出力トンネルルータまたは入力トンネルルータの間の LISP トラフィックを検査し、フローオーナーの所在場所を新規サイトに変更します。

次のコマンドが導入または変更されました。allowed-eid、clear cluster info flow-mobility counters、clear lisp eid、cluster flow-mobility lisp、debug cluster flow-mobility、debug lisp eid-notify-intercept、flow-mobility lisp、inspect lisp、policy-map type inspect lisp、site-id、show asp table classify domain inspect-lisp、show cluster info flow-mobility counters、show conn、show lisp eid、show service-policy、validate-key

キャリアグレード NAT の強化は、フェールオーバーおよび ASA クラスタリングでサポートされます。

9.5(2)

キャリアグレードまたは大規模 PAT では、NAT に 1 度に 1 つのポート変換を割り当てさせるのではなく、各ホストにポートのブロックを割り当てることができます（RFC 6888 を参照してください）。この機能は、フェールオーバーおよび ASA クラスタの導入でサポートされます。

次のコマンドが変更されました。show local-host

クラスタリングトレースエントリの設定可能なレベル

9.5(2)

デフォルトで、すべてのレベルクラスタリングイベントは、多くの下位レベルのイベント以外に、トレースバッファに含まれます。より上位レベルのイベントへのトレースを制限するために、クラスタの最小トレースレベルを設定できます。

次のコマンドが導入されました。trace-level

ルーテッドおよびスパンド EtherChannel モードのサイト固有の IP アドレスのポート

9.6(1)

スパンド EtherChannel のルーテッドモードでのサイト間クラスタリングの場合、サイト個別の MAC アドレスに加えて、サイト個別の IP アドレスを設定できるようになりました。サイト IP アドレスを追加することにより、グローバル MAC アドレスからの ARP 応答を防止するために、ルーティング問題の原因になりかねない Data Center Interconnect（DCI）経由の移動によるオーバーレイトランスポート仮想化（OTV）デバイスの ARP 検査を使用することができます。MAC アドレスをフィルタ処理するために VACL を使用できないスイッチには、ARP 検査が必要です。

次のコマンドが変更されました。mac-address、show interface

ディレクタローカリゼーション：データセンターのサイト間クラスタリングの改善

9.7(1)

データセンターのパフォーマンスを向上し、サイト間クラスタリングのトラフィックを維持するために、ディレクタローカリゼーションを有効にできます。通常、新しい接続は特定のサイト内のクラスタメンバーによってロードバランスされ、所有されています。しかし、ASA は任意のサイトのメンバーにディレクタロールを割り当てます。ディレクタローカリゼーションにより、所有者と同じサイトのローカルディレクタ、どのサイトにも存在可能なグローバルディレクタという追加のディレクタロールが有効になります。所有者とディレクタが同一サイトに存在すると、パフォーマンスが向上します。また、元の所有者が失敗した場合、ローカルなディレクタは同じサイトで新しい接続の所有者を選択します。グローバルなディレクタは、クラスタメンバーが別のサイトで所有される接続のパケットを受信する場合に使用されます。

次のコマンドが導入または変更されました。director-localization、show asp table cluster chash、show conn、show conn detail

クラスタユニットヘルスチェック障害検出の改善

9.8(1)

ユニットヘルスチェックの保留時間をより低めの値に設定できます（最少値は .3 秒）以前の最小値は .8 秒でした。この機能は、ユニットヘルスチェックメッセージングスキームを、コントロールプレーンのキープアライブからデータプレーンのハートビートに変更します。ハートビートを使用すると、コントロールプレーン CPU のホッギングやスケジューリングの遅延の影響を受けないため、クラスタリングの信頼性と応答性が向上します。保留時間を短く設定すると、クラスタ制御リンクのメッセージングアクティビティが増加することに注意してください。保留時間を短く設定する前にネットワークを分析することをお勧めします。例えば、ある保留時間間隔の間に 3 つのハートビートメッセージが存在するため、クラスタ制御リンクを介してあるユニットから別のユニットへの ping が保留時間/3 以内に戻ることを確認します。保留時間を 0.3 ～ 0.7 に設定した後に ASA ソフトウェアをダウングレードした場合、新しい設定がサポートされていないので、この設定はデフォルトの 3 秒に戻ります。

次のコマンドを変更しました。health-check holdtime、show asp drop cluster counter、show cluster info health details

クラスタリングのサイト間冗長性

9.9(1)

サイト間の冗長性により、トラフィックフローのバックアップオーナーは常にオーナーとは別のサイトに置かれます。この機能によって、サイトの障害から保護されます。

新規または変更されたコマンド：site-redundancy、show asp cluster counter change、show asp table cluster chash-table、show conn flag

内部障害発生後に自動的にクラスタに再参加する

9.9(2)

以前は、多くのエラー状態によりクラスタユニットがクラスタから削除されていました。この問題を解決した後、手動でクラスタに再参加する必要がありました。現在は、ユニットはデフォルトで 5 分、10 分、および 20 分の間隔でクラスタに自動的に再参加を試行します。これらの値は設定できます。内部の障害には、アプリケーション同期のタイムアウト、矛盾したアプリケーションステータスなどがあります。

新規または変更されたコマンド：health-check system auto-rejoin、show cluster info auto-join

クラスタの信頼性の高いトランスポートプロトコルメッセージのトランスポートに関連する統計情報の表示

9.9(2)

ユニットごとのクラスタの信頼性の高いトランスポートバッファ使用率を確認して、バッファがコントロールプレーンでいっぱいになったときにパケットドロップの問題を特定できるようになりました。

新規または変更されたコマンド：show cluster info transport cp detail

ASA 5000-X シリーズに対してインターフェイスを障害としてマークするために設定可能なデバウンス時間

9.9(2)

ASA がインターフェイスを障害が発生していると見なし、ASA 5500-X シリーズ上のクラスタからユニットが削除されるまでのデバウンス時間を設定できるようになりました。この機能により、インターフェイスの障害をより迅速に検出できます。デバウンス時間を短くすると、誤検出の可能性が高くなることに注意してください。インターフェイスのステータス更新が発生すると、ASA はインターフェイスを障害としてマークし、クラスタからユニットを削除するまで指定されたミリ秒数待機します。デフォルトのデバウンス時間は 500 ms で、有効な値の範囲は 300 ms ～ 9 秒です。この機能は以前は Firepower 4100/9300 で使用できました。

新規または変更されたコマンド：health-check monitor-interface debounce-time

クラスタインターフェイスデバウンス時間は、ダウン状態から稼働状態に変更するインターフェイスに適用されるようになりました。

9.10(1)

インターフェイスのステータス更新が発生すると、ASA はインターフェイスを障害としてマークし、クラスタからユニットを削除するまで health-check monitor-interface debounce-time コマンドまたは ASDM [Configuration] > [Device Management] > [High Availability and Scalability] > [ASA Cluster] 画面で指定されたミリ秒数待機します。この機能は、ダウン状態から稼働状態に変更するインターフェイスに適用されるようになりました。たとえば、ダウン状態から稼働状態に移行している EtherChannel の場合（スイッチがリロードされた、またはスイッチが有効になっている EtherChannel など）、デバウンス時間を長くすることで、他のクラスタユニットの方がポートのバンドルが速いという理由だけで、クラスタユニット上でインターフェイスがエラー表示されるのを防ぐことができます。

変更されたコマンドはありません。

CLI ブック 1：Cisco ASA シリーズ 9.10 CLI コンフィギュレーション ガイド（一般的な操作）

偏向のない言語

翻訳について

検索結果

章のタイトル： ASA クラスタ

ASA クラスタ

ASA クラスタリングの概要

ASA クラスタをネットワークに適合させる方法

パフォーマンス スケーリング係数

クラスタ メンバー

Bootstrap Configuration

マスターおよびスレーブ ユニットの役割

マスター ユニット選定

クラスタ インターフェイス

クラスタ制御リンク

ASA クラスタ内のハイ アベイラビリティ

ユニットのヘルス モニタリング

インターフェイス モニタリング

障害後のステータス

クラスタへの再参加

データ パス接続状態の複製

設定の複製

ASA クラスタ管理

管理ネットワーク

管理インターフェイス

マスター ユニット管理とスレーブ ユニット管理

RSA キー複製

ASDM 接続証明書 IP アドレス不一致

サイト間クラスタリング

ASA クラスタが接続を管理する方法

接続のロール

新しい接続の所有権

サンプル データ フロー

新しい TCP 接続のクラスタ全体での再分散

ASA の各機能とクラスタリング

クラスタリングでサポートされない機能

クラスタリングの中央集中型機能

個々のユニットに適用される機能

ネットワーク アクセス用の AAA とクラスタリング

FTP とクラスタリング

アイデンティティ ファイアウォールとクラスタリング

マルチキャスト ルーティングとクラスタリング

スパンド EtherChannel モードでのマルチキャスト ルーティング

個別インターフェイス モードでのマルチキャスト ルーティング

NAT とクラスタリング

ダイナミック ルーティングおよびクラスタリング

スパンド EtherChannel モードでのダイナミック ルーティング

個別インターフェイス モードでのダイナミック ルーティング

SCTP とクラスタリング

SIP インスペクションとクラスタリング

SNMP とクラスタリング

STUN とクラスタリング

syslog および NetFlow とクラスタリング

Cisco TrustSec とクラスタリング

VPN とクラスタリング

ASA クラスタリングのライセンス

ASA クラスタリングの要件と前提条件

モデルの要件

ASA のハードウェアおよびソフトウェア要件

スイッチ要件

ASA の要件

サイト間クラスタリング用の Data Center Interconnect のサイジング

その他の要件

ASA クラスタリングのガイドライン

コンテキスト モード

ファイアウォール モード

フェールオーバー

IPv6

スイッチ

EtherChannel

サイト間のガイドライン

その他のガイドライン

ASA クラスタリングのデフォルト

ASA クラスタリングの設定

ユニットのケーブル接続およびインターフェイスの設定

クラスタ インターフェイスについて

クラスタ制御リンクについて

クラスタ制御リンク トラフィックの概要

クラスタ制御リンク インターフェイスとネットワーク

クラスタ制御リンクのサイズ

CLI ブック 1：Cisco ASA シリーズ 9.10 CLI コンフィギュレーションガイド（一般的な操作）

パフォーマンススケーリング係数

クラスタメンバー

マスターおよびスレーブユニットの役割

マスターユニット選定

クラスタインターフェイス

ASA クラスタ内のハイアベイラビリティ

ユニットのヘルスモニタリング

インターフェイスモニタリング

データパス接続状態の複製

マスターユニット管理とスレーブユニット管理

サンプルデータフロー

ネットワークアクセス用の AAA とクラスタリング

アイデンティティファイアウォールとクラスタリング

マルチキャストルーティングとクラスタリング

スパンド EtherChannel モードでのマルチキャストルーティング

個別インターフェイスモードでのマルチキャストルーティング

ダイナミックルーティングおよびクラスタリング

スパンド EtherChannel モードでのダイナミックルーティング

個別インターフェイスモードでのダイナミックルーティング

コンテキストモード

ファイアウォールモード

クラスタインターフェイスについて

クラスタ制御リンクトラフィックの概要

クラスタ制御リンクインターフェイスとネットワーク

ロードバランシング

個別インターフェイス（ルーテッドファイアウォールモードのみ）

ポリシーベースルーティング（ルーテッドファイアウォールモードのみ）

等コストマルチパスルーティング（ルーテッドファイアウォールモードのみ）

Nexus Intelligent Traffic Director（ルーテッドファイアウォールモードのみ）

クラスタユニットのケーブル接続とアップストリームおよびダウンストリーム機器の設定

各ユニットでのクラスタインターフェイスモードの設定

マスターユニットでのインターフェイスの設定

ブートストラップコンフィギュレーションの作成

マスターユニットのブートストラップの設定

スレーブユニットのブートストラップの設定