Cisco IOS IP アプリケーション サービス コンフィ ギュレーション ガイド リリース 15.1

IOS SLB の利点

IOS SLB は Cisco IOS と同じソフトウェア コード ベースを共有し、Cisco IOS ソフトウェアのすべてのソフトウェア機能セットを備えています。IOS SLB は、SLB テクノロジーを従来のシスコ製スイッチおよびルータに完全に統合したいお客様に推奨します。

Cisco Catalyst 6500 ファミリ スイッチで IOS SLB を dispatched モードで実行すると、ハードウェア アクセラレーションによってパケットが非常に高速に転送されます。

IOS SLB によって、実績のある技術でコンテンツとアプリケーションの継続的な高可用性が確保されるため、分散環境のサーバおよび接続を積極的に管理できます。IOS SLB はユーザ要求をサーバ クラスタに分散することで、応答性とシステム容量を最適化し、大規模サイト、中規模サイト、および小規模サイトのインターネット、データベース、アプリケーション サービスの提供コストを大幅に削減します。

IOS SLB はスケーラビリティ、可用性、およびメンテナンスの容易さを向上します。

• 新しい物理（実）サーバの追加や、既存のサーバの削除または障害はいつでも発生する可能性がありますが、仮想サーバの可用性には影響はなく、ユーザが意識することはありません。

• IOS SLB のスロー スタート機能によって、新しいサーバの負荷を徐々に上げることができます。それによって、サーバに対する新規接続の割り当てが多すぎたり、早すぎたりすることで発生する障害を回避できます。

• IOS SLB は、フラグメント化されたパケットおよび IP オプションが指定されたパケットをサポートして、制御が及ばないクライアントやネットワークの変動からくるサーバへの危険性を和らげます。

• IOS SLB ファイアウォール ロード バランシングを使用すると、インターネット サイトへのアクセスを拡張できます。既存の接続に影響を与えることなくファイアウォールを追加できるため、サイトを拡張してもユーザに影響がありません。

DFP を使用すると、別のロード バランシング システムに負荷を分散できます。IOS SLB は DFP マネージャとして動作することでホスト サーバからの負荷を受け入れ、DFP エージェントとして動作することで負荷を DFP マネージャに送出します。この機能は独立してイネーブルにされるため、どちらか一方、または両方を同時に実装できます。

サーバ アプリケーションの管理が容易になります。クライアントが認識するのは仮想サーバのみで、実サーバの変更に管理は必要ありません。

実サーバのアドレスは外部ネットワークに公表されないため、実サーバのセキュリティは確保されます。ユーザが知るのは仮想 IP アドレスだけです。IP アドレスおよびポート番号（TCP または UDP）に基づいて、不必要なフローをフィルタできます。また、ファイアウォールの必要性はなくなりませんが、IOS SLB によって一部のサービス拒絶攻撃から保護できます。

支社の場合、IOS SLB を使用して、複数サイトのロード バランシング、およびサイト全体で障害が発生した場合の障害回復が可能です。また、ロード バランシングの処理を分散できます。

一般的な IOS SLB 機能

IOS SLB には次の機能があります。

• 「ルーティング機能」

• 「セキュリティ機能」

• 「サーバ障害の検出機能および回復機能」

• 「プロトコル サポート機能」

• 「冗長機能」

ルーティング機能

IOS SLB には次のルーティング機能があります。

• 「サーバ ロード バランシングのアルゴリズム」

• 「バインディング ID のサポート」

• 「Client-Assigned ロード バランシング」

• 「接続のレート制限」

• 「コンテンツ フロー モニタのサポート」

• 「TCP 接続コンテキストの遅延削除」

• 「ファイアウォール ロード バランシング」

• 「GTP IMSI スティッキ データベース」

• 「Home Agent Director」

• 「インターフェイス認識」

• 「最大接続」

• 「複数ファイアウォール ファームのサポート」

• 「Network Address Translation（NAT; ネットワーク アドレス変換）」

• 「ポートバインド サーバ」

• 「ルート ヘルス インジェクション」

• 「スティッキ接続」

• 「TCP セッションの再割り当て」

• 「透過的 Web キャッシュ ロード バランシング」

サーバ ロード バランシングのアルゴリズム

IOS SLB には次のロード バランシング アルゴリズムがあります。

• 「加重ラウンド ロビン」

• 「加重最小接続」

• 「ルート マップ」

仮想サーバに到達する新規の各接続要求について、実サーバを選択する基礎としてこれらのアルゴリズムのいずれかを指定できます。

各アルゴリズムについて、終了状態の接続は、実サーバに割り当てられた接続数に継続してカウントされます。その結果、他のアルゴリズムよりも最小接続アルゴリズムに影響が及びます。最小接続アルゴリズムは接続数の影響を受け、接続数が増えるほど影響が大きくなるためです。IOS SLB は、接続が割り当てられるたびに、1 つの実サーバあたりの接続数、およびアルゴリズムのメトリクスを調整します。

加重ラウンド ロビン

加重ラウンド ロビン アルゴリズムでは、循環形式で、サーバ ファームから仮想サーバへの新しい接続に使用される実サーバを選択するように指定します。各実サーバには加重 n が割り当てられます。この加重は、仮想サーバに関連付けられている他の実サーバと比較して、接続を処理できる容量を示します。つまり、n 回、新しい接続がその実サーバに割り当てられてから、サーバ ファームの次の実サーバが選択されます。

たとえば、サーバ ファームが ServerA（n = 3）、ServerB（n = 1）、および ServerC（n = 2）という実サーバで構成されているとします。仮想サーバに対する最初の 3 つの接続は ServerA に割り当てられ、4 番目の接続は ServerB、5 番目と 6 番目の接続は ServerC に割り当てられます。

（注） サーバ ファームのすべてのサーバに n=1 という加重を割り当てると、IOS SLB デバイスは簡易なラウンド ロビン アルゴリズムを使用するように設定されます。

GPRS Tunneling Protocol（GTP; GPRS トンネリング プロトコル）Cause Code Inspection をイネーブルにしない General Packet Radio Service（GPRS）ロード バランシングの場合、加重ラウンド ロビン アルゴリズムが必要です。加重最小接続を使用するサーバ ファームは、GTP Cause Code Inspection をイネーブルにせずに GPRS ロード バランシングを提供する仮想サーバにバインドできますが、仮想サーバを INSERVICE に変更できません。変更しようとすると、エラー メッセージが発行されます。

Home Agent Director には、加重ラウンド ロビン アルゴリズムが必要です。加重最小接続を使用するサーバ ファームは、Home Agent Director 仮想サーバにバインドできますが、仮想サーバを INSERVICE に変更できません。変更しようとすると、エラー メッセージが発行されます。

RADIUS ロード バランシングには、加重ラウンド ロビン アルゴリズムが必要です。

RADIUS ロード バランシング加速データ プレーン フォワーディングでは、加重ラウンド ロビン アルゴリズムをサポートしません。

加重最小接続

加重最小接続アルゴリズムでは、仮想サーバへの新しい接続について、サーバ ファームから選択される次の実サーバが、アクティブな接続数の最も少ないサーバになるように指定します。このアルゴリズムでも、各実サーバに加重が割り当てられます。加重が割り当てられると、最も接続数が少ないサーバは、各サーバのアクティブな接続数、および各サーバの相対的な容量に基づいて決まります。ある実サーバの容量を算出するには、そのサーバに割り当てられた加重を、仮想サーバに関連付けられたすべての実サーバに割り当てられた加重の合計で割ります。つまり、n1/(n1+n2+n3...) です。

たとえば、サーバ ファームが ServerA（n = 3）、ServerB（n = 1）、および ServerC（n = 2）という実サーバで構成されているとします。ServerA には 3/(3+1+2) で算出される容量があります。つまり、仮想サーバ上のすべてのアクティブな接続の半分です。ServerB にはすべてのアクティブな接続の 1/6 の容量、ServerC にはすべてのアクティブな接続の 1/3 の容量があります。任意の時点で、仮想サーバに対する次の接続は、アクティブな接続数が、算出された容量から最も離れている実サーバに割り当てられます。

（注） サーバ ファームのすべてのサーバに n=1 という加重を割り当てると、IOS SLB デバイスは簡易な最小接続アルゴリズムを使用するように設定されます。

GTP Cause Code Inspection をイネーブルにしない GPRS ロード バランシングの場合、加重最小接続アルゴリズムをサポートしません。

GTP Cause Code Inspection をイネーブルにした GPRS ロード バランシングの場合、加重最小接続アルゴリズムをサポートします。

Access Service Network（ASN）R6 ロード バランシング（MS Pre-Attachment 要求用）、Home Agent Director、RADIUS ロード バランシング、および RADIUS ロード バランシング加速データ プレーン フォワーディングでは、加重最小接続アルゴリズムをサポートしません。

ルート マップ

ルート マップ アルゴリズムが有効なのは、IOS SLB RADIUS ロード バランシング加速データ プレーン フォワーディング（Turbo RADIUS ロード バランシングとも呼ばれます）だけです。Turbo RADIUS ロード バランシングは、Cisco Content Services Gateway（CSG）環境で Policy-Based Routing（PBR; ポリシーベース ルーティング）ルート マップを使用し、加入者のデータプレーン トラフィックを処理する高パフォーマンスのソリューションです。Turbo RADIUS ロード バランシングが RADIUS ペイロードを受信すると、ペイロードが検査され、framed-IP アトリビュートが抽出され、ルート マップがその IP アドレスに適用され、加入者を処理する CSG が決定されます。

機能、使用するタイミング、設定方法、イネーブルにする方法など、ポリシーベース ルーティングの詳細については、『 Cisco IOS IP Routing Configuration Guide 』の「Policy-Based Routing」および「Configuring Policy-Based Routing」の項を参照してください。

（注） RADIUS ロード バランシング加速データ プレーン フォワーディングでは、ルート マップ アルゴリズムが必要です。

バインディング ID のサポート

バインド ID を使用すると、単一の物理サーバを複数の仮想サーバにバインドし、それぞれについて異なる加重をレポートできます。したがって、単一の実サーバは、自身の複数インスタンスとして表現され、それぞれに異なるバインド ID が割り当てられます。Dynamic Feedback Protocol（DFP）はバインド ID を使用して、特定の加重が指定された実サーバのインスタンスを識別します。バインド ID が必要なのは、DFP を使用している場合だけです。

GPRS ロード バランシングおよび Home Agent Director は、バインド ID をサポートしません。

Client-Assigned ロード バランシング

Client-Assigned ロード バランシングでは、仮想サーバを使用する権限を持つクライアント IP サブネットのリストを指定することで、仮想サーバに対するアクセスを制限できます。この機能を使用すると、仮想 IP アドレスに接続する 1 セットのクライアント IP サブネット（内部サブネットなど）を、1 つのサーバ ファームまたはファイアウォール ファームに割り当て、別のクライアント セット（外部クライアントなど）を別のサーバ ファームまたはファイアウォール ファームに割り当てることができます。

GPRS ロード バランシングおよび Home Agent Director は、Client-Assigned ロード バランシングをサポートしません。

接続のレート制限

IOS SLB を使用すると、サーバ ファームの 1 つの実サーバに許可する最大接続レートを指定できます。詳細については、実サーバ コンフィギュレーション モードの rate コマンドに関する説明を参照してください。

コンテンツ フロー モニタのサポート

IOS SLB は Cisco Content Flow Monitor（CFM）をサポートします。CFM は、CiscoWorks2000 製品ファミリ内の Web ベース ステータス モニタリング アプリケーションです。CFM 使用すると、Cisco サーバ ロード バランシング デバイスを管理できます。CFM は Windows NT および Solaris ワークステーション上で動作します。CFM には Web ブラウザを使用してアクセスします。

TCP 接続コンテキストの遅延削除

IP パケットは順序どおりに到達しないため、IOS SLB の視点では、TCP 接続の終了（finish [FIN] または reset [RST]）後に、接続の他のパケットが到達することがあります。一般的に、この問題は TCP 接続パケットがたどるパスが複数あるときに発生します。接続が終了した後に到達するパケットを適切にリダイレクトするために、IOS SLB は、特定の期間、TCP 接続情報（つまりコンテキスト）を保持します。接続の終了後にコンテキストを保持する期間は、設定可能な遅延タイマーで制御されます。

ファイアウォール ロード バランシング

この名前が示すように、ファイアウォール ロード バランシングを使用すると、IOS SLB はフローの負荷をファイアウォールに分散します。ファイアウォール ロード バランシングでは、ファイアウォール グループ（ファイアウォール ファームと呼ばれます）の両側にあるロード バランシング デバイスを使用して、各フローのトラフィックが同じファイアウォールに送信されるように確保しているため、セキュリティ ポリシーは保護されます。

各ロード バランシング デバイスに複数のファイアウォール ファームを設定できます。

レイヤ 3 ファイアウォールには IP アドレス指定可能なインターフェイスがあります。ファイアウォール ロード バランシング デバイスとサブネットが隣接し、固有の MAC アドレスを持っている場合、レイヤ 3 ファイアウォールは IOS SLB のファイアウォール ロード バランシングでサポートされます。デバイスはユーザ パケットの IP アドレスを変更しません。選択したファイアウォールにパケットを送信するために、デバイスは使用するインターフェイスを決定し、それに従ってレイヤ 2 ヘッダーを変更します。この種類のルーティングは、IOS SLB が使用する標準の dispatched ルーティングです。

レイヤ 2 ファイアウォールには IP アドレスがなく、IOS SLB ファイアウォール ロード バランシングからは認識されません。IOS SLB がレイヤ 2 ファイアウォールをサポートするには、IP アドレス指定可能なインターフェイス間にファイアウォールを配置します。

ロード バランシング デバイス（たとえば、単一の LAN）上の単一のレイヤ 3 インターフェイスから離れて多数のレイヤ 3 ファイアウォールを配置できますが、各インターフェイスから離れて配置できるレイヤ 2 ファイアウォールは 1 つだけです。

ロード バランシング デバイスを設定する場合、そのデバイスの IP アドレスを使用してレイヤ 3 を設定し、ファイアウォールの「外側」にあるデバイスのインターフェイスの IP アドレスを使用して レイヤ 2 を設定します。

ファイアウォール ファーム内のファイアウォール全体について、フローの負荷を分散するために、IOS SLB ファイアウォール ロード バランシングは各受信フローについてルート検索を実行し、発信元および宛先の IP アドレス（さらに、オプションで発信元および宛先の TCP または User Datagram Protocol（UDP）のポート番号）を確認します。ファイアウォール ロード バランシングでは、ハッシュ アルゴリズムをルート検索に適用し、最適なファイアウォールを選択して接続要求を処理します。

（注） IOS SLB ファイアウォール ロード バランシングでは、受信パケットを確認し、ルート検索を実行する必要があります。Catalyst 6500 ファミリ スイッチでは、さらにいくつからのパケットを確認する必要があります。ファイアウォール ロード バランシングは、内側（保護されている側）のルーティング パフォーマンスに影響があるため、全体的な設計として考慮する必要があります。

複数のファイアウォールを備えるネットワークで可用性と復元力を最大限にするために、ファイアウォールの 1 つだけに単一のルートを設定するのではなく、個別の均等な加重のルートを各ファイアウォールに設定します。

IOS SLB ファイアウォール ロード バランシングには、次の機能があります。

• ファイアウォール ファームの両側から開始される接続の負荷は分散されます。

• ファイアウォール セット（つまり、ファイアウォール ファーム）の中で負荷は分散されます。

• 接続のすべてのパケットは、同じファイアウォールを介して送信されます。以降の接続は、同じファイアウォールに割り当てられるように、「スティッキ」にすることができます。

• source-IP、destination-IP、および source-destination-IP のスティッキ接続がサポートされます。

• ファイアウォールの障害を検出し、回復するために、プローブが使用されます。

• 冗長機能が用意されています。Hot Standby Router Protocol（HSRP; ホット スタンバイ ルータ プロトコル）、ステートレス バックアップ、およびステートフル バックアップのすべてがサポートされます。

• 複数のインターフェイスの種類およびルーティング プロトコルがサポートされているため、外側（インターネット側）のロード バランシング デバイスはアクセス ルータとして動作できます。

• プロキシ ファイアウォールがサポートされます。

GTP IMSI スティッキ データベース

IOS SLB では、特定の International Mobile Subscriber ID（IMSI）に Gateway General Packet Radio Service（GPRS）Support Node（GGSN）を選択し、同じ IMSI から送信される以降の Packet Data Protocol（PDP）作成要求すべてを、選択した GGSN に転送できます。

この機能をイネーブルにするために、IOS SLB では GPRS Tunneling Protocol（GTP）IMSI スティッキ データベースを使用します。このデータベースによって、各 IMSI は、セッション データベースだけでなく、対応する実サーバにマップされます。

その IMSI で最初の GTP PDP 作成要求が処理されると、IOS SLB によってスティッキ データベース オブジェクトが作成されます。また、実サーバから削除を示す通知を受信した場合、または非アクティブな状態の結果として、スティッキ オブジェクトが削除されます。GGSN で 1 つの IMSI に属する最後の PDP が削除されると、GGSN から IOS SLB にスティッキ オブジェクトを削除するように通知されます。

Home Agent Director

Home Agent Director は、ホーム エージェント セット（サーバ ファームの実サーバとして設定されます）の中で、Mobile IP Registration Request（RRQ）のロード バランシングを実行します。ホーム エージェントは、モバイル ノードのアンカー ポイントです。ホーム エージェントは、モバイル ノードのフローを現在の外部エージェント（接続ポイント）にルーティングします。

Home Agent Director には次の特徴があります。

• dispatched モードまたは directed サーバ NAT モードで実行できますが、directed クライアント NAT モードでは実行できません。dispatched モードの場合、ホーム エージェントは IOS SLB デバイスに対して レイヤ 2 隣接にする必要があります。

• ステートフル バックアップをサポートしません。詳細については、「ステートフル バックアップ」を参照してください。

• 仮想 Home Agent Director の IP アドレス宛ての RRQ を、加重ラウンド ロビン ロード バランシング アルゴリズムを使用して、実際のホーム エージェントの 1 つに配信します。このアルゴリズムの詳細については、「加重ラウンド ロビン」を参照してください。

• 容量に基づいて RRQ を割り当てるには、DFP が必要です。

Mobile IP、ホーム エージェントの詳細と関連するトピックについては、『 Cisco IOS IP Mobility Configuration Guide 』を参照してください。

インターフェイス認識

環境によっては、CSG、SSG、またはファイアウォールのファームの両側に IOS SLB が必要です。たとえば、ファームの一方で RADIUS ロード バランシングを実行し、もう一方でファイアウォール ロード バランシングを実行できます。また、ファイアウォール ファームの両側でファイアウォール ロード バランシングを実行することもできます。

このような「サンドイッチ」環境で、仮想サーバ、ファイアウォール ファーム、接続、およびセッションに対してパケットをマッピングする場合、IOS SLB では入力インターフェイスを考慮に入れる必要があります。IOS SLB では、この機能はインターフェイス認識と呼ばれます。インターフェイス認識を設定すると、設定したアクセス インターフェイスに到達したトラフィックのみが処理されます（アクセス インターフェイスは任意の レイヤ 3 インターフェイスです）。

最大接続

IOS SLB では、サーバおよびファイアウォール ロード バランシングの最大接続数を設定できます。

• サーバ ロード バランシングの場合、実サーバに割り当てるアクティブな接続数に制限を設定できます。実サーバの接続の最大数に達すると、以降のすべての接続要求は、接続数が指定した制限値に低下するまで、他のサーバへと自動的に切り替えられます。

• ファイアウォール ロード バランシングの場合、ファイアウォール ファームに割り当てるアクティブな TCP または UDP の数に制限を設定できます。ファイアウォール ファームの接続の最大数に達すると、接続数が指定した制限値に低下するまで、新規の接続はドロップされます。

複数ファイアウォール ファームのサポート

各ロード バランシング デバイスに複数のファイアウォール ファームを設定できます。

Network Address Translation（NAT; ネットワーク アドレス変換）

Cisco IOS NAT（RFC 1631）を使用すると、未登録の「プライベート」IP アドレスをグローバルに登録された IP アドレスに変換してインターネットに接続できます。この機能の一部として、ネットワーク全体について 1 つのアドレスだけを外部に通知するように Cisco IOS NAT を設定できます。この設定には追加のセキュリティおよびネットワーク プライバシーが用意されており、そのアドレスの外部から内部ネットワーク全体を効率的に隠蔽できます。NAT には、セキュリティおよびアドレス保存の二重機能性があり、一般的にリモート アクセス環境で実装されます。

ここでは、次の内容について説明します。

• 「セッション リダイレクション」

• 「dispatched モード」

• 「directed モード」

• 「サーバ NAT」

• 「クライアント NAT」

• 「スタティック NAT」

• 「サーバ ポート変換」

セッション リダイレクション

セッション リダイレクションには、パケットを実サーバにリダイレクトする処理があります。IOS SLB は、dispatched モードまたは directed モードという 2 つのセッション リダイレクション モードのいずれかで動作します。

（注） dispatched モードと directed モードのいずれでも、IOS SLB では常に接続が追跡されます。そのため、ロード バランシング デバイスをバイパスするクライアントに対して、実サーバからの代替ネットワーク パスがないように、ネットワークを設計する必要があります。

dispatched モード

dispatched モードの場合、仮想サーバのアドレスは実サーバに認識されます。各実サーバで、仮想サーバの IP アドレスはループバック アドレスまたはセカンダリ IP アドレスとして設定する必要があります。パケットは、Media Access Control（MAC; メディア アクセス制御）レイヤの実サーバにリダイレクトされます。dispatched モードの場合、仮想サーバの IP アドレスは変更されないため、実サーバは IOS SLB に対してレイヤ 2 隣接にする必要があります。そうしないと、仲介ルータは選択した実サーバにルーティングできない可能性があります。

Catalyst 6500 ファミリ スイッチの場合、ハードウェア データ パケット アクセラレーションを使用した dispatched モードは directed モードよりもパフォーマンスが向上します。

ループバック アドレスの設定の詳細については、『 Cisco IOS Interface Configuration Guide 』の「 Configuring Virtual Interfaces 」の章を参照してください。

（注） 一部の UDP アプリケーションは、ループバック インターフェイスからの要求に応答できません。このような場合、directed モードを使用する必要があります。

directed モード

directed モードでは、任意の実サーバから認識される IP アドレスを仮想サーバに割り当てることができます。IOS SLB は、仮想サーバの IP アドレスを実サーバの IP アドレスに変換する NAT を使用して、クライアントと実サーバ間で交換されるパケットを変換します。

IOS SLB は次の種類の NAT をサポートします。

• 「サーバ NAT」

• 「クライアント NAT」

• 「スタティック NAT」

• 「サーバ ポート変換」

（注） 同じ接続についてサーバ NAT とクライアント NAT の両方を使用できます。

directed モードの場合、IOS SLB は FTP またはファイアウォールのロード バランシングをサポートしません。そのため、FTP およびファイアウォールのロード バランシングは NAT を使用できません。

TCP および UDP の仮想サーバの場合、TCP IOS SLB はクライアント NAT だけをサポートします。

Encapsulation Security Payload（ESP）仮想サーバまたは Generic Routing Encapsulation（GRE）仮想サーバの場合、IOS SLB はサーバ NAT だけをサポートします（ただし、サーバ ポートの変換は行われません）。

サーバ NAT

サーバ NAT には、仮想サーバの IP アドレスを実サーバの IP アドレスに置換する処理（およびその逆の処理）があります。サーバ NAT には次のような利点があります。

• ロード バランシング デバイスから多数のホップを経た位置にサーバを配置できます。

• 仲介ルータは、トンネリングなしでサーバにルーティングできます。

• 実サーバ側にループバックおよびセカンダリ インターフェイスは必要ありません。

• 実サーバを IOS SLB に対してレイヤ 2 隣接にする必要はありません。

• 実サーバは、同じ IOS SLB デバイス上の仮想サーバに対して接続を開始できます。

クライアント NAT

ネットワークで複数のロード バランシング デバイスを使用している場合、クライアント IP アドレスを、デバイスのいずれかに関連付けられている IP アドレスで置換することで、発信フローが適切なデバイスにルーティングされます。また、クライアント NAT の場合、多数のクライアントが同じ一時的ポートを使用できるため、一時的クライアント ポートを変更する必要があります。複数のロード バランシング デバイスを使用しない場合でも、負荷が分散された接続のパケットがデバイス中をルーティングされないようにするには、クライアント NAT が便利です。

スタティック NAT

スタティック NAT の場合、スタティック NAT コマンドを設定すると、アドレス変換は NAT 変換テーブルに登録され、スタティック NAT コマンドを削除するまで変換テーブルに保存されます。

スタティック NAT を使用すると、一部のユーザは NAT を利用し、同じイーサネット インターフェイスの他のユーザは、引き続き固有の IP アドレスを使用できます。このオプションによって、実サーバからの応答と、実サーバが開始した接続要求とを区別することで、実サーバのデフォルトの NAT 動作を設定できます。

たとえば、サーバ NAT を使用すると、実サーバに対する Domain Name System（DNS; ドメイン ネーム システム）の受信要求パケットおよび発信応答パケットをリダイレクトできます。また、スタティック NAT を使用すると、実サーバからの接続要求を処理できます。

（注） DNS にスタティック NAT は必要ありませんが、実サーバの IP アドレスが外部から隠蔽されるため、使用することを推奨します。

IOS SLB は次のスタティック NAT オプションをサポートします。各オプションは ip slb static コマンドを使用して設定します。

• [Static NAT with dropped connections]：既存の接続に対応するパケットではない場合、パケットがドロップされるように実サーバを設定します。通常、このオプションは、スタティック NAT コンフィギュレーション モードの real コマンドで、サブネット マスクまたはポート番号オプションとともに使用されます。その結果、指定したサブネットまたはポートに対する接続が構築され、実サーバからのその他の接続はすべてドロップされます。

• [Static NAT with a specified address]：アドレスの変換時に、ユーザが指定した仮想 IP アドレスを使用するように実サーバが設定されます。

• [Static NAT with per-packet server load balancing]：IOS SLB が実サーバから発信されたパケットの接続状態を維持しないように、実サーバが設定されます。つまり、IOS SLB はサーバ NAT を使用して、実サーバから発信されたパケットをリダイレクトします。パケット別のサーバ ロード バランシングは、DNS ロード バランシングの場合に特に便利です。IOS SLB は、パケット別のサーバ ロード バランシング環境の障害を検出するために DNS プローブを使用します。

• [Static NAT with sticky connections]：実サーバから発信されたパケットがスティッキ オブジェクトに一致しない場合、IOS SLB がそのパケットの接続状態を維持しないように、実サーバが設定されます。

– IOS SLB は一致するスティッキ オブジェクトを検出すると、接続を構築します。

– IOS SLB は一致するスティッキ オブジェクトを検出すると、接続を構築せずにパケットを転送します。

IOS SLB で実サーバからのパケットを扱う場合、次のロジックを使用します。

ステップ 1 パケットは実サーバと一致しますか。

• 「いいえ」の場合、IOS SLB はそのパケットを処理しません。

• 「はい」の場合、処理を続行します。

ステップ 2 パケットは既存の接続と一致しますか。

• 「はい」の場合、IOS SLB は、接続コントロール ブロックに従って、NAT を使用してパケットをリダイレクトします。

• 「いいえ」の場合、処理を続行します。

ステップ 3 スタティック NAT を使用するように実サーバは設定されていますか。

• 「いいえ」の場合、IOS SLB はそのパケットを通常どおりに処理します。この機能は、スタティック NAT パススルーとも呼ばれます。

• 「はい」の場合、処理を続行します。

ステップ 4 既存の接続に対応するパケットではない場合、パケットがドロップされるように実サーバは設定されていますか。

• 「はい」の場合、IOS SLB はパケットをドロップします。

• 「いいえ」の場合、処理を続行します。

ステップ 5 実サーバは、パケット別のサーバ ロード バランシング用に設定されていますか。

• 「はい」の場合、IOS SLB は NAT を使用してパケットをリダイレクトします。

• 「いいえ」の場合、処理を続行します。

ステップ 6 スティッキ接続の接続状態を維持するように実サーバは設定されていますか。

• 「いいえ」の場合、IOS SLB は接続を構築します。

• 「はい」の場合、IOS SLB は一致するスティッキ オブジェクトを検索します。処理を続行します。

ステップ 7 IOS SLB は一致するスティッキ オブジェクトを検索できますか。

• 「いいえ」の場合、IOS SLB はパケットをドロップします。

• 「はい」の場合、IOS SLB は接続を構築します。

サーバ ポート変換

サーバ ポート変換は、Port Address Translation（PAT; ポート アドレス変換）とも呼ばれます。サーバ NAT の形式の 1 つであり、仮想サーバの IP アドレスではなく仮想サーバのポートの変換が行われます。仮想サーバのポート変換には、仮想サーバの IP アドレスの変換は必要ありませんが、2 種類の変換を併用することもできます。

IOS SLB は、TCP および UDP の場合にだけ、サーバ ポート変換をサポートします。

ポートバインド サーバ

仮想サーバを定義する場合、その仮想サーバで処理する TCP または UDP のポートを指定する必要があります。ただし、サーバ ファームで NAT を設定する場合、ポートバインド サーバを設定することもできます。ポートバインド サーバを使用すると、1 つの仮想サーバの IP アドレスで、HTTP などのサービス用の実サーバ セットと、Telnet などのサービス用の実サーバ セットを表現できます。

仮想サーバ定義で指定されていないポートの仮想サーバ アドレス宛てのパケットは、リダイレクトされません。

IOS SLB は、ポートバインド サーバと非ポートバインド サーバの両方をサポートしますが、ポートバインド サーバの使用が推奨されます。

IOS SLB ファイアウォール ロード バランシングは、ポートバインド サーバをサポートしません。

ルート ヘルス インジェクション

（ inservice コマンドを使用して）仮想サーバをサービスに登録すると、デフォルトで、仮想サーバの IP アドレスはアドバタイズされます（ルーティング テーブルに追加されます）。Web サイトの仮想 IP アドレスに対して希望のホスト ルートがある場合、そのホスト ルートをアドバタイズできますが、その IP アドレスを使用できるという保証はありません。ただし、IP アドレスを使用できると IOS SLB で検証された場合にだけ、ホスト ルートをアドバタイズするように、 advertise コマンドで IOS SLB を設定できます。IP アドレスを使用できなくなると、IOS SLB はアドバタイズメントを撤回します。この機能はルート ヘルス インジェクションと呼ばれます。

スティッキ接続

クライアント トランザクションには、複数の連続する接続が必要なことがあります。つまり、同じクライアントの IP アドレスまたはサブネットからの新しい接続を、同じ実サーバに割り当てる必要があります。このような接続は、ファイアウォール ロード バランシングの場合に特に重要です。場合によってファイアウォールは、特定の攻撃を検出するために複数の接続をプロファイルする必要があるためです。

• IOS SLB は、source-IP スティッキ接続をサポートします。

• ファイアウォール ロード バランシングは、source-IP、destination-IP、および source-destination-IP のスティッキ接続をサポートします。

• RADIUS ロード バランシングは、calling-station-IP、framed-IP、および username のスティッキ接続をサポートします。

オプションの sticky コマンドを使用すると、同じクライアントからの発信を、サーバ ファーム内の同じロード バランシング サーバに強制的に接続できます。ファイアウォール ロード バランシングの場合、同じクライアント - サーバ ペア間の接続は、同じファイアウォールに割り当てられます。次の条件をすべて満たす場合、新しい接続はスティッキ接続と見なされます。

• 実サーバの状態は OPERATIONAL または MAXCONNS_THROTTLED です。

• 仮想サーバまたはファイアウォール ファームにスティッキ タイマーが定義されています。

同じサーバまたはファイアウォールに対するこの新しい接続のバインディングは、最後のスティッキ接続が終了した後も、ユーザが定義した期間、継続されます。

「サンドイッチ」ファイアウォール ロード バランシングに必要な、クライアント - サーバ アドレスのスティッキ動作を実現するには、ファイアウォール ファームの両側でスティッキを有効にする必要があります。この設定では、クライアント - サーバ スティッキの関連付けは、クライアント - サーバ アドレス ペア間に最初の接続が開かれたときに作成されます。この最初の接続が確立した後に、IOS SLB はファームの一方にあるファイアウォール ロード バランシング デバイスにスティッキの関連付けを維持し、両方のファイアウォール ロード バランシング デバイスによってクライアントまたはサーバの IP アドレスから開始された接続に、スティッキの関連付けを適用します。

sticky コマンドでサブネット マスクを指定すると、クライアント サブネットのスティッキがイネーブルになります。サブネット スティッキは、ある接続から次の接続でクライアントの IP アドレスが変わる場合に便利です。たとえば、クライアント接続は IOS SLB に到達する前に、スティッキ管理機能がない NAT またはプロキシ ファイアウォールのセットを経由する可能性があります。このような場合、サーバに対処できるロジックがないと、クライアント トランザクションは失敗します。こうしたファイアウォールが同じサブネット セットのアドレスを割り当てるときに発生する可能性がある問題には、IOS SLB のスティッキ サブネット マスクであれば対応できます。

スティッキ接続では、複数の仮想サーバまたはファイアウォール ファームによって処理されるサービスのカップリングも設定できます。このオプションによって、関連サービスの接続要求に同じ実サーバを使用できます。たとえば、通常 Web サーバ（HTTP）は TCP ポート 80 を使用し、HTTPS はポート 443 を使用します。HTTP 仮想サーバおよび HTTPS 仮想サーバをカップリングすると、同じクライアントの IP アドレスまたはサブネットからの ポート 80 および 443 に対する接続は、同じ実サーバに割り当てられます。

同じスティッキ グループに属する仮想サーバは、バディ仮想サーバとも呼ばれます。

Home Agent Director はスティッキ接続をサポートしません。

TCP セッションの再割り当て

クライアントが実サーバに対して新しい接続を開こうとしている場合、そのサーバに送信される各 TCP SYN は IOS SLB によって追跡されます。複数の連続する SYN に応答がない場合、または SYN が RST で応答される場合、TCP セッションは新しい実サーバに再割り当てされます。SYN の試行回数は、設定可能な再割り当てしきい値で制御されます。

IOS SLB ファイアウォール ロード バランシングは、TCP セッションの再割り当てをサポートしません。

透過的 Web キャッシュ ロード バランシング

IOS SLB は、透過的 Web キャッシュのクラスタ全体で HTTP フローの負荷を分散できます。この機能をセットアップするには、透過的 Web キャッシュで処理するサブネット IP アドレス、または何らかの共通するサブセットを仮想サーバとして設定します。透過的 Web キャッシュ ロード バランシングに使用する仮想サーバは、サブネット IP アドレスの代理で ping に応答しません。また、トレースルートに影響がありません。

キャッシュに必要なページが含まれない場合など、状況によっては、Web キャッシュからインターネットに対して独自の接続を開始する必要があります。このような接続は、同じ Web キャッシュ セットに対して負荷を分散しないでください。このような要件に対処するために、IOS SLB では client exclude ステートメントを設定できます。このステートメントで、Web キャッシュから開始された接続はロード バランシング スキームから除外されます。

IOS SLB ファイアウォール ロード バランシングは、透過的 Web キャッシュ ロード バランシングをサポートしません。

セキュリティ機能

IOS SLB には次のセキュリティ機能があります。

• 「代替 IP アドレス」

• 「サーバ ファームおよびファイアウォール ファームに対する攻撃の回避」

• 「スロー スタート」

• 「SynGuard」

代替 IP アドレス

IOS SLB を使用すると、代替 IP アドレスを使用して、ロード バランシング デバイスに Telnet を使用できます。そのためには、次のいずれかの方式を使用します。

• いずれかのインターフェイス IP アドレスを使用して、ロード バランシング デバイスに Telnet を実行します。

• セカンダリ IP アドレスを定義して、ロード バランシング デバイスに Telnet を実行します。

この機能は、LocalDirector（LD）Alias コマンドで提供される機能と似ています。

サーバ ファームおよびファイアウォール ファームに対する攻撃の回避

IOS SLB は、サイトを攻撃から守るためにサイトのファイアウォールに依存しています。一般的に、IOS SLB は、スイッチやルータと同程度に直接攻撃の影響を受けます。ただし、高度にセキュリティなサイトであれば、次の手順でセキュリティを強化できます。

• クライアントが実サーバに直接接続しないように、プライベート ネットワークの実サーバを設定します。この設定によって、クライアントは常に IOS SLB を経由して実サーバに接続するようになります。

• IOS SLB デバイスのインターフェイスを宛先に指定した外部ネットワークからのフローを拒否するように、アクセス ルータまたは IOS SLB デバイスの入力アクセス リストを設定します。つまり、予期しないアドレスからの すべての 直接フローを拒否します。

• ファイアウォール サブネットの実 IP アドレスまたは存在しない IP アドレスに対してフローを送信しようとする攻撃から保護するには、プライベート ネットワークでファイアウォールを設定します。

• ファイアウォール宛ての予期しない すべての フロー（特に、外部ネットワークから発信されたフロー）を拒否するようにファイアウォールを設定します。

スロー スタート

加重最小接続ロード バランシングを使用する環境では、起動した直後の実サーバには接続がないため、新しい接続が多数割り当てられ、過負荷になる可能性があります。このような過負荷を回避するために、スロー スタートによって、起動した直後の実サーバに割り当てられる新しい接続数を制御します。

GPRS ロード バランシングおよび Home Agent Director は、スロー スタートをサポートしません。

SynGuard

SynGuard は、仮想サーバが処理する TCP start-of-connection パケットのレート（SYNchronize Sequence Number（SYN））を制限することで、SYN フラッド サービス拒絶攻撃と呼ばれる種類のネットワークの問題を回避します。ユーザが大量の SYN をサーバに送信することもあり、それによってサーバの過負荷やクラッシュが発生し、他のユーザへのサービスが停止する可能性があります。SynGuard によって、IOS SLB または実サーバを停止させる攻撃などを回避します。SynGuard は、仮想サーバが処理する SYN 数を特定の間隔で監視し、設定した SYN しきい値を超える数の SYN を許可しません。しきい値に達すると、新しい SYN はドロップされます。

IOS SLB ファイアウォール ロード バランシングおよび Home Agent Director は、SynGuard をサポートしません。

サーバ障害の検出機能および回復機能

IOS SLB には、次のサーバ障害検出機能と回復機能があります。

• 「自動サーバ障害検出」

• 「自動アンフェイル」

• 「バックアップ サーバ ファーム」

• 「DFP Agent Subsystem のサポート」

• 「IOS SLB 用 Dynamic Feedback Protocol」

• 「GGSN-IOS SLB メッセージング」

• 「仮想サーバの INOP_REAL 状態」

• 「プローブ」

自動サーバ障害検出

IOS SLB は、実サーバに対して失敗した各 Transmission Control Protocol（TCP; トランスミッション制御プロトコル）接続試行を自動的に検出し、そのサーバの障害カウンタを増加します（同じクライアントからの失敗した TCP 接続がカウント済みの場合、障害カウンタは増加しません）。サーバの障害カウンタが設定可能な障害しきい値を超えると、そのサーバはアウト オブ サービスと見なされ、アクティブな実サーバのリストから削除されます。

RADIUS ロード バランシングの場合、RADIUS 要求に対して実サーバから応答がないと、IOS SLB は自動サーバ障害検出を実行します。

全ポート仮想サーバ（つまり、GTP ポートを除くすべてのポート宛てのフローを受け入れる仮想サーバ）を設定した場合、アプリケーション ポートが存在しないサーバにフローを渡すことができます。サーバがこのようなフローを拒否すると、IOS SLB はそのサーバを無効と見なし、ロード バランシングから除外することがあります。この状況は、RADIUS ロード バランシング環境の応答が遅い AAA サーバの場合にも発生する可能性があります。この状況を回避するには、自動サーバ障害検出をディセーブルにします。

（注） no faildetect inband コマンドを使用して自動サーバ障害検出をディセーブルにする場合、1 つまたは複数のプローブを設定することを強く推奨します。

no faildetect inband コマンドを指定する場合、faildetect numconns コマンドを指定しても無視されます。

自動アンフェイル

実サーバに障害が発生し、アクティブなサーバのリストから削除されると、設定可能な再試行タイマーに指定された期間、新しい接続は割り当てられません。タイマーの期限が切れると、そのサーバには新しい仮想サーバ接続を受ける資格ができ、IOS SLB から次の適格性確認の接続がサーバに送信されます。その接続が成功すると、失敗したサーバはアクティブな実サーバのリストに戻されます。接続に失敗すると、サーバはアウト オブ サービスのままで、再試行タイマーがリセットされます。失敗した接続は少なくとも 1 回は再試行が実行されます。実行されていない場合、次の適格性確認の接続もその失敗したサーバに送信されます。

バックアップ サーバ ファーム

バックアップ サーバ ファームは、プライマリ サーバ ファームに定義されている実サーバで新しい接続を受け入れることができないときに使用できるサーバ ファームです。バックアップ サーバ ファームを設定する場合、次の注意事項を考慮する必要があります。

• サーバ ファームは、同時にプライマリとバックアップの両方として動作できます。

• 同じ実サーバを、同時にプライマリとバックアップの両方に定義することはできません。

• プライマリとバックアップのどちらも、同じ NAT 設定（なし、クライアント、サーバ、または両方）にする必要があります。さらに、NAT を指定する場合、両方のサーバ ファームは同じ NAT プールを使用する必要があります。

DFP Agent Subsystem のサポート

IOS SLB は DFP Agent Subsystem 機能（グローバル ロード バランシングとも呼ばれます）をサポートします。そのため、IOS SLB 以外のクライアント サブシステムも DFP エージェントとして実行できます。DFP Agent Subsystem を利用すると、複数のクライアント サブシステムの複数の DFP エージェントを同時に使用できます。

DFP Agent Subsystem の詳細については、Cisco IOS リリース 12.2(18)SXD の DFP Agent Subsystem 機能に関するドキュメントを参照してください。

IOS SLB 用 Dynamic Feedback Protocol

ロード バランシング環境の DFP マネージャが IOS SLB Dynamic Feedback Protocol（DFP）をサポートしている場合、DFP エージェントを使用して TCP 接続を開始できます。接続後は、DFP エージェントによって 1 つまたは複数の実サーバからステータス情報が収集され、情報は相対的な加重に変換され、DFT マネージャに加重がレポートされます。実サーバのロード バランシング処理時に、DFP マネージャで加重が考慮されます。ユーザが定義した間隔でのレポートに加え、実サーバのステータスに急な変化があった場合に DFP エージェントから初期のレポートが送信されます。

DFP によって算出される加重は、サーバ ファーム コンフィギュレーション モードで weight コマンドを使用してユーザが定義した静的な加重よりも優先されます。ネットワークから DFP を外すと、IOS SLB は静的な加重に戻されます。

IOS SLB は、DFP マネージャ、別の DFP マネージャ用の DFP エージェント、または同時に両方の役割として定義できます。両方の役割を設定する場合、IOS SLB から他の DFP マネージャへ定期的なレポートが送信されます。その DFP マネージャでは、新しい各接続要求について最適なサーバ ファームを選択するためにレポートの情報が使用されます。次に、IOS SLB では、選択したサーバ ファーム内で最適な実サーバを選択するために同じ情報が使用されます。

また、DFP は、複数のクライアント サブシステム（IOS SLB と GPRS など）の複数の DFP エージェントの同時使用もサポートしています。

詳細については、以下の項を参照してください。

• 「DFP および GPRS ロード バランシング」

• 「DFP および Home Agent Director」

DFP および GPRS ロード バランシング

GPRS ロード バランシングの場合、DFP マネージャとして IOS SLB を定義し、サーバ ファームの各 GGSN に DFP エージェントを定義できます。定義後は、DFP エージェントから GGSN の加重をレポートできます。DFP エージェントでは、CPU 使用率、プロセッサ メモリ、および各 GGSN でアクティブ化できる Packet Data Protocol（PDP）コンテキスト（モバイル セッション）の最大数に基づいて、各 GGSN の加重が算出されます。第一近似として、DFP では、既存の PDP コンテキスト数を、最大許容 PDP コンテキスト数で割った値が算出されます。

（既存の PDP コンテキスト数）/（最大 PDP コンテキスト数）

最大 PDP コンテキスト数は、 gprs maximum-pdp-context-allowed コマンドを使用して指定します。デフォルト値は、10,000 PDP コンテキストです。デフォルト値を受け入れると、GGSN の加重が非常に低く算出されることがあります。

（既存の PDP コンテキスト）/10000 = 低い GGSN 加重

gprs maximum-pdp-context-allowed コマンドを使用して最大 PDP コンテキスト数を指定する場合、この計算を考慮してください。たとえば、GGSN として動作する Cisco 7200 シリーズ ルータは、多くの場合、45,000 PDP コンテキストの最大値で設定されます。

DFP および Home Agent Director

Home Agent Director の場合、DFP マネージャとして IOS SLB を定義し、サーバ ファームの各ホーム エージェントに DFP エージェントを定義できます。また、DFP エージェントから、ホーム エージェントの加重をレポートできます。DFP エージェントでは、CPU 使用率、プロセッサ メモリ、および各ホーム エージェントでアクティブ化できるバインディングの最大数に基づいて、各ホーム エージェントの加重が算出されます。

（バインディングの最大数 - 現在のバインディング数）/バインディングの最大数×（CPU 使用率 + メモリ使用率）/32 ×最大 DFP 加重 = レポートされる加重

バインディングの最大数 は 235,000 です。 最大 DFP 加重 は 24 です。

GGSN-IOS SLB メッセージング

特定の状況が発生した場合、GGSN ではこの機能を使用して IOS SLB に通知できます。IOS SLB では通知によって適切な判断を下すことができます。結果として、GPRS ロード バランシングと障害検出が改善されます。

GGSN から送信される通知では、未使用の空間（将来的に使用するための予備）および次の Information Element（IE; 情報要素）のメッセージの種類とともに GTP を使用します。

• 通知の種類。通知条件を示します。たとえば、Call Admission Control（CAC; コール アドミッション制御）で現在の GGSN に障害が発生したときに、代替 GGSN にセッションを再割り当てするための IOS SLB に対する通知があります。

• 関連セッションの ID（セッション キー）。

• 通知の種類に固有のその他の IE。たとえば、再割り当てのための通知には、本来は SGSN に送信される予定だった作成応答が含まれます。この処理によって、通知によって再割り当ての最大数が設定した制限に達しても、IOS SLB からこの応答を SGSN にリレーできます。

GGSN-IOS SLB メッセージングは、dispatched モードと directed モードの両方でサポートされます。

仮想サーバの INOP_REAL 状態

仮想サーバに関連付けられているすべての実サーバが非アクティブの場合、次のアクションを実行するように、仮想サーバを設定できます。

• 仮想サーバを INOP_REAL 状態に設定します。

• 仮想サーバの状態遷移について SNMP トラップを生成します。

• 仮想サーバは ICMP 要求に対する応答を停止します。

詳細については、SLB サーバ ファームの仮想サーバ コンフィギュレーション モードの inservice（サーバ ファームの仮想サーバ） コマンドに関する説明を参照してください。

プローブ

IOS SLB は、DNS、HTTP、ping、TCP、カスタム UDP、および WSP プローブをサポートします。

• DNS プローブは実サーバに対してドメイン名解決要求を送信し、返される IP アドレスを確認します。

• HTTP プローブは実サーバに対する HTTP 接続を確立し、実サーバに対して HTTP 要求を送信し、その応答を確認します。HTTP プローブは、サーバ ロード バランシング処理されたデバイス、およびファイアウォール ロード バランシング処理されたファイアウォール（ファイアウォールのもう一方にあるデバイスでも）について、接続を確認できる簡単な方法です。

また、HTTP プローブを使用して、サーバ ロード バランシング処理されたアプリケーションを監視することもできます。頻繁にプローブを使用すると、アプリケーションに対する接続だけでなく、各アプリケーションの動作を確認できます。

HTTP プローブは、HTTP over Secure Socket Layer（HTTPS）をサポートしません。つまり、HTTP プローブを SSL サーバに送信できません。

• ping プローブは実サーバに ping を送信します。HTTP プローブと同様に、ping プローブは、ロード バランシング処理されたデバイスとファイアウォールの接続を確認できる簡単な方法です。

• TCP プローブは TCP 接続の確立と削除を行います。TCP ポート 443（HTTPS）の障害を検出するには、TCP プローブを使用します。

• カスタム UDP プローブは、次のように多様なアプリケーションとプロトコルをサポートできます。

– RADIUS Accounting/Authorization プローブ

– GTP Echo プローブ

– Connectionless WSP プローブ

– CSG ユーザ データベース ロード バランシング用 XML-over-UDP プローブ

– Mobile IP RRQ/RRP

• WSP プローブは、ワイヤレス コンテンツの要求をシミュレートし、取得したコンテンツを確認します。ポート 9201 のワイヤレス アプリケーション プロトコル（WAP）スタックの障害を検出するには、WSP プローブを使用します。

各サーバ ファーム、またはファイアウォール ファームの各ファイアウォールに、複数のプローブを設定できます。また、サポートされる種類のプローブを任意に組み合わせることができます。

経路選択済みプローブとしてプローブにフラグを付けることもできます。ただし、次の注意事項があります。

• 1 つのサーバ ファームにつき、同時に 1 インスタンスの経路選択済みプローブだけを実行できます。

• 経路選択済みプローブ宛ての発信パケットは、指定した IP アドレスに直接ルーティングされます。

IOS SLB プローブは SA Agent を使用します。SA Agent が使用できるメモリの量を指定するには、 rtr low-memory コマンドを使用します。使用できる空きメモリの量が、 rtr low-memory コマンドで指定された値を下回ると、SA Agent では、新しい動作を設定できません。詳細については、『 Cisco IOS IP SLAs Command Reference 』の rtr low-memory コマンドの説明を参照してください。

サーバ ロード バランシングのプローブ

プローブは、サーバ ファーム内の各実サーバのステータスを判断します。そのサーバ ファームに属するすべての仮想サーバに関連付けられたすべての実サーバが検査されます。

あるプローブに対して実サーバが失敗すると、すべてのプローブに失敗したことになります。実サーバが回復すると、サービスを復旧する前に、すべてのプローブがその回復を承認する必要があります。

（注） ステートフル バックアップのためにプローブを設定し、フェールオーバーが発生した場合、ステータスの変更（バックアップからアクティブへ）は、新しいアクティブ IOS SLB デバイスに正確に反映されます。ただし、（フェールオーバー前はアクティブ デバイスだった）新しいバックアップ IOS SLB デバイスのプローブのステータスは、アクティブと表示されます。

ファイアウォール ロード バランシングのプローブ

プローブはファイアウォールの障害を検出します。ファイアウォール ファームに関連付けられているすべてのファイアウォールが検査されます。

あるプローブに対してファイアウォールが失敗すると、すべてのプローブに失敗したことになります。ファイアウォールが回復すると、サービスを復旧する前に、すべてのプローブがその回復を承認する必要があります。

パスワードの問題を解消するために、ステータス コード 401 を受け入れるように HTTP プローブを設定します。詳細については、 expect コマンドの説明を参照してください。

デバイスの HTTP サーバを設定するには、 ip http server コマンドを使用します。詳細については、『 Cisco IOS Configuration Fundamentals Command Reference 』の ip http server コマンドの説明を参照してください。

透過的 Web キャッシュ ロード バランシング環境では、仮想 IP アドレスは設定されないため、HTTP プローブは Web キャッシュの実 IP アドレスを使用します。

プロトコル サポート機能

IOS SLB には次のプロトコル サポート機能があります。

• 「プロトコル サポート」

• 「AAA ロード バランシング」

• 「オーディオおよびビデオのロード バランシング」

• 「VPN サーバ ロード バランシング」

プロトコル サポート

IOS SLB は次のプロトコルをサポートします。

• Access Service Network（ASN）R6

• ドメイン ネーム システム（DNS）

• Encapsulation Security Payload（ESP; カプセル化セキュリティ ペイロード）

• ファイル転送プロトコル（FTP）

• Generic Routing Encapsulation（GRE）

• GPRS トンネリング プロトコル v0（GTP v0）

• GPRS トンネリング プロトコル v1（GTP v1）

• GPRS トンネリング プロトコル v2（GTP v2）

• ハイパーテキスト転送プロトコル（HTTP）

• Hypertext Transfer Protocol over Secure Socket Layer（HTTPS; HTTP over SSL）

• Internet Message Access Protocol（IMAP）

• Internet Key Exchange（IKE、旧称 ISAKMP）

• IP in IP Encapsulation（IPinIP）

• Mapping of Airline Traffic over IP, Type A（MATIP-A）

• Network News Transport Protocol（NNTP）

• Post Office Protocol, version 2（POP2）

• Post Office Protocol, version 3（POP3）

• RealAudio/RealVideo via RTSP

• Remote Authentication Dial-In User Service（RADIUS）

• Simple Mail Transport Protocol（SMTP）

• Telnet

• トランスミッション制御プロトコル（TCP）および標準の TCP プロトコル

• ユーザ データグラム プロトコル（UDP）および標準の UDP プロトコル

• X.25 over TCP（XOT）

• 次のようなワイヤレス アプリケーション プロトコル（WAP）

– Connectionless Secure WSP

– Connectionless WSP

– Connection-Oriented Secure WSP

– Connection-Oriented WSP

AAA ロード バランシング

IOS SLB には、RADIUS の認証、認可、アカウンティング（AAA）サーバ用の RADIUS ロード バランシング機能があります。

また、次の RADIUS ロード バランシング機能があります。

• 使用可能な RADIUS サーバおよびプロキシ サーバに、RADIUS 要求を分散します。

• RADIUS 要求の再送信（未応答の要求の再送信など）を、元の要求と同じ RADIUS サーバまたはプロキシ サーバにルーティングします。

• セッションベースの自動障害検出機能があります。

• ステートレス バックアップとステートフル バックアップの両方をサポートします。

さらに IOS SLB は、従来およびモバイルのワイヤレス ネットワークの両方で、RADIUS の認可フローとアカウンティング フローをプロキシするデバイスの負荷を分散できます。詳細については、「RADIUS ロード バランシング」を参照してください。

オーディオおよびビデオのロード バランシング

IOS SLB は、RealNetworks アプリケーションを実行するサーバについて、Real-Time Streaming Protocol（RTSP; リアルタイム トランスポート ストリーミング プロトコル）を介する RealAudio および RealVideo ストリームの負荷を分散できます。

VPN サーバ ロード バランシング

IOS SLB は、次のような実行中のフローなど、バーチャル プライベート ネットワーク（VPN）フローの負荷を分散します。

• IP Security（IPSec; IP セキュリティ）フロー。 IPSec フローは、UDP コントロール セッションと ESP トンネルから構成されます。

• Point-to-Point Tunneling Protocol（PPTP）フロー。PPTP フローは、TCP コントロール セッションと GRE トンネルから構成されます。

冗長機能

IOS SLB デバイスはシングル ポイント障害を示すことがあり、次のいずれかの状況になると、サーバはバックボーンに対する接続を失う可能性があります。

• IOS SLB デバイスに障害が発生する。

• あるスイッチから distribution-layer スイッチへのリンクが解除状態になる。

このリスクを軽減するために、IOS SLB は HSRP に基づいて、次の冗長性の強化をサポートします。

• 「ステートレス バックアップ」

• 「ステートフル バックアップ」

• 「アクティブ スタンバイ」

ステートレス バックアップ

ステートレス バックアップは、シングル レイヤ 3 スイッチの可用性に依存することなく、イーサネット ネットワーク上のホストからの IP フローをルーティングすることで、ネットワークの高可用性を実現します。Router Discovery Protocol（System-to-Intermediate System（IS-IS）Interdomain Routing Protocol（IDRP）など）をサポートしないホストで、新しいレイヤ 3 スイッチにシフトする機能がない場合は特に、ステートレス バックアップが有効です。

ステートフル バックアップ

ステートフル バックアップを使用すると、ロード バランシングの決定を段階的にバックアップするか、プライマリ スイッチとバックアップ スイッチ間で「状態を維持」できます。バックアップ スイッチは、HSRP がフェールオーバーを検出するまで、仮想サーバを休止状態にしたままにします。検出後、バックアップ（現在はプライマリ）スイッチは、仮想アドレスのアドバタイズとフローの処理を開始します。フェールオーバーを迅速に検出する方法を設定するには、HSRP を使用します。

ステートフル バックアップは、IOS SLB に 1 対 1 のステートフルまたはアイドル バックアップ スキームを提供します。つまり、クライアント フローまたはサーバ フローを同時に処理できる IOS SLB は 1 インスタンスだけであり、アクティブな各 IOS SLB スイッチのバックアップ プラットフォームは 1 つだけです。

Home Agent Director はステートフル バックアップをサポートしません。

（注） ステートフル バックアップのためにプローブを設定し、フェールオーバーが発生した場合、ステータスの変更（バックアップからアクティブへ）は、新しいアクティブ IOS SLB デバイスに正確に反映されます。ただし、（フェールオーバー前はアクティブ デバイスだった）新しいバックアップ IOS SLB デバイスのプローブのステータスは、アクティブと表示されます。

アクティブ スタンバイ

アクティブ スタンバイによって、2 つの IOS SLB は同じ仮想 IP アドレスの負荷を分散すると同時に、相互にバックアップとして動作できます。負荷を分散できる仮想 IP アドレスがサイトに 1 つしかない場合、アクセス ルータでポリシーベース ルーティングを使用して、フローのサブセットを各 IOS SLB 宛てにします。

IOS SLB ファイアウォール ロード バランシングは、アクティブ スタンバイをサポートします。つまり、2 ペアのファイアウォール ロード バランシング デバイス（ファイアウォールの各サイドに 1 ペア）を設定できます。各ペアの各デバイスは、トラフィックを処理し、ペアのパートナーをバックアップします。

Exchange Director 機能

IOS SLB は、Catalyst 6500 ファミリ スイッチおよび Catalyst 7600 シリーズ スイッチ用の mobile Service Exchange Framework（mSEF）の場合、Exchange Director をサポートします。Exchange Director には次の機能があります。

• 「ASN R6 ロード バランシング」

• 「GPRS ロード バランシング」

• 「GTP Cause Code Inspection なしの GPRS ロード バランシング」

• 「GTP Cause Code Inspection ありの GPRS ロード バランシング」

• 「Home Agent Director」

• 「KeepAlive Application Protocol（KAL-AP）エージェントのサポート」

• 「RADIUS ロード バランシング」

• 「RADIUS ロード バランシング加速データ プレーン フォワーディング」

• 「WAP ロード バランシング」

• 「冗長ルート プロセッサのステートフル バックアップ」

• 「フローの永続性」

ASN R6 ロード バランシング

IOS SLB は、Access Service Network（ASN）ゲートウェイ セット全体のロード バランシングを実行できます。ゲートウェイ サーバ ファームは、ベース ステーションから単一の ASN ゲートウェイのように見えます。

Mobile Subscriber Station（MSS）はネットワークに参加するとき、ベース ステーションから Mobile Station（MS; モバイル ステーション）Pre-Attachment 要求を IOS SLB の仮想 IP アドレスに送信します。IOS SLB は ASN ゲートウェイを選択し、要求をそのゲートウェイに転送します。ゲートウェイは MS Pre-Attachment 応答でベース ステーションに直接応答します。設定に従い、ベース ステーションから IOS SLB に MS Pre-Attachment ACK を返します。その ACK は選択したゲートウェイに転送されます。以降のすべてのトランザクションは、ベース ステーションとゲートウェイ間で送信されます。

GPRS ロード バランシング

General Packet Radio Service（GPRS）は、European Telecommunications Standards Institute（ETSI）Global System for Mobile Communication（GSM）フェーズ 2+ 標準に基づくパケット ネットワーク インフラストラクチャです。GSM モバイル ユーザからのパケット データを Packet Data Network（PDN）に転送するために使用されます。Cisco Gateway GPRS Support Node（GGSN; ゲートウェイ GPRS サポート ノード）は、GPRS Tunneling Protocol（GTP; GPRS トンネリング プロトコル）を使用して Serving GPRS Support Node（SGSN）と接続します。結果として、トランスポートに UDP を使用します。IOS SLB には GPRS ロード バランシング機能があり、GGSN 用に信頼性と可用性を向上しました。

IOS SLB と GGSN で共有するネットワークを設定する場合、次の注意事項を考慮してください。

• レイヤ 2 情報が適切で明確になるように、スタティック ルータ（ ip route コマンドを使用します）および実サーバの IP アドレス（ real コマンドを使用します）を指定します。

• 次のいずれかの方式を使用して、サブネットを慎重に選択します。

– 仮想テンプレート アドレス サブネットの重複を回避します。

– 実サーバ上のインターフェイスではなく、実サーバに対するネクストホップのアドレスを指定します。

• IOS SLB は、特定の IMSI から作成されたすべての PDP コンテキストを同じ GGSN に割り当てます。

• IOS SLB は、GTP Version 0（GTP v0）、バージョン 1（GTP v1）、およびバージョン 2（GTP v2）をサポートします。GTP のサポートによって IOS SLB は「GTP 対応」になるため、IOS SLB の認識をレイヤ 5 まで拡張できます。

• GPRS ロード バランシング マップによって、IOS SLB は Access Point Name（APN）に基づいてユーザ トラフィックを分類し、ルーティングできます。

IOS SLB は 2 種類の GPRS ロード バランシングをサポートします。

• 「GTP Cause Code Inspection なしの GPRS ロード バランシング」

• 「GTP Cause Code Inspection ありの GPRS ロード バランシング」

GTP Cause Code Inspection なしの GPRS ロード バランシング

Cisco GGSN の場合、GTP Cause Code Inspection をイネーブルに しない GPRS ロード バランシングを推奨します。このロード バランシングには次の特徴があります。

• dispatched モードまたは directed サーバ NAT モードで実行できますが、directed クライアント NAT モードでは実行できません。dispatched モードの場合、GGSN は IOS SLB デバイスに対して レイヤ 2 隣接にする必要があります。

• スティッキ接続がイネーブルの場合にだけ、ステートフル バックアップがサポートされます。詳細については、「ステートフル バックアップ」を参照してください。

• 仮想 GGSN の IP アドレス宛てのトンネル作成メッセージを、加重ラウンド ロビン ロード バランシング アルゴリズムを使用して、実際の GGSN の 1 つに配信します。このアルゴリズムの詳細については、「加重ラウンド ロビン」を参照してください。

• GTP v1 および GTP v2 のセカンダリ PDP コンテキストを考慮に入れるには、DFP が必要です。

GTP Cause Code Inspection ありの GPRS ロード バランシング

GTP Cause Code Inspection をイネーブルに した GPRS ロード バランシングを使用すると、IOS SLB は、GGSN サーバ ファームとの間で送受信するすべての PDP コンテキスト シグナリング フローを監視できます。それによって、GTP 障害の原因コードを監視し、Cisco GGSN と非 Cisco GGSN の両方について、システムレベルの問題を検出できます。

表 1 は、PDP 作成応答の原因コードと、それに対して IOS SLB で実行されるアクションの一覧です。

GTP Cause Code Inspection をイネーブルに した GPRS ロード バランシングには、次の特徴があります。

• 常に directed サーバ NAT モードで動作します。

• ステートフル バックアップをサポートします。詳細については、「ステートフル バックアップ」を参照してください。

• 各 GGSN の開いている PDP コンテキスト数を追跡します。それによって GGSN サーバ ファームは、GPRS ロード バランシングに加重最小接続（ leastconns ）アルゴリズムを使用できます。このアルゴリズムの詳細については、「加重最小接続」を参照してください。

• 要求している International Mobile Subscriber ID（IMSI）のキャリア コードが指定した値と一致しない場合、IOS SLB は仮想 GGSN に対するアクセスを拒否できます。

• DFP を使用しなくても、IOS SLB はセカンダリ PDP コンテキストを把握できます。

Home Agent Director

Home Agent Director は、ホーム エージェント セット（サーバ ファームの実サーバとして設定されます）の中で、Mobile IP Registration Request（RRQ）のロード バランシングを実行します。ホーム エージェントは、モバイル ノードのアンカー ポイントです。ホーム エージェントは、モバイル ノードのフローを現在の外部エージェント（接続ポイント）にルーティングします。

Home Agent Director には次の特徴があります。

• dispatched モードまたは directed サーバ NAT モードで実行できますが、directed クライアント NAT モードでは実行できません。dispatched モードの場合、ホーム エージェントは IOS SLB デバイスに対して レイヤ 2 隣接にする必要があります。

• ステートフル バックアップをサポートしません。詳細については、「ステートフル バックアップ」を参照してください。

• 仮想 Home Agent Director の IP アドレス宛ての RRQ を、加重ラウンド ロビン ロード バランシング アルゴリズムを使用して、実際のホーム エージェントの 1 つに配信します。このアルゴリズムの詳細については、「加重ラウンド ロビン」を参照してください。

• 容量に基づいて RRQ を割り当てるには、DFP が必要です。

Mobile IP、ホーム エージェントの詳細と関連するトピックについては、『 Cisco IOS IP Configuration Guide , Release 12.2』を参照してください。

KeepAlive Application Protocol（KAL-AP）エージェントのサポート

KAL-AP エージェントのサポートによって、IOS SLB は Global Server Load Balancing（GSLB; グローバル サーバ ロード バランシング）環境でロード バランシングを実行できます。KAL-AP は、負荷情報とキープアライブ応答メッセージを KAL-AP マネージャまたは GSLB デバイス（Global Site Selector（GSS）など）に提供します。また、GSLB デバイスが、最も負荷が少ない IOS SLB デバイスにクライアント要求の負荷を分散できるように支援します。

KAL-AP エージェントのサポートを IOS SLB に設定する場合、次の注意事項を考慮してください。

• KAL-AP エージェントのサポートによって、受信要求パケットの Virtual Private Network（VPN）Routing and Forwarding（VRF）ID を自動的に検出し、応答のソリューション指示に同じ VRF ID を使用します。

• DNS キャッシングを使用するクライアントは、GSS を介して要求を送信するのではなく、IOS SLB に直接送信できます。そのため、このような状況を回避するために、クライアントで DNS 設定を指定してください。

KAL-AP は、相対的または絶対的のいずれかの方法で、負荷値を算出します（IOS SLB CPU/メモリ負荷は、最終的な KAL-AP 負荷値に影響を及ぼす可能性があります）。

相対的 KAL-AP 負荷値

サーバ ファーム コンフィギュレーション モードで farm-weight コマンドを設定していない場合、または IOS SLB で DFP がイネーブルではない場合、KAL-AP は次の数式を使用して相対的な負荷値を算出します。

KAL-AP 負荷 = 256 -（ アクティブな実サーバの数 × 256 / サービスに参加している実サーバの数 ）

たとえば、サイトに 2 つの実サーバがあり、両方の実サーバがサービスに参加していますが、現在アクティブなサーバは 1 つだけの場合、そのサイトの KAL-AP 負荷値は次のようになります。

KAL-AP 負荷 = 256 - ( 1 × 256 / 2 ) = 256 - 128 = 128

絶対的 KAL-AP 負荷値

サーバ ファーム コンフィギュレーション モードで farm-weight コマンドを設定しており、IOS SLB で DFP がイネーブルの場合、KAL-AP は次の数式を使用して絶対的な負荷値を算出します。

KAL-AP 負荷 = 256 -（ 実サーバの最大 DFP 加重の合計 × 256 / ファームの加重 ）

（注） 実サーバの最大 DFP 加重は、グローバル コンフィギュレーション モードで gprs dfp max-weight コマンドを使用して設定します。ただし、KAL-AP にレポートされる実際の DFP 加重は、GGSN の負荷に比例します。たとえば、100 の最大 DFP 加重で GGSN を設定し、GGSN の負荷は 50% の場合、50 の最大 DFP 負荷が KAL-AP にレポートされます。

実サーバに対する DFP 接続がダウン状態の場合、KAL-AP では、SLB 実サーバ コンフィギュレーション モードで weight コマンドの設定が使用されます。実サーバに対して weight コマンドが設定されていない場合、KAL-AP では 8 というデフォルトの加重が使用されます。

たとえば、次の設定のサイトがあるとします。

• サーバ ファームには 200 のファーム加重が設定されています。

• GGSN-1 には 100 の最大 DFP 加重が設定され、0% の負荷です（そのため、100 の DFP 加重がレポートされます）。

• GGSN-2 には 100 の最大 DFP 加重が設定され、50% の負荷です（そのため、50 の DFP 加重がレポートされます）。

このサイトの KAL-AP 負荷値は次のようになります。

KAL-AP 負荷 = 256 - [( 100 + 50) × 256 / 200 ] = 256 - 192 = 64

最適な結果を得るには、サーバ ファームの実サーバの最大 DFP 加重の合計と等値になるように ファームの加重 を設定します。たとえば、サーバ ファームに 3 つの実サーバがあり、100、50、および 50 の最大 DFP 加重が設定されている場合、200（つまり、100 + 50 + 50）の ファームの加重 を設定します。サーバ ファームに実サーバを追加した場合、またはファームから削除した場合、それに従って ファームの加重 を調整する必要があります。

RADIUS ロード バランシング

IOS SLB には、RADIUS サーバ用の RADIUS ロード バランシング機能があります。さらに IOS SLB は、従来およびモバイルのワイヤレス ネットワークの両方で、RADIUS の認可フローとアカウンティング フローをプロキシするデバイスを必要に応じて負荷を分散できます。そのために IOS SLB では、その加入者フローの RADIUS を処理した同じプロキシに、データ フローが関連付けられます。

IOS SLB は、サービス ゲートウェイ（Cisco Service Selection Gateway（SSG）または Cisco Content Services Gateway（CSG））を使用するモバイル ワイヤレス ネットワークに RADIUS ロード バランシング機能を提供します。次のモバイル ワイヤレス ネットワークがサポートされます。

• GPRS ネットワーク。GPRS モバイル ワイヤレス ネットワークでは、RADIUS クライアントは通常 GGSN です。

• 簡易 IP CDMA2000 ネットワーク。CDMA2000 は Third-Generation（3-G; 第 3 世代）バージョンの Code Division Multiple Access（CDMA; 符号分割多重接続）です。簡易 IP CDMA2000 モバイル ワイヤレス ネットワークの場合、RADIUS クライアントは Packet Data Service Node（PDSN）です。

• Mobile IP CDMA2000 ネットワーク。Mobile IP CDMA2000 モバイル ワイヤレス ネットワークの場合、Home Agent（HA）および PDSN/Foreign Agent（PDSN/FA）の両方が RADIUS クライアントです。

また、次の RADIUS ロード バランシング機能があります。

• 使用可能な RADIUS サーバおよびプロキシ サーバに、RADIUS 要求を分散します。

• RADIUS 要求の再送信（未応答の要求の再送信など）を、元の要求と同じ RADIUS サーバまたはプロキシ サーバにルーティングします。

• すべての加入者の RADIUS フローと、同じ加入者の非 RADIUS データ フローを、同じサービス ゲートウェイにルーティングします。

• 複数のサービス ゲートウェイ サーバ ファームをサポートします（たとえば、SSG ファームと CSG ファーム）。適切なサービス ゲートウェイ サーバ ファームにルーティングするために、パケットの入力インターフェイスが確認されます。

• RADIUS ロード バランシング仮想サーバの背後に、複数の WAP ゲートウェイ サーバ ファームを配置できます。RADIUS 発信ステーション ID およびユーザ名を使用して特定のサーバ ファームを選択できます。この強化によって、コントロール プレーンとデータ プレーンの両方で RADIUS ロード バランシングが可能になります。コントロール プレーンの RADIUS ロード バランシングでは、加入者の認可、認証、およびアカウンティングに関して、RADIUS メッセージの負荷を AAA サーバに分散できます。データ プレーンの RADIUS ロード バランシングでは、特定の加入者のデータ フローに、宛先ネットワーク デバイスに対する一貫したネットワーク パスを維持できます。さらに、RADIUS 仮想サーバは RADIUS アカウンティング メッセージを承認し、スティッキ オブジェクトを構築または削除できます。メッセージを指定したサーバに転送する必要はありません。

• データ パケットを CSG ファームの実サーバにルーティングしてから、SSG ファームの実サーバにルーティングできます。

• 加入者の RADIUS Access-Request メッセージを処理したサービス ゲートウェイに対して、RADIUS クライアントからの RADIUS Accounting-Request メッセージをルーティングします。その後、サービス ゲートウェイはその加入者に関して作成したホスト エントリを消去できます。

• 加重ラウンド ロビン アルゴリズムを使用します。このアルゴリズムの詳細については、「加重ラウンド ロビン」を参照してください。

• RADIUS プロトコルを介して SSG シングル サインオンが容易になります。

• セッションベースの自動障害検出機能があります。

• ステートレス バックアップとステートフル バックアップの両方をサポートします。

RADIUS ロード バランシングを実行するには、IOS SLB に次の RADIUS スティッキ データベースを使用します。

• IOS SLB RADIUS framed-IP スティッキ データベースは、各加入者の IP アドレスを特定のサービス ゲートウェイに関連付けます。GPRS モバイル ワイヤレス ネットワークの場合、IOS SLB は RADIUS framed-IP スティッキ データベースを使用して、パケットを適切にルーティングします。

（注） 加入者の IP アドレスは、サービス ゲートウェイまたは RADIUS クライアントによって割り当てられます。サービスごとに分離されたゲートウェイ プールから加入者の IP アドレスが割り当てられている場合（そのため、ネクストホップのサービス ゲートウェイを発信元 IP アドレスに基づいて選択できる場合）、加入者フローのルーティングにポリシー ルーティングを使用できます。

• IOS SLB RADIUS calling-station-ID スティッキ データベースは、各加入者の発信ステーション ID を特定のサービス ゲートウェイに関連付けます。

• IOS SLB RADIUS username スティッキ データベースは、各加入者のユーザ名を特定のサービス ゲートウェイに関連付けます。

• RADIUS ロード バランシング マップによって、IOS SLB は RADIUS 発信ステーション ID とユーザ名に基づいてユーザ トラフィックを分類し、ルーティングできます。RADIUS ロード バランシング マップは、Turbo RADIUS ロード バランシングおよび RADIUS ロード バランシング アカウンティングのローカル ACK と同時に使用できません。

• RADIUS ロード バランシング アカウンティングのローカル ACK によって、IOS SLB は RADIUS アカウンティング パケットに ACK で応答し、さらにそのセッションのスティッキ オブジェクトを維持できるようになります。RADIUS ロード バランシング アカウンティングのローカル ACK は、RADIUS ロード バランシング マップと Turbo RADIUS ロード バランシングと同時に使用できません。

• CDMA2000 モバイル ワイヤレス ネットワークの場合、パケットを適切にルーティングするには、RADIUS framed-IP スティッキ データベースに加え、RADIUS username スティッキ データベースまたは RADIUS calling-station-ID スティッキ データベースが必要です。

• IOS SLB RADIUS International Mobile Subscriber ID（IMSI）は、各ユーザの IMSI アドレスを対応するゲートウェイにルーティングします。その結果、同じユーザに対する以降のすべてのフローを同じゲートウェイに転送できるようになります。

RADIUS ロード バランシング加速データ プレーン フォワーディング

RADIUS ロード バランシング加速データ プレーン フォワーディング（Turbo RADIUS ロード バランシングとも呼ばれます）は、CSG 環境でポリシーベース ルーティング（PBR）ルート マップを使用し、加入者のデータプレーン トラフィックを処理する高パフォーマンスのソリューションです。

Turbo RADIUS ロード バランシングが RADIUS ペイロードを受信すると、ペイロードが検査され、framed-IP アトリビュートが抽出され、ルート マップがその IP アドレスに適用され、加入者を処理する CSG が決定されます。

Vendor-Specific Attribute（VSA; ベンダー固有アトリビュート）関連付けを設定し、Cisco VSA がバッファリングされている場合、Cisco VSA は RADIUS Accounting-Start パケットに注入されます。

Turbo RADIUS ロード バランシングに VSA 関連付けは必要ありませんが、アカウンティング仮想サーバに predictor route-map で設定したサーバ ファームは必要です。

（注） SLB サーバ ファーム コンフィギュレーション モードで predictor route-map コマンドを指定する場合、SLB サーバ ファーム コンフィギュレーション モードまたは実サーバ コンフィギュレーション モードで他のコマンドは使用できません。

機能、使用するタイミング、設定方法、イネーブルにする方法など、ポリシーベース ルーティングの詳細については、『 Cisco IOS IP Routing Configuration Guide 』の「Policy-Based Routing」および「Configuring Policy-Based Routing」の項を参照してください。

mobile Service Exchange Framework（mSEF）環境の場合、CSG クラスタのネットワーク側では、Turbo RADIUS ロード バランシングにファイアウォール ロード バランシングは必要ありません（クラスタのネットワーク側では、標準の RADIUS ロード バランシングにファイアウォール ロード バランシングは必要ありません）。

Turbo RADIUS ロード バランシングは、RADIUS ロード バランシング マップおよび RADIUS ロード バランシング アカウンティングのローカル ACK と同時に使用できません。

Turbo RADIUS ロード バランシングは、Virtual Private Network（VPN）Routing and Forwarding（VRF）と同時に使用できません。

Turbo RADIUS ロード バランシングは、簡易な IP アクセス コントロール リスト（ACL）をサポートし、ネクストホップ ペアのマッチングと設定を行います。

Turbo RADIUS ロード バランシングは、オプションの ACL ロギング ファシリティと同時に使用できません。Turbo RADIUS ロード バランシングを使用するには、まずロギング ファシリティをディセーブルにする必要があります。詳細については、『 Cisco IOS Security Command Reference （Cisco IOS 12.4）』の access-list （IP 標準） コマンドの説明を参照してください。

WAP ロード バランシング

IOS SLB を使用すると、IP ベアラ ネットワークの WAP ゲートウェイまたはサーバのグループ内で、Wireless Session Protocol（WSP）セッションの負荷を分散できます。WAP は、既知のポート セットで、UDP 上で実行されます。各ポートは異なる WAP モードを示します。

• Connectionless WSP モード（IP/UDP [9200]/WSP）。Connectionless WSP モードの場合、WSP は簡易な 1 要求/1 応答プロトコルであり、単一のサーババインド パケットによって、1 つまたは複数のパケットのサーバ応答が返されます。

• Connection-oriented WSP モード（IP/UDP [9201]/WTP/WSP）。Connection-oriented WSP モードの場合、WDP イベントの再送信は WTP によって処理され、WSP は定義済みのセッション起動/切断シークエンスを使用して動作します。セッションの再割り当てには、WSP セッションのイベントによって動作する WAP 対応の Finite State Machine（FSM; 有限状態マシン）が使用されます。この FSM はポート 9201 でのみ動作します。この WSP セッションは暗号化されていないため、WTP によって再送信が処理されます。

• Connectionless Secure WSP モード（IP/UDP [9202]/WTLS/WSP）。このモードの機能は Connectionless WSP モードと同じですが、WTLS によってセキュリティが提供されます。

• Connection-oriented Secure WSP モード（IP/UDP [9203]/WTLS/WTP/WSP）。このモードの機能は Connection-oriented WSP モードと同じですが、WTLS によってセキュリティが提供されます。

ポート 9201 の WAP スタックの障害を検出するには、WSP プローブを使用します。

冗長ルート プロセッサのステートフル バックアップ

Catalyst 6500 ファミリ スイッチおよび Cisco 7600 シリーズ ルータで、RPR+ を併用する場合、IOS SLB は mSEF について冗長ルート プロセッサのステートフル バックアップをサポートします。これによって、IOS SLB と同じシャーシに、Cisco Multiprocessor WAN Application Module（MWAN）を配置し、さらにロード バランシング割り当ての高可用性を維持できます。

フローの永続性

フローの永続性には、負荷分散された IP フローを適切なノードに返す、高度なリターン ルーティング機能があります。負荷分散されたデータ パスの両側でハッシュ メカニズムを調整する必要はありません。また、ネットワーク アドレス変換（NAT）やプロキシを使用して、クライアントまたはサーバの IP アドレスを変更する必要もありません。

必須および任意の IOS SLB 機能の設定

IOS SLB 機能を設定するには、次の項の作業を実行します。必須および任意の作業を示します。

• 「サーバ ファームおよび実サーバの設定」（必須）

• 「仮想サーバの設定」（必須）

• 「サーバ ファームの確認」（任意）

• 「仮想サーバの確認」（任意）

• 「クライアントの確認」（任意）

• 「IOS SLB 接続の確認」（任意）

サーバ ファームおよび実サーバの設定

サーバ ファームおよび実サーバを設定するには、この作業を実行します。

（注） 複数のユーザ セッションから同時に IOS SLB を設定することはできません。

手順の概要

1. enable

2. configure terminal

3. ip slb serverfarm server-farm

4. bindid [ bind-id ]

5. nat { client pool | server }

6. predictor [ roundrobin | leastconns | route-map mapname ]

7. probe probe

8. real ip-address [ port ]

9. faildetect numconns number-of-conns [ numclients number-of-clients ]

10. maxclients number-of-conns

11. maxconns number-of-conns [ sticky-override ]

12. reassign threshold

13. retry retry-value

14. weight setting

15. inservice

手順の詳細

（注） サーバ ロード バランシングおよびファイアウォール ロード バランシングの両方を Catalyst 6500 ファミリ スイッチで実行する場合、PFC 上の TCAM の容量を超える可能性を軽減するには、mls ip slb wildcard search rp コマンドを使用します。詳細については、「ワイルドカード検索の設定」を参照してください。

仮想サーバの設定

仮想サーバを設定するには、次の作業を実行します。

IOS SLB は最大 500 仮想サーバをサポートします。

手順の概要

1. enable

2. configure terminal

3. ip slb vserver virtual-server

4. virtual ip-address [ netmask [ group ]] { esp | gre | protocol }

または

virtual ip-address [ netmask [ group ]] { tcp | udp } [ port | any ] [ service service ]

5. serverfarm primary-farm [ backup backup-farm [ sticky ]] [ map map-id priority priority ]

6. access interface [ route framed-ip ]

7. advertise [ active ]

8. client { ip-address netmask [ exclude ] | gtp carrier-code [ code ]}

9. delay { duration | radius framed-ip duration }

10. gtp notification cac [ reassign-count ]

11. hand-off radius duration

12. idle [ asn r6 request | gtp request | ipmobile request | radius { request | framed-ip }] duration

13. purge radius framed-ip acct on-off

14. purge radius framed-ip acct stop { attribute-number | { 26 | vsa } { vendor-ID | 3gpp | 3gpp2 } sub-attribute-number }

15. radius acct local-ack key [encrypt] secret-string

16. radius inject auth group-number { calling-station-id | username }

17. radius inject auth timer seconds

18. radius inject auth vsa vendor-id

19. replicate casa listen-ip remote-ip port [interval] [ password [encrypt] secret-string timeout]

20. replicate interval interval

21. replicate slave

22. sticky { duration [ group group-id ] [ netmask netmask ] | gtp imsi [ group group-id ] | radius calling-station-id | radius framed-ip [ group group-id ] | radius username [ msid-cisco ] [ group group-id ]}

23. synguard syn-count interval

24. inservice [ standby group-name ] [ active ]

手順の詳細

仮想サーバの確認

仮想サーバを確認するには、次の作業を実行します。

手順の概要

1. show ip slb vservers

手順の詳細

次の show ip slb vservers コマンドで、仮想サーバの PUBLIC_HTTP および RESTRICTED_HTTP の設定を確認します。

サーバ ファームの確認

サーバ ファームを確認するには、次の作業を実行します。

手順の概要

1. show ip slb reals

2. show ip slb serverfarm

手順の詳細

次の show ip slb reals コマンドで、サーバ ファーム PUBLIC および RESTRICTED のステータス、関連する実サーバ、およびそのステータスを表示します。

次の show ip slb serverfarm コマンドで、サーバ ファーム PUBLIC および RESTRICTED の設定およびステータスを表示します。

クライアントの確認

クライアントを確認するには、次の作業を実行します。

手順の概要

1. show ip slb conns

手順の詳細

次の show ip slb conns コマンドで、制限されたクライアント アクセスおよびステータスを確認します。

次の show ip slb conns コマンドで、制限されたクライアント アクセス ステータスに関する詳細情報を表示します。

IOS SLB 接続の確認

IOS SLB 接続を確認するには、次の作業を実行します。

手順の概要

1. show ip slb stats

手順の詳細

IOS SLB 機能がインストールされ、適切に動作していることを確認するには、IOS SLB スイッチから実サーバに ping を送信し、次にクライアントから仮想サーバに ping を送信します。

次の show ip slb stats コマンドで、IOS SLB ネットワーク ステータスに関する詳細情報を表示します。

通常のスイッチングは、通常の IOS スイッチング パスで IOS SLB パケットが処理されるときです（CEF、ファースト スイッチング、およびプロセス レベル スイッチング）。特殊なスイッチングは、ハードウェア割り当てのスイッチング パスで IOS SLB パケットが処理されるときです。

IOS SLB ネットワークおよび接続の確認に使用されるその他のコマンドについては、「IOS SLB のモニタおよびメンテナンス」を参照してください。

ファイアウォール ロード バランシングの設定

基本的な IOS SLB ファイアウォール ロード バランシング ネットワークを設定するには、次の作業を実行します。

IOS SLB ファイアウォール ロード バランシングでは、障害の検出と回復にプローブを使用します。ファイアウォール ファームの各実サーバにプローブを設定する必要があります。ping プローブが推奨されます。詳細については、「ping プローブの設定」を参照してください。ファイアウォールで、ping プローブの転送を許可していない場合、代わりに HTTP プローブを使用します。詳細については、「HTTP プローブの設定」を参照してください。ファイアウォール ファームの各ファイアウォールに、複数のプローブを設定できます。また、サポートされる種類（DNS、HTTP、TCP、または ping）のプローブを任意に組み合わせることができます。

サーバ ロード バランシングおよびファイアウォール ロード バランシングの両方を Catalyst 6500 ファミリ スイッチで実行する場合、PFC 上の TCAM の容量を超える可能性を軽減するには、グローバル コンフィギュレーション モードで mls ip slb wildcard search rp コマンドを使用します。詳細については、「ワイルドカード検索の設定」を参照してください。

IOS SLB の消去率が高くなると、CPU に影響が及ぶ可能性があります。この問題が発生する場合、グローバル コンフィギュレーション モードで no 形式の mls ip slb purge global コマンドを使用し、TCP および UDP フロー パケットで消去スロットリングをディセーブルにします。詳細については、「MLS エントリのプロトコルレベル消去の設定」を参照してください。

ここでは、次の IOS SLB ファイアウォール ロード バランシング設定作業について説明します。必須および任意の作業を示します。

• 「ファイアウォール ファームの設定」（必須）

• 「ファイアウォール ファームの確認」（任意）

• 「ファイアウォール接続の確認」（任意）

ファイアウォール ファームの設定

ファイアウォール ファームを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb firewallfarm firewall-farm

4. real ip-address

5. probe probe

6. weight service

7. inservice

8. access [ source source-ip netmask ] [ destination destination-ip netmask ]

9. predictor hash address [ port ]

10. purge connection

11. purge sticky

12. replicate casa listen-ip remote-ip port [interval] [ password [[encrypt] secret-string [timeout]]

13. replicate interval interval

14. replicate slave

15. protocol tcp

16. delay duration

17. idle duration

18. maxconns maximum-number

19. sticky duration [ netmask netmask ] [ source | destination ]

20. protocol datagram

21. idle duration

22. maxconns maximum-number

23. sticky duration [ netmask netmask ] [ source | destination ]

24. inservice

手順の詳細

ファイアウォール ファームの確認

ファイアウォール ファームを確認するには、次の作業を実行します。

手順の概要

1. show ip slb real

2. show ip slb firewallfarm

手順の詳細

次の show ip slb reals コマンドで、ファイアウォール ファーム FIRE1 のステータス、関連する実サーバ、およびそのステータスを表示します。

次の show ip slb firewallfarm コマンドで、ファイアウォール ファーム FIRE1 の設定およびステータスを表示します。

ファイアウォール接続の確認

ファイアウォールの接続を確認するには、次の作業を実行します。

手順の概要

1. 外部実サーバに ping を送信します。

2. 内部実サーバに ping を送信します。

3. show ip slb stats

4. show ip slb real detail

5. show ip slb conns

手順の詳細

IOS SLB ファイアウォール ロード バランシングが設定済みで、適切に動作していることを確認するには、次の手順を実行します。

ステップ 1 IOS SLB ファイアウォール ロード バランシング スイッチから外部実サーバ（ファイアウォールの外側にあるサーバ）に ping を送信します。

ステップ 2 クライアントから内部実サーバ（ファイアウォールの内側にあるサーバ）に ping を送信します。

ステップ 3 show ip slb stats コマンドを使用して、IOS SLB ファイアウォール ロード バランシングのネットワーク ステータスに関する詳細情報を表示します。

通常のスイッチングは、通常の IOS スイッチング パスで IOS SLB パケットが処理されるときです（CEF、ファースト スイッチング、およびプロセス レベル スイッチング）。特殊なスイッチングは、ハードウェア割り当てのスイッチング パスで IOS SLB パケットが処理されるときです。

ステップ 4 show ip slb real detail コマンドを使用して、IOS SLB ファイアウォール ロード バランシングの実サーバのステータスに関する詳細情報を表示します。

ステップ 5 show ip slb conns コマンドを使用して、アクティブな IOS SLB ファイアウォール ロード バランシングの接続に関する詳細情報を表示します。

IOS SLB ネットワークおよび接続の確認に使用されるその他のコマンドについては、「IOS SLB のモニタおよびメンテナンス」を参照してください。

プローブの設定

プローブを設定するには、次の作業を実行します。

IOS SLB で接続を確認し、障害を検出するには、プローブが使用されます。プローブの各種類の詳細については、「プローブ」を参照してください。

デフォルトで、IOS SLB に設定されているプローブはありません。ここでは、プローブを設定および確認する方法について説明します。必須および任意の作業を示します。

• 「カスタム UDP プローブの設定」（必須）

• 「DNS プローブの設定」（必須）

• 「HTTP プローブの設定」（必須）

• 「ping プローブの設定」（必須）

• 「TCP プローブの設定」（必須）

• 「WSP プローブの設定」（必須）

• 「プローブの関連付け」（必須）

• 「プローブの確認」（任意）

カスタム UDP プローブの設定

カスタム UDP プローブを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb probe probe custom udp

4. address [ ip-address ] [ routed ]

5. faildetect number-of-probes

6. interval seconds

7. port port

8. request data {start-byte | continue } hex-data-string

9. response clause-number data start-byte hex-data-string

10. timeout seconds

手順の詳細

DNS プローブの設定

DNS プローブを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb probe probe dns

4. address [ip-address [ routed ]]

5. faildetect number-of-probes

6. interval seconds

7. lookup ip-address

手順の詳細

HTTP プローブの設定

HTTP プローブを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb probe probe http

4. address [ip-address [ routed ]]

5. credentials {username [password]}

6. expect [ status status-code] [ regex expression]

7. header field-name [ field-value ]

8. interval seconds

9. port port

10. request [ method { get | post | head | name name }] [ url path ]

11. 仮想サーバへのルートを設定します。

手順の詳細

さらに、HTTP プローブには仮想サーバへのルートが必要です。このルートは使用されませんが、宛先に到達可能であることをソケット コードが確認するために必要です。結果として、HTTP プローブが適切に動作するために不可欠です。ルートには、ホスト ルート（仮想サーバによってアドバタイズされます）またはデフォルト ルート（たとえば、 ip route 0.0.0.0 0.0.0.0 コマンドを使用して指定されます）を使用できます。

ping プローブの設定

ping プローブを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb probe probe ping

4. address [ip-address [ routed ]]

5. faildetect number-of-pings

6. interval seconds

手順の詳細

TCP プローブの設定

TCP プローブを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb probe probe tcp

4. address [ip-address [ routed ]]

5. interval seconds

6. port port

手順の詳細

WSP プローブの設定

WSP プローブを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb probe probe wsp

4. address [ip-address [ routed ]]

5. interval seconds

6. url [path]

手順の詳細

プローブの関連付け

プローブを実サーバまたはファイアウォールに関連付けるには、次の作業を実行します。

プローブの設定後、 probe コマンドを使用して、実サーバまたはファイアウォールと関連付ける必要があります。詳細については、「サーバ ファームおよび実サーバの設定」および「ファイアウォール ロード バランシングの設定」を参照してください。

（注） WSP プローブをファイアウォールに関連付けることはできません。

手順の概要

1. enable

2. configure terminal

3. ip slb firewallfarm firewall-farm

または

ip slb serverfarm server-farm

4. probe probe

手順の詳細

プローブの確認

プローブを確認するには、次の作業を実行します。

手順の概要

1. show ip slb probe

手順の詳細

プローブが適切に設定されていることを確認するには、 show ip slb probe コマンドを使用します。

DFP の設定

DFP マネージャとして IOS SLB を設定し、IOS SLB が接続を開始する DFP エージェントを指定するには、次の作業を実行します。

IOS SLB は、DFP マネージャ、別の DFP マネージャ用の DFP エージェント、または同時に両方の役割として定義できます。ネットワーク設定によっては、IOS SLB を DFP マネージャとして設定するためにコマンドを入力し、同じデバイスまたは別のデバイス上で IOS SLB を DFP エージェントとして設定するためにコマンドを入力します。

手順の概要

1. enable

2. configure terminal

3. ip slb dfp [ password [[encrypt] secret-string [ timeout ]]

4. agent ip-address port [ timeout [ retry-count [ retry-interval ]]]

手順の詳細

この次の手順

IOS SLB を DFP エージェントとして設定するには、Cisco IOS リリース 12.2(18)SXB の DFP Agent Subsystem 機能のマニュアルを参照してください。

GPRS ロード バランシングの設定作業リスト

GPRS ロード バランシングを設定するには、次の作業を実行します。

手順の概要

1. サーバ ファームおよび実サーバを設定します。

2. 仮想サーバを設定します。

3. サーバの各 GGSN でループバックとして仮想 IP アドレスを設定します。

4. 各 GGSN を、それぞれに関連付けられた SGSN にルーティングします。

5. 各 SGSN を、それぞれに関連付けられた Cisco GGSN 上の仮想テンプレート、および GPRS ロード バランシング仮想サーバにルーティングします。

6. GSN アイドル タイマーを設定します。

手順の詳細

GSN アイドル タイマーの設定

GSN アイドル タイマーを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb timers gtp gsn duration

手順の詳細

GGSN-IOS SLB のメッセージング作業リスト

GGSN-IOS SLB メッセージングを設定するには、次の作業を実行します。

手順の概要

1. GGSN-IOS SLB メッセージングをサポートするには、GGSN を設定します。

2. サーバ ファームおよび実サーバを設定します。

3. 仮想サーバを設定します。

手順の詳細

GPRS ロード バランシング マップの設定

GPRS ロード バランシング マップを設定するには、次の作業を実行します。

GPRS ロード バランシング マップによって、IOS SLB は APN に基づいてユーザ トラフィックを分類し、ルーティングできます。GPRS ロード バランシングのマップをイネーブルにするには、GTP マップを定義してから、そのマップをサーバ ファームに関連付ける必要があります。

手順の概要

1. enable

2. configure terminal

3. ip slb map map-id gtp | radius }

4. apn string

5. exit

6. ip slb vserver virtual-server

7. virtual ip-address [ netmask [ group ]] { tcp | udp } [ port | any ] [ service service ]

8. serverfarm primary-farm [ backup backup-farm [ sticky ]] [ map map-id priority priority ]

手順の詳細

KeepAlive Application Protocol（KAL-AP）エージェントのサポートの設定

KAL-AP エージェントのサポートを設定するには、次の作業を実行します。

KAL-AP エージェントのサポートによって、IOS SLB は Global Server Load Balancing（GSLB; グローバル サーバ ロード バランシング）環境でロード バランシングを実行できます。

手順の概要

1. enable

2. configure terminal

3. ip slb capp udp

4. peer [ ip-address ] port port

5. peer [ ip-address ] secret [ encrypt ] secret-string

6. exit

7. ip slb serverfarm server-farm

8. kal-ap domain tag

9. farm-weight setting

手順の詳細

RADIUS ロード バランシングの設定作業リスト

RADIUS ロード バランシングを設定するには、次の作業を実行します。

手順の概要

1. サーバ ファームおよび実サーバを設定します。

2. 仮想サーバを設定します。

3. IOS SLB で、RADIUS framed-IP スティッキ ルーティングのパケットを検査できるようにします。

4. RADIUS ロード バランシング マップを設定します。

5. RADIUS ロード バランシング加速データ プレーン フォワーディングを設定します。

6. 使用できるマルチレイヤ スイッチング（MLS）エントリの数を増やします。

7. プローブを設定します。

手順の詳細

RADIUS framed-IP スティッキ ルーティングのパケット検査のイネーブル化

IOS SLB で、RADIUS framed-IP スティッキ ルーティングのパケットを検査できるようにするには、次の作業を実行します。

IP アドレスとサブネット マスクと一致する発信元 IP アドレスのパケットを検査するように設定できます。検査対象のパケットの発信元 IP アドレスが、IOS SLB RADIUS framed-IP スティッキ データベースのエントリと一致する場合、パケットのルーティングにそのエントリが使用されます。それ以外の場合、IOS がパケットをルーティングします。

手順の概要

1. enable

2. configure terminal

3. ip slb route { framed-ip deny | ip-address netmask framed-ip | inter-firewall }

手順の詳細

RADIUS ロード バランシング マップの設定

RADIUS ロード バランシング マップを設定するには、次の作業を実行します。

RADIUS ロード バランシング マップによって、IOS SLB は RADIUS 発信ステーション ID とユーザ名に基づいてユーザ トラフィックを分類し、ルーティングできます。RADIUS ロード バランシングのマップをイネーブルにするには、RADIUS マップを定義してから、そのマップをサーバ ファームに関連付ける必要があります。

手順の概要

1. enable

2. configure terminal

3. ip slb map map-id radius

4. calling-station-id string

5. username string

6. exit

7. ip slb vserver virtual-server

8. virtual ip-address [ netmask [ group ]] { tcp | udp } [ port | any ] [ service service ]

9. serverfarm primary-farm [ backup backup-farm [ sticky ]] [ map map-id priority priority ]