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

IOS SLB の利点

IOS SLB は Cisco IOS と同じソフトウェア コード ベースを共有しており、Cisco IOS ソフトウェアのすべてのソフトウェア機能セットを備えています。

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

IOS SLB は、分散環境でサーバと接続を積極的に管理するためのテクニックを駆使して、コンテンツとアプリケーションの継続的なハイ アベイラビリティを保証します。また、ユーザ要求をサーバのクラスタ全体で分散することによって、応答性とシステム容量を最適化し、大規模サイト、中規模サイト、および小規模サイトのインターネット、データベース、およびアプリケーション サービスの提供コストを削減します。

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

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

• IOS SLB のスロー スタート機能を使用すれば、新しいサーバの負荷を段階的に上げることによって、短期間に多くの新しい接続をサーバに割り当てることで発生する障害を阻止できます。

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

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

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

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

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

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

Cisco IOS SLB 機能

Cisco IOS SLB には次のようなサブ機能が含まれています。

• 「ルーティング機能」

• 「セキュリティ機能」

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

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

• 「冗長機能」

ルーティング機能

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

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

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

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

• 「接続のレート制限」

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

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

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

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

• 「Home Agent Director」

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

• 「最大接続」

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

• 「ネットワーク アドレス変換」

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

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

• 「スティッキ接続」

• 「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 に割り当てられます。

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

GTP Cause Code Inspection がイネーブルになっていない GPRS ロード バランシングには、加重ラウンド ロビン アルゴリズムが必要です。加重最小接続を使用するサーバ ファームを GTP Cause Code Inspection がイネーブルになっていない GPRS ロード バランシングを提供する仮想サーバにバインドすることはできますが、その仮想サーバを稼動させることはできません。これを実行しようとすると、IOS SLB からエラー メッセージが発行されます。

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

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 ロード バランシングは、加重最小接続アルゴリズムをサポートします。

ASN ロード バランシング（Mobile Station 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 を使用すれば、1 台の物理サーバを複数の仮想サーバにバインドして、サーバごとに加重を報告させることができます。したがって、単一の実サーバは、自身の複数インスタンスとして表現され、それぞれに異なるバインド ID が割り当てられます。Dynamic Feedback Protocol（DFP; ダイナミック フィードバック プロトコル）は、バインド ID を使用して、特定の加重が指定された実サーバのインスタンスを識別します。DFP を使用している場合にのみ、バインド ID 機能を使用します。

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 アドレスが一意の場合に、IOS SLB ファイアウォール ロード バランシングでサポートされます。デバイスはユーザ パケットの IP アドレスを変更しません。選択したファイアウォールにパケットを送信するために、デバイスは使用するインターフェイスを決定し、それに従ってレイヤ 2 ヘッダーを変更します。この種類のルーティングは、IOS SLB が使用する標準の dispatched ルーティングです。

• レイヤ 2 ファイアウォール：IP アドレスがありません。IOS SLB ファイアウォール ロード バランシングに対して透過的です。IOS SLB は、レイヤ 2 ファイアウォールを IP アドレス指定可能インターフェイス間に配置することによってサポートします。

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

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

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

（注） IOS SLB ファイアウォール ロード バランシングでは、受信パケットを確認し、ルート検索を実行する必要があります。Cisco 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）用の GGSN を選択して、同じ IMSI から、選択された GGSN に、以降のすべての Packet Data Protocol（PDP）作成要求を転送することができます。

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

1. その IMSI で最初の GTP PDP 作成要求が処理されると、IOS SLB によってスティッキ データベース オブジェクトが作成されます。

2. また、実サーバから削除を示す通知を受信した場合、または非アクティブな状態の結果として、スティッキ オブジェクトが削除されます。

3. 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 』を参照してください。

インターフェイス認識

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

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

最大接続

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

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

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

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

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

ネットワーク アドレス変換

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

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

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

• 「dispatched モード」

• 「directed モード」

• 「サーバ NAT」

• 「クライアント NAT」

• 「スタティック NAT」

• 「サーバ ポート変換」

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

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

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

dispatched モード

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

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

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

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

directed モード

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

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

• 「サーバ NAT」

• 「クライアント NAT」

• 「スタティック NAT」

• 「サーバ ポート変換」

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

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

IOS SLB は、TCP 仮想サーバと UDP 仮想サーバに対して、クライアント NAT しかサポートしません。

IOS SLB は、Encapsulation Security Payload（ESP; 暗号ペイロード）仮想サーバまたは Generic Routing Encapsulation（GRE; 総称ルーティング カプセル化）仮想サーバに対して、サーバ 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 プローブを使用します。

（注） パケット単位サーバ ロード バランシングを使用したスタティック NAT では、フラグメント化されたパケットが負荷分散されません。

• 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 の場合にだけ、サーバ ポート変換をサポートします。

ポートバインド サーバ

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

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

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

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

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

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

スティッキ接続

オプションの sticky コマンドを使用すると、同じクライアントからの発信を、サーバ ファーム内の同じロード バランシング サーバに強制的に接続できます。

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

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

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

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

ファイアウォール ロード バランシングの場合、同じクライアント - サーバ ペア間の接続は、同じファイアウォールに割り当てられます。次の条件をすべて満たす場合、新しい接続はスティッキ接続と見なされます。

• 実サーバの状態は 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 セッションの再割り当て

IOS SLB は、クライアントが新しい接続を開こうとして実サーバに送信される各 TCP SYNchronize Sequence Number（SYN）を追跡します。複数の連続する 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 パケット（SYN）のレートを制限して、SYN フラッド サービス拒否攻撃と呼ばれるネットワーク上の問題を阻止します。ユーザが大量の SYN をサーバに送信することもあり、それによってサーバの過負荷やクラッシュが発生し、他のユーザへのサービスが停止する可能性があります。SynGuard によって、IOS SLB または実サーバを停止させる攻撃などを回避します。SynGuard は、仮想サーバによって管理される SYN 数を一定間隔でモニタして、その数が、設定された SYN しきい値を超えないようにします。しきい値に達すると、新しい SYN はドロップされます。

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

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

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

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

• 「自動アンフェイル」

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

• 「Dynamic Feedback Protocol（DFP）Agent Subsystem のサポート」

• 「Cisco IOS SLB 用の DFP」

• 「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 プールを使用する必要があります。

Dynamic Feedback Protocol（DFP）Agent Subsystem のサポート

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

DFP Agent Subsystem の詳細については、Cisco IOS Release 12.2(18)SXD の DFP Agent Subsystem 機能に関するマニュアルを参照してください。

Cisco IOS SLB 用の DFP

IOS SLB DFP がサポートされている場合は、ロード バランシング環境内の 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（サーバ ファームの仮想サーバ） コマンドに関する説明を参照してください。

プローブ

プローブは、サーバ ファーム内の実サーバごとまたはファイアウォール ファーム内のファイアウォールごとのステータスを決定します。Cisco 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 コマンドの説明を参照してください。

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

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

実サーバが 1 つのプローブで合格しなかった場合は、すべてのプローブで合格しません。実サーバが回復すると、サービスを復旧する前に、すべてのプローブがその回復を承認する必要があります。

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

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

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

あるプローブに対してファイアウォールが失敗すると、すべてのプローブに失敗したことになります。ファイアウォールが回復したら、すべてのプローブがその回復を認識するまで、プローブをサービスに戻すことができません。

パスワードの問題を回避するには、HTTP プローブがステータス コード 401 を想定するように設定されていることを確認します。詳細については、 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）

• Domain Name System（DNS; ドメイン ネーム システム）

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

• File Transfer Protocol（FTP; ファイル転送プロトコル）

• Generic Routing Encapsulation（GRE）

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

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

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

• Hypertext Transfer Protocol（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）

• RTSP 経由の RealAudio/RealVideo

• Remote Authentication Dial-In User Service（RADIUS）

• Simple Mail Transport Protocol（SMTP）

• Telnet

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

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

• X.25 over TCP（XOT）

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

– Connectionless Secure WSP

– Connectionless WSP

– Connection-Oriented Secure WSP

– Connection-Oriented WSP

AAA ロード バランシング

IOS SLB には、RADIUS の Authentication, Authorization, and Accounting（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 に基づいて、次の冗長性の強化をサポートします。

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

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

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

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

ステートレス バックアップは、1 台のレイヤ 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 は、Cisco Catalyst 6500 シリーズ スイッチおよび Cisco 7600 シリーズ ルータ用の mobile Service Exchange Framework（mSEF）に対して、Exchange Director をサポートします。Exchange Director には次の機能があります。

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

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

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

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

• 「GTP ロード バランシングに対するデュアルスタック サポート」

• 「Home Agent Director」

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

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

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

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

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

• 「フローの永続性」

ASN ロード バランシング

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

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

ASN ゲートウェイに対してスティッキ接続がイネーブルになっている場合は、IOS SLB が、加入者に関するロード バランシングを決定したら、同じ加入者からの以降の要求をすべて同じ Cisco BWG に転送します。スティッキ情報がスタンバイ IOS SLB に複製されます。

IOS SLB は、Mobile Station ID（MSID; モバイル ステーション ID）を使用して、MSS ごとに 1 つずつのスティッキ エントリを持つスティッキ データベースを生成します。このスティッキ データベースを使用すれば、IOS SLB で選択された実サーバの MSID に関する永続的セッション トラッキングを実行することができます。MSS から仮想 IP アドレスに送信された最初のパケットによって、セッション オブジェクトとスティッキ オブジェクトが作成されます。セッション ルックアップが失敗した場合は、MSS からの以降のパケットは MSID を使用してスティッキ データベース内の実サーバを検索します。スティッキ オブジェクトが存在するかぎり、特定の MSS に属しているすべてのパケットが同じ BWG に対して負荷分散されます。

スティッキ MSID エントリをバックアップ IOS SLB に複製することによって、冗長性がサポートされています。冗長性は、シャーシ内（ステートフル スイッチオーバー）環境とシャーシ間（HSRP）環境の両方で動作します。セッションは、スタンバイ IOS SLB に複製する必要はありません。

GPRS ロード バランシング

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 サポート ノード）は、GTP を使用して 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）、version 1（GTP v1）、および version 2（GTP v2）をサポートします。GTP のサポートによって、IOS SLB は、「GTP 認識」になり、レイヤ 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 コンテキストを把握できます。

GTP ロード バランシングに対するデュアルスタック サポート

IPv6 サポートによって、IOS SLB ですべてのバージョンの GTP（v0、v1、v2）に対する GTP ロード バランシング用の IPv6 アドレスを管理することができます。

デュアルスタック サポートを使用すれば、IOS SLB で GTP ロード バランシング用のデュアルスタック実装を管理することができます。デュアルスタック実装とは、IPv4 アドレスと IPv6 アドレスの両方を使用する実装です。

デュアルスタック サポートが GTP ロード バランシング用に設定されている場合は、次の留意点を考慮してください。

• 実サーバは、SLB サーバ ファーム コンフィギュレーション モードで real コマンドを使用して、IPv4 アドレスと IPv6 アドレスを持つデュアルスタック実サーバとして設定する必要があります。

• 仮想サーバは、SLB 仮想サーバ ファーム コンフィギュレーション モードで virtual コマンドを使用して、IPv4 アドレス、IPv6 アドレス、およびオプションの IPv6 プレフィクスを持つデュアルスタック仮想サーバとして設定する必要があります。

• プライマリ IPv6 サーバ ファームとオプションのバックアップ IPv6 サーバ ファームを指定するには、SLB 仮想サーバ コンフィギュレーション モードで serverfarm コマンドを使用します。

• SLB 仮想サーバ コンフィギュレーション モードの client コマンドはサポートされていません。

• ゲートウェイは、仮想サーバの IPv4 アドレスと IPv6 アドレスで設定する必要があります。

• IOS SLB とゲートウェイ間のインターフェイスは、デュアルスタック アドレスで設定する必要があります。

• クライアント側インターフェイスのすべての HSRP インスタンス（IPv4 と IPv6 の両方）を同じ HSRP ステートにする必要があります。

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 ロード バランシング アカウンティング ローカル確認応答：

– IOS SLB は 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 ペイロードを受信すると、次のアクションを実行します。

1. ペイロードを検査する。

2. framed-IP アトリビュートを抽出する。

3. ルート マップを IP アドレスに適用する。

4. 加入者を管理する 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 ロード バランシング

• 単純な IP アクセス コントロール リスト（ACL）をサポートし、ネクストホップ ペアのマッチングと設定を行います。

• RADIUS ロード バランシング マップおよび Turbo RADIUS ロード バランシング アカウンティング ローカル確認応答と相互排他的です。

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

WAP ロード バランシング

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

• Connectionless WSP モード（IP/UDP [9200]/WSP）。Connectionless WSP モードでは、WSP が、1 つのサーババインド パケットが 1 つまたは複数のパケットのサーバ応答になる単純な 1 要求/1 応答プロトコルになります。

• Connection-oriented WSP モード（IP/UDP [9201]/WTP/WSP）。Connection-oriented WSP モードでは、WTP が WDP イベントの再送信を管理し、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 プローブを使用します。

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

RPR+ を併用した場合、IOS SLB は Cisco Catalyst 6500 スイッチと Cisco 7600 ルータの 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. access interface

5. bindid [ bind-id ]

6. nat { client pool | server }

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

8. probe probe

9. real ipv4-address [ ipv6 ipv6-address ] [ port ]

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

11. maxclients number-of-conns

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

13. reassign threshold

14. retry retry-value

15. weight setting

16. inservice

手順の詳細

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

仮想サーバの設定方法

仮想サーバを設定するには、この必須作業を実行します。IOS SLB は最大 500 仮想サーバをサポートします。

手順の概要

1. enable

2. configure terminal

3. ip slb vserver virtual-server

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

または

virtual ipv4-add ress [ ipv4-netmask [ group ]] [ ipv6 ipv6-address [ prefix ipv6-prefix ]] { tcp | udp } [ port | any ] [ service service ]

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

6. access interface [ route framed-ip ]

7. advertise [ active ]

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

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

10. gtp notification cac [ reassign-count ]

11. gtp session

12. gw port port

13. hand-off radius duration

14. idle [ asn request duration | asn msid msid | gtp imsi duration [ query [max-queries]] | gtp request duration | ipmobile request duration | radius { request | framed-ip } duration ]

15. purge radius framed-ip acct on-off

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

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

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

19. radius inject auth timer seconds

20. radius inject auth vsa vendor-id

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

22. replicate interval interval

23. replicate slave

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

25. synguard syn-count interval

26. 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 SLB パケットが通常の IOS スイッチング パス（CEF、ファースト スイッチング、およびプロセス レベル スイッチング）上で管理されているときに発生します。

• 特殊なスイッチングは、IOS SLB パケットがハードウェア支援スイッチング パス上で管理されているときに発生します。

IOS SLB ネットワークおよび接続の確認に使用されるその他のコマンドについては、「Cisco IOS SLB 機能のモニタ方法と保守方法」を参照してください。

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

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

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

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

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. access [ source source-ip netmask | destination destination-ip netmask | inbound { inbound-interface | datagram connection } | outbound outbound-interface ]

10. predictor hash address [ port ]

11. purge connection

12. purge sticky

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

14. replicate interval interval

15. replicate slave

16. protocol tcp

17. delay duration

18. idle duration

19. maxconns maximum-number

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

21. protocol datagram

22. idle duration

23. maxconns maximum-number

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

25. 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 SLB パケットが通常の IOS スイッチング パス（CEF、ファースト スイッチング、およびプロセス レベル スイッチング）上で管理されているときに発生します。

• 特殊なスイッチングは、IOS SLB パケットがハードウェア支援スイッチング パス上で管理されているときに発生します。

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

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

IOS SLB ネットワークおよび接続の確認に使用されるその他のコマンドについては、「Cisco 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. 仮想サーバへのルートを設定します。

手順の詳細

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 プローブの設定方法

Wireless Session Protocol（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 の設定方法

IOS SLB を Dynamic Feedback Protocol（DFP）マネージャとして設定し、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 ]]]

5. IOS SLB を DFP エージェントとして設定します。

手順の詳細

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

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

手順の概要

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

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

3. サーバ内の各ゲートウェイ GPRS サポート ノード（GGSN）でループバックとして仮想 IP アドレスを設定します。

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

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

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

手順の詳細

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

GPRS Support Node（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 は Access Point Name（APN）に基づいてユーザ トラフィックを分類し、ルーティングできます。GPRS ロード バランシング マップをイネーブルにするには、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 ipv4-add ress [ ipv4-netmask [ group ]] [ ipv6 ipv6-address [ prefix ipv6-prefix ]] { tcp | udp } [ port | any ] [ service service ]

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

手順の詳細

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

手順の詳細