Cisco IOS IP アプリケーション サービス コンフィ ギュレーション ガイド リリース 15.1
サーバ ロード バランシングの設定
サーバ ロード バランシングの設定
発行日;2012/02/03 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

サーバ ロード バランシングの設定

機能情報の確認

この章の構成

IOSSLB に関する制約事項

IOSSLB に関する情報

IOSSLB の利点

一般的な IOSSLB 機能

ルーティング機能

セキュリティ機能

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

プロトコル サポート機能

冗長機能

Exchange Director 機能

IOSSLB の設定方法

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

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

仮想サーバの設定

仮想サーバの確認

サーバ ファームの確認

クライアントの確認

IOS SLB 接続の確認

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

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

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

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

プローブの設定

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

DNS プローブの設定

HTTP プローブの設定

ping プローブの設定

TCP プローブの設定

WSP プローブの設定

プローブの関連付け

プローブの確認

DFP の設定

この次の手順

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

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

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

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

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

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

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

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

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

前提条件

mSEF 用 Exchange Director の設定作業リスト

Exchange Director 用の RADIUS の設定

Exchange Director 用のファイアウォールの設定

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

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

Home Agent Director の設定作業リスト

NAT の設定

スタティック NAT の設定

ステートレス バックアップの設定作業リスト

ステートレス バックアップ設定の確認

冗長ルート プロセッサのステートフル バックアップの設定作業リスト

データベース エントリの設定

フラグメント データベースのバッファの設定

データベースおよびカウンタのクリア

ワイルドカード検索の設定

MLS エントリのプロトコルレベル消去の設定

接続の消去および再割り当て

自動サーバ障害検出のディセーブル化

IOS SLB のモニタおよびメンテナンス

IOSSLB の設定例

基本的な IOS SLB ネットワークの設定:例

サーバ ファームの設定

仮想サーバの設定

限定されたクライアントの設定

IOS SLB ネットワーク一式の設定:例

ファイアウォール ロード バランシングを使用する IOS SLB の設定:例

基本的なファイアウォール ロード バランシングを使用する IOS SLB の設定:例

サーバ ロード バランシングおよびファイアウォール ロード バランシングを使用する IOS SLB の設定:例

複数のファイアウォール ファームを使用する IOS SLB の設定:例

二重ファイアウォール ロード バランシング「サンドイッチ」を使用する IOS SLB の設定:例

プローブを使用する IOS SLB の設定:例

ping プローブおよび HTTP プローブを使用する IOS SLB の設定:例

ルーテッド プローブを使用する IOS SLB の設定:例

IOS SLB による レイヤ 3 スイッチングの設定:例

NAT およびスタティック NAT を使用する IOS SLB の設定:例

NAT を使用する IOS SLB の設定:例

スタティック NAT を使用する IOS SLB の設定:例

冗長性を使用する IOS SLB の設定:例

ステートレス バックアップを使用する IOS SLB の設定:例

ステートフル バックアップを使用する IOS SLB の設定:例

冗長ルート プロセッサのステートフル バックアップを使用する IOS SLB の設定:例

アクティブ スタンバイを使用する IOS SLB の設定:例

スタティック ルートの再配布を使用する IOS SLB の設定:例

Routing Information Protocol(RIP)

Open Shortest Path First(OSPF)

Interior Gateway Routing Protocol(IGRP)

Enhanced Interior Gateway Routing Protocol(Enhanced IGRP)

WAP および UDP ロード バランシングを使用する IOS SLB の設定:例

UDP ポート 9201 の WAP フローのロード バランシング

UDP ポート 9203 の WAP フローのロード バランシング

ルート ヘルス インジェクションを使用する IOS SLB の設定:例

1 つずつ Web サーバがある 2 つの分散サイトの設定:例

2 つずつ Web サーバがある 2 つの分散サイトの設定:例

それぞれ 1 つの Web サーバと 1 つのバックアップ IOS SLB スイッチがある 2 つの分散サイトの設定:例

GPRS ロード バランシングを使用する IOS SLB の設定:例

GTP Cause Code Inspection なしで GPRS ロード バランシングを使用する IOS SLB の設定: 例

GPRS ロード バランシングおよび NAT を使用する IOS SLB の設定:例

GPRS ロード バランシング、NAT、および GTP Cause Code Inspection を使用する IOS SLB の設定: Example

GPRS ロード バランシング マップを使用する IOS SLB の設定:例

VPN サーバ ロード バランシングを使用する IOS SLB の設定:例

RADIUS ロード バランシングを使用する IOS SLB の設定:例

GPRS ネットワークに RADIUS ロード バランシングを使用する IOS SLB の設定:例

簡易 IP CDMA2000 ネットワークに RADIUS ロード バランシングを使用する IOS SLB の設定:例

Mobile IP CDMA2000 ネットワークに RADIUS ロード バランシングを使用する IOS SLB の設定:例

複数のサービス ゲートウェイ ファームに RADIUS ロード バランシングを使用する IOS SLB の設定:例

RADIUS ロード バランシング/ファイアウォール ロード バランシングの「サンドイッチ」を使用する IOS SLB の設定:例

RADIUS ロード バランシング マップを使用する IOS SLB の設定:例

RADIUS ロード バランシング加速データ プレーン フォワーディングを使用する IOS SLB の設定:例

Home Agent Director を使用する IOS SLB の設定:例

スティッキ接続を使用する IOS SLB の設定:例

GTP IMSI スティッキ データベースを使用する IOS SLB の設定:例

透過的 Web キャッシュ ロード バランシングを使用する IOS SLB の設定:例

KAL-AP エージェントを使用する IOS SLB の設定:例

GSS

サイト 1:IOS SLB - CHICAGO

サイト 2:IOS SLB - NEWYORK

その他の参考資料

トラブルシューティング

関連資料

サポートされているプラットフォーム

規格

MIB

RFC

シスコのテクニカル サポート

IOSSLB の機能情報

サーバ ロード バランシングの設定

このマニュアルでは、IOS Server Load Balancing(IOS SLB)機能の設定方法について説明します。この章の IOS SLB コマンドの詳細な説明については、『 Cisco IOS IP Application Services Command Reference 』の「Server Load Balancing Commands」の章を参照してください。この章に記載されている他のコマンドのドキュメントを探すには、コマンド リファレンス マスター インデックスを使用するか、オンラインで検索してください。

SLB 機能は、IP サーバのロード バランシングを実現する Cisco IOS ベースのソリューションです。ネットワーク管理者は、IOS SLB 機能を使用して 仮想 サーバを定義します。仮想サーバとは、 サーバ ファーム と呼ばれるネットワーク サーバのクラスタ内にある サーバのグループです。この環境では、仮想サーバの IP アドレスにセット属性するようにクライアントを設定します。仮想サーバの IP アドレスは、各実サーバのループバック アドレスまたはセカンダリ IP アドレスとして設定されます。クライアントが仮想サーバへの接続を開始すると、設定されているロード バランシング アルゴリズムに基づいて、IOS SLB 機能によって接続の実サーバが設定されます。

IOS SLB 機能には、次のように、多様なネットワーク デバイスおよびサービスに適したロード バランシングが用意されています。

Hypertext Transfer Protocol(HTTP; ハイパーテキスト転送プロトコル)、Telnet、File Transfer Protocol(FTP; ファイル転送プロトコル)などのアプリケーション サーバ

ファイアウォール

Authentication, Authorization, and Accounting(AAA; 認証、認可、アカウンティング)、サーバ、Web キャッシュなどのサービス ノード

さらに、IOS SLB Exchange Director では、その他にも次のサービス ノードに適した高度なロード バランシング ルーティング機能を使用できます。

mobile Service Exchange Framework(mSEF)コンポーネント:

Cisco Content Services Gateway(CSG)

Supervisor Engine 32(SUP32-MSFC2A)とともに実行している場合、CSG リリース 3.1(3)C7(1) 以降が必要です。

Cisco Gateway GPRS サポート ノード(GGSN)

Cisco Service Selection Gateway(SSG)

Cisco Home Agent

モバイル、Public Wireless LAN(PWLAN; パブリック ワイヤレス LAN)、およびサービス プロバイダー ネットワーク用のその他のコンポーネント:

Wireless Application Protocol(WAP; ワイヤレス アプリケーション プロトコル)ゲートウェイ

プロトコル最適化ゲートウェイ

他社製 GGSN および Home Agent

他の RADIUS 対応フロー ゲートウェイ。これらのゲートウェイは、ゲートウェイを介してユーザに送信されるルートの RADIUS 認可要求およびアカウンティング要求を受信するプロキシまたはルーティング ノードです。Exchange Director は RADIUS およびデータ フローを同じゲートウェイにバインドし、ユーザのネットワーク アクティビティの完全で一貫したビューをゲートウェイが受信できるようにします。

また、Exchange Director には次の機能もあります。

Catalyst 6500 ファミリ スイッチおよび Cisco 7600 シリーズ ルータの mSEF 内の単一シャーシのフェールオーバー用に強化されたフェールオーバー機能。Route Processor Redundancy Plus(RPR+)とともに使用すると、冗長ルート プロセッサの IOS SLB ステートフル バックアップで、これらのプラットフォーム向けのフル IOS SLB ステートフル フェールオーバー機能が実現します。

フローが永続的になるため、負荷が分散された IP フローの高度なリターン ルーティングが実現します。

図 1 に、簡易 IOS SLB ネットワークの論理図を示します。

図 1 IOS SLB の論理図

 

機能情報の確認

ご使用のソフトウェア リリースでは、このモジュールで説明されるすべての機能がサポートされているとは限りません。最新の機能情報と注意事項については、ご使用のプラットフォームとソフトウェア リリースに対応したリリース ノートを参照してください。この章に記載されている機能の詳細、および各機能がサポートされているリリースのリストについては、「IOS SLB の機能情報」 を参照してください。

プラットフォーム サポートと Cisco IOS および Catalyst OS ソフトウェア イメージ サポートに関する情報を入手するには、Cisco Feature Navigator を使用します。Cisco Feature Navigator には、 http://www.cisco.com/go/cfn からアクセスします。Cisco.com のアカウントは必要ありません。

IOS SLB に関する制約事項

一般的な制約事項

同じローカルエリア ネットワーク(LAN)または virtual LAN(VLAN)上にあるクライアントと実サーバ間のフローのロード バランシングはサポートされません。同じインターフェイス上のロード バランシング デバイスには、ロード バランシング対象のパケットを入出力できません。

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

実サーバの IP アドレスを含むすべてのサーバ ファームが nat サーバ で設定されている場合を除き、実サーバの IP アドレスと同じサブネットにある IOS SLB の仮想 IP アドレスは設定しないでください。

スタンドアロン モードで動作します。また、現在、MultiNode Load Balancing(MNLB)Services Manager として動作していません。異なるサービス用であっても、同じ仮想 IP アドレスで設定されている IOS SLB および MNLB はサポートされません。IOS SLB を使用する場合でも、MNLB 環境で外部サービス マネージャ(LocalDirector など)による既存の MNLB フォワーディング エージェントを使用できます(MNLB は Cisco Application Services Architecture(CASA)とも呼ばれます)。

バックアップ機能用の複数の IOS SLB インスタンスに関するサーバのロード バランシング統計情報の調整はサポートされません。

FTP およびファイアウォール ロード バランシングは、dispatched モードでのみサポートされます。

Dynamic Host Configuration Protocol(DHCP)のロード バランシングはサポートされません。

Internet Protocol version 6(IPv6)はサポートされません。

dispatched モードで実行する場合、実サーバはレイヤ 2 隣接、タグスイッチ型、または GRE トンネル経由にする必要があります。

サーバ NAT を使用して directed モードで実行している場合、実サーバは IOS SLB に対してレイヤ 2 隣接にする必要はありません。この機能によって、IOS SLB スイッチとは別に複数のレイヤ 3 ホップをサーバに配置できるため、ネットワーク設計が柔軟になります。

マルチキャスト グループのメンバとして directed モードで実行されている場合、IOS SLB はマルチキャスト フローを受信できますが、マルチキャスト フローの送信はできません。dispatched モードで実行される場合、これは制限ではありません。

クライアント NAT およびサーバ ポート変換は、TCP および UDP の仮想サーバでのみサポートされます。

IOS インターフェイス IP アドレスの 1 つと同じ仮想 IP アドレスに対するバランシング ストリームの場合(ループバック、イーサネットなど)、IOS SLB は、そのアドレスに対するすべての UDP パケットをトレースルート パケットとして扱い、「ホスト到達不能」の ICMP パケットで応答します。この問題は、IOS が対象 UDP ポートをリスンしている場合でも発生します。この問題を回避するには、仮想サーバをホスト(address/32)ではなくネットワーク(address/31)として設定します。

IOS SLB 仮想サーバで設定した仮想 IP アドレスは、SNMP などの UDP ベースのルータ管理アプリケーションに使用しないでください。使用すると、CPU の使用率が高くなる可能性があります(これは、宛先ポート番号 0 で設定した UDP 仮想サーバの問題ではありません)。

DFP エージェントには 3 秒以上の hello メッセージが必要です。そのため、DFP マネージャがタイムアウトを指定した場合、3 秒以上のタイムアウトを設定する必要があります。

Catalyst 6500 ファミリ スイッチで IOS SLB および Web Cache Communication Protocol(WCCP)の両方を 設定し、IOS SLB を使用して WCCP Input Redirection を設定している場合、ルータとキャッシュ間にレイヤ 2 WCCP のフォワーディングを使用する必要があります。この場合、WCCP および IOS SLB の両方がハードウェアで実行され、適切な順で処理されます。Generic Routing Encapsulation(GRE)フォワーディングを使用する場合、IOS SLB は WCCP よりも優先されます。また、MSFC で GRE フォワーディングが実行されるため、リダイレクトはありません。WCCP フォワーディング方式(レイヤ 2 または GRE)は、スイッチではなくキャッシュ エンジンで設定します。

IOS SLB と Cisco Service Selection Gateway(SSG)は、同じデバイスに設定しないでください。

フローが 2 つの IOS SLB インスタンス(仮想サーバまたはファイアウォール ファーム)を介して送信される「サンドイッチ」設定の場合、その IOS SLB インスタンスは、異なる Virtual Private Network(VPN; バーチャル プライベート ネットワーク)Routing and Forwarding(VRF)に存在する必要があります。

サーバ ファーム、仮想サーバ、またはファイアウォール ファームのコンフィギュレーション モードで access コマンドを使用してアクセス インターフェイスを設定しない場合、VRF インターフェイスなど、デバイスのすべての使用可能なインターフェイスのサーバ ファーム、仮想サーバ、またはファイアウォール ファームについて、ワイルドカードがインストールされます。IOS SLB が VRF インターフェイスで必要ない場合、 access コマンドを使用して、指定したインターフェイスにのみワイルドカードを制限します。

スタティック NAT

クライアント NAT サーバ ファームと併用できません。つまり、実サーバがサーバ NAT に特定の仮想 IP アドレスを使用しており、サーバ ファームをその同じ仮想 IP アドレスに関連付けている場合、クライアント NAT を使用するようにサーバ ファームを設定することはできません。

各実サーバは 1 つの仮想サーバにのみ関連付ける必要があります。これは、IOS SLB が接続を適切に作成するためです。

0 ポートの仮想サーバが必要です。

仮想サービス FTP はサポートされません。

バックアップ サーバ ファームのサポート

プライマリ サーバ ファームとバックアップ サーバ ファームの両方に同じ実サーバを定義する方法はサポートされません。

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

HTTP リダイレクト ロード バランシングはサポートされません。プライマリ サーバ ファームでリダイレクト仮想サーバを指定している場合、そのプライマリをバックアップとして定義できません。また、そのプライマリ用のバックアップを定義できません。

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

各ロード バランシング デバイスで、単一のファイアウォール ファームに制限されなくなりました。

各ファイアウォールは固有の MAC アドレスを持つ必要があります。また、各デバイスに対してレイヤ 2 隣接にする必要があります。ファイアウォールはデバイス上の個々のインターフェイスに接続できます。または、すべてのデバイスで VLAN を共有し、単一のインターフェイスを使用して接続できます。

各ファイアウォール ロード バランシング デバイスと各ファイアウォール間には、イーサネットが必要です。

各ファイアウォール ロード バランシング デバイスでは、各レイヤ 2 ファイアウォールを単一のレイヤ 3(IP)インターフェイスに接続する必要があります。

設定したファイアウォールの IP アドレスと同じサブネット上にある宛先 IP アドレスを使用するフローの負荷は分散されません(たとえば、ファイアウォール コンソール セッションのフローや、ファイアウォール LAN 上のその他のフローです)。

次の IOS SLB 機能はサポートされません。

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

ポートバインド サーバ

SynGuard

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

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

GTP Cause Code Inspection をイネーブルに しない GPRS ロード バランシング

複数のサーバ ファームに 1 つの実サーバが定義されている場合、各サーバ ファームは異なる仮想サーバに関連付ける必要があります。

dispatched または directed サーバ NAT モードでだけ動作します。

スティッキ接続がイネーブルの場合にだけ、ステートフル バックアップがサポートされます。

ネットワークから送信された PDP コンテキスト要求の負荷は分散されません。

次の IOS SLB 機能はサポートされません。

バインド ID

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

スロー スタート

加重最小接続ロード バランシング アルゴリズム

GTP Cause Code Inspection をイネーブルに した GPRS ロード バランシング

複数のサーバ ファームに 1 つの実サーバが定義されている場合、各サーバ ファームは異なる仮想サーバに関連付ける必要があります。

directed サーバ NAT モードでだけ動作します。

ネットワークから送信された PDP コンテキスト要求の負荷は分散できません。

受信シグナリングおよび発信シグナリングは IOS SLB を介して送信される必要があります。

SGSN または GGSN からピアにエコーを送信する必要があります。

次の IOS SLB 機能はサポートされません。

バインド ID

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

スロー スタート

GPRS トンネリング プロトコル v2(GTP v2)

次の機能はサポートされません。

クライアント NAT

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

Internet Control Message Protocol(ICMP; インターネット制御メッセージ プロトコル)およびワイルドカード(0-protocol)仮想サーバはサポートされません。

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

ルート マップ アルゴリズムが必要です。

最適な結果を得るには、冗長 CSG が必要です。

加入者のアドレスの範囲による負荷分散のスタティック プロビジョニングが必要です。

簡易な IP Access Control List(ACL; アクセス コントロール リスト)だけがサポートされます。

VSA 関連付けを使用する場合、IOS SLB は関連付け情報をアクティブな RADIUS ロード バランシング デバイスにだけ維持します。バックアップ RADIUS ロード バランシング デバイスには維持しません。バックアップ RADIUS ロード バランシング デバイスは、アクティブな RADIUS ロード バランシング デバイスから VSA 関連付け情報を受信しません。

すべての Accounting-Request メッセージおよび Access-Accept メッセージには、RADIUS 割り当ての Framed-ip-address アトリビュートを含める必要があります。また、各加入者フローの発信元 IP アドレスは、Access-Accept メッセージの Framed-ip-address アトリビュートの値と一致する必要があります。

RADIUS アカウンティングを RADIUS クライアント(一般的に Network Access Server(NAS))でイネーブルにする必要があります。

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

VSA 関連付け

VSA 関連付けの結果、パフォーマンスが低下することがあります。

IOS SLB は関連付け情報をアクティブな RADIUS ロード バランシング デバイスにだけ維持します。バックアップ RADIUS ロード バランシング デバイスには維持しません。バックアップ RADIUS ロード バランシング デバイスは、アクティブな RADIUS ロード バランシング デバイスから VSA 関連付け情報を受信しません。

Cisco VSA は RADIUS Accounting-Start パケットに注入されます。Cisco VSA は、その他の RADIUS メッセージまたはパケット(interim RADIUS Accounting ON または OFF メッセージや、RADIUS Accounting-Stop パケットなど)には注入されません。

radius inject acct コマンドおよび radius inject auth コマンドは、同じ仮想サーバに設定できません。

GPRS 用の RADIUS ロード バランシング

加重ラウンド ロビン アルゴリズムが必要です。

フラグメント化された RADIUS パケットはサポートされません。

すべての Accounting-Request メッセージおよび Access-Accept メッセージには、RADIUS 割り当ての Framed-ip-address アトリビュートを含める必要があります。また、各加入者フローの発信元 IP アドレスは、Access-Accept メッセージの Framed-ip-address アトリビュートの値と一致する必要があります。

RADIUS アカウンティングを RADIUS クライアント(一般的に Network Access Server(NAS))でイネーブルにする必要があります。

CDMA2000 用の RADIUS ロード バランシング

加重ラウンド ロビン アルゴリズムが必要です。

フラグメント化された RADIUS パケットはサポートされません。

モバイル ネットワークのすべての加入者には、モバイル ワイヤレス ネットワーク内でルーティング可能な、固有の IP アドレスを割り当てる必要があります(つまり、重複する IP アドレスがない状態)。

各 User-Name アトリビュートは単一の加入者、または最大限でも非常に少数の加入者に対応付ける必要があります。そうしないと、予定外に大きな負荷が単一の SSG にかかる可能性があります。

簡易 IP ネットワークの場合、さらに次の制約事項が適用されます。

PDSN は、すべての RADIUS Access-Request パケットおよび Accounting-Start パケットに User-Name アトリビュートを含める必要があります。各加入者の User-Name アトリビュート値は、すべてのパケットで同じにする必要があります(ただし、MSID ベースのアクセスを提供する Cisco PDSN は除きます)。

PDSN は、すべての RADIUS Accounting-Start パケットおよび Accounting-Stop パケットに Framed-ip-address アトリビュートおよび NAS-ip-address を含める必要があります。Framed-ip-address アトリビュートの値は、SSG サービスの RADIUS ロード バランシングによってルーティングされる加入者データ パケットの発信元 IP アドレスと同じにする必要があります。

PDSN は、すべての Accounting-Requests に NAS-ip-address を含める必要があります。BSC/PCF ハンドオフの場合、Accounting-Stop には、 1 の値を指定した 3GPP2-Session-Continue VSA を含めることで、加入者の RADIUS ロード バランシング スティッキ接続 データベース オブジェクトの破壊を回避します。

Mobile IP ネットワークの場合、さらに次の制約事項が適用されます。

その加入者セッションについて、PDSN および HA は、User-Name アトリビュートを指定した RADIUS Access-Request パケットおよび Accounting-Start パケットを送信する必要があります。すべての PDSN パケットおよび HA RADIUS パケットの User-Name アトリビュート値は、そのセッションで同じにする必要があります。

その加入者セッションについて、PDSN および HA は、SSG サービス用の RADIUS ロード バランシングによってルーティングされる加入者データ パケットの発信元 IP アドレスと同じ Framed-ip-address アトリビュートを指定した RADIUS Accounting-Request パケットを送信する必要があります。PDSN および HA から送信されるすべての RADIUS Accounting-Requests には、NAS-ip-address アトリビュートも含める必要があります。

PDSN は、すべての Accounting-Requests に 3GPP2-Correlation-Identifier アトリビュートを含める必要があります。

Home Agent Director

ロード バランシングのために、Registration Request(RRQ)には Network Access Identifier(NAI)を含める必要があります。

ロード バランシングのために、RRQ には 0.0.0.0 または 255.255.255.255 というホーム エージェントの IP アドレスを含める必要があります。

ファースト スイッチングのために、パケットに含まれる RRQ の NAI は 96 バイト長を超えることはできません。NAI が 96 バイトを超える場合、IOS SLB はプロセス レベルでパケットを処理します。

dispatched または directed サーバ NAT モードでだけ動作します。

次の IOS SLB 機能はサポートされません。

バインド ID

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

スロー スタート

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

スティッキ接続

加重最小接続ロード バランシング アルゴリズム

HTTP プローブ

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

UDP プローブ

UDP プローブは、フラグメント化された Response パケットをサポートしません。

UDP プローブは、プローブ パケットに特定の発信元ポート値を必要とするホストをサポートしません。UDP プローブによって、各プローブ用に一時的なポートが選択されます。

ペイロードから生成された Message Digest Algorithm Version 5(MD5)チェックサムがあるプロトコルおよびアプリケーションは、適切なチェックサムを取得するために、「スニファ」によってキャプチャする必要があります。

Cisco IOS Multiprotocol Label Switching(MPLS)の場合:

Supervisor Engine 720 環境の場合、クライアントは MPLS クラウド経由で IOS SLB に接続できます。

MPLS クライアント インターフェイスは、トンネル エンジニアリングを使用して設定する必要があります。その他の MPLS 設定はサポートされません。

MPLS クライアント インターフェイスは、IP パケットとしてパケットを受信する必要があります。

MPLS クライアント インターフェイスは、Penultimate Hop Popping(PHP)ルータの背後に配置する必要があります。

Catalyst 6500 ファミリ スイッチおよび Cisco 7600 シリーズ ルータの場合:

Native IOS だけがサポートされます(c6sup イメージ)。Native IOS には、MSFC および Policy Feature Card(PFC; ポリシー フィーチャ カード)が必要です。同じ Catalyst 6500 ファミリ スイッチで冗長 MSFC を実行する場合、2 つの MSFC 間のステートフル バックアップはサポートされませんが、2 つの MSFC 間のステートレス バックアップはサポートされます。

「MSFC」という用語は、特に区別している場合を除き、MSFC1、MSFC2、または MSFC3 を指します。

「PFC」という用語は、特に区別している場合を除き、PFC1、PFC2、または PFC3 を指します。

Multilayer Switching(MLS; マルチレイヤ スイッチング)フロー モードは、フルフロー モードまたはインターフェイス フルフロー モードで動作する必要があります。IOS SLB は、固有に使用するフロー モードを自動的に設定します。MLS フローの設定方法の詳細については、『 Catalyst 6000 Family IOS Software Configuration Guide 』を参照してください。

dispatched モードで実行する場合、実サーバは、PFC によって実行されるハードウェア データ パケットのアクセラレーションを使用して、IOS SLB に対してレイヤ 2 隣接にする必要があります(つまり、追加のルータを超えません)。同じサーバ ファーム内のすべての実サーバは、同じ VLAN 上にある必要があります。実サーバでループバック アドレスを設定する必要があります。

ファイアウォール ファームのすべての実サーバは同じ VLAN 上にある必要があります。異なるファイアウォール ファームにある実サーバは、異なる VLAN に配置できます。

directed モードには、ハードウェア データ パケット アクセラレーション機能がありません(ハードウェア データ パケット アクセラレーションは、PFC によって実行され、directed モードではパケットは PFC ではなく MSFC によって処理されます)。

Supervisor Engine 2 の場合、ファイアウォール ロード バランシングを必要とする「サンドイッチ」設定はサポートされません。このような設定には VRF が必要であり、VRF は Supervisor Engine 2 でサポートされないためです。

Access Service Network(ASN)R6 ロード バランシング

dispatched または directed サーバ NAT モードでだけ動作します。directed モードの場合、IOS SLB は、Mobile Station(MS)Pre-Attachment 要求の宛先 IP アドレスを、選択した ASN ゲートウェイの実サーバの IP アドレスに変更します。

DFP が必要です。

次の機能はサポートされません。

クライアント NAT

加重最小接続アルゴリズム(MS Pre-Attachment 要求用)

IOS SLB をバイパスして、MS Pre-Attachment ACK パケットを ASN ゲートウェイに直接送信するようにベース ステーションを設定する場合、実サーバを停止することなくセッションがタイムアウトできるようにする必要があります。そのために、 no faildetect inband コマンドの実サーバ コンフィギュレーション モードを設定します。

IOS SLB に関する情報

IOS SLB を設定するには、次の概念を理解する必要があります。

「IOS SLB の利点」

「一般的な IOS SLB 機能」:ここでは、IOS SLB の一般的な機能について説明します。

「Exchange Director 機能」:ここでは、mobile Service Exchange Framework(mSEF)用の Exchange Director が提供する独自の機能について説明します。


) 一部の IOS SLB 機能は単一プラットフォームに固有であり、機能に関するドキュメントには記載されていません。このような機能については、該当するプラットフォームのドキュメントを参照してください。


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 には次のルーティング機能があります。

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

「バインディング 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 キャッシュ ロード バランシングをサポートしません。

代替 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 は、実サーバに対して失敗した各 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 で実行されるアクションの一覧です。

 

表 1 PDP 作成応答の原因コードと対応する IOS SLB のアクション

原因コード
IOS SLB のアクション

Request Accepted

セッションを確立します

No Resource Available

現在の実サーバを無効と見なし、セッションを再割り当てし、応答をドロップします

All dynamic addresses are occupied

現在の実サーバを無効と見なし、セッションを再割り当てし、応答をドロップします

No memory is available

現在の実サーバを無効と見なし、セッションを再割り当てし、応答をドロップします

System Failure

現在の実サーバを無効と見なし、セッションを再割り当てし、応答をドロップします

Missing or Unknown APN

応答を転送します

Unknown PDP Address or PDP type

応答を転送します

User Authentication Failed

応答を転送します

Semantic error in TFT operation

応答を転送します

Syntactic error in TFT operation

応答を転送します

Semantic error in packet filter

応答を転送します

Syntactic error in packet filter

応答を転送します

Mandatory IE incorrect

応答を転送します

Mandatory IE missing

応答を転送します

Optional IE incorrect

応答を転送します

Invalid message format

応答を転送します

Version not supported

応答を転送します

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 コマンドの詳細な説明については、『 Cisco IOS IP Application Services Command Reference 』の「Server Load Balancing Commands」の章を参照してください。この項に記載されている他のコマンドのドキュメントについては、Cisco.com でオンライン検索してください。

IOS SLB を設定するには、次の項の作業を実行します。

「必須および任意の IOS SLB 機能の設定」(必須)

「ファイアウォール ロード バランシングの設定」(任意)

「プローブの設定」(任意)

「DFP の設定」(任意)

「GPRS ロード バランシングの設定作業リスト」(任意)

「GGSN-IOS SLB のメッセージング作業リスト」(任意)

「GPRS ロード バランシング マップの設定」(任意)

「KeepAlive Application Protocol(KAL-AP)エージェントのサポートの設定」(任意)

「RADIUS ロード バランシングの設定作業リスト」(任意)

「mSEF 用 Exchange Director の設定作業リスト」(任意)

「VPN サーバ ロード バランシングの設定作業リスト」(任意)

「ASN R6 ロード バランシングの設定作業リスト」(任意)

「Home Agent Director の設定作業リスト」(任意)

「NAT の設定」(任意)

「スタティック NAT の設定」(任意)

「ステートレス バックアップの設定作業リスト」(任意)

「冗長ルート プロセッサのステートフル バックアップの設定作業リスト」(任意)

「データベース エントリの設定」(任意)

「フラグメント データベースのバッファの設定」(任意)

「データベースおよびカウンタのクリア」(任意)

「ワイルドカード検索の設定」(任意)

「接続の消去および再割り当て」(任意)

「自動サーバ障害検出のディセーブル化」(任意)

「IOS SLB のモニタおよびメンテナンス」(任意)

必須および任意の 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

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb serverfarm server-farm
 
Router(config)# ip slb serverfarm PUBLIC

サーバ ファームの定義を IOS SLB ロード バランシング(IOS SLB)設定に追加し、サーバ ファーム コンフィギュレーション モードを開始します。

ステップ 4

bindid [ bind-id ]

 
Router(config-slb-sfarm)# bindid 309

(任意)Dynamic Feedback Protocol(DFP)に使用されるサーバ ファームのバインド ID を指定します。

(注) GPRS ロード バランシングおよび Home Agent Director は、このコマンドをサポートしません。

ステップ 5

nat { client pool | server }

 
Router(config-slb-sfarm)# nat server

(任意)サーバ ファームで、ネットワーク アドレス変換(NAT)クライアントの変換モードまたは NAT サーバ アドレス変換モードを設定します。

ステップ 6

predictor [ roundrobin | leastconns | route-map mapname ]

 
Router(config-slb-sfarm)# predictor leastconns

(任意)実サーバを選択する方法を決定するために使用するアルゴリズムを指定します。

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

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

「加重ラウンド ロビン」

「加重最小接続」

「ルート マップ」

ステップ 7

probe probe

 
Router(config-slb-sfarm)# probe PROBE1

(任意)プローブを実サーバに関連付けます。

ステップ 8

real ip-address [ port ]

 

Router(config-slb-sfarm)# real 10.1.1.1

サーバ ファームのメンバとして、実サーバを IP アドレスとオプションのポート番号で指定し、実サーバ コンフィギュレーション モードを開始します。

Home Agent Director の場合、ホーム エージェントとして動作する実サーバの IP アドレスを指定します。

ステップ 9

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

Router(config-slb-real)# faildetect numconns 10 numclients 3

(任意)連続する接続エラーの回数、およびオプションで特定クライアントの接続エラーの回数を指定します。この回数を超えると、実サーバの障害と見なされます。

GPRS ロード バランシングの場合、環境に 1 つの SGSN しかない場合、値 1 の numclients キーワードを指定します。

RADIUS ロード バランシングの場合、自動的なセッションベースの障害検出のために、値 1 の numclients キーワードを指定します。

ステップ 10

maxclients number-of-conns

 

Router(config-slb-real)# maxclients 10

(任意)個々の仮想サーバに割り当てることができる、IOS Server Load Balancing(IOS SLB)および GTP スティッキ加入者の最大数を指定します。

ステップ 11

maxconns number-of-conns [ sticky-override ]
 
Router(config-slb-real)# maxconns 1000

(任意)実サーバで同時に使用できるアクティブな接続の最大数を指定します。

ステップ 12

reassign threshold
 
Router(config-slb-real)# reassign 2

(任意)連続して ACK が受信されない SYNchronize Sequence Number(SYN)要求または Create Packet Data Protocol(PDP)要求のしきい値を指定します。しきい値を超えると、別の実サーバに接続が試行されます。

(注) GPRS ロード バランシングの場合、SGSN の N3-REQUESTS カウンタ値未満の reassign threshold を指定する必要があります。

ステップ 13

retry retry-value

 
Router(config-slb-real)# retry 120

(任意)サーバの障害を検出してから、その障害が発生したサーバへの接続を再試行するまでの間隔(秒)を指定します。

ステップ 14

weight setting
 
Router(config-slb-real)# weight 24

(任意)実サーバの作業負荷容量を指定します。サーバ ファーム内の他のサーバと相対的な値です。

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

ステップ 15

inservice

 
Router(config-slb-real)# inservice

IOS Server Load Balancing(IOS SLB)が使用する実サーバをイネーブルにします。


) サーバ ロード バランシングおよびファイアウォール ロード バランシングの両方を 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

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb vserver virtual-server
 

Router(config)# ip slb vserver PUBLIC_HTTP

仮想サーバを指定し、仮想サーバ コンフィギュレーション モードを開始します。

ステップ 4

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

または

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

Router(config-slb-vserver)# virtual 10.0.0.1 tcp www

仮想サーバの IP アドレス、接続の種類、およびオプションの TCP またはユーザ データグラム プロトコル(UDP)のポート番号を指定し、Internet Key Exchange(IKE; インターネット キー エクスチェンジ)または Wireless Session Protocol(WSP)の設定、およびサービスのカップリングを指定します。

キーワード オプションを指定します。

キーワード オプションを指定します。

(注) GPRS ロード バランシングの場合:

仮想 GGSN IP アドレスを仮想サーバとして指定し、 udp キーワード オプションを指定します。

GTP v1 および GTP v2 セッションの負荷を分散するには、GGSN および SGSN が ETSI 標準に準拠している場合、ポート番号 2123 を指定します。また、全ポート仮想サーバ(つまり、すべてのポート宛てのフローを受け入れる仮想サーバ)を設定するには、ポート番号 0 または any を指定します。

GTP v0 セッションの負荷を分散するには、GGSN および SGSN が ETSI 標準に準拠している場合、ポート番号 3386 を指定します。また、全ポート仮想サーバを設定するには、ポート番号 0 または any を指定します。

GTP Cause Code Inspection なし の GPRS ロード バランシングをイネーブルにするには、 service gtp キーワード オプションを指定します。

GTP Cause Code Inspection あり の GPRS ロード バランシングをイネーブルにするには、 service gtp-inspect キーワード オプションを指定します。

ステップ 5

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

 
Router(config-slb-vserver)# serverfarm SF1 backup SF2 map 1 priority 1

実サーバ ファームを仮想サーバに関連付け、オプションで、バックアップ サーバ ファームを設定し、バックアップ サーバ ファームでスティッキ接続を使用することを指定します。

コマンドを設定し、それぞれに固有のマップ ID と固有のプライオリティを指定します(つまり、各マップ ID および各マップ プライオリティは、仮想サーバに関連付けられているすべてのサーバ ファームで固有にする必要があります)。

ステップ 6

access interface [ route framed-ip ]

 
Router(config-slb-vserver)# access Vlan20 route framed-ip

(任意)入力インターフェイスを検査するには、framed-IP ルーティングをイネーブルにします。

ステップ 7

advertise [ active ]
 
Router(config-slb-vserver)# advertise

(任意)仮想サーバ アドレスの Null0 インターフェイスに対するスタティック ルートのインストールを制御します。

ステップ 8

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

 
Router(config-slb-vserver)# client 10.4.4.0 255.255.255.0

(任意)仮想サーバの使用を許可するクライアントを指定します。

オプションだけをサポートします。

ステップ 9

delay { duration | radius framed-ip duration }

 
Router(config-slb-vserver)# delay 30

(任意)接続の終了後、IOS Server Load Balancing(IOS SLB)が TCP 接続コンテキストを維持する時間を指定します。

ステップ 10

gtp notification cac [ reassign-count ]

 
Router(config-slb-vserver)# gtp notification cac 5

(任意)IOS SLB が GGSN-IOS SLB メッセージングのために新しい実サーバにセッションを割り当てることができる回数を制限します。

ステップ 11

hand-off radius duration

 
Router(config-slb-vserver)# hand-off radius 30

(任意)外部エージェントのハンドオフ時に、IOS Server Load Balancing(IOS SLB)が新しい Mobile IP 外部エージェントからの ACCT-START メッセージを待機する時間を変更します。

ステップ 12

idle [ asn r6 request | gtp request | ipmobile request | radius { request | framed-ip }] duration
 
Router(config-slb-vserver)# idle 120

(任意)パケット アクティビティがない場合、IOS Server Load Balancing(IOS SLB)が接続コンテキストを維持する最短時間を指定します。

GPRS ロード バランシングの場合、SGSN 上の PDP コンテキスト要求間で可能な最も長い間隔よりも、長いアイドル タイマーを指定します。

ステップ 13

purge radius framed-ip acct on-off

 
Router(config-slb-vserver)# purge radius framed-ip acct on-off

(任意)Accounting ON または OFF メッセージの受信時に、IOS SLB が IOS SLB RADIUS framed-ip スティッキ データベースのエントリを消去できるようにします。

ステップ 14

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

 
Router(config-slb-vserver)# purge radius framed-ip acct stop 44

(任意)Accounting-Stop メッセージの受信時に、IOS SLB が IOS SLB RADIUS framed-ip スティッキ データベースのエントリを消去できるようにします。

ステップ 15

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

 
Router(config-slb-vserver)# radius acct local-ack key SECRET_PASSWORD

(任意)RADIUS 仮想サーバが RADIUS アカウンティング メッセージを承認できるようにします。

ステップ 16

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

 
Router(config-slb-vserver)# radius inject auth 1 calling-station-id

(任意)RADIUS ロード バランシング加速データ プレーン フォワーディングの認証仮想サーバについて、ベンダー固有アトリビュート(VSA)関連付けグループを設定します。また、RADIUS 発信ステーション ID または RADIUS ユーザ名に基づいて、IOS SLB で VSA 関連付けエントリを作成するかどうかを指定します。

ステップ 17

radius inject auth timer seconds
 
Router(config-slb-vserver)# radius inject auth timer 45

(任意)IOS SLB RADIUS ロード バランシング加速データ プレーン フォワーディングの認証仮想サーバについて、ベンダー固有アトリビュート(VSA)関連付けのタイマーを設定します。

ステップ 18

radius inject auth vsa vendor-id

 
Router(config-slb-vserver)# radius inject auth vsa vendor1

(任意)IOS SLB RADIUS ロード バランシング加速データ プレーン フォワーディングの認証仮想サーバについて、ベンダー固有アトリビュート(VSA)関連付けの VSA をバッファリングします。

ステップ 19

replicate casa listen-ip remote-ip port [interval] [password [encrypt] secret-string timeout]
 
Router(config-slb-vserver)# replicate casa 10.10.10.11 10.10.11.12 4231

(任意)バックアップ スイッチに対する IOS Server Load Balancing(IOS SLB)の判定テーブルのステートフル バックアップを設定します。

コマンドはサポートされません(セッションは永続的ではなく、レプリケートする対象がないためです)。

ステップ 20

replicate interval interval
 
Router(config-slb-vserver)# replicate interval 20

(任意)IOS Server Load Balancing(IOS SLB)仮想サーバのレプリケーション配信間隔を設定します。

コマンドはサポートされません(セッションは永続的ではなく、レプリケートする対象がないためです)。

ステップ 21

replicate slave

 
Router(config-slb-vserver)# replicate slave

(任意)IOS Server Load Balancing(IOS SLB)仮想サーバの冗長ルート プロセッサのステートフル バックアップをイネーブルにします。

を設定した単一の Supervisor を使用する場合、Supervisor で out-of-sync メッセージを受信することがあります。

ステップ 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 ]}

 
Router(config-slb-vserver)# sticky 60 group 10

(任意)クライアント接続の間隔が指定した期間を超えない限り、同じクライアントからの接続が同じ実サーバを使用するように指定します。

GPRS ロード バランシングおよび Home Agent Director はこのコマンドをサポートしません。

ステップ 23

synguard syn-count interval

 
Router(config-slb-vserver)# synguard 50

(任意)SYN フラッド サービス拒絶攻撃を回避するために、仮想サーバが処理する TCP SYNchronize Sequence Number(SYN)を指定します。

(注) GPRS ロード バランシングおよび Home Agent Director は、このコマンドをサポートしません。

ステップ 24

inservice [ standby group-name ] [ active ]

 
Router(config-slb-vserver)# inservice

IOS Server Load Balancing(IOS SLB)が使用する仮想サーバをイネーブルにします。

仮想サーバの確認

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

手順の概要

1. show ip slb vservers

手順の詳細

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

Router# show ip slb vservers
 
slb vserver prot virtual state conns
-------------------------------------------------------------------
PUBLIC_HTTP TCP 10.0.0.1:80 OPERATIONAL 0
RESTRICTED_HTTP TCP 10.0.0.2:80 OPERATIONAL 0
Router#

サーバ ファームの確認

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

手順の概要

1. show ip slb reals

2. show ip slb serverfarm

手順の詳細

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

Router# show ip slb real
 
real farm name weight state conns
---------------------------------------------------------------------
10.1.1.1 PUBLIC 8 OPERATIONAL 0
10.1.1.2 PUBLIC 8 OPERATIONAL 0
10.1.1.3 PUBLIC 8 OPERATIONAL 0
10.1.1.20 RESTRICTED 8 OPERATIONAL 0
10.1.1.21 RESTRICTED 8 OPERATIONAL 0
Router#
 

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

Router# show ip slb serverfarm
 
server farm predictor nat reals bind id
---------------------------------------------------
PUBLIC ROUNDROBIN none 3 0
RESTRICTED ROUNDROBIN none 2 0
Router#

クライアントの確認

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

手順の概要

1. show ip slb conns

手順の詳細

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

Router# show ip slb conns
 
vserver prot client real state nat
-------------------------------------------------------------------------------
RESTRICTED_HTTP TCP 10.4.4.0:80 10.1.1.20 CLOSING none
Router#
 

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

Router# show ip slb conns client 10.4.4.0 detail
VSTEST_UDP, client = 10.4.4.0:80
state = CLOSING, real = 10.1.1.20, nat = none
v_ip = 10.0.0.2:80, TCP, service = NONE
client_syns = 0, sticky = FALSE, flows attached = 0
Router#

IOS SLB 接続の確認

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

手順の概要

1. show ip slb stats

手順の詳細

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

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

Router# show ip slb stats
 
Pkts via normal switching: 0
Pkts via special switching: 6
Pkts dropped: 0
Connections Created: 1
Connections Established: 1
Connections Destroyed: 0
Connections Reassigned: 0
Zombie Count: 0
Connections Reused: 0
 

通常のスイッチングは、通常の 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

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb firewallfarm firewall-farm

 
Router(config)# ip slb firewallfarm FIRE1

ファイアウォール ファームの定義を IOS SLB ロード バランシング(IOS SLB)設定に追加し、ファイアウォール ファーム コンフィギュレーション モードを開始します。

ステップ 4

real ip-address

 
Router(config-slb-fw)# real 10.1.1.1

ファイアウォール ファームのメンバとして、ファイアウォールを IP アドレスで指定し、実サーバ コンフィギュレーション モードを開始します。

ステップ 5

probe probe

 
Router(config-slb-fw-real)# probe FireProbe

プローブをファイアウォールに関連付けます。

ステップ 6

weight setting

 
Router(config-slb-fw-real)# weight 24

(任意)ファイアウォールの作業負荷容量を指定します。ファイアウォール ファーム内の他のファイアウォールと相対的な値です。

ステップ 7

inservice

 
Router(config-slb-fw-real)# inservice

ファイアウォールおよび IOS Server Load Balancing(IOS SLB)が使用するファイアウォールをイネーブルにします。

ステップ 8

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

 
Router(config-slb-fw)# access destination 10.1.6.0 255.255.255.0

(任意)特定のフローをファイアウォール ファームにルーティングします。

ステップ 9

predictor hash address [ port ]

 
Router(config-slb-fw)# predictor hash address

(任意)ファイアウォールを選択するときに、発信元および宛先の IP アドレスに加え、発信元および宛先の TCP またはユーザ データグラム プロトコル(UDP)のポート番号を使用するかどうかを指定します。

ステップ 10

purge connection

 
Router(config-slb-fw)# purge connection

(任意)IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングから、接続の消去要求を送信できるようにします。

ステップ 11

purge sticky

 
Router(config-slb-fw)# purge sticky

(任意)スティッキ タイマーが期限切れになるとき、IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングから、スティッキ接続の消去要求を送信できるようにします。

ステップ 12

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

 
Router(config-slb-fw)# replicate casa 10.10.10.11 10.10.11.12 4231

(任意)バックアップ スイッチに対する IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングの判定テーブルのステートフル バックアップを設定します。

ステップ 13

replicate interval interval

 
Router(config-slb-fw)# replicate interval 20

(任意)IOS Server Load Balancing(IOS SLB)ファイアウォール ファームのレプリケーション配信間隔を設定します。

コマンドはサポートされません(セッションは永続的ではなく、レプリケートする対象がないためです)。

ステップ 14

replicate slave

 
Router(config-slb-fw)# replicate slave

(任意)IOS Server Load Balancing(IOS SLB)ファイアウォール ファームの冗長ルート プロセッサのステートフル バックアップをイネーブルにします。

を設定した単一の Supervisor を使用する場合、Supervisor で out-of-sync メッセージを受信することがあります。

ステップ 15

protocol tcp

 
Router(config-slb-fw)# protocol tcp

(任意)ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードを開始します。

ステップ 16

delay duration

 
Router(config-slb-fw-tcp)# delay 30

(任意)ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードの場合、接続の終了後、IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングが TCP 接続コンテキストを維持する時間を指定します。

ステップ 17

idle duration

 
Router(config-slb-fw-tcp)# idle 120

(任意)ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードで、パケット アクティビティがない場合、IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングが接続コンテキストを維持する最短時間を指定します。

ステップ 18

maxconns maximum-number

 
Router(config-slb-fw-tcp)# maxconns 1000

(任意)ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードの場合、ファイアウォール ファームで同時に使用できるアクティブな TCP 接続の最大数を指定します。

ステップ 19

sticky duration [ netmask netmask ] [ source | destination ]

 
Router(config-slb-fw-tcp)# sticky 60

(任意)ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードで、次のいずれかの条件を満たす場合、同じ IP アドレスからの接続に、同じファイアウォールを使用することを指定します。

同じペアの IP アドレス間に接続が存在する間(発信元/宛先スティッキ)。

最後の接続が破棄された後の duration で定義される期間。

ステップ 20

protocol datagram

 
Router(config-slb-fw)# protocol datagram

(任意)ファイアウォール ファーム データグラム プロトコル コンフィギュレーション モードを開始します。

ステップ 21

idle duration

 
Router(config-slb-fw-udp)# idle 120

(任意)ファイアウォール ファーム データグラム プロトコル コンフィギュレーション モードで、パケット アクティビティがない場合、IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングが接続コンテキストを維持する最短時間を指定します。

ステップ 22

maxconns maximum-number

 
Router(config-slb-fw-udp)# maxconns 1000

(任意)ファイアウォール ファーム データグラム プロトコル コンフィギュレーション モードの場合、ファイアウォール ファームで同時に使用できるアクティブな データグラム 接続の最大数を指定します。

ステップ 23

sticky duration [ netmask netmask ] [ source | destination ]
 
Router(config-slb-fw-udp)# sticky 60

(任意)ファイアウォール ファーム データグラム プロトコル コンフィギュレーション モードで、次のいずれかの条件を満たす場合、同じ IP アドレスからの接続に、同じファイアウォールを使用することを指定します。

同じペアの IP アドレス間に接続が存在する間(発信元/宛先スティッキ)。

最後の接続が破棄された後の duration で定義される期間。

ステップ 24

inservice

 
Router(config-slb-fw)# inservice

IOS Server Load Balancing(IOS SLB)が使用するファイアウォール ファームをイネーブルにします。

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

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

手順の概要

1. show ip slb real

2. show ip slb firewallfarm

手順の詳細

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

Router# show ip slb real
 
real farm name weight state conns
--------------------------------------------------------------------
10.1.1.2 FIRE1 8 OPERATIONAL 0
10.1.2.2 FIRE1 8 OPERATIONAL 0
 

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

Router# show ip slb firewallfarm
 
firewall farm hash state reals
------------------------------------------------
FIRE1 IPADDR INSERVICE 2

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

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

手順の概要

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 ファイアウォール ロード バランシングのネットワーク ステータスに関する詳細情報を表示します。

Router# show ip slb stats
 
Pkts via normal switching: 0
Pkts via special switching: 0
Pkts dropped: 0
Connections Created: 1911871
Connections Established: 1967754
Connections Destroyed: 1313251
Connections Reassigned: 0
Zombie Count: 0
Connections Reused: 59752
Connection Flowcache Purges:1776582
Failed Connection Allocs: 17945
Failed Real Assignments: 0
 

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

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

Router# show ip slb real detail
 
10.1.1.3, FIRE1, state = OPERATIONAL, type = firewall
conns = 299310, dummy_conns = 0, maxconns = 4294967295
weight = 10, weight(admin) = 10, metric = 104, remainder = 2
total conns established = 1074779, hash count = 4646
server failures = 0
interface FastEthernet1/0, MAC 0010.f68f.7020
 

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

Router# show ip slb conns
 
vserver prot client real state nat
-------------------------------------------------------------------------------
FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none
FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none
FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none
FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none
FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none
 


 

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

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb probe probe custom udp

 
Router(config)# ip slb probe PROBE6 custom udp

IOS Server Load Balancing(IOS SLB)プローブの名前を設定し、カスタム ユーザ データグラム プロトコル(UDP)プローブ コンフィギュレーション モードを開始します。

ステップ 4

address [ ip-address ] [ routed ]

 
Router(config-slb-probe)# address 10.1.1.1

(任意)カスタム ユーザ データグラム プロトコル(UDP)プローブの送信先 IP アドレスを設定します。

ステップ 5

faildetect number-of-probes

 
Router(config-slb-probe)# faildetect 16

(任意)連続して ACK が受信されないカスタム ユーザ データグラム プロトコル(UDP)プローブの数を指定します。この数を超えると、実サーバの障害と見なされます。

ステップ 6

interval seconds

 
Router(config-slb-probe)# interval 11

(任意)カスタム ユーザ データグラム プロトコル(UDP)プローブの送信タイマーを設定します。

ステップ 7

port port

 
Router(config-slb-probe)# port 8

カスタム ユーザ データグラム プロトコル(UDP)プローブが接続するポートを設定します。

ステップ 8

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

 
Router(config-slb-probe)# request data 0 05 04 00 77 18 2A D6 CD 0A AD 53 4D F1 29 29 CF C1 96 59 CB

カスタム UDP プローブから送信されるユーザ データグラム プロトコル(UDP)要求パケットのペイロードを定義します。

ステップ 9

response clause-number data start-byte hex-data-string
 
Router(config-slb-probe)# response 2 data 44 DD DD

カスタム ユーザ データグラム プロトコル(UDP)プローブ応答パケットに一致するデータ ストリングを定義します。

ステップ 10

timeout seconds

 
Router(config-slb-probe)# timeout 20

(任意)カスタム ユーザ データグラム プロトコル(UDP)プローブのタイムアウトを設定します。

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

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb probe probe dns

 
Router(config)# ip slb probe PROBE4 dns

IOS Server Load Balancing(IOS SLB)プローブの名前を設定し、ドメイン ネーム システム(DNS)プローブ コンフィギュレーション モードを開始します。

ステップ 4

address [ip-address [routed]]

 
Router(config-slb-probe)# address 10.1.10.1

(任意)ドメイン ネーム システム(DNS)プローブの送信先 IP アドレスを設定します。

ステップ 5

faildetect number-of-probes

 
Router(config-slb-probe)# faildetect 16

(任意)連続して ACK が受信されないドメイン ネーム システム(DNS)プローブの数を指定します。この数を超えると、実サーバまたはファイアウォールの障害と見なされます。

ステップ 6

interval seconds

 
Router(config-slb-probe)# interval 11

(任意)ドメイン ネーム システム(DNS)プローブの送信タイマーを設定します。

ステップ 7

lookup ip-address

 
Router(config-slb-probe)# lookup 10.1.10.1

(任意)ドメイン ネーム システム(DNS)サーバが、ドメイン ネーム解決要求に対する応答で示す必要がある実サーバの IP アドレスを設定します。

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. 仮想サーバへのルートを設定します。

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb probe probe http

 
Router(config)# ip slb probe PROBE2 http

IOS Server Load Balancing(IOS SLB)プローブの名前を設定し、HTTP プローブ コンフィギュレーション モードを開始します。

ステップ 4

address [ip-address [routed]]

 
Router(config-slb-probe)# address 10.1.10.1

(任意)HTTP プローブの送信先 IP アドレスを設定します。

ステップ 5

credentials {username [password]}

 
Router(config-slb-probe)# credentials Username1 password

(任意)HTTP プローブのヘッダー値を設定します。

ステップ 6

expect [status status-code] [regex expression]

 
Router(config-slb-probe)# expect status 401 regex Copyright

(任意)予想される HTTP ステータス コードまたは正規表現を設定します。

ステップ 7

header field-name [ field-value ]

 
Router(config-slb-probe)# header HeaderName HeaderValue

(任意)HTTP プローブのヘッダー値を設定します。

ステップ 8

interval seconds

 
Router(config-slb-probe)# interval 11

(任意)HTTP プローブの送信タイマーを設定します。

ステップ 9

port port

 
Router(config-slb-probe)# port 8

(任意)HTTP プローブが接続するポートを設定します。

ステップ 10

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

 
Router(config-slb-probe)# request method post url /probe.cgi?all

(任意)サーバからの要求への URL パス、およびサーバへの要求に使用するメソッドを設定します。

さらに、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

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb probe probe ping

 
Router(config)# ip slb probe PROBE1 ping

IOS Server Load Balancing(IOS SLB)プローブの名前を設定し、ping プローブ コンフィギュレーション モードを開始します。

ステップ 4

address [ip-address [routed]]

 
Router(config-slb-probe)# address 10.1.10.1

(任意)ping プローブの送信先 IP アドレスを設定します。

ステップ 5

faildetect number-of-pings

 
Router(config-slb-probe)# faildetect 16

(任意)連続して ACK が受信されない ping プローブの数を指定します。この数を超えると、実サーバまたはファイアウォールの障害と見なされます。

ステップ 6

interval seconds

 
Router(config-slb-probe)# interval 11

(任意)ping プローブの送信タイマーを設定します。

TCP プローブの設定

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

手順の概要

1. enable

2. configure terminal

3. ip slb probe probe tcp

4. address [ip-address [ routed ]]

5. interval seconds

6. port port

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb probe probe tcp

 
Router(config)# ip slb probe PROBE5 tcp

IOS Server Load Balancing(IOS SLB)プローブの名前を設定し、TCP プローブ コンフィギュレーション モードを開始します。

ステップ 4

address [ip-address [routed]]

 
Router(config-slb-probe)# address 10.1.10.1

(任意)TCP プローブの送信先 IP アドレスを設定します。

ステップ 5

interval seconds

 
Router(config-slb-probe)# interval 5

(任意)TCP プローブの送信タイマーを設定します。

ステップ 6

port port

 
Router(config-slb-probe)# port 8

TCP プローブが接続するポートを設定します。

WSP プローブの設定

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

手順の概要

1. enable

2. configure terminal

3. ip slb probe probe wsp

4. address [ip-address [ routed ]]

5. interval seconds

6. url [path]

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb probe probe wsp

 
Router(config)# ip slb probe PROBE3 wsp

IOS Server Load Balancing(IOS SLB)プローブの名前を設定し、Wireless Session Protocol(WSP)プローブ コンフィギュレーション モードを開始します。

ステップ 4

address [ip-address [routed]]

 
Router(config-slb-probe)# address 10.1.10.1

(任意)Wireless Session Protocol(WSP)プローブの送信先 IP アドレスを設定します。

ステップ 5

interval seconds

 
Router(config-slb-probe)# interval 11

(任意)Wireless Session Protocol(WSP)プローブの送信タイマーを設定します。

ステップ 6

url [path]

 
Router(config-slb-probe)# url http://localhost/test.txt

(任意)Wireless Session Protocol(WSP)プローブの URL パスを設定します。

プローブの関連付け

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

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


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


手順の概要

1. enable

2. configure terminal

3. ip slb firewallfarm firewall-farm

または

ip slb serverfarm server-farm

4. probe probe

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb firewallfarm firewall-farm

または

ip slb serverfarm server-farm

 
Router(config)# ip slb serverfarm PUBLIC

または

Router(config)# ip slb firewallfarm FIRE1

ファイアウォール ファームを指定し、ファイアウォール ファーム コンフィギュレーション モードを開始します。

または

サーバ ファームを指定し、SLB サーバ ファーム コンフィギュレーション モードを開始します。

ステップ 4

probe probe

 

Router(config-slb-sfarm)# probe PROBE1

または

Router(config-slb-fw-real)# probe FireProbe

プローブをファイアウォール ファームまたはサーバ ファームに関連付けます。

プローブの確認

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

手順の概要

1. show ip slb probe

手順の詳細

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

Router# show ip slb probe
 
Server:Port State Outages Current Cumulative
----------------------------------------------------------------
10.1.1.1:80 OPERATIONAL 0 never 00:00:00
10.1.1.2:80 OPERATIONAL 0 never 00:00:00
10.1.1.3:80 OPERATIONAL 0 never 00:00:00

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 ]]]

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

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

 
Router(config)# ip slb dfp password Password1 360

Dynamic Feedback Protocol(DFP)を設定し、オプションのパスワードを指定し、DFP コンフィギュレーション モードを開始します。

ステップ 4

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

 
Router(config-slb-dfp)# agent 10.1.1.1 2221 30 0 10

IOS Server Load Balancing(IOS SLB)が接続できる Dynamic Feedback Protocol(DFP)エージェントを指定します。

この次の手順

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 アイドル タイマーを設定します。

手順の詳細

タスク
説明

ステップ 1

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

「サーバ ファームおよび実サーバの設定」を参照してください。

GPRS ロード バランシングのサーバ ファームおよび実サーバを設定する場合、次の注意事項を考慮してください。

GTP Cause Code Inspection をイネーブルにしない場合、 predictor コマンドのデフォルト設定(加重ラウンド ロビン アルゴリズム)を受け入れます。

GTP Cause Code Inspection をイネーブルにする場合、加重ラウンド ロビン( roundrobin )アルゴリズムまたは加重最小接続( leastconns )アルゴリズムを指定します。

real コマンドを使用して、GGSN 機能を実行する実サーバの IP アドレス(Cisco GGSN の場合、仮想テンプレート アドレス)を指定します。

reassign コマンドを使用して、SGSN の N3-REQUESTS カウンタ値未満の reassign threshold を指定します。

ステップ 2

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

「仮想サーバの設定」を参照してください。

virtual コマンドを設定する場合、次の注意事項を考慮してください。

仮想 GGSN IP アドレスを仮想サーバとして指定し、 udp キーワード オプションを指定します。

GTP v1 および GTP v2 セッションの負荷を分散するには、GGSN および SGSN が ETSI 標準に準拠している場合、ポート番号 2123 を指定します。また、全ポート仮想サーバ(つまり、すべてのポート宛てのフローを受け入れる仮想サーバ)を設定するには、ポート番号 0 または any を指定します。

GTP v0 セッションの負荷を分散するには、GGSN および SGSN が ETSI 標準に準拠している場合、ポート番号 3386 を指定します。また、全ポート仮想サーバを設定するには、ポート番号 0 または any を指定します。

GTP Cause Code Inspection なし の GPRS ロード バランシングをイネーブルにするには、 service gtp キーワード オプションを指定します。

GTP Cause Code Inspection あり の GPRS ロード バランシングをイネーブルにするには、 service gtp-inspect キーワード オプションを指定します。

GTP Cause Code Inspection をイネーブルに しない GPRS ロード バランシングの場合、 idle コマンドを使用して idle タイマーを設定するときは、SGSN 上の PDP コンテキスト要求間で可能な最も長い間隔よりも、長いアイドル タイマーを指定します。

ステップ 3

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

(dispatched モードの場合に必須)この手順が必須なのは、GTP Cause Code Inspection をイネーブルに しない で dispatched モードを使用する場合だけです。詳細については、『 Cisco IOS Interface Configuration Guide 』の「 Configuring Virtual Interfaces 」の項を参照してください。

ステップ 4

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

スタティック ルートまたはダイナミック ルートを使用できますが、GGSN は SGSN に到達可能な必要があります。詳細については、『 Cisco IOS Mobile Wireless Configuration Guide 』の「 Configuring Network Access to the GGSN 」の項を参照してください。

ステップ 5

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

(必須)詳細については、SGSN の設定ガイドを参照してください。

ステップ 6

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

(任意)この手順を適用できるのは、GTP Cause Code Inspection がイネーブルの場合だけです。

詳細については、「GSN アイドル タイマーの設定」を参照してください。

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

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

手順の概要

1. enable

2. configure terminal

3. ip slb timers gtp gsn duration

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb timers gtp gsn duration

 
Router(config)# ip slb timers gtp gsn 45

IOS Server Load Balancing(IOS SLB)が、アイドルのゲートウェイ GPRS サポート ノード(GGSN)または動作中の GPRS サポート ノード(SGSN)との間でやりとりするセッションを維持する時間を変更します。

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

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

手順の概要

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

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

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

手順の詳細

タスク
説明

ステップ 1

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

GGSN-IOS SLB メッセージング サポートを設定する場合、同じ GGSN を共有するすべての IOS SLB 仮想サーバを、同じ NAT モード(dispatched モードまたは directed モード)を使用するように設定します。このとき、 gprs slb mode コマンドを使用します。1 つの GGSN につき 1 つの NAT モードしか設定できないため、仮想サーバは dispatched モードと directed モードを混在して使用できません。

詳細については、GGSN 5.0 for Cisco IOS リリース 12.3(2)XU 以降の『 Cisco IOS Mobile Wireless Configuration Guide 』を参照してください。

ステップ 2

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

「サーバ ファームおよび実サーバの設定」を参照してください。

GGSN-IOS SLB メッセージングのサーバ ファームおよび実サーバを設定する場合、セッションを新しい実サーバに再割り当てするときに、IOS SLB が現在の実サーバを停止しないように、 no faildetect inband コマンドを指定して、自動サーバ障害検出機能をディセーブルにします。

ステップ 3

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

「仮想サーバの設定」を参照してください。

GGSN-IOS SLB メッセージングの仮想サーバを設定する場合、 gtp notification cac コマンドを指定して、IOS SLB がセッションを新しい実サーバに再割り当てできる回数を制限します。

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 ]

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb map map-id gtp | radius }

 
Router(config)# ip slb map 1 radius

IOS SLB GTP マップを設定し、SLB GTP マップ コンフィギュレーション モードを開始します。

ステップ 4

apn string
 
Router(config-slb-map-gtp)# apn abc

グローバル パケット ラジオ サービス(GPRS)ロード バランシングのアクセス ポイント ネーム(APN)とマッチングする ASCII 正規表現ストリングを設定します。

ステップ 5

exit
 

Router(config-slb-map-gtp)# exit

SLB GTP マップ コンフィギュレーション モードを終了します。

ステップ 6

ip slb vserver virtual-server
 

Router(config)# ip slb vserver GGSN_SERVER

仮想サーバを指定し、仮想サーバ コンフィギュレーション モードを開始します。

ステップ 7

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

Router(config-slb-vserver)# virtual 10.10.10.10 udp 0 service gtp

仮想サーバの IP アドレス、接続の種類、およびオプションの TCP またはユーザ データグラム プロトコル(UDP)のポート番号を指定し、Internet Key Exchange(IKE; インターネット キー エクスチェンジ)または Wireless Session Protocol(WSP)の設定、およびサービスのカップリングを指定します。

(注) GPRS ロード バランシングの場合:

仮想 GGSN IP アドレスを仮想サーバとして指定し、 udp キーワード オプションを指定します。

GTP v1 および GTP v2 セッションの負荷を分散するには、GGSN および SGSN が ETSI 標準に準拠している場合、ポート番号 2123 を指定します。また、全ポート仮想サーバ(つまり、すべてのポート宛てのフローを受け入れる仮想サーバ)を設定するには、ポート番号 0 または any を指定します。

GTP v0 セッションの負荷を分散するには、GGSN および SGSN が ETSI 標準に準拠している場合、ポート番号 3386 を指定します。また、全ポート仮想サーバを設定するには、ポート番号 0 または any を指定します。

GTP Cause Code Inspection なし の GPRS ロード バランシングをイネーブルにするには、 service gtp キーワード オプションを指定します。

GTP Cause Code Inspection あり の GPRS ロード バランシングをイネーブルにするには、 service gtp-inspect キーワード オプションを指定します。

ステップ 8

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

 
Router(config-slb-vserver)# serverfarm farm1 backup farm2 map 1 priority 3

GTP マップをサーバ ファームに関連付けます。実サーバ ファームを仮想サーバに関連付け、オプションで、バックアップ サーバ ファームを設定し、バックアップ サーバ ファームでスティッキ接続を使用することを指定します。

(注) GPRS ロード バランシングで、複数のサーバ ファームに 1 つの実サーバが定義されている場合、各サーバ ファームは異なる仮想サーバに関連付ける必要があります。

複数のサーバ ファームを特定の仮想サーバに関連付けるには、 serverfarm コマンドを複数設定し、それぞれに固有のマップ ID と固有のプライオリティを指定します(つまり、各マップ ID および各マップ プライオリティは、仮想サーバに関連付けられているすべてのサーバ ファームで固有にする必要があります)。

GTP マップを使用し、複数のサーバ ファームで 1 つの実サーバを設定した場合、異なる仮想サーバを各サーバ ファームに関連付ける必要があります。

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

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb capp udp

 
Router(config)# ip slb capp udp

KAL-AP エージェントをイネーブルにし、SLB Content Application Peering Protocol(CAPP)コンフィギュレーション モードを開始します。

ステップ 4

peer [ ip-address ] port port

 
Router(config-slb-capp)# peer port 6000

(任意)KAL-AP エージェントが接続するポートを指定します。

ステップ 5

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

 
Router(config-slb-capp)# peer secret SECRET_STRING

(任意)KAL-AP エージェントのために Message Digest Algorithm Version 5(MD5)認証をイネーブルにします。

ステップ 6

exit

 

Router(config-slb-map-gtp)# exit

SLB CAPP コンフィギュレーション モードを終了します。

ステップ 7

ip slb serverfarm server-farm

 
Router(config)# ip slb serverfarm PUBLIC

サーバ ファームを指定し、SLB サーバ ファーム コンフィギュレーション モードを開始します。

ステップ 8

kal-ap domain tag

 
Router(config-slb-sfarm)# kal-ap domain chicago-com

(任意)KAL-AP エージェントが仮想サーバの負荷をレポートするとき、ドメイン タグを確認できるようにします。

ステップ 9

farm-weight setting

 
Router(config-slb-sfarm)# farm-weight 16

(任意)サーバ ファームの負荷値を算出するときに、KAL-AP エージェントが使用する加重を指定します。

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

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

手順の概要

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

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

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

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

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

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

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

手順の詳細

タスク
説明

ステップ 1

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

「サーバ ファームおよび実サーバの設定」を参照してください。

RADIUS ロード バランシングのサーバ ファームおよび実サーバを設定する場合、次の注意事項を考慮してください。

predictor コマンドのデフォルト設定(加重ラウンド ロビン アルゴリズム)を受け入れます。

(任意)セッションベースの障害検出をイネーブルにする場合、 faildetect numconns コマンドで numclients キーワードに値 1 を指定します。

(任意)個々の仮想サーバに割り当てることができる、IOS SLB RADIUS および GTP スティッキ加入者の最大数を指定するには、 maxclients コマンドを使用します。

ステップ 2

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

「仮想サーバの設定」を参照してください。

RADIUS ロード バランシングの仮想サーバを設定する場合、次の注意事項を考慮してください。

virtual コマンドを使用して、 service radius キーワード オプションを指定します。

(任意)入力インターフェイスを検査するために framed-IP ルーティングをイネーブルにするには、 access interface route framed-ip コマンドを指定します。

access interface route framed-ip コマンドを設定する場合、さらに service radius キーワードを指定した virtual コマンドを設定する必要があります。

(任意)外部エージェントのハンドオフ時に、IOS SLB が新しい Mobile IP 外部エージェントからの ACCT-START メッセージを待機する時間を変更するには、 hand-off radius コマンドを設定します。

(任意)IOS SLB セッション データベースで RADIUS エントリのデュレーションを設定するには、 radius request キーワードを指定した idle コマンドを設定します。

(任意)IOS SLB RADIUS framed-IP スティッキ データベースでエントリのデュレーションを設定するには、 radius framed-ip キーワードを指定した idle コマンドを設定します。

仮想サーバを設定します。
(続き)

「仮想サーバの設定」を参照してください。

RADIUS ロード バランシングの仮想サーバを設定する場合、次の注意事項を考慮してください。

(任意)IOS SLB が、IOS SLB RADIUS framed-IP スティッキ データベースを作成し、特定の加入者からの RADIUS 要求および非 RADIUS フローを同じサービス ゲートウェイに送信できるようにするには、 sticky コマンドで radius framed-ip キーワードを指定します。

sticky radius framed-ip コマンドを設定する場合、さらに service radius キーワードを指定した virtual コマンドを設定する必要があります。

(任意)Accounting ON または OFF メッセージの受信時に、IOS SLB が IOS SLB RADIUS framed-ip スティッキ データベースのエントリを消去できるようにするには、 purge radius framed-ip acct on-off 仮想サーバ コンフィギュレーション コマンドを指定します。

Accounting ON または OFF メッセージの受信時に、IOS SLB が IOS SLB RADIUS framed-ip スティッキ データベースのエントリを消去できないようにするには、 no purge radius framed-ip acct on-off 仮想サーバ コンフィギュレーション コマンドを指定します。

(任意)Accounting-Stop メッセージの受信時に、IOS SLB が IOS SLB RADIUS framed-ip スティッキ データベースのエントリを消去できるようにするには、 purge radius framed-ip acct stop 仮想サーバ コンフィギュレーション コマンドを指定します。

Accounting-Stop メッセージの受信時に、IOS SLB が IOS SLB RADIUS framed-ip スティッキ データベースのエントリを消去できないようにするには、 no purge radius framed-ip acct stop 仮想サーバ コンフィギュレーション コマンドを指定します。

仮想サーバを設定します。
(続き)

「仮想サーバの設定」を参照してください。

RADIUS ロード バランシングの仮想サーバを設定する場合、次の注意事項を考慮してください。

(任意:CDMA2000 ネットワーク用のみ)IOS SLB が IOS SLB RADIUS calling-station-ID スティッキ データベースを作成し、発信ステーション ID に基づいて、特定の加入者からの RADIUS 要求を同じサービス ゲートウェイに送信できるようにするには、 sticky コマンドで radius calling-station-id キーワードを指定します。

IOS SLB が IOS SLB RADIUS username スティッキ データベースを作成し、ユーザ名に基づいて、特定の加入者からの RADIUS 要求を同じサービス ゲートウェイに送信できるようにするには、 sticky コマンドで radius username キーワードを指定します。

sticky radius calling-station-id コマンドまたは sticky radius username コマンドを設定する場合、さらに service radius キーワードを指定した virtual コマンドを設定し、 sticky radius framed-ip コマンドを設定する必要があります。

同じ仮想サーバに sticky radius calling-station-id コマンドと sticky radius username コマンドの両方を設定することはできません。

(任意:RADIUS ロード バランシング加速データ プレーン フォワーディングの場合のみ)認証仮想サーバの VSA 関連付けグループを設定し、RADIUS 発信ステーション ID または RADIUS ユーザ名に基づいて IOS SLB が VSA 関連付けエントリを作成するかどうかを指定するには、 radius inject auth コマンドを設定します。

認証仮想サーバの VSA 関連付けのタイマーを設定するには、 radius inject auth timer コマンドを設定します。

認証仮想サーバの VSA 関連付けの VSA をバッファリングするには、 radius inject auth vsa コマンドを設定します。

アカウンティング仮想サーバの VSA 関連付けグループを設定し、VSA 関連付けの Message Digest Algorithm Version 5(MD5)認証をイネーブルにするには、 radius inject acct コマンドを設定します。

ステップ 3

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

(任意)「RADIUS framed-IP スティッキ ルーティングのパケット検査のイネーブル化」を参照してください。

ステップ 4

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

(任意)「RADIUS ロード バランシング マップの設定」を参照してください。

ステップ 5

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

(任意)「RADIUS ロード バランシング加速データ プレーン フォワーディングの設定」を参照してください。

ステップ 6

使用できる MLS エントリの数を増やします。

(任意)Supervisor Engine 2 を搭載した Catalyst 6500 ファミリ スイッチで dispatched モードを使用して IOS SLB を実行している場合、 no mls netflow コマンドを設定するとパフォーマンスを改善できます。このコマンドで、エンドユーザ フローのハードウェア スイッチングに使用できる MLS エントリの数が増えます。

コマンドは設定しないでください。

MLS NetFlow の設定方法の詳細については、『 Catalyst 6000 Family IOS Software Configuration Guide 』を参照してください。

ステップ 7

プローブを設定します。

「プローブの設定」を参照してください。

サーバの動作状況を確認するには、ping プローブを設定します。

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 }

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

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

 
Router(config)# ip slb route 10.10.10.1 255.255.255.255 framed-ip

IOS Server Load Balancing(IOS SLB)で、RADIUS framed-IP スティッキ データベースによるパケットのルーティングをイネーブルにします。または、特定のファイアウォール実サーバから別のファイアウォール実サーバを介するパケットのルーティングをイネーブルします。

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 ]

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb map map-id radius

 
Router(config)# ip slb map 1 radius

IOS SLB RADIUS マップを設定し、SLB RADIUS マップ コンフィギュレーション モードを開始します。

ステップ 4

calling-station-id string

 
Router(config-slb-radius-map)# calling-station-id .919*

RADIUS ロード バランシングの発信ステーション ID アトリビュートとマッチングする ASCII 正規表現ストリングを設定します。

ステップ 5

username string

 

Router(config-slb-map-radius)# )# username ...?525*

RADIUS ロード バランシングのユーザ名アトリビュートとマッチングする ASCII 正規表現ストリングを設定します。

ステップ 6

exit

 

Router(config-slb-map-gtp)# exit

SLB RADIUS マップ コンフィギュレーション モードを終了します。

ステップ 7

ip slb vserver virtual-server

 

Router(config)# ip slb vserver GGSN_SERVER

仮想サーバを指定し、仮想サーバ コンフィギュレーション モードを開始します。

ステップ 8

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

 

Router(config-slb-vserver)# virtual 10.0.0.1 udp 0 service radius

仮想サーバの IP アドレス、接続の種類、およびオプションの TCP またはユーザ データグラム プロトコル(UDP)のポート番号を指定し、Internet Key Exchange(IKE; インターネット キー エクスチェンジ)または Wireless Session Protocol(WSP)の設定、およびサービスのカップリングを指定します。

キーワード オプションを指定します。

ステップ 9

serverfarm primary-farm [ backup backup-farm [ sticky ]] [ map map-id priority priority ]
 
Router(config-slb-vserver)# serverfarm SF1 backup SF2 map 1 priority 1

RADIUS マップをサーバ ファームに関連付けます。実サーバ ファームを仮想サーバに関連付け、オプションで、バックアップ サーバ ファームを設定し、バックアップ サーバ ファームでスティッキ接続を使用することを指定します。

キーワードをサポートしません。

複数のサーバ ファームを特定の仮想サーバに関連付けるには、 serverfarm コマンドを複数設定し、それぞれに固有のマップ ID と固有のプライオリティを指定します(つまり、各マップ ID および各マップ プライオリティは、仮想サーバに関連付けられているすべてのサーバ ファームで固有にする必要があります)。

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

RADIUS ロード バランシング加速データ プレーン フォワーディングを設定するには、次の作業を実行します。

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

前提条件

Turbo RADIUS ロード バランシングには、アカウンティング仮想サーバに predictor route-map で設定したサーバ ファームが必要です。

手順の概要

1. enable

2. configure terminal

3. ip slb serverfarm server-farm

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

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 ]

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

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

11. radius inject auth timer seconds

12. radius inject auth vsa vendor-id

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb serverfarm server-farm

 
Router(config)# ip slb serverfarm PUBLIC

サーバ ファームを指定し、SLB サーバ ファーム コンフィギュレーション モードを開始します。

ステップ 4

predictor [ roundrobin | leastconns | route-map mapname ]

 
Router(config-slb-sfarm)# predictor route-map map1

(任意)実サーバを選択する方法を決定するために使用するアルゴリズムを指定します。

Turbo RADIUS ロード バランシングには、 route-map キーワードおよび mapname 引数が必要です。

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

ステップ 5

exit

 

Router(config-slb-sfarm)# exit

SLB サーバ ファーム コンフィギュレーション モードを終了します。

ステップ 6

ip slb vserver virtual-server

 
Router(config)# ip slb vserver RADIUS_AUTH

仮想サーバを指定し、仮想サーバ コンフィギュレーション モードを開始します。

ステップ 7

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

 

Router(config-slb-vserver)# virtual 10.10.10.10 udp 1813 service radius

仮想サーバの IP アドレス、接続の種類、およびオプションの TCP またはユーザ データグラム プロトコル(UDP)のポート番号を指定し、Internet Key Exchange(IKE; インターネット キー エクスチェンジ)または Wireless Session Protocol(WSP)の設定、およびサービスのカップリングを指定し、SLB 仮想サーバ コンフィギュレーション モードを開始します。

キーワード オプションを指定します。

ステップ 8

serverfarm primary-farm [ backup backup-farm [ sticky ]] [ map map-id priority priority ]
 
Router(config-slb-vserver)# serverfarm AAAFARM

RADIUS マップをサーバ ファームに関連付けます。実サーバ ファームを仮想サーバに関連付け、オプションで、バックアップ サーバ ファームを設定し、バックアップ サーバ ファームでスティッキ接続を使用することを指定します。

キーワードをサポートしません。

複数のサーバ ファームを特定の仮想サーバに関連付けるには、 serverfarm コマンドを複数設定し、それぞれに固有のマップ ID と固有のプライオリティを指定します(つまり、各マップ ID および各マップ プライオリティは、仮想サーバに関連付けられているすべてのサーバ ファームで固有にする必要があります)。

ステップ 9

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

 
Router(config-slb-vserver)# radius acct local-ack key SECRET_PASSWORD

(任意)VSA 関連付けを設定し、RADIUS 仮想サーバが RADIUS アカウンティング メッセージを承認できるようにします。

(注) ベンダー固有アトリビュート(VSA)関連付けを設定し、Cisco VSA がバッファリングされている場合、Cisco VSA は RADIUS Accounting-Start パケットに注入されます。Turbo RADIUS ロード バランシングに VSA 関連付けは必要ありません。

このコマンドが有効なのは、VSA 関連付けアカウンティング仮想サーバの場合だけです。

ステップ 10

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

 
Router(config-slb-vserver)# radius inject auth 1 calling-station-id

(任意)RADIUS ロード バランシング加速データ プレーン フォワーディングの認証仮想サーバについて、ベンダー固有アトリビュート(VSA)関連付けグループを設定します。また、RADIUS 発信ステーション ID または RADIUS ユーザ名に基づいて、IOS SLB で VSA 関連付けエントリを作成するかどうかを指定します。

特定の認証仮想サーバについて、単一の radius inject auth group-number calling-station-id コマンド、または単一の radius inject auth group-number username コマンドを設定できますが、両方同時には使用できません。

このコマンドが有効なのは、VSA 関連付け認証仮想サーバの場合だけです。

ステップ 11

radius inject auth timer seconds

 
Router(config-slb-vserver)# radius inject auth timer 45

(任意)IOS SLB RADIUS ロード バランシング加速データ プレーン フォワーディングの認証仮想サーバについて、ベンダー固有アトリビュート(VSA)関連付けのタイマーを設定します。

このコマンドが有効なのは、VSA 関連付け認証仮想サーバの場合だけです。

ステップ 12

radius inject auth vsa vendor-id

 
Router(config-slb-vserver)# radius inject auth vsa vendor1

(任意)IOS SLB RADIUS ロード バランシング加速データ プレーン フォワーディングの認証仮想サーバについて、ベンダー固有アトリビュート(VSA)関連付けの VSA をバッファリングします。

このコマンドが有効なのは、VSA 関連付け認証仮想サーバの場合だけです。

mSEF 用 Exchange Director の設定作業リスト

mSEF 用 Exchange Director を設定するには、次の作業を実行します。

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

「Exchange Director 用の RADIUS の設定」

「Exchange Director 用のファイアウォールの設定」

Exchange Director 用の RADIUS の設定

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

手順の概要

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

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

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

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

5. 使用できる MLS エントリの数を増やします。

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

手順の詳細

タスク
説明

ステップ 1

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

「サーバ ファームおよび実サーバの設定」を参照してください。

Exchange Director 用に RADIUS のサーバ ファームおよび実サーバを設定する場合、次の注意事項を考慮してください。

(任意)セッションベースの障害検出をイネーブルにする場合、 faildetect numconns コマンドで numclients キーワードに値 1 を指定します。

(任意)個々の仮想サーバに割り当てることができる、IOS SLB RADIUS および GTP スティッキ加入者の最大数を指定するには、 maxclients コマンドを使用します。

ステップ 2

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

「仮想サーバの設定」を参照してください。

Exchange Director 用に RADIUS の仮想サーバを設定する場合、次の注意事項を考慮してください。

virtual コマンドを使用して、 service radius キーワード オプションを指定します。

(任意)入力インターフェイスを検査するために framed-IP ルーティングをイネーブルにするには、 access interface route framed-ip コマンドを指定します。

access interface route framed-ip コマンドを設定する場合、さらに service radius キーワードを指定した virtual コマンドを設定する必要があります。

(任意)外部エージェントのハンドオフ時に、IOS SLB が新しい Mobile IP 外部エージェントからの ACCT-START メッセージを待機する時間を変更するには、 hand-off radius コマンドを設定します。

(任意)IOS SLB セッション データベースで RADIUS エントリのデュレーションを設定するには、 radius request キーワードを指定した idle コマンドを設定します。

(任意)IOS SLB RADIUS framed-IP スティッキ データベースでエントリのデュレーションを設定するには、 radius framed-ip キーワードを指定した idle コマンドを設定します。

仮想サーバを設定します。
(続き)

「仮想サーバの設定」を参照してください。

RADIUS ロード バランシングの仮想サーバを設定する場合、次の注意事項を考慮してください。

(任意)IOS SLB が、IOS SLB RADIUS framed-IP スティッキ データベースを作成し、特定の加入者からの RADIUS 要求および非 RADIUS フローを同じサービス ゲートウェイに送信できるようにするには、 sticky コマンドで radius framed-ip キーワードを指定します。

sticky radius framed-ip コマンドを設定する場合、さらに service radius キーワードを指定した virtual コマンドを設定する必要があります。

(任意:CDMA2000 ネットワーク用のみ)IOS SLB が IOS SLB RADIUS calling-station-ID スティッキ データベースを作成し、発信ステーション ID に基づいて、特定の加入者からの RADIUS 要求を同じサービス ゲートウェイに送信できるようにするには、 sticky コマンドで radius calling-station-id キーワードを指定します。

IOS SLB が IOS SLB RADIUS username スティッキ データベースを作成し、ユーザ名に基づいて、特定の加入者からの RADIUS 要求を同じサービス ゲートウェイに送信できるようにするには、 sticky コマンドで radius username キーワードを指定します。

sticky radius calling-station-id コマンドまたは sticky radius username コマンドを設定する場合、さらに service radius キーワードを指定した virtual コマンドを設定し、 sticky radius framed-ip コマンドを設定する必要があります。

同じ仮想サーバに sticky radius calling-station-id コマンドと sticky radius username コマンドの両方を設定することはできません。

ステップ 3

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

(任意)「RADIUS framed-IP スティッキ ルーティングのパケット検査のイネーブル化」を参照してください。

ステップ 4

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

(任意)「RADIUS ロード バランシング マップの設定」を参照してください。

ステップ 5

使用できる MLS エントリの数を増やします。

(任意)Supervisor Engine 2 を搭載した Catalyst 6500 ファミリ スイッチで dispatched モードを使用して IOS SLB を実行している場合、no mls netflow コマンドを設定するとパフォーマンスを改善できます。このコマンドで、エンドユーザ フローのハードウェア スイッチングに使用できる MLS エントリの数が増えます。

(注) micro-flow QoS、reflexive ACL、TCP intercept、Web Cache Redirect など、ハードウェア NetFlow テーブルを使用する IOS 機能を使用している場合、no mls netflow コマンドは設定しないでください。

MLS NetFlow の設定方法の詳細については、『Catalyst 6000 Family IOS Software Configuration Guide』を参照してください。

ステップ 6

プローブを設定します。

「プローブの設定」を参照してください。

サーバの動作状況を確認するには、ping プローブを設定します。

Exchange Director 用のファイアウォールの設定

Exchange Director 用にファイアウォール ロード バランシングを設定するには、次の作業を実行します。

ここでは、Exchange Director 用にファイアウォールを設定するための作業リストを示します。詳細な設定情報については、このマニュアルまたは別のマニュアルの該当する項を参照してください。必須および任意の作業を示します。

「ファイアウォール ファームの設定」(必須)

「ファイアウォール ファームの確認」(任意)

「ファイアウォール接続の確認」(任意)

「プローブの設定」(必須)

「ワイルドカード検索の設定」(任意)

「MLS エントリのプロトコルレベル消去の設定」(任意)

「接続の消去要求動作の設定」(任意)

「スティッキ接続の消去要求動作の設定」(任意)

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

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

手順の概要

1. enable

2. configure terminal

3. ip slb firewallfarm firewall-farm

4. real ip-address

5. probe probe

6. weight setting

7. inservice

8. exit

9. access [ source source-ip netmask ] [ destination destination-ip netmask ]| inbound inbound-interface | 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. protocol tcp

15. delay duration

16. idle duration

17. maxconns maximum-number

18. sticky seconds [ netmask netmask ] [ source | destination ]

19. exit

20. protocol datagram

21. idle duration

22. maxconns maximum-number

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

24. exit

25. inservice

手順の詳細

コマンド
目的

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb firewallfarm firewall-farm

 

Router(config)# ip slb firewallfarm FIRE1

ファイアウォール ファームの定義を IOS SLB ロード バランシング(IOS SLB)設定に追加し、ファイアウォール ファーム コンフィギュレーション モードを開始します。

ステップ 4

real ip-address

 
Router(config-slb-fw)# real 10.1.1.1

ファイアウォール ファームのメンバとして、ファイアウォールを IP アドレスで指定し、実サーバ コンフィギュレーション モードを開始します。

ステップ 5

probe probe

 
Router(config-slb-fw-real)# probe FireProbe

プローブをファイアウォールに関連付けます。

ステップ 6

weight setting

 
Router(config-slb-fw-real)# weight 16

(任意)ファイアウォールの作業負荷容量を指定します。ファイアウォール ファーム内の他のファイアウォールと相対的な値です。

ステップ 7

inservice

 
Router(config-slb-fw-real)# inservice

ファイアウォールおよび IOS Server Load Balancing(IOS SLB)が使用するファイアウォールをイネーブルにします。

ステップ 8

exit

 
Router(config-slb-fw-real)# exit

実サーバ コンフィギュレーション モードを終了します。

ステップ 9

access [ source source-ip netmask ] [ destination destination-ip netmask ]| inbound inbound-interface | outbound outbound-interface ]

 
Router(config-slb-fw)# access destination 10.1.6.0 255.255.255.0

(任意)特定のフローをファイアウォール ファームにルーティングします。

ステップ 10

predictor hash address [ port ]

 
Router(config-slb-fw)# predictor hash address

(任意)ファイアウォールを選択するときに、発信元および宛先の IP アドレスに加え、発信元および宛先の TCP またはユーザ データグラム プロトコル(UDP)のポート番号を使用するかどうかを指定します。

ステップ 11

purge connection

 
Router(config-slb-fw)# purge connection

(任意)IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングから、接続の消去要求を送信できるようにします。

ステップ 12

purge sticky

 
Router(config-slb-fw)# purge sticky

(任意)スティッキ アイドル タイマーが期限切れになるとき、IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングから消去要求を送信できるようにします。

ステップ 13

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

 
Router(config-slb-fw)# replicate casa 10.10.10.11 10.10.11.12 4231

(任意)バックアップ スイッチに対する IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングの判定テーブルのステートフル バックアップを設定します。

ステップ 14

protocol tcp

 
Router(config-slb-fw)# protocol tcp

(任意)ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードを開始します。

ステップ 15

delay duration

 
Router(config-slb-fw-tcp)# delay 30

(任意)ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードの場合、接続の終了後、IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングが TCP 接続コンテキストを維持する時間を指定します。

ステップ 16

idle duration

 
Router(config-slb-fw-tcp)# idle 120

(任意)ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードで、パケット アクティビティがない場合、IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングが接続コンテキストを維持する最短時間を指定します。

ステップ 17

maxconns maximum-number
 
Router(config-slb-fw-tcp)# maxconns 1000

(任意)ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードの場合、ファイアウォール ファームで同時に使用できるアクティブな TCP 接続の最大数を指定します。

ステップ 18

sticky seconds [ netmask netmask ] [ source | destination ]

 
Router(config-slb-fw-tcp)# sticky 60

(任意)ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードで、次のいずれかの条件を満たす場合、同じ IP アドレスからの接続に、同じファイアウォールを使用することを指定します。

同じペアの IP アドレス間に接続が存在する間(発信元/宛先スティッキ)。

最後の接続が破棄された後の duration で定義される期間。

ステップ 19

exit

 
Router(config-slb-fw-tcp)# exit

ファイアウォール ファーム TCP プロトコル コンフィギュレーション モードを終了します。

ステップ 20

protocol datagram

 
Router(config-slb-fw)# protocol datagram

(任意)ファイアウォール ファーム データグラム プロトコル コンフィギュレーション モードを開始します。

ステップ 21

idle duration

 
Router(config-slb-fw-udp)# idle 120

(任意)ファイアウォール ファーム データグラム プロトコル コンフィギュレーション モードで、パケット アクティビティがない場合、IOS Server Load Balancing(IOS SLB)ファイアウォール ロード バランシングが接続コンテキストを維持する最短時間を指定します。

ステップ 22

maxconns maximum-number
 
Router(config-slb-fw-udp)# maxconns 1000

(任意)ファイアウォール ファーム データグラム プロトコル コンフィギュレーション モードの場合、ファイアウォール ファームで同時に使用できるアクティブな データグラム 接続の最大数を指定します。

ステップ 23

sticky seconds [ netmask netmask ] [ source | destination ]

 
Router(config-slb-fw-udp)# sticky 60

(任意)ファイアウォール ファーム データグラム プロトコル コンフィギュレーション モードで、次のいずれかの条件を満たす場合、同じ IP アドレスからの接続に、同じファイアウォールを使用することを指定します。

同じペアの IP アドレス間に接続が存在する間(発信元/宛先スティッキ)。

最後の接続が破棄された後の duration で定義される期間。

ステップ 24

exit

 
Router(config-slb-fw-udp)# exit

ファイアウォール ファーム データグラム プロトコル コンフィギュレーション モードを終了します。

ステップ 25

inservice

 
Router(config-slb-fw)# inservice

IOS Server Load Balancing(IOS SLB)が使用するファイアウォール ファームをイネーブルにします。

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

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

手順の概要

1. show ip slb real

2. show ip slb firewallfarm

手順の詳細


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

Router# show ip slb real
 
real farm name weight state conns
--------------------------------------------------------------------
10.1.1.2 FIRE1 8 OPERATIONAL 0
10.1.2.2 FIRE1 8 OPERATIONAL 0
 

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

Router# show ip slb firewallfarm
 
firewall farm hash state reals
------------------------------------------------
FIRE1 IPADDR INSERVICE 2


 

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

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

手順の概要

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 ファイアウォール ロード バランシングのネットワーク ステータスに関する詳細情報を表示します。

Router# show ip slb stats
 
Pkts via normal switching: 0
Pkts via special switching: 0
Pkts dropped: 0
Connections Created: 1911871
Connections Established: 1967754
Connections Destroyed: 1313251
Connections Reassigned: 0
Zombie Count: 0
Connections Reused: 59752
Connection Flowcache Purges:1776582
Failed Connection Allocs: 17945
Failed Real Assignments: 0
 

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

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

Router# show ip slb real detail
 
10.1.1.3, FIRE1, state = OPERATIONAL, type = firewall
conns = 299310, dummy_conns = 0, maxconns = 4294967295
weight = 10, weight(admin) = 10, metric = 104, remainder = 2
total conns established = 1074779, hash count = 4646
server failures = 0
interface FastEthernet1/0, MAC 0010.f68f.7020
 

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

Router# show ip slb conns
 
vserver prot client real state nat
-------------------------------------------------------------------------------
FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none
FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none
FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none
FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none
FirewallTCP TCP 80.80.50.187:40000 10.1.1.4 ESTAB none
 


 

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

プローブの設定

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

手順の概要

1. ファイアウォール ファームの各実サーバにプローブを設定します。

手順の詳細

Exchange Director では、障害の検出と回復にプローブを使用します。ファイアウォール ファームの各実サーバにプローブを設定する必要があります。

ping プローブが推奨されます。詳細については、「ping プローブの設定」を参照してください。

ファイアウォールで、ping プローブの転送を許可していない場合、代わりに HTTP プローブを使用します。詳細については、「HTTP プローブの設定」を参照してください。

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

ワイルドカード検索の設定

ワイルドカード検索を設定するには、次の作業を実行します。

手順の概要

1. mls ip slb wildcard search rp

手順の詳細

PFC 上の TCAM の容量を超える可能性を減らすには、 mls ip slb wildcard search rp コマンドを使用します。

MLS エントリのプロトコルレベル消去の設定

アクティブな TCP および UDP フロー パケットからの MLS エントリのプロトコルレベル消去を設定するには、次の作業を実行します。

手順の概要

1. mls ip slb purge global

手順の詳細

mls ip slb purge global コマンドを使用して、TCP および UDP フロー パケットの消去スロットリングをイネーブルにします(これがデフォルトの設定です)。

TCP および UDP フロー パケットの消去スロットリングをディセーブルにするには、このコマンドの no 形式を使用します。

接続の消去要求動作の設定

IOS SLB ファイアウォール ロード バランシングから、接続の消去要求を送信できるようにするには、次の作業を実行します。

手順の概要

1. purge connection

手順の詳細

purge connection コマンドを使用して、IOS SLB ファイアウォール ロード バランシングから、接続の消去要求を送信できるようにします(これがデフォルトの設定です)。

消去要求の送信を完全に停止するには、このコマンドの no 形式を使用します。

スティッキ接続の消去要求動作の設定

スティッキ タイマーが期限切れになるとき、IOS SLB ファイアウォール ロード バランシングから、スティッキ接続の消去要求を送信できるようにするには、次の作業を実行します。

手順の概要

1. purge sticky

手順の詳細

スティッキ タイマーが期限切れになるとき、IOS SLB ファイアウォール ロード バランシングから、スティッキ接続の消去要求を送信できるようにするには、 purge sticky コマンドを使用します(これがデフォルトの設定です)。

スティッキ接続の消去要求の送信を完全に停止するには、このコマンドの no 形式を使用します。

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

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

手順の概要

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

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

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

手順の詳細

タスク
説明

ステップ 1

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

「サーバ ファームおよび実サーバの設定」を参照してください。

VPN サーバ ロード バランシングのサーバ ファームおよび実サーバを設定する場合、 real コマンドを使用して、VPN ターミネータとして動作する実サーバの IP アドレスを指定します。

ステップ 2

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

「仮想サーバの設定」を参照してください。

IPSec フローの VPN サーバ ロード バランシングの仮想サーバを設定する場合、次の注意事項を考慮してください。

プロトコルを udp 、ポートを isakmp に設定した virtual コマンドを使用して、UDP 仮想サーバを設定します。 isakmp キーワードを使用すると、IKE(ポート 500)を介して暗号鍵を交換できます。

プロトコルを esp に設定した virtual コマンドを使用して、ESP 仮想サーバを設定します。

15 秒以上の duration を指定した sticky コマンドを使用して、UDP 仮想サーバから ESP 仮想サーバ方向とその逆方向のスティッキ接続を指定します。

PPTP フローの VPN サーバ ロード バランシングの仮想サーバを設定する場合、次の注意事項を考慮してください。

tcp キーワードとポート番号 1723 を指定した virtual コマンドを使用して、TCP 仮想サーバを設定します。

gre キーワードを指定した virtual コマンドを使用して、GRE 仮想サーバを設定します。

15 秒以上の duration を指定した sticky コマンドを使用して、TCP 仮想サーバから GRE 仮想サーバ方向とその逆方向のスティッキ接続を指定します。

ステップ 3

プローブを設定します。

「プローブの設定」を参照してください。

サーバの動作状況を確認するには、ping プローブを設定します。

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

Access Service Network(ASN)ゲートウェイ セット全体のロード バランシングを設定するには、次の作業を実行します。

手順の概要

1. ベース ステーションを設定します。

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

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

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

手順の詳細

タスク
説明

ステップ 1

ベース ステーションを設定します。

Mobile Subscriber Station(MSS)からの要求を IOS SLB で処理できるようにするには、IOS SLB デバイスの仮想 IP アドレスを使用してベース ステーションを設定します。

ステップ 2

プローブを設定します。

「プローブの設定」を参照してください。

サーバの動作状況を確認するには、ping プローブを設定します。

ステップ 3

サーバ ファームおよび実サーバをプローブに関連付けます。

「サーバ ファームおよび実サーバの設定」を参照してください。

ASN R6 ロード バランシングのサーバ ファームおよび実サーバを設定する場合、 real コマンドを使用して、ASN ゲートウェイの IP アドレスを指定します。

ステップ 4

仮想サーバをサーバ ファームに関連付けます。

「仮想サーバの設定」を参照してください。

ASN R6 ロード バランシングの仮想サーバを設定する場合、次の注意事項を考慮してください。

サービスを asn r6 に設定した virtual コマンドを使用して、仮想サーバを設定します。

サービスを asn r6 request キーワードに設定した idle コマンドを使用して、ASN R6 ロード バランシングのアイドル接続タイマーを設定します。

Home Agent Director の設定作業リスト

Home Agent Director を設定するには、次の作業を実行します。

手順の概要

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

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

3. サーバの各ホーム エージェントでループバックとして仮想 IP アドレスを設定します。

4. DFP を設定します。

手順の詳細

タスク
説明

ステップ 1

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

「サーバ ファームおよび実サーバの設定」を参照してください。

Home Agent Director 用にサーバ ファームおよび実サーバを設定する場合、次の注意事項を考慮してください。

predictor コマンドのデフォルト設定(加重ラウンド ロビン アルゴリズム)を受け入れます。

real コマンドを使用して、ホーム エージェントとして動作する実サーバの IP アドレスを指定します。

ステップ 2

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

「仮想サーバの設定」を参照してください。

virtual コマンドを使用して Home Agent Director 用に仮想サーバを設定する場合、次の注意事項を考慮してください。

仮想サーバとして Home Agent Director の IP アドレスを指定します。

udp キーワード オプションを指定します。

ホーム エージェントが IP Mobility Support(RFC 2002)に準拠している場合、ポート番号 434 を指定します。また、全ポート仮想サーバ(つまり、すべてのポート宛てのフローを受け入れる仮想サーバ)を設定するには、ポート番号 0 または any を指定します。

service ipmobile キーワード オプションを指定します。

ステップ 3

サーバの各ホーム エージェントでループバックとして仮想 IP アドレスを設定します。

(dispatched モードの場合に必須)この手順が必須なのは、dispatched モードを使用する場合だけです。詳細については、『 Cisco IOS Interface Configuration Guide , Release 12.2』の「Configuring a Loopback Interface」の項を参照してください。

ステップ 4

DFP を設定します。

(任意)「DFP の設定」を参照してください。

Home Agent Director 用に DFP を設定する場合、次の注意事項を考慮してください。

ホーム エージェントから IOS SLB に送信する DFP の最大加重を制御するには、 ip mobile home-agent dfp-max-weight コマンドを使用します。

実ホーム エージェントのアドレスとして、Registration Reply(RRP)の発信元アドレスおよびホーム エージェント アドレス フィールドを設定するには、 ip mobile home-agent dynamic-address コマンドを使用します。

バインディングの最大数を設定するには、 ip mobile home-agent max-binding コマンドを使用します。

これらの Mobile IP コマンドの詳細については、『 Cisco Mobile Wireless Home Agent Release 2.0 のフィーチャ モジュールを参照してください。

NAT の設定

クライアント NAT の IOS SLB NAT クライアント アドレス プールを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb natpool pool start-ip end-ip [ netmask netmask | prefix-length leading-1-bits ] [ entries init-address [ max-address ]]

4. nat { client pool | server }

手順の詳細

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

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb natpool pool start-ip end-ip [ netmask netmask | prefix-length leading-1-bits ] [ entries init-address [ max-address ]]

 

Router(config)# ip slb natpool web-clients 10.1.10.1 10.1.10.5 netmask 255.255.0.0

クライアント アドレス プールを設定します。

GPRS ロード バランシングはこのコマンドをサポートしません。

サーバ NAT のクライアント アドレス プールを設定する必要はありません。

ステップ 4

nat { client pool | server }
 

Router(config-slb-sfarm)# nat server

SLB NAT を設定し、NAT モードを指定します。

また、 nat コマンドを使用して、サーバ ファームで NAT クライアント変換モードまたは NAT サーバ アドレス変換モードを指定する必要があります。詳細については、「サーバ ファームおよび実サーバの設定」を参照してください。NAT の仮想サーバを設定する場合、ESP または GRE 仮想サーバにクライアント NAT は設定できません。

スタティック NAT の設定

スタティック NAT を設定するには、次の作業を実行します。

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


) 予期しない結果を回避するために、スタティック NAT 設定が仮想サーバ設定を反映するようにします。


手順の概要

1. enable

2. configure terminal

3. ip slb static { drop | nat { virtual | virtual-ip [ per-packet | sticky ]}}

4. real ip-address [ port ]

手順の詳細

コマンド
説明

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb static { drop | nat { virtual | virtual-ip [ per-packet | sticky ]}}

 
Router(config)# ip slb static nat 10.1.10.1 per-packet

実サーバのネットワーク アドレス変換(NAT)の動作を設定し、スタティック NAT コンフィギュレーション モードを開始します。

オプションを指定しない場合、IOS Server Load Balancing(IOS SLB)ではサーバ ポートの変換を使用して、別の実サーバから開始された接続要求を区別します。

ステップ 4

real ip-address [ port ]

 
Router(config-slb-static)# real 10.1.1.3

スタティック ネットワーク アドレス変換(NAT)を使用するには、1 つまたは複数の実サーバを設定します。

ステートレス バックアップの設定作業リスト

IOS SLB デバイス間の VLAN でステートレス バックアップを設定するには、次の作業を実行します。


) 複数の IOS SLB デバイスが仮想 IP アドレスを共有しているアクティブ スタンバイの場合、重複しないクライアントの範囲を使用する必要があります。また、ポリシー ルーティングを使用して、適切な IOS SLB デバイスにフローを転送する必要があります。


手順の概要

1. 必須および任意の IOS SLB 機能を設定します。

2. ファイアウォール ロード バランシングを設定します。

3. IP ルーティング プロトコルを設定します。

4. IOS SLB デバイス間の VLAN を設定します。

5. ステートレス バックアップ設定を確認します。

手順の詳細

タスク
説明

ステップ 1

必須および任意の IOS SLB 機能を設定します。

(サーバ ロード バランシングの場合に必須)「必須および任意の IOS SLB 機能の設定」を参照してください。

ステップ 2

ファイアウォール ロード バランシングを設定します。

(ファイアウォール ロード バランシングの場合に必須)「ファイアウォール ロード バランシングの設定」を参照してください。

ステップ 3

IP ルーティング プロトコルを設定します。

詳細については、『 Cisco IOS IP Configuration Guide , Release 12.2』の「IP Routing Protocols」の章を参照してください。

ステップ 4

IOS SLB デバイス間の VLAN を設定します。

詳細については、『 Cisco IOS Switching Services Configuration Guide , Release 12.2』の「Virtual LANs」の章を参照してください。

ステップ 5

ステートレス バックアップ設定を確認します。

(任意)「ステートレス バックアップ設定の確認」を参照してください。

ステートレス バックアップ設定の確認

ステートレス バックアップ設定を確認するには、次の作業を実行します。

手順の概要

1. show ip slb vservers

2. show ip slb vservers detail

3. show ip slb firewallfarm

4. show ip slb firewallfarm details

手順の詳細

サーバ ロード バランシングの場合、ステートレス バックアップが設定済みで、適切に動作していることを確認するには、次の show ip slb vservers コマンドを使用して、IOS SLB 仮想サーバのステータスに関する情報を表示します。

Router# show ip slb vservers
 
slb vserver prot virtual state conns
-------------------------------------------------------------------
VS1 TCP 10.10.10.12:23 OPERATIONAL 2
VS2 TCP 10.10.10.18:23 OPERATIONAL 2
 
Router# show ip slb vservers detail
 
VS1, state = OPERATIONAL, v_index = 10
virtual = 10.10.10.12:23, TCP, service = NONE, advertise = TRUE
server farm = SERVERGROUP1, delay = 10, idle = 3600
sticky timer = 0, sticky subnet = 255.255.255.255
sticky group id = 0
synguard counter = 0, synguard period = 0
conns = 0, total conns = 0, syns = 0, syn drops = 0
standby group = None
VS2, state = INSERVICE, v_index = 11
virtual = 10.10.10.18:23, TCP, service = NONE, advertise = TRUE
server farm = SERVERGROUP2, delay = 10, idle = 3600
sticky timer = 0, sticky subnet = 255.255.255.255
sticky group id = 0
synguard counter = 0, synguard period = 0
conns = 0, total conns = 0, syns = 0, syn drops = 0
standby group = None
 

ファイアウォール ロード バランシングの場合、ステートレス バックアップが設定済みで、適切に動作していることを確認するには、次の show ip slb firewallfarm コマンドを使用して、IOS SLB ファイアウォール ファームのステータスに関する情報を表示します。

Router# show ip slb firewallfarm
 
firewall farm hash state reals
------------------------------------------------
FIRE1 IPADDR INSERVICE 2
 
Router# show ip slb firewallfarm details
 
FIRE1, hash = IPADDRPORT, state = INSERVICE, reals = 2
FirewallTCP:
sticky timer = 0, sticky subnet = 255.255.255.255
idle = 3600, delay = 10, syns = 1965732, syn drop = 0
maxconns = 4294967295, conns = 597445, total conns = 1909512
FirewallUDP:
sticky timer = 0, sticky subnet = 255.255.255.255
idle = 3600
maxconns = 1, conns = 0, total conns = 1
Real firewalls:
10.1.1.3, weight = 10, OPERATIONAL, conns = 298823
10.1.1.4, weight = 10, OPERATIONAL, conns = 298622
Total connections = 597445

冗長ルート プロセッサのステートフル バックアップの設定作業リスト

冗長ルート プロセッサのステートフル バックアップを設定するには、次の作業を実行します。

手順の概要

1. スレーブ レプリケーションのレプリケーション メッセージ レートを設定します。

2. 必須および任意の IOS SLB 機能を設定します。

3. ファイアウォール ロード バランシングを設定します。

手順の詳細

タスク
説明

ステップ 1

スレーブ レプリケーションのレプリケーション メッセージ レートを設定します。

グローバル コンフィギュレーション モードで ip slb replicate slave rate コマンドを指定します。

ステップ 2

必須および任意の IOS SLB 機能を設定します。

(サーバ ロード バランシングの場合に必須)「必須および任意の IOS SLB 機能の設定」を参照してください。

冗長ルート プロセッサのステートフル バックアップの仮想サーバを設定する場合、次の注意事項を考慮してください。

replicate slave コマンドを指定します。

(任意)仮想サーバのレプリケーション配信間隔を設定するには、 replicate interval コマンドを設定します。

ステップ 3

ファイアウォール ロード バランシングを設定します。

(ファイアウォール ロード バランシングの場合に必須)「ファイアウォール ロード バランシングの設定」を参照してください。

冗長ルート プロセッサのステートフル バックアップのファイアウォール ファームを設定する場合、次の注意事項を考慮してください。

replicate slave コマンドを指定します。

(任意)ファイアウォール ファームのレプリケーション配信間隔を設定するには、 replicate interval コマンドを設定します。

データベース エントリの設定

データベース エントリを設定するを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb entries [ conn [ init-conn [ max-conn ]] | frag [ init-frag [ max-frag ] | lifetime timeout ] | gtp { gsn [ init-gsn [ max-gsn ] | nsapi [ init-nsapi [ max-nsapi ]} | sticky [ init-sticky [ max-sticky ]]]

手順の詳細

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

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb entries [ conn [ init-conn [ max-conn ]] | frag [ init-frag [ max-frag ] | lifetime timeout ] | gtp { gsn [ init-gsn [ max-gsn ] | nsapi [ init-nsapi [ max-nsapi ]} | sticky [ init-sticky [ max-sticky ]]]
 
Router(config)# ip slb entries conn 128000 512000

IOS Server Load Balancing(IOS SLB)データベース エントリの最初の割り当てと最大値を指定します。

に入力します。IOS SLB 設定がすでに存在する場合、このコマンドを入力してから、IOS SLB をリロードする必要があります。

フラグメント データベースのバッファの設定

フラグメント データベースのバッファを設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. ip slb maxbuffers frag buffers

手順の詳細

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

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb maxbuffers frag buffers

 
Router(config)# ip slb maxbuffers frag 300

IOS Server Load Balancing(IOS SLB)フラグメント データベースのバッファの最大数を設定します。

データベースおよびカウンタのクリア

データベースおよびカウンタをクリアするには、次の作業を実行します。

手順の概要

1. clear ip slb connections [ firewallfarm firewall-farm | serverfarm server-farm | vserver virtual-server ]

2. clear ip slb counters [ kal-ap ]

3. clear ip slb sessions [ firewallfarm firewall-farm | serverfarm server-farm | vserver virtual-server ]

4. clear ip slb sticky gtp imsi [ id imsi ]

5. clear ip slb sticky radius { calling-station-id [ id string ] | framed-ip [ framed-ip [ netmask ]]}

手順の詳細

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

ステップ 1

clear ip slb connections [ firewallfarm firewall-farm | serverfarm server-farm | vserver virtual-server ]

 
Router# clear ip slb connections vserver VSERVER1

1 つまたは複数のファイアウォール ファーム、サーバ ファーム、または仮想サーバについて、IOS Server Load Balancing(IOS SLB)接続データベースをクリアします。

ステップ 2

clear ip slb counters [ kal-ap ]

 
Router# clear ip slb counters

IOS Server Load Balancing(IOS SLB)カウンタをクリアします。

IP IOS SLB KeepAlive Application Protocol(KAL-AP)だけをクリアするには、 kal-ap キーワードを使用します。

ステップ 3

clear ip slb sessions [ firewallfarm firewall-farm | serverfarm server-farm | vserver virtual-server ]

 
Router# clear ip slb sessions serverfarm FARM1

1 つまたは複数のファイアウォール ファーム、サーバ ファーム、または仮想サーバについて、IOS Server Load Balancing(IOS SLB)RADIUS セッション データベースをクリアします。

ステップ 4

clear ip slb sticky gtp imsi [ id imsi ]

 
Router# clear ip slb sticky gtp imsi

IOS Server Load Balancing(IOS SLB)グローバル パケット ラジオ サービス(GPRS)トンネリング プロトコル(GTP)International Mobile Subscriber ID(IMSI)スティッキ データベースからのエントリをクリアします。

ステップ 5

clear ip slb sticky radius { calling-station-id [ id string ] | framed-ip [ framed-ip [ netmask ]]}
 
Router# clear ip slb sticky radius framed-ip

IOS Server Load Balancing(IOS SLB)RADIUS スティッキ データベースからのエントリをクリアします。

ワイルドカード検索の設定

ワイルドカード検索を設定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. mls ip slb search

手順の詳細

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

Router(config)# mls ip slb search {wildcard [pfc | rp] | icmp}
 

Router(config)# mls ip slb search wildcard rp

IOS Server Load Balancing(IOS SLB)ワイルドカード検索の動作を指定します。

このコマンドがサポートされるのは Catalyst 6500 ファミリ スイッチだけです。

MLS エントリのプロトコルレベル消去の設定

アクティブな TCP および UDP フロー パケットからの MLS エントリのプロトコルレベル消去を指定するには、次の作業を実行します。

手順の概要

1. enable

2. configure terminal

3. mls ip slb purge global

手順の詳細

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

Router(config)# mls ip slb purge global
 
Router(config)# mls ip slb purge global

アクティブな TCP および UDP フロー パケットからの MLS エントリのプロトコルレベル消去を指定します。

このコマンドがサポートされるのは Catalyst 6500 ファミリ スイッチだけです。

接続の消去および再割り当て

接続を消去し、再割り当てするには、次の作業を実行します。

アイドル タイマーの期限が切れていない場合でも、障害が発生したサーバおよびファイアウォールへの接続を接続データベースから自動的に削除する機能をイネーブルにできます。この機能は、発信元ポートを循環させないアプリケーション(IKE など)の場合、およびフローを区別するポートがないプロトコル(ESP など)の場合に有効です。

また、障害が発生した実サーバまたはファイアウォール宛ての RADIUS スティッキ オブジェクトを、新しい実サーバまたはファイアウォールに自動的に再割り当てする機能をイネーブルにできます。

手順の概要

1. enable

2. configure terminal

3. ip slb serverfarm server-farm

4. failaction [ purge | gtp purge | radius reassign ]

5. exit

6. ip slb firewallfarm firewall-farm

7. failaction purge

手順の詳細

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

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb serverfarm server-farm

 
Router(config)# ip slb serverfarm PUBLIC

サーバ ファーム コンフィギュレーション モードを開始します。

ステップ 4

failaction [ purge | gtp purge | radius reassign ]

 
Router(config-slb-sfarm)# failaction purge

実サーバに障害が発生した場合の IOS Server Load Balancing(IOS SLB)の動作を設定します。

ステップ 5

exit

 

Router(config-slb-sfarm)# exit

サーバ ファーム コンフィギュレーション モードを終了します。

ステップ 6

ip slb firewallfarm firewall-farm
 
Router(config)# ip slb firewallfarm fire1

ファイアウォール ファーム コンフィギュレーション モードを開始します。

ステップ 7

failaction purge

 
Router(config-slb-fw)# failaction purge

ファイアウォールに障害が発生した場合の IOS Server Load Balancing(IOS SLB)の動作を設定します。

自動サーバ障害検出のディセーブル化

自動サーバ障害検出をディセーブルにするには、次の作業を実行します。

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

手順の概要

1. enable

2. configure terminal

3. ip slb serverfarm server-farm

4. real ip-address [ port ]

5. no faildetect inband

手順の詳細

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

ステップ 1

enable

 

Router> enable

特権 EXEC モードをイネーブルにします。

プロンプトが表示されたら、パスワードを入力します。

ステップ 2

configure terminal

 

Router# configure terminal

グローバル コンフィギュレーション モードを開始します。

ステップ 3

ip slb serverfarm server-farm

 
Router(config)# ip slb serverfarm PUBLIC

サーバ ファーム コンフィギュレーション モードを開始します。

ステップ 4

real ip-address [ port ]

 
Router(config-slb-sfarm)# real 10.1.1.1

サーバ ファームのメンバとして実サーバを指定し、実サーバ コンフィギュレーション モードを開始します。

ステップ 5

no faildetect inband

 
Router(config-slb-real)# no faildetect inband

自動サーバ障害検出をディセーブルにします。

コマンドを指定しても無視されます。

IOS SLB のモニタおよびメンテナンス

IOS SLB の実行時情報を取得および表示するには、次の作業を実行します。

手順の概要

1. show ip slb conns

2. show ip slb dfp

3. show ip slb firewallfarm

4. show ip slb fragments

5. show ip slb gtp

6. show ip slb map

7. show ip slb natpool

8. show ip slb probe

9. show ip slb reals

10. show ip slb replicate

11. show ip slb serverfarms

12. show ip slb sessions

13. show ip slb static

14. show ip slb stats

15. show ip slb sticky

16. show ip slb vservers

手順の詳細


ステップ 1 show ip slb conns [ vserver virtual-server | client ip-address | firewall firewall-farm ] [ detail ]

IOS SLB で処理されるすべての接続、またはオプションで特定の仮想サーバまたはクライアントに関連付けられている接続だけを表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb conns
 
vserver prot client real state
----------------------------------------------------------------------------
TEST TCP 10.150.72.183:328 10.80.90.25:80 INIT
TEST TCP 10.250.167.226:423 10.80.90.26:80 INIT
TEST TCP 10.234.60.239:317 10.80.90.26:80 ESTAB
TEST TCP 10.110.233.96:747 10.80.90.26:80 ESTAB
TEST TCP 10.162.0.201:770 10.80.90.30:80 CLOSING
TEST TCP 10.22.225.219:995 10.80.90.26:80 CLOSING
TEST TCP 10.2.170.148:169 10.80.90.30:80
 

ステップ 2 show ip slb dfp [ agent agent-ip port | manager manager-ip | detail | weights ]

Dynamic Feedback Protocol(DFP)および DFP エージェントに関する情報、および実サーバに割り当てられた加重に関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb dfp
 
DFP Manager:
Current passwd:NONE Pending passwd:NONE
Passwd timeout:0 sec
Agent IP Port Timeout Retry Count Interval
--------------------------------------------------------------
172.16.2.34 61936 0 0 180 (Default)
 

ステップ 3 show ip slb firewallfarm [ detail ]

ファイアウォール ファームに関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb firewallfarm
 
firewall farm hash state reals
------------------------------------------------
FIRE1 IPADDR OPERATIONAL 2
 

ステップ 4 show ip slb fragments

IOS SLB フラグメント データベースの情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb fragments
 
ip src id forward src nat dst nat
---------------------------------------------------------------------
10.11.2.128 12 10.11.2.128 10.11.11.11 10.11.2.128
10.11.2.128 13 10.11.2.128 10.11.11.11 10.11.2.128
10.11.2.128 14 10.11.2.128 10.11.11.11 10.11.2.128
10.11.2.128 15 10.11.2.128 10.11.11.11 10.11.2.128
10.11.2.128 16 10.11.2.128 10.11.11.11 10.11.2.128
 

ステップ 5 show ip slb gtp { gsn [ gsn-ip-address ] | nsapi [ nsapi-key ] [ detail ]

IOS Server Load Balancing(IOS SLB)の GTP 情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb gtp gsn 10.0.0.0
type ip recovery-ie purging
------------------------------------------
SGSN 10.0.0.0 UNKNOWN N
 

ステップ 6 show ip slb map [ map-id ]

IOS SLB プロトコル マップに関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb map
 
ID: 1, Service: GTP
APN: Cisco.com, yahoo.com
PLMN ID(s): 11122, 444353
SGSN access list: 100
ID: 2, Service: GTP
PLMN ID(s): 67523, 345222
PDP Type: IPv4, PPP
ID: 3, Service: GTP
PDP Type: IPv6
ID: 4, Service: RADIUS
Calling-station-id: “?919*”
ID: 5, Service: RADIUS
Username: “. .778cisco.*”
 

ステップ 7 show ip slb natpool [ name pool] [ detail ]

IOS Server Load Balancing(IOS SLB)のネットワーク アドレス変換(NAT)の設定に関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb natpool
 
nat client B 209.165.200.225 1.1.1.6 1.1.1.8 Netmask 255.255.255.0
nat client A 10.1.1.1 1.1.1.5 Netmask 255.255.255.0
 

ステップ 8 show ip slb probe [ name probe] [ detail ]

IOS Server Load Balancing(IOS SLB)に定義されたプローブに関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb probe
 
Server:Port State Outages Current Cumulative
----------------------------------------------------------------
10.10.4.1:0 OPERATIONAL 0 never 00:00:00
10.10.5.1:0 FAILED 1 00:00:06 00:00:06
 

ステップ 9 show ip slb reals [ sfarm server-farm ] [ detail ]

IOS Server Load Balancing(IOS SLB)に定義された実サーバに関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb reals
 
real farm name weight state conns
--------------------------------------------------------------------
10.80.2.112 FRAG 8 OUTOFSERVICE 0
10.80.5.232 FRAG 8 OPERATIONAL 0
10.80.15.124 FRAG 8 OUTOFSERVICE 0
10.254.2.2 FRAG 8 OUTOFSERVICE 0
10.80.15.124 LINUX 8 OPERATIONAL 0
10.80.15.125 LINUX 8 OPERATIONAL 0
10.80.15.126 LINUX 8 OPERATIONAL 0
10.80.90.25 SRE 8 OPERATIONAL 220
10.80.90.26 SRE 8 OPERATIONAL 216
10.80.90.27 SRE 8 OPERATIONAL 216
10.80.90.28 SRE 8 TESTING 1
10.80.90.29 SRE 8 OPERATIONAL 221
10.80.90.30 SRE 8 OPERATIONAL 224
10.80.30.3 TEST 100 READY_TO_TEST 0
10.80.30.4 TEST 100 READY_TO_TEST 0
10.80.30.5 TEST 100 READY_TO_TEST 0
10.80.30.6 TEST 100 READY_TO_TEST 0
 

ステップ 10 show ip slb replicate

IOS Server Load Balancing(IOS SLB)のレプリケーション設定に関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb replicate
 
VS1, state = NORMAL, interval = 10
Slave Replication: Enabled
Slave Replication statistics:
unsent conn updates: 0
conn updates received: 0
conn updates transmitted: 0
update messages received: 0
update messages transmitted: 0
Casa Replication:
local = 10.1.1.1 remote = 10.2.2.2 port = 1024
current password = <none> pending password = <none>
password timeout = 180 sec (Default)
Casa Replication statistics:
unsent conn updates: 0
conn updates received: 0
conn updates transmitted: 0
update packets received: 0
update packets transmitted: 0
failovers: 0
 

ステップ 11 show ip slb serverfarms [ name server-farm ] [ detail ]

IOS Server Load Balancing(IOS SLB)に定義されているサーバ ファームに関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb serverfarms
 
server farm predictor reals bind id
-------------------------------------------------
FRAG ROUNDROBIN 4 0
LINUX ROUNDROBIN 3 0
SRE ROUNDROBIN 6 0
TEST ROUNDROBIN 4 0
 

ステップ 12 show ip slb sessions [ asn r6 | gtp | gtp-inspect | ipmobile | radius ] [ vserver virtual-server ] [ client ip-address netmask ] [ detail ]

IOS Server Load Balancing(IOS SLB)に処理されるセッションに関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb sessions radius
 
Source Dest Retry
Addr/Port Addr/Port Id Count Real Vserver
------------------------------------------------------------------------------
10.10.11.1/1645 10.10.11.2/1812 15 1 10.10.10.1 RADIUS_ACCT
 

ステップ 13 show ip slb static

IOS Server Load Balancing(IOS SLB)サーバのネットワーク アドレス変換(NAT)の設定に関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb static
 
real action address counter
---------------------------------------------------------------
10.11.3.4 drop 0.0.0.0 0
10.11.3.1 NAT 10.11.11.11 3
10.11.3.2 NAT sticky 10.11.11.12 0
10.11.3.3 NAT per-packet 10.11.11.13 0
 

ステップ 14 show ip slb stats

IOS Server Load Balancing(IOS SLB)の統計情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb stats
 
Pkts via normal switching: 779
Pkts via special switching: 0
Pkts via slb routing: 0
Pkts Dropped: 4
Connections Created: 4
Connections Established: 4
Connections Destroyed: 4
Connections Reassigned: 5
Zombie Count: 0
Connections Reused: 0
Connection Flowcache Purges: 0
Failed Connection Allocs: 0
Failed Real Assignments: 0
RADIUS framed-ip Sticky Count: 0
RADIUS username Sticky Count: 0
RADIUS calling-station-id Sticky Count: 0
GTP IMSI Sticky Count: 0
Failed Correlation Injects: 0
Pkt fragments drops in ssv: 0
 

ステップ 15 show ip slb sticky [ client ip-address netmask | radius calling-station-id [ id string ] | radius framed-ip [ client ip-address netmask ] | radius username [ name string ]]

IOS Server Load Balancing(IOS SLB)に定義されたスティッキ接続に関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb sticky
client netmask group real conns
-----------------------------------------------------------------------
10.10.2.12 255.255.0.0 4097 10.10.3.2 1
 

ステップ 16 show ip slb vservers [ name virtual-server ] [ redirect ] [ detail ]

IOS Server Load Balancing(IOS SLB)に定義された仮想サーバに関する情報を表示します。次に、このコマンドのサンプル出力を示します。

Router# show ip slb vservers
 
slb vserver prot virtual state conns
---------------------------------------------------------------------
TEST TCP 10.80.254.3:80 OPERATIONAL 1013
TEST21 TCP 10.80.254.3:21 OUTOFSERVICE 0
TEST23 TCP 10.80.254.3:23 OUTOFSERVICE 0

IOS SLB の設定例

ここでは、IOS SLB の使用例を紹介します。この項の IOS SLB コマンドの詳細な説明については、『 Cisco IOS IP Application Services Command Reference 』を参照してください。この項に記載されている他のコマンドのドキュメントについては、Cisco.com でオンライン検索してください。

ここでは、次の設定例について説明します。

「基本的な IOS SLB ネットワークの設定:例」

「IOS SLB ネットワーク一式の設定:例」

「ファイアウォール ロード バランシングを使用する IOS SLB の設定:例」

「プローブを使用する IOS SLB の設定:例」

「IOS SLB による レイヤ 3 スイッチングの設定:例」

「NAT およびスタティック NAT を使用する IOS SLB の設定:例」

「冗長性を使用する IOS SLB の設定:例」

「スタティック ルートの再配布を使用する IOS SLB の設定:例」

「WAP および UDP ロード バランシングを使用する IOS SLB の設定:例」

「ルート ヘルス インジェクションを使用する IOS SLB の設定:例」

「GPRS ロード バランシングを使用する IOS SLB の設定:例」

「VPN サーバ ロード バランシングを使用する IOS SLB の設定:例」

「RADIUS ロード バランシングを使用する IOS SLB の設定:例」

「Home Agent Director を使用する IOS SLB の設定:例」

「スティッキ接続を使用する IOS SLB の設定:例」

「GTP IMSI スティッキ データベースを使用する IOS SLB の設定:例」

「透過的 Web キャッシュ ロード バランシングを使用する IOS SLB の設定:例」

「KAL-AP エージェントを使用する IOS SLB の設定:例」


) 例に使用される IP アドレスおよびネットワーク アドレスは一般的なものです。実際のネットワークのアドレスで置き換えてください。


基本的な IOS SLB ネットワークの設定:例

図 2 に、次のコンポーネントを使用した IOS SLB ネットワークの例を示します。

2 つのサーバ ファーム:1 つはパブリック アクセスを許可するように設定し、PUBLIC という名前をつけ、もう 1 つはアクセスを限定的になるように設定し、RESTRICTED という名前をつけます。

5 つの実サーバは次のように設定します。

PUBLIC サーバ ファームの 3 つの実サーバには、IP アドレス 10.1.1.1、10.1.1.2、および 10.1.1.3 を設定します。

RESTRICTED サーバ ファームの 2 つの実サーバには、IP アドレス 10.1.1.20 および 10.1.1.21 を設定します。

2 つの仮想サーバ:1 つはパブリック アクセスを許可するように設定し、PUBLIC_HTTP という名前をつけ、もう 1 つはアクセスを限定的になるように設定し、RESTRICTED_HTTP という名前をつけます。

仮想サーバ PUBLIC_HTTP は、IP アドレス 10.0.0.1、ロード バランシング TCP 接続 WWW ポート(80)と設定します。

仮想サーバ RESTRICTED_HTTP は、IP アドレス 10.0.0.2、ロード バランシング TCP 接続 WWW ポート(80)と設定します。また、ネットワーク 10.4.4.0 255.255.255.0 のクライアントからのアクセスだけを許可します。

図 2 IOS SLB ネットワークの例

 

以下の項には、図 2 に示す IOS SLB ネットワークの設定および確認に使用するコンフィギュレーション コマンドの例を紹介します。

「サーバ ファームの設定」

「仮想サーバの設定」

「限定されたクライアントの設定」

サーバ ファームの設定

次に、3 つの実サーバに関連付けられたサーバ ファーム PUBLIC の設定例を示します。

ip slb serverfarm PUBLIC
real 10.1.1.1
reassign 2
faildetect numconns 4 numclients 2
retry 20
inservice
exit
real 10.1.1.2
reassign 2
faildetect numconns 4
retry 20
inservice
exit
real 10.1.1.3
reassign 2
faildetect numconns 4
retry 20
inservice
end
 

次に、2 つの実サーバに関連付けられたサーバ ファーム RESTRICTED の設定例を示します。

ip slb serverfarm RESTRICTED
real 10.1.1.20
reassign 2
faildetect numconns 4
retry 20
inservice
exit
real 10.1.1.21
reassign 2
faildetect numconns 4
retry 20
inservice
end

仮想サーバの設定

次に、仮想サーバ PUBLIC_HTTP および RESTRICTED_HTTP の設定例を示します。

ip slb vserver PUBLIC_HTTP
virtual 10.0.0.1 tcp www
serverfarm PUBLIC
idle 120
delay 5
inservice
exit
ip slb vserver RESTRICTED_HTTP
virtual 10.0.0.2 tcp www
serverfarm RESTRICTED
idle 120
delay 5
inservice
end

限定されたクライアントの設定

次に、仮想サーバ RESTRICTED_HTTP の設定例を示します。

ip slb vserver RESTRICTED_HTTP
no inservice
client 10.4.4.0 255.255.255.0
inservice
end

IOS SLB ネットワーク一式の設定:例

次に、この機能マニュアルで説明しているコマンドの多数を使用した設定例の一式を示します。

ip slb probe PROBE2 http
request method POST url /probe.cgi?all
header HeaderName HeaderValue
!
ip slb serverfarm PUBLIC
nat server
real 10.1.1.1
reassign 4
faildetect numconns 16
retry 120
inservice
real 10.1.1.2
reassign 4
faildetect numconns 16
retry 120
inservice
probe PROBE2
!
ip slb serverfarm RESTRICTED
predictor leastconns
bindid 309
real 10.1.1.1
weight 32
maxconns 1000
reassign 4
faildetect numconns 16
retry 120
inservice
real 10.1.1.20
reassign 4
faildetect numconns 16
retry 120
inservice
real 10.1.1.21
reassign 4
faildetect numconns 16
retry 120
inservice
!
ip slb vserver PUBLIC_HTTP
virtual 10.0.0.1 tcp www
serverfarm PUBLIC
!
ip slb vserver RESTRICTED_HTTP
virtual 10.0.0.2 tcp www
serverfarm RESTRICTED
no advertise
sticky 60 group 1
idle 120
delay 5
client 10.4.4.0 255.255.255.0
synguard 3600000
inservice

ファイアウォール ロード バランシングを使用する IOS SLB の設定:例

ここでは次の例を紹介し、さまざまな IOS SLB ファイアウォール ロード バランシング設定を示します。

「基本的なファイアウォール ロード バランシングを使用する IOS SLB の設定:例」

「サーバ ロード バランシングおよびファイアウォール ロード バランシングを使用する IOS SLB の設定:例」

「複数のファイアウォール ファームを使用する IOS SLB の設定:例」

「二重ファイアウォール ロード バランシング「サンドイッチ」を使用する IOS SLB の設定:例」

「RADIUS ロード バランシング/ファイアウォール ロード バランシングの「サンドイッチ」を使用する IOS SLB の設定:例」

基本的なファイアウォール ロード バランシングを使用する IOS SLB の設定:例

図 3 に、次のコンポーネントを使用した IOS SLB ファイアウォール ロード バランシング ネットワークの例を示します。

図のように IP アドレスを指定した 2 つのファイアウォール

ファイアウォールのセキュア側に内部ファイアウォール ロード バランシング デバイス

ファイアウォールのインターネット側に外部ファイアウォール ロード バランシング デバイス

FIRE1 という 1 つのファイアウォール ファームに、両方のファイアウォールが含まれます

図 3 異なるサブネットにレイヤ 3 ファイアウォールを備えた IOS SLB

 

IOS SLB ファイアウォール ロード バランシングを設定する場合、ロード バランシング デバイスでは、そのファイアウォール宛てのフローを認識するためにルート検索が使用されます。ルート検索をイネーブルにするには、そのデバイスにフローをルーティングする各ファイアウォールの IP アドレスを使用して、各デバイスを設定する必要があります。

以下のファイアウォール ファーム設定例の場合:

内部(セキュア側)のファイアウォール ロード バランシング デバイスは、ファイアウォール IP アドレス 10.1.3.1 および 10.1.4.1 を使用して設定します。

外部(インターネット側)のファイアウォール ロード バランシング デバイスは、ファイアウォール IP アドレス 10.1.1.2 および 10.1.2.2 を使用して設定します。

内部ファイアウォール ロード バランシング デバイス

次に、ping プローブ PROBE1、HTTP プローブ PROBE2、およびファイアウォール ファーム FIRE1 の設定例を示します。これらは、ファイアウォールの内部(セキュア側)にあるロード バランシング デバイスの 2 つの実サーバに関連付けられています。

!-----Ping probe
ip slb probe PROBE1 ping
!-----IP address of other load-balancing device
address 10.1.1.1
faildetect 4
!-----HTTP probe
ip slb probe PROBE2 http
!-----IP address of other load-balancing device
address 10.1.2.1
expect status 401
!-----Firewall farm FIRE1
ip slb firewallfarm FIRE1
!-----First firewall
real 10.1.4.1
probe PROBE1
!-----Enable first firewall
inservice
!-----Second firewall
real 10.1.3.1
probe PROBE2
!-----Enable second firewall
inservice

外部ファイアウォール ロード バランシング デバイス

次に、ping プローブ PROBE1、HTTP プローブ PROBE2、およびファイアウォール ファーム FIRE1 の設定例を示します。これらは、ファイアウォールの外部(インターネット側)にあるロード バランシング デバイスの 2 つの実サーバに関連付けられています。

!-----Ping probe
ip slb probe PROBE1 ping
!-----IP address of other load-balancing device
address 10.1.4.2
faildetect 4
!-----HTTP probe
ip slb probe PROBE2 http
!-----IP address of other load-balancing device
address 10.1.3.2
expect status 401
!-----Firewall farm FIRE1
ip slb firewallfarm FIRE1
!-----First firewall
real 10.1.1.2
probe PROBE1
!-----Enable first firewall
inservice
 
!-----Second firewall
real 10.1.2.2
probe PROBE2
!-----Enable second firewall
inservice
exit
inservice

サーバ ロード バランシングおよびファイアウォール ロード バランシングを使用する IOS SLB の設定:例

図 4 に、サーバ ロード バランシングおよびファイアウォール ロード バランシングの両方と、次のコンポーネントを使用する IOS SLB ロード バランシング ネットワークの例を示します。

図のように IP アドレスを指定した 2 つの実サーバ

PUBLIC という 1 つのサーバ ファームに、両方の実サーバが含まれます。

図のように IP アドレスを指定した 2 つのファイアウォール

FIRE1 という 1 つのファイアウォール ファームに、両方のファイアウォールが含まれます。

ファイアウォールのセキュア側にある内部 IOS SLB デバイスは、サーバ ロード バランシングおよびファイアウォール ロード バランシングを実行します。

ファイアウォールのインターネット側に外部ファイアウォール ロード バランシング デバイス

図 4 サーバ ロード バランシングおよびファイアウォール ロード バランシングを使用する IOS SLB

 

以下のファイアウォール ファーム設定例の場合:

内部(セキュア側)のファイアウォール ロード バランシング デバイスは、ファイアウォール IP アドレス 10.1.3.1 および 10.1.4.1 を使用して設定します。

外部(インターネット側)のファイアウォール ロード バランシング デバイスは、ファイアウォール IP アドレス 10.1.1.2 および 10.1.2.2 を使用して設定します。

内部サーバおよびファイアウォール ロード バランシング デバイス

次に、ファイアウォールの内部(セキュア側)にあるロード バランシング デバイスの ping プローブ ABCPROBE および XYZPROBE、ファイアウォール ファーム FIRE1、およびサーバ ファーム PUBLIC の設定例を示します。

ip slb probe ABCPROBE ping
address 10.1.1.1
ip slb probe XYZPROBE ping
address 10.1.2.1
!
ip slb firewallfarm FIRE1
real 10.1.4.1
probe ABCPROBE
inservice
real 10.1.3.1
probe XYZPROBE
inservice
inservice
!
ip slb serverfarm PUBLIC
nat server
real 10.2.1.1
inservice
real 10.2.1.2
inservice
!
ip slb vserver HTTP1
virtual 128.1.0.1 tcp www
serverfarm PUBLIC
idle 120
delay 5
inservice

) Catalyst 6500 ファミリ スイッチでは、ルート プロセッサで IOS SLB ワイルドカード検索を実行するように指定できます。この場合、グローバル コンフィギュレーション モードで mls ip slb search wildcard rp コマンドを使用します。


外部ファイアウォール ロード バランシング デバイス

次に、ファイアウォールの外部(インターネット側)にあるロード バランシング デバイスの ping プローブ ABCPROBE および XYZPROBE、およびファイアウォール ファーム FIRE1 の設定例を示します。

ip slb probe ABCPROBE ping
address 10.1.4.2
ip slb probe XYZPROBE ping
address 10.1.3.2
ip slb firewallfarm FIRE1
real 10.1.1.2
probe ABCPROBE
inservice
probe XYZPROBE
inservice

複数のファイアウォール ファームを使用する IOS SLB の設定:例

図 5 に、複数のファイアウォール ファームと次のコンポーネントを使用した IOS SLB ファイアウォール ロード バランシング ネットワークの例を示します。

図のように IP アドレスを指定した 4 つのファイアウォール

ファイアウォールのセキュア側に内部ファイアウォール ロード バランシング デバイス

ファイアウォールのインターネット側に外部ファイアウォール ロード バランシング デバイス

左側に 2 つのファイアウォールを含む ABCFARM という 1 つのファイアウォール ファーム

右側に 2 つのファイアウォールを含む XYZFARM という 1 つのファイアウォール ファーム

図 5 複数のファイアウォール ファームがある IOS SLB

 

以下のファイアウォール ファーム設定例の場合:

内部(セキュア側)のファイアウォール ロード バランシング デバイスは、ファイアウォール IP アドレス 10.1.3.1 および 10.1.4.1 を使用して設定します。

外部(インターネット側)のファイアウォール ロード バランシング デバイスは、ファイアウォール IP アドレス 10.1.1.2 および 10.1.2.2 を使用して設定します。

内部ファイアウォール ロード バランシング デバイス

次に、ファイアウォールの内部(セキュア側)にあるロード バランシング デバイスの ping プローブ ABCPROBE および XYZPROBE、およびファイアウォール ファーム ABCFARM および XYZFARM の設定例を示します。

ip slb probe ABCPROBE ping
address 10.1.2.1
ip slb probe XYZPROBE ping
address 10.1.1.1
ip slb firewallfarm ABCFARM
access source 10.1.6.0 255.255.255.0
inservice
real 10.1.4.2
probe ABCPROBE
inservice
real 10.1.4.3
probe ABCPROBE
inservice
ip slb firewallfarm XYZFARM
access source 10.1.5.0 255.255.255.0
inservice
real 10.1.3.2
probe XYZPROBE
inservice
real 10.1.3.3
probe XYZPROBE
inservice

外部ファイアウォール ロード バランシング デバイス

次に、ファイアウォールの外部(インターネット側)にあるロード バランシング デバイスの ping プローブ ABCPROBE および XYZPROBE、およびファイアウォール ファーム ABCFARM および XYZFARM の設定例を示します。

ip slb probe ABCPROBE ping
address 10.1.4.1
ip slb probe XYZPROBE ping
address 10.1.3.1
ip slb firewallfarm ABCFARM
access destination 10.1.6.0 255.255.255.0
inservice
real 10.1.2.2
probe ABCPROBE
inservice
real 10.1.2.3
probe ABCPROBE
inservice
ip slb firewallfarm XYZFARM
access destination 10.1.5.0 255.255.255.0
inservice
real 10.1.1.2
probe XYZPROBE
inservice
real 10.1.1.3
probe XYZPROBE
inservice

二重ファイアウォール ロード バランシング「サンドイッチ」を使用する IOS SLB の設定:例

図 6 は、単一の IOS SLB デバイスでホストされる基本的な二重ファイアウォール ロード バランシング「サンドイッチ」の設定例です。Virtual Private Network(VPN)Routing and Forwarding(VRF)とアクセス インターフェイス設定を含みます。VL105、VL106、VL107、および VL108 は VLAN です。


) この設定のクライアントとサーバは直接接続されています。より一般的な展開では、VRF の内側と外側に追加のルータが必要です。


図 6 二重ファイアウォール ロード バランシング「サンドイッチ」を使用する IOS SLB

 

次に、図 6 の設定の IOS SLB 設定文を示します。

ip vrf client
rd 0:1
!
ip slb probe P642 ping
address 10.10.106.42
interval 120
ip slb probe P643 ping
address 10.10.106.43
interval 120
ip slb probe P742 ping
address 10.10.107.42
interval 120
ip slb probe P743 ping
address 10.10.107.43
interval 120
!
ip slb firewallfarm CLIENT
access inbound Vlan105
access outbound Vlan106
no inservice
!
real 10.10.106.42
probe P642
inservice
real 10.10.106.43
probe P643
inservice
protocol tcp
sticky 180 source
protocol datagram
sticky 180 source
predictor hash address port
!
ip slb firewallfarm SERVER
access inbound Vlan108
access outbound Vlan107
inservice
!
real 10.10.107.42
probe P742
inservice
real 10.10.107.43
probe P743
inservice
protocol tcp
sticky 180 destination
protocol datagram
sticky 180 destination
predictor hash address port
!
mls flow ip interface-full
!
!*************************************************
!* Switchports, port channels and trunks *
!* added to vlans 105-108 (left out for brevity) *
!*************************************************
!
interface Vlan105
ip vrf forwarding client
ip address 10.10.105.2 255.255.255.0
!
interface Vlan106
ip vrf forwarding client
ip address 10.10.106.2 255.255.255.0
!
interface Vlan107
ip address 10.10.107.2 255.255.255.0
!
interface Vlan108
ip address 10.10.108.2 255.255.255.0
!
ip route 10.10.105.0 255.255.255.0 10.10.107.42
ip route vrf client 10.10.108.0 255.255.255.0 10.10.106.42

プローブを使用する IOS SLB の設定:例

ここでは次の例を紹介し、さまざまな IOS SLB プローブ設定を示します。

「ping プローブおよび HTTP プローブを使用する IOS SLB の設定:例」

「ルーテッド プローブを使用する IOS SLB の設定:例」

ping プローブおよび HTTP プローブを使用する IOS SLB の設定:例

図 7 に、サーバ ファームの一部として IOS SLB 実サーバ接続を設定した例を示します。ping プローブおよび HTTP プローブを使用して、サーバ ロード バランシングを使用するアプリケーションを監視する処理を中心に説明します。

図 7 ping プローブおよび HTTP プローブ トポロジの例

:

図 7 のトポロジは、単一の仮想サーバにサービスを提供する混在型サーバ ファームです。次に、このトポロジの設定文を示します。トポロジには、PROBE1 という ping プローブと PROBE2 という HTTP プローブがあります。

! Configure ping probe PROBE1, change CLI to IOS SLB probe configuration mode
ip slb probe PROBE1 ping
! Configure probe to receive responses from IP address 13.13.13.13
address 13.13.13.13
! Configure unacknowledged ping threshold to 16
faildetect 16
! Configure ping probe timer interval to send every 11 seconds
interval 11
! Configure HTTP probe PROBE2
ip slb probe PROBE2 http
! Configure request method as POST, set URL as /probe.cgi?all
request method post url /probe.cgi?all
! Configure header HeaderName
header HeaderName HeaderValue
! Configure basic authentication username and password
credentials Semisweet chips
! Exit to global configuration mode
exit
! Enter server farm configuration mode for server farm PUBLIC
ip slb serverfarm PUBLIC
! Configure NAT server and real servers on the server farm
nat server
real 10.1.1.1
inservice
real 10.1.1.2
inservice
real 10.1.1.3
inservice
real 10.1.1.4
inservice
real 10.1.1.5
inservice
! Configure ping probe on the server farm
probe PROBE1
! Configure HTTP probe on the server farm
probe PROBE2
end

ルーテッド プローブを使用する IOS SLB の設定:例

図 8 に、一般的なデータセンターと IOS SLB の設定を示します。仮想サーバ ACME_VSERVER は、サーバ ファーム ACME_FARM の 2 つの実サーバ(10.10.10.1 と 10.10.10.2)を使用して設定されています。ユーザは、バックエンド サーバ(10.10.10.3)の動作状況に基づいて、実サーバに障害が発生していると見なすことを希望しています。実サーバを介してヘルス チェックを送信せずにこの設定を達成するには、ルーテッド ping プローブの BACKEND をバックエンド サーバの IP アドレスに定義します。

図 8 ルーテッド ping プローブを使用する IOS SLB

 

次に、図 8 の設定の IOS SLB 設定文を示します。

ip slb probe BACKEND ping
address 10.10.10.3 routed
 
ip slb serverfarm ACME_SFARM
nat server
probe BACKEND
real 10.10.10.1
inservice
real 10.10.10.2
inservice
ip slb vserver ACME_VSERVER
virtual 10.10.10.10 tcp 80
serverfarm ACME_SFARM
inservice

IOS SLB による レイヤ 3 スイッチングの設定:例

図 9 に、サーバ ファームの一部として設定した IOS SLB サーバ接続の設定例を示します。

図 9 IOS SLB のネットワーク設定

 

次の設定例に示すように、このトポロジ例には 3 つのパブリック Web サーバと、サブネット 10.4.4.0 の権限を持つクライアントに限定された 2 つの Web サーバがあります。パブリック Web サーバは容量に応じて加重が設定され、サーバ 10.1.1.2 は最も容量が低く、接続が制限されています。制限付きの Web サーバは、同じスティッキ グループのメンバとして設定されているため、同じクライアントの HTTP 設定と Secure Socket Layer(SSL)接続は、同じ実サーバを使用します。

前述した IOS SLB 機能を備えるネットワーク設定は、次のとおりです。

ip slb probe PROBE2 http
request method POST url /probe.cgi?all
header HeaderName HeaderValue
header Authorization Basic U2VtaXN3ZWV0OmNoaXBz
!
ip slb serverfarm PUBLIC
nat server
predictor leastconns
! First real server
real 10.1.1.1
reassign 4
faildetect numconns 16
retry 120
inservice
! Second real server
real 10.1.1.2
reassign 4
faildetect numconns 16
retry 120
inservice
! Third real server
real 10.1.1.3
reassign 4
faildetect numconns 16
retry 120
inservice
! Probe
probe PROBE2
! Restricted web server farm
ip slb serverfarm RESTRICTED
predictor leastconns
! First real server
real 10.1.1.20
reassign 2
faildetect numconns 4
retry 20
inservice
! Second real server
real 10.1.1.21
reassign 2
faildetect numconns 4
retry 20
inservice
!
! Unrestricted web virtual server
ip slb vserver PUBLIC_HTTP
virtual 10.0.0.1 tcp www
serverfarm PUBLIC
idle 120
delay 5
inservice
!
! Restricted HTTP virtual server
ip slb vserver RESTRICTED_HTTP
virtual 10.0.0.1 tcp www
serverfarm RESTRICTED
client 10.4.4.0 255.255.255.0
sticky 60 group 1
idle 120
delay 5
inservice
!
! Restricted SSL virtual server
ip slb vserver RESTRICTED_SSL
virtual 10.0.0.1 tcp https
serverfarm RESTRICTED
client 10.4.4.0 255.255.255.0
sticky 60 group 1
idle 120
delay 5
inservice
!
interface GigabitEthernet1/1
switchport
switchport access vlan 3
switchport mode access
no ip address
!
interface FastEthernet2/1
switchport
switchport access vlan 2
switchport mode access
no ip address
!
interface FastEthernet2/2
switchport
switchport access vlan 2
switchport mode access
no ip address
!
interface FastEthernet2/3
switchport
switchport access vlan 2
switchport mode access
no ip address
!
interface Vlan2
ip address 10.1.1.100 255.255.255.0
!
interface Vlan3
ip address 40.40.40.1 255.255.255.0

NAT を使用する IOS SLB の設定:例

図 10 に、サーバ ファームの一部として IOS SLB 実サーバ接続を設定した例を示します。NAT サーバおよびクライアントのアドレス プールの設定を中心に説明します。

図 10 IOS SLB NAT のトポロジ例

 

図 10 のトポロジには 4 つの Web サーバがあり、次のように設定されています。

サーバ 1、2、および 3 は、ポート 80 をリスンする HTTP サーバ アプリケーションを実行しています。

サーバ 4 には、ポート 8080、8081、および 8082 をリスンする複数の HTTP サーバ アプリケーションがあります。

サーバ 1 とサーバ 2 は、スイッチ A を使用して負荷が分散されます。スイッチ A はサーバ アドレス変換を実行します。

サーバ 3 とサーバ 4 は、スイッチ B とスイッチ C を使用して負荷が分散されます。これら 2 つのスイッチは、クライアントとサーバ間に複数のパスがあるため、サーバ アドレスとクライアント アドレス両方の変換を実行します。また、これらのスイッチでは、HTTP パケットとサーバ 4 の間でサーバ ポートの変換を実行する必要があります。

スイッチ A の設定文

ip slb serverfarm FARM1
! Translate server addresses
nat server
! Server 1 port 80
real 10.1.1.1
reassign 2
faildetect numconns 4 numclients 2
retry 20
inservice
! Server 2 port 80
real 10.2.1.1
reassign 2
faildetect numconns 4
retry 20
inservice
!
ip slb vserver HTTP1
! Handle HTTP (port 80) requests
virtual 128.1.0.1 tcp www
serverfarm FARM1
idle 120
delay 5
inservice

スイッチ B の設定文

ip slb natpool web-clients 128.3.0.1 128.3.0.254
! NAT address pool for clients
ip slb serverfarm FARM2
! Translate server addresses
nat server
! Translate client addresses
nat client web-clients
! Server 3 port 80
real 10.3.1.1
reassign 2
faildetect numconns 4
retry 20
inservice
! Server 4 port 8080
real 10.4.1.1 port 8080
reassign 2
faildetect numconns 4
retry 20
inservice
! Server 4 port 8081
real 10.4.1.1 port 8081
reassign 2
faildetect numconns 4
retry 20
inservice
! Server 4 port 8082
real 10.4.1.1 port 8082
reassign 2
faildetect numconns 4
retry 20
inservice
!
ip slb vserver HTTP2
! Handle HTTP (port 80) requests
virtual 128.2.0.1 tcp www
serverfarm FARM2
idle 120
delay 5
inservice

スイッチ C の設定文

ip slb natpool web-clients 128.5.0.1 128.5.0.254
! NAT address pool for clients
ip slb serverfarm FARM2
! Translate server addresses
nat server
! Translate client addresses
nat client web-clients
! Server 3 port 80
real 10.3.1.1
reassign 2
faildetect numconns 4
retry 20
inservice
! Server 4 port 8080
real 10.4.1.1 port 8080
reassign 2
faildetect numconns 4
retry 20
inservice
! Server 4 port 8081
real 10.4.1.1 port 8081
reassign 2
faildetect numconns 4
retry 20
inservice
! Server 4 port 8082
real 10.4.1.1 port 8082
reassign 2
faildetect numconns 4
retry 20
inservice
!
ip slb vserver HTTP2
! Handle HTTP (port 80) requests
virtual 128.4.0.1 tcp www
serverfarm FARM2
idle 120
delay 5
inservice

スタティック NAT を使用する IOS SLB の設定:例

次の例では、次のアイテムの設定文を示します。

DNS プローブの PROBE4。ドメイン名解決要求に対して、実サーバの IP アドレス 13.13.13.13 を返すように設定します。

サーバ ファームの DNS。サーバ NAT および PROBE4 を使用するように設定します。

サーバ ファームの DNS に関連付けられた全ポート仮想サーバの 10.11.11.11。UDP 接続にパケット別サーバ ロード バランシングを実行します。

サーバ ファームの DNS に関連付けられた実サーバ 10.1.1.3。スタティック NAT およびパケット別サーバ ロード バランシング用に設定します。

ip slb probe PROBE4 dns
lookup 13.13.13.13
!
ip slb serverfarm DNS
nat server
probe PROBE4
real 10.1.1.3
inservice
!
ip slb vserver DNS
virtual 10.11.11.11 UDP 0 service per-packet
serverfarm DNS
!
ip slb static nat 10.11.11.11 per-packet
real 10.1.1.3

ステートレス バックアップを使用する IOS SLB の設定:例

IOS SLB ステートレス バックアップを設定する方法は複数あります。各設定方法の違いは、ロード バランシング デバイスのネットワーキング機能、およびクライアント トラフィックをロード バランシング デバイスに送信する配信デバイスの機能によって変わります。

ロード バランシング デバイスに レイヤ 2 スイッチングおよび VLAN トランキングの機能がある場合(Catalyst 6500 ファミリ スイッチなど)、デバイスをその実サーバに直接接続できます。また、実サーバからの発信フローを処理しながら、IOS SLB のスタンバイとして動作できます。HSRP は、ロード バランシング デバイスのサーバ側 VLAN で使用され、実サーバは HSRP アドレスにルーティングされます。

ロード バランシング デバイスにレイヤ 2 スイッチングと VLAN トランキングの両方の機能が ない 場合、そのデバイスと実サーバを レイヤ 2 スイッチに接続する必要があります。この設定は、サーバ側 VLAN で HSRP を使用するために必要です。

配信デバイスに レイヤ 3 スイッチングの機能がある場合、アクティブなロード バランシング デバイスにフローを送信するように経路再配布を使用できます。

配信デバイスに レイヤ 2 スイッチングの機能がある場合、アクティブなロード バランシング デバイスにフローを送信するように、ロード バランシング デバイスでクライアント側の HSRP を使用できます。

ほとんどの設定で、HSRP によってフェールオーバー時間が短縮され、さらにルーティングの収束も速くなります。ロード バランシング デバイスでクライアント側およびサーバ側の HSRP の両方を使用する場合、HSRP インターフェイス トラッキングおよびプライオリティを使用して、クライアント側およびサーバ側の HSRP グループを動機する必要があります。

ここでは次の例を紹介し、さまざまな IOS SLB ステートレス バックアップ設定を示します。

「ダイナミック ルーティングおよびトランキングの設定:例」

「ダイナミック ルーティングあり、トランキングなしの設定:例」

「スタティック ルーティングおよびトランキングの設定:例」

「スタティック ルーティングあり、トランキングなしの設定:例」


) 簡略化するために、この例ではステートフル バックアップを省略しています。ステートフル バックアップを使用する例については、「ステートフル バックアップを使用する IOS SLB の設定:例」を参照してください。


ダイナミック ルーティングおよびトランキングの設定:例

図 11 に、次の特徴を持つ IOS SLB ステートレス バックアップ設定の例を示します。

実サーバ 1 の IP アドレスは 10.10.1.3、実サーバ 2 は 10.10.1.4 で、10.10.1.100 を介してクライアントにルーティングされます。

仮想サーバの IP アドレスは 10.10.14.1 です。

VLAN 1 の IP アドレスは 10.10.1.0 で、サブネット マスクは 255.255.255.0 です。

サブネット 2 の IP アドレスは 10.10.2.0 で、サブネット マスクは 255.255.255.0 です。

サブネット 3 の IP アドレスは 10.10.3.0 で、サブネット マスクは 255.255.255.0 です。

配信デバイスは EIGRP を使用して、10.10.2.1 または 10.10.3.1(IOS SLB がアクティブな方によって変わります)を介して 10.10.14.1 に送信されるルートを認識します。

図 11 レイヤ 3 およびトランキングを使用するステートレス バックアップ

 

SLB 1 の設定文

ip slb serverfarm SF1
real 10.10.1.3
reassign 2
faildetect numconns 4 numclients 2
retry 20
inservice
real 10.10.1.4
reassign 2
faildetect numconns 4
retry 20
inservice
ip slb vserver VS1
virtual 10.10.14.1 tcp www
serverfarm SF1
idle 120
delay 5
inservice standby SERVER
!
interface Ethernet1
switchport
switchport vlan 1
interface Ethernet2
ip address 10.10.2.1 255.255.255.0
interface vlan 1
ip address 10.10.1.1 255.255.255.0
standby ip 10.10.1.100
standby priority 10 preempt delay sync 20
standby name SERVER
standby track Ethernet2
standby timers 1 3
router eigrp 666
redistribute static
network 10.0.0.0

SLB 2 の設定文

ip slb serverfarm SF1
real 10.10.1.3
reassign 2
faildetect numconns 4
retry 20
inservice
real 10.10.1.4
reassign 2
faildetect numconns 4
retry 20
inservice
ip slb vserver VS1
virtual 10.10.14.1 tcp www
serverfarm SF1
idle 120
delay 5
inservice standby SERVER
!
interface GigabitEthernet1
no ip address
switchport
switchport trunk encapsulation isl
interface Ethernet1
switchport
switchport vlan 1
interface Ethernet2
ip address 10.10.3.1 255.255.255.0
interface vlan 1
ip address 10.10.1.2 255.255.255.0
standby ip 10.10.1.100
standby priority 5 preempt delay sync 20
standby name SERVER
standby track Ethernet2
standby timers 1 3
router eigrp 666
redistribute static
network 10.0.0.0

ダイナミック ルーティングあり、トランキングなしの設定:例

図 12 に、次の特徴を持つ IOS SLB ステートレス バックアップ設定の例を示します。

実サーバ 1 の IP アドレスは 10.10.1.3、実サーバ 2 は 10.10.1.4 で、10.10.1.100 を介してクライアントにルーティングされます。

仮想サーバの IP アドレスは 10.10.14.1 です。

サブネット 2 の IP アドレスは 10.10.2.0 で、サブネット マスクは 255.255.255.0 です。

サブネット 3 の IP アドレスは 10.10.3.0 で、サブネット マスクは 255.255.255.0 です。

配信デバイスは EIGRP を使用して、10.10.2.2 または 10.10.3.2(IOS SLB がアクティブな方によって変わります)を介して 10.10.14.1 に送信されるルートを認識します。

図 12 レイヤ 3 あり、トランキングなしのステートレス バックアップ

 

SLB 1 の設定文

ip slb serverfarm SF1
real 10.10.1.3
reassign 2
faildetect numconns 4
retry 20
inservice
real 10.10.1.4
reassign 2
faildetect numconns 4
retry 20
inservice
ip slb vserver VS1
virtual 10.10.14.1 tcp www
serverfarm SF1
idle 120
delay 5
inservice standby SERVER
!
interface Ethernet1
ip address 10.10.1.1 255.255.255.0
standby ip 10.10.1.100
standby priority 10 preempt delay sync 20
standby name SERVER
standby track Ethernet2
standby timers 1 3
interface Ethernet2
ip address 10.10.2.1 255.255.255.0
router eigrp 666
redistribute static
network 10.0.0.0

SLB 2 の設定文

ip slb serverfarm SF1
real 10.10.1.3
reassign 2
faildetect numconns 4
retry 20
inservice
real 10.10.1.4
reassign 2
faildetect numconns 4
retry 20
inservice
ip slb vserver VS1
virtual 10.10.14.1 tcp www
serverfarm SF1
idle 120
delay 5
inservice standby SERVER
!
interface Ethernet1
ip address 10.10.1.2 255.255.255.0
standby ip 10.10.1.100
standby priority 5 preempt delay sync 20
standby name SERVER
standby track Ethernet2
standby timers 1 3
interface Ethernet2
ip address 10.10.3.1 255.255.255.0
router eigrp 666
redistribute static
network 10.0.0.0

スタティック ルーティングおよびトランキングの設定:例

図 13 に、次の特徴を持つ IOS SLB ステートレス バックアップ設定の例を示します。

実サーバ 1 の IP アドレスは 10.10.1.3、実サーバ 2 は 10.10.1.4 で、10.10.1.100 を介してクライアントにルーティングされます。

仮想サーバの IP アドレスは 10.10.14.1 です。

VLAN 1 の IP アドレスは 10.10.1.0 で、サブネット マスクは 255.255.255.0 です。

サブネット 2 の IP アドレスは 10.10.2.0 で、サブネット マスクは 255.255.255.0 です。

サブネット 3 の IP アドレスは 10.10.3.0 で、サブネット マスクは 255.255.255.0 です。

この設定では、配信デバイスで HSRP ルートにスタティック ルーティングを使用します。

図 13 レイヤ 2 およびトランキングを使用するステートレス バックアップ

 

SLB 1 の設定文

ip slb serverfarm SF1
real 10.10.1.3
reassign 2
faildetect numconns 4
retry 20
inservice
real 10.10.1.4
reassign 2
faildetect numconns 4
retry 20
inservice
ip slb vserver VS1
virtual 10.10.14.1 tcp www
serverfarm SF1
idle 120
delay 5
inservice standby SERVER
!
interface Ethernet1
switchport
switchport vlan 1
interface Ethernet2
ip address 10.10.2.1 255.255.255.0
standby ip 10.10.2.100
standby priority 10 preempt delay sync 20
standby track vlan1
standby timers 1 3
interface vlan 1
ip address 10.10.1.1 255.255.255.0
standby ip 10.10.1.100
standby priority 10 preempt delay sync 20
standby name SERVER
standby track Ethernet2
standby timers 1 3

SLB 2 の設定文

ip slb serverfarm SF1
real 10.10.1.3
reassign 2
faildetect numconns 4
retry 20
inservice
real 10.10.1.4
reassign 2
faildetect numconns 4
retry 20
inservice
ip slb vserver VS1
virtual 10.10.14.1 tcp www
serverfarm SF1
idle 120
delay 5
inservice standby SERVER
!
interface GigabitEthernet1
no ip address
switchport
switchport trunk encapsulation isl
interface Ethernet1
switchport
switchport vlan 1
interface Ethernet2
ip address 10.10.2.2 255.255.255.0
standby ip 10.10.2.100
standby priority 5 preempt delay sync 20
standby track vlan 1
standby timers 1 3
interface vlan 1
ip address 10.10.1.2 255.255.255.0
standby ip 10.10.1.100
standby priority 5 preempt delay sync 20
standby name SERVER
standby track Ethernet2
standby timers 1 3

配信デバイスの設定文

interface Ethernet1
switchport
switchport distribution vlan 2
interface Ethernet2
switchport
switchport distribution vlan 2
interface vlan2
ip address 10.10.2.3 255.255.255.0
no shut
ip route 10.10.14.1 255.255.255.255 10.10.2.100

スタティック ルーティングあり、トランキングなしの設定:例

図 14 に、次の特徴を持つ IOS SLB ステートレス バックアップ設定の例を示します。

実サーバ 1 の IP アドレスは 10.10.1.3、実サーバ 2 は 10.10.1.4 で、10.10.1.100 を介してクライアントにルーティングされます。

仮想サーバの IP アドレスは 10.10.14.1 です。

サブネット 2 の IP アドレスは 10.10.2.0 で、サブネット マスクは 255.255.255.0 です。

サブネット 3 の IP アドレスは 10.10.3.0 で、サブネット マスクは 255.255.255.0 です。

この設定では、配信デバイスで HSRP ルートにスタティック ルーティングを使用します。

図 14 レイヤ 2 あり、トランキングなしのステートレス バックアップ

 

SLB 1 の設定文

ip slb serverfarm SF1
real 10.10.1.3
reassign 2
faildetect numconns 4
retry 20
inservice
real 10.10.1.4
reassign 2
faildetect numconns 4
retry 20
inservice
ip slb vserver VS1
virtual 10.10.14.1 tcp www
serverfarm SF1
idle 120
delay 5
inservice standby SERVER
!
interface Ethernet1
ip address 10.10.1.1 255.255.255.0
standby ip 10.10.1.100
standby priority 10 preempt delay sync 20
standby name SERVER
standby track Ethernet2
standby timers 1 3
interface Ethernet2
ip address 10.10.2.1 255.255.255.0
standby ip 10.10.2.100
standby priority 10 preempt delay sync 20
standby track Ethernet1
standby timers 1 3

SLB 2 の設定文

ip slb serverfarm SF1
real 10.10.1.3
reassign 2
faildetect numconns 4
retry 20
inservice
real 10.10.1.4
reassign 2
faildetect numconns 4
retry 20
inservice
ip slb vserver VS1
virtual 10.10.14.1 tcp www
serverfarm SF1
idle 120
delay 5
inservice standby SERVER
!
interface Ethernet1
ip address 10.10.1.2 255.255.255.0
standby ip 10.10.1.100
standby priority 5 preempt delay sync 20
standby name SERVER
standby track Ethernet2
standby timers 1 3
!
interface Ethernet2
ip address 10.10.2.2 255.255.255.0
standby ip 10.10.2.100
standby priority 5 preempt delay sync 20
standby track Ethernet1
standby timers 1 3

配信デバイスの設定文

interface Ethernet1
switchport
switchport distribution vlan 2
interface Ethernet2
switchport
switchport distribution vlan 2
interface vlan2
ip address 10.10.2.3 255.255.255.0
no shut
ip route 10.10.14.1 255.255.255.255 10.10.2.100

ステートフル バックアップを使用する IOS SLB の設定:例

この設定例では、サーバ ファームの一部として設定されている IOS SLB 実サーバ接続と、ステートフル バックアップ スタンバイ接続を使用するファスト イーサネット インターフェイス上の実サーバおよび仮想サーバを中心に説明します。

図 15 はステートフル バックアップ設定の例です。クライアント側およびサーバ側の両方で HSRP を使用して、フェールオーバーを処理します。実サーバは発信フローを 10.10.3.100 にルーティングします。これはサーバ側インターフェイスの HSRP アドレスです。クライアント(アクセス ルータ)は、クライアント側の HSRP アドレスである 10.10.2.100 を介して、仮想 IP アドレス(10.10.10.12)にルーティングされます。

ループバック インターフェイスは、これらのメッセージ交換のために、両方のデバイスで設定されています。また、各 IOS SLB には、他のスイッチ ループバック アドレス宛ての二重ルートを割り当てる必要があります。この設定では、インターフェイスで障害が発生しても、レプリケーション メッセージを送信できます。


) HSRP が適切に機能するには、IOS SLB スイッチ間のすべての レイヤ 2 デバイスに set spantree portfast コマンドを設定する必要があります。


図 15 IOS SLB ステートフル環境

 

スイッチ SLB1 の設定文

ip slb serverfarm SF1
nat server
real 10.10.3.1
inservice
real 10.10.3.2
inservice
real 10.10.3.3
inservice
!
ip slb vserver VS1
virtual 10.10.10.12 tcp telnet
serverfarm SF1
replicate casa 10.10.99.132 10.10.99.99 1024 password PASS
inservice standby virt
!
interface loopback 1
ip address 10.10.99.132 255.255.255.255
!
interface FastEthernet1
ip address 10.10.3.132 255.255.255.0
no ip redirects
no ip mroute-cache
standby priority 5 preempt
standby name out
standby ip 10.10.3.100
standby track FastEthernet2
standby timers 1 3
interface FastEthernet2
ip address 10.10.2.132 255.255.255.0
no ip redirects
standby priority 5
standby name virt
standby ip 10.10.2.100
standby timers 1 3

スイッチ SLB2 の設定文

ip slb serverfarm SF1
nat server
real 10.10.3.1
inservice
real 10.10.3.2
inservice
real 10.10.3.3
inservice
!
ip slb vserver VS1
virtual 10.10.10.12 tcp telnet
serverfarm SF1
replicate casa 10.10.99.99 10.10.99.132 1024 password PASS
inservice standby virt
!
interface loopback 1
ip address 10.10.99.99 255.255.255.255
!
interface FastEthernet2
ip address 10.10.2.99 255.255.255.0
no ip redirects
no ip route-cache
no ip mroute-cache
standby priority 10 preempt delay sync 20
standby name virt
standby ip 10.10.2.100
standby track FastEthernet3
standby timers 1 3
!
interface FastEthernet3
ip address 10.10.3.99 255.255.255.0
no ip redirects
no ip route-cache
no ip mroute-cache
standby priority 10 preempt delay 20
standby name out
standby ip 10.10.3.100
standby track FastEthernet2
standby timers 1 3

冗長ルート プロセッサのステートフル バックアップを使用する IOS SLB の設定:例

図 16 の IOS SLB デバイスには、ステートフル バックアップ用に設定されている 2 つのスーパーバイザ エンジンが含まれます。アクティブなスーパーバイザ エンジンに障害が発生すると、IOS SLB 同期情報が設定済みの RPR+ を介して、バックアップ スーパーバイザ エンジンが引き継ぎます。IOS SLB は、アクティブなスーパーバイザ エンジンの仮想サーバ ACME_VSERVER(10.10.10.10)の状態情報を、20 秒ごとにバックアップにレプリケートします。実サーバ(10.10.10.1、10.10.10.2、および 10.10.10.3)は、サーバ ファーム ACME_SFARM に設定されます。

図 16 冗長ルート プロセッサを使用する IOS SLB

 

次に、図 16 の設定の IOS SLB 設定文を示します。

ip slb replicate slave rate 300
 
ip slb serverfarm ACME_SFARM
nat server
real 10.10.10.1
inservice
real 10.10.10.2
inservice
real 10.10.10.3
inservice
 
ip slb vserver ACME_VSERVER
virtual 10.10.10.10 tcp 80
replicate interval 20
replicate slave
serverfarm ACME_SFARM
inservice

アクティブ スタンバイを使用する IOS SLB の設定:例

図 17 に、アクティブ スタンバイに設定されている IOS SLB ネットワークを示します。このネットワークには、同じ仮想 IP アドレスの負荷を分散し、さらに相互にバックアップしあう 2 つの IOS SLB デバイスがあります。いずれかのデバイスに障害が発生すると、もう一方は通常の HSRP フェールオーバーと IOS SLB ステートレス冗長機能を介して負荷を引き継ぎます。

図 17 IOS SLB アクティブ スタンバイ

 

図 17 のネットワーク設定例には、次の特徴があります。

SLB 1 はサーバ 1A および 1B の負荷を分散し、SLB 2 は 2A および 2B の負荷を分散します。

単一の仮想 IP アドレス(Web の場合は 10.10.10.12)は、2 つの IOS SLB デバイス全体でサポートされます。

クライアント トラフィックはアクセス ルータで分割され、IP アドレスが偶数のクライアントは HSRP1(10.10.5.100)に送信され、IP アドレスが奇数のクライアントは HSRP2(10.10.2.100)に送信されます。IP アドレスが奇数のクライアントの場合、SLB 1 がプライマリとして設定され、IP アドレスが奇数のクライアントの場合、SLB 2 がプライマリになります。

IOS SLB デバイスは、分離された各実サーバ セットにトラフィックを分散します(この例でクライアント NAT を使用する場合、この特徴は必須ではなくなります)。

各実サーバ セットには、IOS SLB デバイスに設定されているデフォルト ゲートウェイがあります。

VLAN 105 の HSRP アドレスは 10.10.5.100 です。VLAN 102 の HSRP アドレスは 10.10.2.100 です。

SLB 1 の設定文

ip slb serverfarm EVEN
nat server
real 10.10.3.2
reassign 2
faildetect numconns 4 numclients 2
retry 20
inservice
real 10.10.3.3
reassign 2
faildetect numconns 4
retry 20
inservice
!
ip slb serverfarm ODD
nat server
real 10.10.3.2
reassign 2
faildetect numconns 4
retry 20
inservice
real 10.10.3.3
reassign 2
faildetect numconns 4
retry 20
inservice
!-----Same EVEN virtual server as in SLB 2
ip slb vserver EVEN
virtual 10.10.10.12 tcp www
serverfarm EVEN
client 0.0.0.0 0.0.0.1
idle 120
delay 5
!-----See standby name in Ethernet 3/3 below
inservice standby STANDBY_EVEN
!-----Same ODD virtual server as in SLB 2
ip slb vserver ODD
virtual 10.10.10.12 tcp www
serverfarm ODD
client 0.0.0.1 0.0.0.1
idle 120
delay 5
!-----See standby name in Ethernet 3/2 below
inservice standby STANDBY_ODD
!
interface Ethernet3/2
ip address 10.10.5.132 255.255.255.0
standby priority 20 preempt delay sync 20
!-----See standby name in SLB 2, Ethernet 3/5
standby name STANDBY_ODD
standby ip 10.10.5.100
standby track Ethernet3/3
standby timers 1 3
!
interface Ethernet3/3
ip address 10.10.2.132 255.255.255.0
standby priority 10
!-----See standby name in SLB 2, Ethernet 3/1
standby name STANDBY_EVEN
standby ip 10.10.2.100
standby track Ethernet3/2
standby timers 1 3

SLB 2 の設定文

ip slb serverfarm EVEN
nat server
real 10.10.3.4
reassign 2
faildetect numconns 4
retry 20
inservice
real 10.10.3.5
reassign 2
faildetect numconns 4
retry 20
inservice
!
ip slb serverfarm ODD
nat server
real 10.10.3.4
reassign 2
faildetect numconns 4
retry 20
inservice
real 10.10.3.5
reassign 2
faildetect numconns 4
retry 20
inservice
!-----Same EVEN virtual server as in SLB 1
ip slb vserver EVEN
virtual 10.10.10.12 tcp www
serverfarm EVEN
client 0.0.0.0 0.0.0.1
idle 120
delay 5
!-----See standby name in Ethernet 3/1 below
inservice standby STANDBY_EVEN
!-----Same ODD virtual server as in SLB 1
ip slb vserver ODD
virtual 10.10.10.12 tcp www
serverfarm ODD
client 0.0.0.1 0.0.0.1
idle 120
delay 5
!-----See standby name in Ethernet 3/5 below
inservice standby STANDBY_ODD
!
interface Ethernet3/1
ip address 10.10.2.128 255.255.255.0
standby priority 20 preempt delay sync 20
!-----See standby name in SLB 1, Ethernet 3/3
standby name STANDBY_EVEN
standby ip 10.10.2.100
standby track Ethernet3/5
standby timers 1 3
!
interface Ethernet3/5
ip address 10.10.5.128 255.255.255.0
standby priority 10 preempt delay sync 20
!-----See standby name in SLB 1, Ethernet 3/2
standby name STANDBY_ODD
standby ip 10.10.5.100
standby track Ethernet3/1
standby timers 1 3

アクセス ルータの設定文

interface Ethernet0/0
ip address 10.10.5.183 255.255.255.0
no ip directed-broadcast
no ip route-cache
no ip mroute-cache
!
interface Ethernet0/1
ip address 10.10.2.183 255.255.255.0
no ip directed-broadcast
no ip route-cache
no ip mroute-cache
!
interface Ethernet0/2
ip address 10.10.6.183 255.255.255.0
no ip directed-broadcast
no ip route-cache
no ip mroute-cache
ip policy route-map virts
!
access-list 100 permit ip 0.0.0.1 255.255.255.254 host 10.10.10.12
access-list 101 permit ip 0.0.0.0 255.255.255.254 host 10.10.10.12
route-map virts permit 10
match ip address 100
set ip next-hop 10.10.5.100
!
route-map virts permit 15
match ip address 101
set ip next-hop 10.10.2.100

スタティック ルートの再配布を使用する IOS SLB の設定:例

図 18 に、スタティック ルートを仮想サーバの IP アドレスに配布するように設定されている IOS SLB ネットワークを示します。仮想サーバをサービスに参加させるとき( inservice コマンドを使用します)、アドレスをアドバタイズする場合、そのアドレスへのルートは、 static としてルーティング テーブルに追加されます。仮想サーバの IP アドレスをアドバタイズする方法の詳細については、『 Cisco IOS IP Application Services Command Reference 』の advertise コマンドの説明を参照してください。

ルーティング設定はプロトコルによって異なるため、いくつかのルーティング プロトコルの設定例を示します。

図 18 スタティック ルートの IOS SLB の再配布

 

Routing Information Protocol(RIP)

図 18 の IOS SLB スイッチの RIP スタティック ルートの再配布設定を次に示します。

router rip
redistribute static
network 10.0.0.0
network 8.0.0.0
 

図 18 のルーティングの更新をリスンするアクセス ルータに関する RIP スタティック ルートの再配布設定を次に示します。

router rip
network 10.0.0.0
network 8.0.0.0

Open Shortest Path First(OSPF)

図 18 の IOS SLB スイッチの OSPF スタティック ルートの再配布設定を次に示します。

router ospf 1
redistribute static subnets
network 10.10.6.217 0.0.0.0 area 0
network 8.8.8.0 0.0.0.255 area 0
 

図 18 のルーティングの更新をリスンするアクセス ルータに関する OSPF スタティック ルートの再配布設定を次に示します。

router ospf 1
network 10.10.6.2 0.0.0.0 area 0
network 8.8.8.0 0.0.0.255 area 0

Interior Gateway Routing Protocol(IGRP)

図 18 の IOS SLB スイッチの IGRP スタティック ルートの再配布設定を次に示します。

router igrp 1
redistribute connected
redistribute static
network 8.0.0.0
network 10.0.0.0
 

図 18 のルーティングの更新をリスンするアクセス ルータに関する IGRP スタティック ルートの再配布設定を次に示します。

router igrp 1
network 8.0.0.0
network 10.0.0.0

Enhanced Interior Gateway Routing Protocol(Enhanced IGRP)

図 18 の IOS SLB スイッチの Enhanced IGRP スタティック ルートの再配布設定を次に示します。

router eigrp 666
redistribute static
network 10.0.0.0
network 8.0.0.0
 

図 18 のルーティングの更新をリスンするアクセス ルータに関する Enhanced IGRP スタティック ルートの再配布設定を次に示します。

router eigrp 666
network 10.0.0.0
network 8.0.0.0

WAP および UDP ロード バランシングを使用する IOS SLB の設定:例

図 19 に、WAP フローの負荷を分散するように設定されている IOS SLB ネットワークを示します。この例の場合:

WAP フローの負荷は、WAP ゲートウェイ 10.10.2.1、10.10.2.2、および 10.10.2.3 で分散されます。

クライアントは、IOS SLB 仮想サーバ アドレス 10.10.1.1 に接続します。

接続のアイドル時間が仮想サーバのアイドル接続タイマーよりも長い場合(この例では 3000 秒)、そのセッションに関するロード バランシングの判断は変わります。

図 19 WAP ロード バランシングを使用する IOS SLB

 

WAP の場合に IOS SLB のロード バランシングを設定するには、2 つの方法があります。

コネクション型 WSP モードで実行されているセッションの負荷を分散するには、WSP プローブを定義し、WAP ロード バランシングを使用します。WAP ロード バランシングには、WAP ポートの 1 つで、WAP 仮想サーバを設定する必要があります。

コネクションレス型 WSP モード、コネクションレス型セキュア WSP モード、およびコネクション型セキュア WSP モードで実行されているセッションの負荷を分散するには、ping プローブまたは WSP プローブを定義し、低いアイドル タイマーを指定した標準の UDP ロード バランシングを使用します。

UDP ポート 9201 の WAP フローのロード バランシング

次に、図 19 に示す IOS SLB デバイスの設定例を示します。UDP ポート 9201 の WAP フローの負荷を分散します(WSP/WTP/UDP)。

ip slb probe PROBE3 wsp
url http://localhost/test.txt
!
ip slb serverfarm WAPFARM
nat server
real 10.10.2.1
inservice
real 10.10.2.2
inservice
real 10.10.2.3
inservice
probe PROBE3
!
ip slb vserver VSERVER
virtual 10.10.1.1 udp 9201
serverfarm WAPFARM
idle 3000
inservice

UDP ポート 9203 の WAP フローのロード バランシング

次に、図 19 に示す IOS SLB デバイスの設定例を示します。UDP ポート 9203 の WAP フローの負荷を分散します(WSP/WTP/WTLS/UDP)。

ip slb probe PROBE1 ping
!
ip slb serverfarm WAPFARM
nat server
real 10.10.2.1
inservice
real 10.10.2.2
inservice
real 10.10.2.3
inservice
probe PROBE1
!
ip slb vserver VSERVER
virtual 10.10.1.1 udp 9203
serverfarm WAPFARM
idle 3000
inservice

ルート ヘルス インジェクションを使用する IOS SLB の設定:例

ここでは次の例を紹介し、さまざまな IOS SLB ルート ヘルス インジェクションの設定を示します。

「1 つずつ Web サーバがある 2 つの分散サイトの設定:例」

「2 つずつ Web サーバがある 2 つの分散サイトの設定:例」

「それぞれ 1 つの Web サーバと 1 つのバックアップ IOS SLB スイッチがある 2 つの分散サイトの設定:例」

1 つずつ Web サーバがある 2 つの分散サイトの設定:例

図 20 に、次の特徴を持つルート ヘルス インジェクションを使用して設定した IOS SLB ネットワークを示します。

両方の IOS SLB デバイスは、同じ仮想 IP アドレスで設定されます。

各 IOS SLB デバイスには、実サーバとしてローカルで接続された Web サーバだけを含むサーバ ファームがあります。

SLB A へのパスは低い加重です。

図 20 1 つずつ Web サーバがある 2 つの分散サイト

 

図 20 の両方の Web サーバが動作している場合、クライアント ルータは、両方の IOS SLB デバイスからホスト ルートを受信します。

Web サーバ A に障害が発生すると、SLB A 上にある仮想 IP アドレスの仮想サーバは FAILED 状態になり、仮想 IP アドレスのホスト ルートのアドバタイジングを停止します。すると、クライアント ルータは、SLB B へのルートを使用し始めます。

Web サーバ A がまた使用可能になると、仮想サーバは仮想 IP アドレスのホスト ルートを改めてアドバタイズし、クライアント ルータは SLB A の使用を開始します。

2 つずつ Web サーバがある 2 つの分散サイトの設定:例

図 21 に、次の特徴を持つルート ヘルス インジェクションを使用して設定した IOS SLB ネットワークを示します。

両方の IOS SLB デバイスは、同じ仮想 IP アドレスで設定されます。

各 IOS SLB デバイスには、実サーバとしてローカルで接続された 2 つの Web サーバを含むサーバ ファームがあります。

SLB A へのパスは低い加重です。

図 21 2 つずつ Web サーバがある 2 つの分散サイト

 

図 21 のすべての Web サーバが動作している場合、クライアント ルータは、両方の IOS SLB デバイスからホスト ルートを受信します。

いずれかのサーバ ファームの一方の Web サーバに障害が発生すると、その IOS SLB デバイスによるルートのアドバタイジングは継続されます。

Web サーバ A1 と Web サーバ A2 の両方に障害が発生すると、SLB A 上にある仮想 IP アドレスの仮想サーバは FAILED 状態になり、仮想 IP アドレスのホスト ルートのアドバタイジングを停止します。すると、クライアント ルータは、SLB B へのルートを使用し始めます。

Web サーバ A1 または Web サーバ A2 がまた使用可能になると、仮想サーバは仮想 IP アドレスのホスト ルートを改めてアドバタイズし、クライアント ルータは SLB A の使用を開始します。

それぞれ 1 つの Web サーバと 1 つのバックアップ IOS SLB スイッチがある 2 つの分散サイトの設定:例

図 22 に、次の特徴を持つルート ヘルス インジェクションを使用して設定した IOS SLB ネットワークを示します。

両方の IOS SLB デバイスは、同じ仮想 IP アドレスで設定されます。

各 IOS SLB デバイスには、実サーバとしてローカルで接続された Web サーバだけを含むサーバ ファームがあります。

各サイトには、プライマリ IOS SLB デバイスとバックアップ IOS SLB デバイスがあります。

SLB A へのパスは低い加重です。

図 22 それぞれ 1 つの Web サーバと 1 つのバックアップ IOS SLB スイッチがある 2 つの分散サイト

 

図 22 の両方の Web サーバが動作している場合、クライアント ルータは、SLB A Primary および SLB B Primary の両方からホスト ルートを受信します。

SLB A Primary に障害が発生すると、SLB A Backup は仮想 IP アドレスに対するホスト ルートのアドバタイジングを開始します。SLB A Backup にも障害が発生すると、SLB A Primary および SLB A Backup 上にある仮想 IP アドレスの仮想サーバは FAILED 状態になり、仮想 IP アドレスのホスト ルートのアドバタイジングを停止します。すると、クライアント ルータは SLB B Primary(SLB B Primary が使用できない場合は、SLB B Backup)に対するルートの使用を開始します。

SLB A Primary または SLB A Backup がまた使用可能になると、仮想サーバは仮想 IP アドレスのホスト ルートを改めてアドバタイズし、クライアント ルータは SLB A Primary または SLB A Backup の使用を開始します。

GTP Cause Code Inspection なしで GPRS ロード バランシングを使用する IOS SLB の設定: 例

図 23 に、GTP Cause Code Inspection をイネーブルに しない 一般的な GPRS ロード バランシング設定を示します。この設定の場合:

IOS SLB は、複数の実 GGSN について GPRS フローの負荷を分散できます。SGSN からは、複数の実 GGSN が単一の仮想 GGSN のように「見え」ます。この設定では、実 GGSN のフロー処理能力を増やし、信頼性と可用性を向上しています。

SGSN の仮想テンプレート アドレスは 10.111.111.111 です。

GGSN1 の仮想テンプレート アドレスは 192.168.1.1 です。

GGSN2 の仮想テンプレート アドレスは 192.168.2.2 です。

GGSN3 の仮想テンプレート アドレスは 192.168.3.3 です。

図 23 GPRS ロード バランシングを使用する IOS SLB

 

次に、図 23 の設定の設定文を示します。

「IOS SLB の設定文」

「GGSN1 の設定文」

「GGSN2 の設定文」

「GGSN3 の設定文」

詳細な GGSN 設定例については、『 Cisco IOS Mobile Wireless Configuration Guide 』を参照してください。

IOS SLB の設定文

hostname GTP_SLB
!
ip domain-name gprs.com
!
ip slb serverfarm GPRS
real 192.168.1.1
weight 1
faildetect numconns 1 numclients 1
inservice
!
real 192.168.2.2
weight 1
faildetect numconns 1 numclients 1
inservice
!
 
real 192.168.3.3
weight 1
faildetect numconns 1 numclients 1
inservice
!
ip slb vserver FOR_GPRS
virtual 10.10.10.10 udp 3386 service gtp
serverfarm GPRS
inservice
!
ip slb dfp password Password1 0
agent 10.1.1.201 1111 30 0 10
agent 10.1.1.202 1111 30 0 10
agent 10.1.1.203 1111 30 0 10
!
interface FastEthernet1/0
description TO SERVERFARM GPRS
ip address 10.1.1.100 255.255.255.0
no ip redirects
duplex half
!
interface FastEthernet3/0
description TO SGSN
ip address 10.2.1.100 255.255.255.0
no ip mroute-cache
duplex half
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
ip route 192.168.1.1 255.255.255.255 10.1.1.201
ip route 192.168.2.2 255.255.255.255 10.1.1.202
ip route 192.168.3.3 255.255.255.255 10.1.1.203

GGSN1 の設定文

service gprs ggsn
!
hostname GGSN1
!
ip dfp agent gprs
port 1111
password Password1 0
inservice
!
ip domain-name gprs.com
!
interface loopback 1
description LOOPBACK SAME AS IOS SLB VSERVER ADDRESS
ip address 10.10.10.10 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface FastEthernet1/0
description TO SLB
ip address 10.1.1.201 255.255.255.0
ip directed-broadcast
no ip mroute-cache
duplex half
!
interface Virtual-Template1
description GTP VIRTUAL TEMPLATE
ip address 192.168.1.1 255.255.255.0
encapsulation gtp
gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
access-point 1
access-point-name gprs.company.com
access-mode non-transparent
ip-address-pool dhcp-proxy-client
dhcp-server 10.100.0.5 10.100.0.6
dhcp-gateway-address 10.27.3.1
exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32
gprs slb cef 10.10.10.10

GGSN2 の設定文

service gprs ggsn
!
hostname GGSN2
!
ip dfp agent gprs
port 1111
password Password1 0
inservice
!
ip domain-name gprs.com
!
interface loopback 1
description LOOPBACK SAME AS IOS SLB VSERVER ADDRESS
ip address 10.10.10.10 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface FastEthernet1/0
description TO SLB
ip address 10.1.1.202 255.255.255.0
ip directed-broadcast
no ip mroute-cache
duplex half
!
interface Virtual-Template1
description GTP VIRTUAL TEMPLATE
ip address 192.168.2.2 255.255.255.0
encapsulation gtp
gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
access-point 1
access-point-name gprs.company.com
access-mode non-transparent
ip-address-pool dhcp-proxy-client
dhcp-server 10.100.0.5 10.100.0.6
dhcp-gateway-address 10.27.3.1
exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32
gprs slb cef 10.10.10.10

GGSN3 の設定文

service gprs ggsn
!
hostname GGSN3
!
ip dfp agent gprs
port 1111
password Password1 0
inservice
!
ip domain-name gprs.com
!
interface loopback 1
description LOOPBACK SAME AS IOS SLB VSERVER ADDRESS
ip address 10.10.10.10 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface FastEthernet1/0
description TO SLB
ip address 10.1.1.203 255.255.255.0
ip directed-broadcast
no ip mroute-cache
duplex half
!
interface Virtual-Template1
description GTP VIRTUAL TEMPLATE
ip address 192.168.3.3 255.255.255.0
encapsulation gtp
gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
access-point 1
access-point-name gprs.company.com
access-mode non-transparent
ip-address-pool dhcp-proxy-client
dhcp-server 10.100.0.5 10.100.0.6
dhcp-gateway-address 10.27.3.1
exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32
gprs slb cef 10.10.10.10

GPRS ロード バランシングおよび NAT を使用する IOS SLB の設定:例

次の例では、図 23 のネットワークを含め、「GTP Cause Code Inspection なしで GPRS ロード バランシングを使用する IOS SLB の設定: 例」と同じ基本設定を使用しますが、NAT を追加します。

「IOS SLB の設定文」

「GGSN1 の設定文」

「GGSN2 の設定文」

「GGSN3 の設定文」

詳細な GGSN 設定例については、『 Cisco IOS Mobile Wireless Configuration Guide 』を参照してください。

IOS SLB の設定文

hostname GTP_SLB
!
ip domain-name gprs.com
!
ip slb serverfarm GPRS
nat server
real 192.168.1.1
weight 1
faildetect numconns 1 numclients 1
inservice
!
real 192.168.2.2
weight 1
faildetect numconns 1 numclients 1
inservice
!
real 192.168.3.3
weight 1
faildetect numconns 1 numclients 1
inservice
!
ip slb vserver FOR_GPRS
virtual 10.10.10.10 udp 3386 service gtp
serverfarm GPRS
inservice
!
ip slb dfp password Password1 0
agent 10.1.1.201 1111 30 0 10
agent 10.1.1.202 1111 30 0 10
agent 10.1.1.203 1111 30 0 10
!
interface FastEthernet1/0
description TO SERVERFARM GPRS
ip address 10.1.1.100 255.255.255.0
no ip redirects
duplex half
!
interface FastEthernet3/0
description TO SGSN
ip address 10.2.1.100 255.255.255.0
no ip mroute-cache
duplex half
!
 
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
ip route 192.168.1.1 255.255.255.255 10.1.1.201
ip route 192.168.2.2 255.255.255.255 10.1.1.202
ip route 192.168.3.3 255.255.255.255 10.1.1.203

GGSN1 の設定文

service gprs ggsn
!
hostname GGSN1
!
ip dfp agent gprs
port 1111
password Password1 0
inservice
!
ip domain-name gprs.com
!
interface FastEthernet1/0
description TO SLB
ip address 10.1.1.201 255.255.255.0
ip directed-broadcast
no ip mroute-cache
duplex half
!
interface Virtual-Template1
description GTP VIRTUAL TEMPLATE
ip address 192.168.1.1 255.255.255.0
encapsulation gtp
gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
access-point 1
access-point-name gprs.company.com
access-mode non-transparent
ip-address-pool dhcp-proxy-client
dhcp-server 10.100.0.5 10.100.0.6
dhcp-gateway-address 10.27.3.1
exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32

GGSN2 の設定文

service gprs ggsn
!
hostname GGSN2
!
ip dfp agent gprs
port 1111
password Password1 0
inservice
!
ip domain-name gprs.com
!
interface FastEthernet1/0
description TO SLB
ip address 10.1.1.202 255.255.255.0
ip directed-broadcast
no ip mroute-cache
duplex half
interface Virtual-Template1
description GTP VIRTUAL TEMPLATE
ip address 192.168.2.2 255.255.255.0
encapsulation gtp
gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
access-point 1
access-point-name gprs.company.com
access-mode non-transparent
ip-address-pool dhcp-proxy-client
dhcp-server 10.100.0.5 10.100.0.6
dhcp-gateway-address 10.27.3.1
exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32

GGSN3 の設定文

service gprs ggsn
!
hostname GGSN3
!
ip dfp agent gprs
port 1111
password Password1 0
inservice
!
ip domain-name gprs.com
!
interface FastEthernet1/0
description TO SLB
ip address 10.1.1.203 255.255.255.0
ip directed-broadcast
no ip mroute-cache
duplex half
!
 
interface Virtual-Template1
description GTP VIRTUAL TEMPLATE
ip address 192.168.3.3 255.255.255.0
encapsulation gtp
gprs access-point-list gprs1
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
!
gprs access-point-list gprs1
access-point 1
access-point-name gprs.company.com
access-mode non-transparent
ip-address-pool dhcp-proxy-client
dhcp-server 10.100.0.5 10.100.0.6
dhcp-gateway-address 10.27.3.1
exit
!
gprs maximum-pdp-context-allowed 45000
gprs qos map canonical-qos
gprs gtp path-echo-interval 0
gprs dfp max-weight 32

GPRS ロード バランシング、NAT、および GTP Cause Code Inspection を使用する IOS SLB の設定: Example

次の例では、図 23 のネットワークを含め、「GPRS ロード バランシングおよび NAT を使用する IOS SLB の設定:例」と同じ基本設定を使用しますが、GTP Cause Code Inspection をイネーブルにします。この設定の場合:

GSN アイドル タイマーは 20 秒に設定されます。

GTP 要求のアイドル タイマーは 15 秒に設定されます。

仮想サーバは、キャリア コード mcc 222 mnc 22 の International Mobile Subscriber ID(IMSI)からの PDP コンテキスト作成を受け入れます。

次に、図 23 の設定に、NAT と GTP Cause Code Inspection のサポートを追加した設定文を示します。

「IOS SLB の設定文」

「GGSN1 の設定文」(GTP Cause Code Inspection に変更はありません)

「GGSN2 の設定文」(GTP Cause Code Inspection に変更はありません)

「GGSN3 の設定文」(GTP Cause Code Inspection に変更はありません)

詳細な GGSN 設定例については、『 Cisco IOS Mobile Wireless Configuration Guide 』を参照してください。

IOS SLB の設定文

hostname GTP_SLB
!
ip domain-name gprs.com
!
ip slb timers gtp gsn 20
!
ip slb serverfarm GPRS
nat server
real 192.168.1.1
weight 1
faildetect numconns 1 numclients 1
inservice
!
real 192.168.2.2
weight 1
faildetect numconns 1 numclients 1
inservice
!
real 192.168.3.3
weight 1
faildetect numconns 1 numclients 1
inservice
!
ip slb vserver FOR_GPRS
virtual 10.10.10.10 udp 0 service gtp-inspect
idle gtp request 15
client gtp carrier-code mcc 222 mnc 22
serverfarm GPRS
inservice
!
ip slb dfp password Password1 0
agent 10.1.1.201 1111 30 0 10
agent 10.1.1.202 1111 30 0 10
agent 10.1.1.203 1111 30 0 10
!
interface FastEthernet1/0
description TO SERVERFARM GPRS
ip address 10.1.1.100 255.255.255.0
no ip redirects
duplex half
!
interface FastEthernet3/0
description TO SGSN
ip address 10.2.1.100 255.255.255.0
no ip mroute-cache
duplex half
!
ip route 10.111.111.111 255.255.255.255 FastEthernet1/0
ip route 192.168.1.1 255.255.255.255 10.1.1.201
ip route 192.168.2.2 255.255.255.255 10.1.1.202
ip route 192.168.3.3 255.255.255.255 10.1.1.203

GPRS ロード バランシング マップを使用する IOS SLB の設定:例

次の設定例では、アクセス ポイント ネーム(APN)を使用してサーバ ファームを選択し、GPRS ロード バランシング仮想サーバの背後で、IOS SLB が複数のサーバ ファームをサポートできるようにします。サーバ ファーム farm6 は関連マップなしで設定されているため、デフォルト サーバ ファームとして動作します。IOS SLB が他のサーバ ファーム マップのいずれもマッチングできない場合、IOS SLB はデフォルト サーバ ファームに GPRS 要求を送信します。

ip slb map 1 gtp
apn cisco*
ip slb map 4 gtp
apn abc.microsoft.com
apn xyz.intel.com
ip slb map 5 gtp
apn yahoo.com
!
ip slb serverfarm farm1
real 10.0.0.1
inservice
real 10.0.0.2
inservice
ip slb serverfarm farm2
real 10.0.0.3
inservice
real 10.0.0.4
inservice
ip slb serverfarm farm3
real 10.0.0.5
inservice
real 10.0.0.6
inservice
ip slb serverfarm farm4
real 10.0.0.7
inservice
real 10.0.0.8
inservice
ip slb serverfarm farm5
real 10.0.0.9
inservice
real 10.0.0.10
inservice
ip slb serverfarm farm6
real 10.0.0.11
inservice
!
ip slb map 1 gtp
apn cisco*
ip slb map 4 gtp
apn abc.microsoft.com
apn xyz.intel.com
ip slb map 5 gtp
apn yahoo.com
!
ip slb vserver GGSN_SERVER
virtual 10.10.10.10 udp 0 service gtp
serverfarm farm1 backup farm2 map 1 priority 3
serverfarm farm4 map 4 priority 1
serverfarm farm5 map 5 priority 4
serverfarm farm6
inservice

VPN サーバ ロード バランシングを使用する IOS SLB の設定:例

図 24 に、一般的な VPN サーバ ロード バランシング設定を示します。この設定の場合:

VPN フローの負荷は、実サーバ 20.20.20.10 および 20.20.20.20 の間で分散されます。

クライアントは、IOS SLB 仮想サーバ アドレス 10.10.1.1 に接続します。

ESP 仮想サーバと UDP 仮想サーバの間にはスティッキ接続があります。

暗号鍵の交換は、IKE を介して発生します(ISAKMP、ポート 500)。

図 24 VPN サーバ ロード バランシングを使用する IOS SLB

 

次に、図 24 の設定の IOS SLB 設定文を示します。

ip slb serverfarm VPN
nat server
real 20.20.20.10
inservice
real 20.20.20.20
inservice
failaction purge
!
ip slb vserver ESP
virtual 10.10.1.1 ESP
serverfarm VPN
sticky 3600 group 69
inservice
!
ip slb vserver UDP
virtual 10.10.1.1 UDP isakmp
serverfarm VPN
sticky 3600 group 69
inservice

RADIUS ロード バランシングを使用する IOS SLB の設定:例

ここでは次の例を紹介し、さまざまな IOS SLB RADIUS ロード バランシング設定を示します。

「GPRS ネットワークに RADIUS ロード バランシングを使用する IOS SLB の設定:例」

「簡易 IP CDMA2000 ネットワークに RADIUS ロード バランシングを使用する IOS SLB の設定:例」

「Mobile IP CDMA2000 ネットワークに RADIUS ロード バランシングを使用する IOS SLB の設定:例」

「複数のサービス ゲートウェイ ファームに RADIUS ロード バランシングを使用する IOS SLB の設定:例」

「RADIUS ロード バランシング/ファイアウォール ロード バランシングの「サンドイッチ」を使用する IOS SLB の設定:例」

「RADIUS ロード バランシング マップを使用する IOS SLB の設定:例」

「RADIUS ロード バランシング加速データ プレーン フォワーディングを使用する IOS SLB の設定:例」

GPRS ネットワークに RADIUS ロード バランシングを使用する IOS SLB の設定:例

図 25 に、GPRS ネットワークの一般的な IOS SLB RADIUS ロード バランシング設定を示します。この設定の場合:

RADIUS 要求の負荷は、SSG RADIUS プロキシ サーバ 10.10.10.1 および 10.10.10.2 の間で分散されます。

エンドユーザ データ パケットは、IOS SLB デバイスにルーティングされます。

1.1.1.0 サブネットからのエンドユーザ データ パケットは、IOS SLB から SSG1 に送信されます。

1.1.2.0 サブネットからのエンドユーザ データ パケットは、IOS SLB から SSG2 に送信されます。

図 25 GPRS ネットワークに RADIUS ロード バランシングを使用する IOS SLB

 

次に、図 25 の設定の IOS SLB 設定文を示します。

ip slb route 1.1.0.0 255.255.0.0 framed-ip
!
ip slb serverfarm SSGFARM
nat server
real 10.10.10.1
inservice
real 10.10.10.2
inservice
!
ip slb vserver RADIUS_ACCT
virtual 10.10.10.10 udp 1813 service radius
serverfarm SSGFARM
idle radius request 20
idle radius framed-ip 7200
sticky radius framed-ip group 1
inservice
!
ip slb vserver RADIUS_AUTH
virtual 10.10.10.10 udp 1812 service radius
serverfarm SSGFARM
idle radius request 20
idle radius framed-ip 7200
sticky radius framed-ip group 1
inservice

簡易 IP CDMA2000 ネットワークに RADIUS ロード バランシングを使用する IOS SLB の設定:例

図 26 に、簡易 IP サービスを使用する CDMA2000 ネットワークの一般的な IOS SLB RADIUS ロード バランシング設定を示します。この設定の場合:

PDSN の RADIUS 仮想サーバの IP アドレスは 10.10.10.10 です。

RADIUS 要求の負荷は、SSG RADIUS プロキシ サーバ 10.10.10.1 および 10.10.10.2 の間で分散されます。

エンドユーザ データ パケットは、IOS SLB デバイスにルーティングされます。

1.1.0.0 ネットワークからのエンドユーザ データ パケットは、SSG にルーティングされます。

図 26 簡易 IP CDMA2000 ネットワークに RADIUS ロード バランシングを使用する IOS SLB

 

次に、図 26 の設定の IOS SLB 設定文を示します。

ip slb route 1.1.0.0 255.255.0.0 framed-ip
!
ip slb serverfarm SSGFARM
nat server
real 10.10.10.1
inservice
real 10.10.10.2
inservice
!
ip slb vserver RADIUS_SIP
virtual 10.10.10.10 udp 0 service radius
serverfarm SSGFARM
idle radius framed-ip 3600
sticky radius username
sticky radius framed-ip
inservice

Mobile IP CDMA2000 ネットワークに RADIUS ロード バランシングを使用する IOS SLB の設定:例

図 27 に、Mobile IP サービスを使用する CDMA2000 ネットワークの一般的な IOS SLB RADIUS ロード バランシング設定を示します。この設定の場合:

PDSN および HA の RADIUS 仮想サーバの IP アドレスは 10.10.10.10 です。

RADIUS 要求の負荷は、SSG RADIUS プロキシ サーバ 10.10.10.1 および 10.10.10.2 の間で分散されます。

エンドユーザ データ パケットは、IOS SLB デバイスにルーティングされます。

1.1.0.0 ネットワークからのエンドユーザ データ パケットは、SSG にルーティングされます。

図 27 Mobile IP CDMA2000 ネットワークに RADIUS ロード バランシングを使用する IOS SLB

 

次に、図 27 の設定の IOS SLB 設定文を示します。

ip slb route 1.1.0.0 255.255.0.0 framed-ip
!
ip slb serverfarm SSGFARM
nat server
real 10.10.10.1
inservice
real 10.10.10.2
inservice
!
ip slb vserver RADIUS_SIP
virtual 10.10.10.10 udp 0 service radius
serverfarm SSGFARM
idle radius framed-ip 3600
sticky radius username
sticky radius framed-ip
inservice

複数のサービス ゲートウェイ ファームに RADIUS ロード バランシングを使用する IOS SLB の設定:例

IOS SLB は、次の設定例で複数のサービス ゲートウェイ サーバ ファーム(この例では、SSG のサーバ ファームと CSG のサーバ ファーム)のセットに対するパケット フローの負荷を分散できるようになります。

ip slb route 1.1.0.0 255.255.0.0 framed-ip
!
ip slb serverfarm SSGFARM
nat server
real 10.10.10.1
inservice
real 10.10.10.2
inservice
!
ip slb serverfarm CSGFARM
nat server
real 20.20.20.1
inservice
real 20.20.20.2
inservice
!
ip slb vserver SSG_AUTH
virtual 10.10.10.10 udp 1812 service radius
serverfarm SSGFARM
idle radius request 20
idle radius framed-ip 7200
sticky radius framed-ip group 1
access Vlan20 route framed-ip
inservice
!
ip slb vserver SSG_ACCT
virtual 10.10.10.10 udp 1813 service radius
serverfarm SSGFARM
idle radius request 20
idle radius framed-ip 7200
sticky radius framed-ip group 1
access Vlan20 route framed-ip
inservice
!
ip slb vserver CSG_ACCT
virtual 20.20.20.20 udp 1813 service radius
serverfarm CSGFARM
idle radius request 25
idle radius framed-ip 0
sticky radius framed-ip
access Vlan30 route framed-ip
inservice

RADIUS ロード バランシング/ファイアウォール ロード バランシングの「サンドイッチ」を使用する IOS SLB の設定:例

図 28 に、単一の IOS SLB デバイス上の RADIUS ロード バランシング/ファイアウォール ロード バランシングの「サンドイッチ」設定を示します。この設定例の場合:

RADIUS ロード バランシングの仮想 IP アドレスは 5.5.5.5。

加入者の framed-IP ネットワークは 1.0.0.0/255.0.0.0 です。

VL105、VL106、VL107、および VL108 は VLAN です。

VLAN VL105 に到達する RADIUS 要求の負荷は、10.10.106.42 と 10.10.106.43 の間で分散されます。

ユーザ トラフィックは、1.0.0.0 サブネットの framed-IP アドレスの割り当てに基づいて、スティッキ接続されます。

相手側(10.10.107.42/43)のファイアウォール ロード バランシングによって、加入者へのリターン パス トラフィックは、適切なゲートウェイに配信されます。

図 28 RADIUS ロード バランシング/ファイアウォール ロード バランシングの「サンドイッチ」を使用する IOS SLB

 

次に、図 28 の設定の IOS SLB 設定文を示します。

ip vrf client
rd 0:1
!
ip slb probe P742 ping
address 10.10.107.42
interval 120
!
ip slb probe P743 ping
address 10.10.107.43
interval 120
!
ip slb route 1.0.0.0 255.0.0.0 framed-ip
ip slb route framed-ip deny
!
ip slb firewallfarm SERVER
access inbound Vlan108
access outbound Vlan107
inservice
real 10.10.107.42
probe P742
inservice
real 10.10.107.43
probe P743
inservice
protocol tcp
sticky 180 destination
protocol datagram
sticky 180 destination
predictor hash address port
!
 
ip slb serverfarm SF1
nat server
access Vlan106
!
real 10.10.106.42
inservice
real 10.10.106.43
inservice
!
ip slb vserver VS1
virtual 5.5.5.5 udp 0 service radius
serverfarm SF1
sticky radius framed-ip
access Vlan105 route framed-ip
access Vlan105
inservice
!
mls flow ip interface-full
!
!*************************************************
!* Switchports, port channels and trunks *
!* added to vlans 105-108 (left out for brevity) *
!*************************************************
!
interface Vlan105
ip vrf forwarding client
ip address 10.10.105.2 255.255.255.0
!
interface Vlan106
ip vrf forwarding client
ip address 10.10.106.2 255.255.255.0
!
interface Vlan107
ip address 10.10.107.2 255.255.255.0
!
interface Vlan108
ip address 10.10.108.2 255.255.255.0
!
ip route 10.10.105.0 255.255.255.0 10.10.107.42
ip route vrf client 10.10.108.0 255.255.255.0 10.10.106.42

RADIUS ロード バランシング マップを使用する IOS SLB の設定:例

次の設定例では、RADIUS 発信ステーション ID およびユーザ名を使用してサーバ ファームを選択し、RADIUS ロード バランシング仮想サーバの背後で、IOS SLB が複数のサーバ ファームをサポートできるようにします。サーバ ファーム farm3 は関連マップなしで設定されているため、デフォルト サーバ ファームとして動作します。IOS SLB が他のサーバ ファーム マップのいずれもマッチングできない場合、IOS SLB はデフォルト サーバ ファームに RADIUS 要求を送信します。

ip slb serverfarm CSGFARM
predictor route-map rlb-pbr
ip slb serverfarm AAAFARM
nat server
real 10.10.10.1
inservice
real 10.10.10.2
inservice
 
ip slb vserver RADIUS_ACCT
virtual 10.10.10.10 udp 1813 service radius
serverfarm CSGFARM
 
radius inject acct 1 key 0 cisco
inservice
 
ip slb vserver RADIUS_AUTH
virtual 10.10.10.10 udp 1812 service radius
serverfarm AAAFARM
radius inject auth 1 calling-station-id
radius inject auth timer 45
radius inject auth vsa cisco
inservice
 
!
interface vlan 100
ip policy route-map rlb-pbr
!
access-list 1 permit 0.0.0.1 255.255.255.254
access-list 2 permit 0.0.0.0 255.255.255.254
!
route-map rlb-pbr permit 10
match ip address 1
set ip next-hop 10.10.10.1
!
route-map rlb-pbr permit 20
match ip address 2
set ip next-hop 10.10.10.2

RADIUS ロード バランシング加速データ プレーン フォワーディングを使用する IOS SLB の設定:例

この IOS SLB 設定には、次の特徴があります。

Network Access Server(NAS)デバイスを処理する IP アドレス 10.10.10.10 の仮想 RADIUS サーバがあります。

IP アドレス 10.10.10.1 および 10.10.10.2 という 2 つのパケット ゲートウェイがあります。

仮想 RADIUS サーバ宛ての RADIUS トラフィックは、ルート マップ rlb-pbr に従い、マップ済み framed-IP アドレスに基づいて、パケット ゲートウェイ間で分散されます。

サーバ ファーム CSGFARM は、ルート マップ rlb-pbr の可能な結果に一致する実 IP アドレスを使用して設定されます。

VLAN 100 に到達するエンドユーザ トラフィックは、アクセス コントロール リスト(ACL)に基づいて、適切な Cisco Content Services Gateway(CSG)にルーティングされます。

ACL 1 は、末尾が奇数の IP アドレスを、パケット ゲートウェイ 10.10.10.1 の背後にある CSG に送信します。

ACL 2 は、末尾が偶数の IP アドレスを、パケット ゲートウェイ 10.10.10.2 の背後にある CSG に送信します。

図 29 RADIUS ロード バランシング加速データ プレーン フォワーディングを使用する IOS SLB

 

次に、図 29 の設定の IOS SLB 設定文を示します。

ip slb serverfarm CSGFARM
predictor route-map rlb-pbr
ip slb serverfarm AAAFARM
nat server
real 10.10.10.1
inservice
real 10.10.10.2
inservice
!
ip slb vserver RADIUS_ACCT
virtual 10.10.10.10 udp 1813 service radius
serverfarm CSGFARM
radius inject acct 1 key 0 cisco
inservice
!
ip slb vserver RADIUS_AUTH
virtual 10.10.10.10 udp 1812 service radius
serverfarm AAAFARM
radius inject auth 1 calling-station-id
radius inject auth timer 45
radius inject auth vsa cisco
inservice
!
interface vlan 100
ip policy route-map rlb-pbr
!
access-list 1 permit 0.0.0.1 255.255.255.254
access-list 2 permit 0.0.0.0 255.255.255.254
!
route-map rlb-pbr permit 10
match ip address 1
set ip next-hop 10.10.10.1
!
route-map rlb-pbr permit 20
match ip address 2
set ip next-hop 10.10.10.2

Home Agent Director を使用する IOS SLB の設定:例

次の設定例では、IOS SLB が複数のホーム エージェントに Mobile IP RRQ の負荷を分散できるようにします。

図 30 Home Agent Director を使用する IOS SLB

 

次に、図 30 の設定の IOS SLB 設定文を示します。

ip slb serverfarm HA_FARM
nat server
real 10.10.10.1
inservice
real 10.10.10.2
inservice
 
ip slb vserver VIRTUAL_HA
virtual 10.10.10.10 udp 434 service ipmobile
serverfarm HA_FARM
inservice

スティッキ接続を使用する IOS SLB の設定:例

次の設定例では、サブネットからのすべての HTTP 接続を、サーバ ファーム PUBLIC の同じ実サーバに割り当てます。

ip slb vserver http
serverfarm PUBLIC
sticky 30 group 1 netmask 255.255.255.248
virtual 20.20.20.20 tcp 80
inservice
 

次の設定例では、HTTP 接続を上記の設定に追加します。上記と同じスティッキ情報を使用しますが、仮想サーバは異なります。

ip slb vserver https
serverfarm PUBLIC
sticky 30 group 1 netmask 255.255.255.248
virtual 20.20.20.20 tcp 443
inservice
 

この例では、サブネットからのすべての HTTP 接続 および HTTPS 接続は、同じ実サーバに割り当てられます。たとえば、あるユーザが HTTP に接続する場合、次のユーザは HTTPS に接続し、両方の接続は同じ実サーバに割り当てられます。

GTP IMSI スティッキ データベースを使用する IOS SLB の設定:例

次の設定例で、IOS SLB GTP IMSI スティッキ データベースをイネーブルにする方法を示します。

ip slb serverfarm GGSN_FARM
failaction gtp purge
real 10.20.10.1
weight 1
faildetect numconns 255 numclients 8
inservice
!
real 10.20.10.2
weight 1
faildetect numconns 255 numclients 8
inservice
!
real 10.20.10.3
weight 1
faildetect numconns 255 numclients 8
inservice
!
ip slb vserver GGSN_SERVER1
virtual 10.10.10.10 udp 3386 service gtp
serverfarm GGSN_FARM backup GGSN_FARM
idle gtp request 90
idle gtp imsi 10000000
sticky gtp imsi group 1
gtp notification cac 3
inservice
!
ip slb vserver GGSN_SERVER2
virtual 10.10.10.10 udp 2123 service gtp
serverfarm GGSN_FARM backup GGSN_FARM
idle gtp request 90
idle gtp imsi 10000000
sticky gtp imsi group 1
gtp notification cac 3
inservice

透過的 Web キャッシュ ロード バランシングを使用する IOS SLB の設定:例

次の設定例では、仮想サーバ WEBCACHE によって、ロード バランシング デバイスを経由するすべての Web フローを確認し、サーバ ファーム WEBCACHE-FARM に送出します。 client exclude 文によってサブネット 80.80.7.0 から発信されたフローを無視し、実サーバ 80.80.7.188 および 80.80.7.189 が必要に応じてインターネットと通信できるようにします。

ip slb serverfarm WEBCACHE-FARM
real 80.80.7.188
inservice
real 80.80.7.189
inservice
ip slb vserver WEBCACHE
virtual 0.0.0.0 0.0.0.0 tcp www
serverfarm WEBCACHE-FARM
client 80.80.7.0 255.255.255.0 exclude
inservice

KAL-AP エージェントを使用する IOS SLB の設定:例

次の設定例では、ドメイン ネーム システム(DNS)クエリー abcd.com を GSS に送信するようにクライアントを設定します。DUBLIN サイトの Global Site Selector(GSS)は、クライアントから要求を受信します。GSS は、仮想サーバからレポートされる負荷に基づき、CHICAGO(10.0.0.100)または NEWYORK(10.0.0.200)の仮想 IP アドレスを使用して DNS クエリーに応答します。

図 31 KAL-AP エージェントを使用する IOS SLB

 

次に、図 31 の設定の IOS SLB 設定文を示します。

GSS

shared-keepalive kalap 192.168.1.1 capp-secure enable key kap
shared-keepalive kalap 192.168.2.1 capp-secure enable key kap
!
answer vip 10.0.0.100 name CHICAGO activate
keepalive type kalap tag 192.168.1.1 chicao.com
answer vip 10.0.0.200 name NEWYORK activate
keepalive type kalap tag 192.168.2.1 newyork.com
!
 
answer-group ABCD owner System type vip
answer-add 10.0.0.100 name CHICAGO weight 1 order 0 load-threshold 254 activate
answer-add 10.0.0.200 name NEWYORK weight 1 order 0 load-threshold 254 activate
dns rule ABCDGPRS owner System source-address-list Anywhere domain-list abcd.com query a
clause 1 vip-group method least-loaded ttl 20 count 1 sticky disable

サイト 1:IOS SLB - CHICAGO

ip slb capp udp
peer port 6000 secret 0 kap
!
ip slb serverfarm SF
kal-ap domain chicago.com
farm-weight 200
real 10.10.10.1
inservice
real 10.10.10.2
inservice
!
ip slb vserver chicago
virtual 10.0.0.100 udp 0
serverfarm SF
inservice
!
ip slb dfp
agent 10.10.10.1 5000 30 0 10
agent 10.10.10.2 5000 30 0 10
!
int vlan100
ip address 192.168.1.1 255.255.255.0

GGSN-1

gprs dfp max-weight 100
gprs maximum-pdp-context-allowed 20000
!
ip dfp agent gprs
port 5000
inservice

GGSN-2

gprs dfp max-weight 100
gprs maximum-pdp-context-allowed 20000
!
ip dfp agent gprs
port 5000
inservice

サイト 2:IOS SLB - NEWYORK

ip slb capp udp
peer port 6000
peer 192.1.1.1 secret 0 test
peer 10.100.100.100 port 1234
!
ip slb serverfarm SF
kal-ap domain newyork.com
farm-weight 6200
real 10.20.20.1
inservice
real 10.20.20.2
inservice
real 10.20.20.3
inservice
real 10.20.20.4
inservice
!
ip slb vserver chicago
virtual 10.0.0.200 udp 0
serverfarm SF
inservice
!
ip slb dfp
agent 10.10.10.1 5000 30 0 10
agent 10.10.10.2 5000 30 0 10
!
int vlan200
ip address 192.168.2.1 255.255.255.0

GGSN-1

gprs dfp max-weight 100
gprs maximum-pdp-context-allowed 20000
!
ip dfp agent gprs
port 5000
inservice

GGSN-2

gprs dfp max-weight 100
gprs maximum-pdp-context-allowed 20000
!
ip dfp agent gprs
port 5000
inservice

その他の参考資料

ここでは、IOS SLB に関する参考資料について説明します。

「トラブルシューティング」

「サポートされているプラットフォーム」

「関連資料」

「規格」

「MIB」

「RFC」

「シスコのテクニカル サポート」

トラブルシューティング

質問
回答

IOS SLB を使用して、同じ LAN または VLAN 上にあるクライアントおよび実サーバの負荷を分散できますか。

いいえ。

IOS SLB は、同じ LAN または VLAN 上にあるクライアントおよび実サーバ間のフローのロード バランシングをサポートしていません。同じインターフェイス上のロード バランシング デバイスには、ロード バランシング対象のパケットを入出力できません。

データを転送しているのに、IOS SLB で接続が ESTABLISHED とマークされないのはなぜですか。

dispatched モードを使用している場合、発信フローが IOS SLB をバイパスできる代替パスがないようにします。また、クライアントと実サーバが同じ IP サブネット上にない(つまり、同じ LAN または VLAN 上にない)ようにします。

実サーバに直接接続できるのに、仮想サーバに接続できないのはなぜですか。

仮想 IP アドレスが、各実サーバでループバックとして設定されていることを確認します(dispatched モードで実行している場合)。

ネットワークから実サーバの接続を解除しても、IOS SLB で実サーバが FAILED とマークされないのはなぜですか。

numclients numconns 、および delay の各キーワードの値を調整します。

クライアント数がごく少数の場合(たとえば、テスト環境)、 numclients キーワードを使用すると問題が発生する可能性があります。これは、IOS SLB が少数のクライアントの障害を実サーバの障害と取り違えないようにするパラメータです。

実サーバを終了したり、物理的に接続を解除しても、IOS SLB で INSERVICE とマークされないのはなぜですか。

INSERVICE 状態および OUTOFSERVICE 状態は、ネットワーク管理者が、実サーバの動作時にその実サーバを使用する 意図 があるかどうかを示します。INSERVICE 状態で、IOS SLB の自動障害検出によって動的に選択リストから削除された実サーバは、FAILED とマークされます。これらの実サーバを表示するには、 show ip slb reals detail コマンドを使用します。

リリース 12.1(1)E 以降、サーバ動作の実態を反映するために、INSERVICE は OPERATIONAL に変更されました。

IOS SLB スティッキ接続が適切に動作していることは、どのように確認できますか。

次の手順を使用します。

1. スティッキ接続を設定します。

2. クライアント接続を開始します。

3. show ip slb reals detail および show ip slb conns コマンドを入力します。

4. 実サーバの接続カウントを確認します。カウントが増える実サーバは、クライアント接続が割り当てられた実サーバです。

5. show ip slb sticky コマンドを入力して、IOS SLB に格納されているスティッキの関係を表示します。

6. 接続を終了します。

7. 実サーバの接続カウントが減ることを確認します。

8. スティッキ タイムアウト値の間待ってから、接続を再開します。

9. もう一度 show ip slb conns コマンドを入力します。

10. 実サーバの接続カウントをもう一度調べて、スティッキ接続は以前と同じ実サーバに割り当てられていることを確認します。

サーバ障害が適切に検出されていることは、どのように確認できますか。

次の手順を使用します。

1. 大量のクライアント数を使用します。クライアント数がごく少数の場合、サーバが FAILED と表示されないように、 faildetect numconns (実サーバ) コマンドで numclients キーワードを調整します。

2. show ip slb reals detail コマンドを入力して、実サーバのステータスを表示します。

3. 実サーバのステータスと接続カウントを確認します。

障害が発生したサーバは、コマンドの送信時にサーバがバックアップになったことを確認するかどうかに基づいて、FAILED、TESTING、または READY_TO_TEST のステータスを示します。

実サーバに障害が発生すると、割り当て済みで確立していない(SYN または ACK を受信していない)接続は、 reassign しきい値に達した後、最初に受信した SYN で、別の実サーバに再割り当てされます。ただし、確立済みの接続は同じ実サーバに転送されます。これは、新しい接続を受け入れない可能性があり、さらに既存の接続を提供している可能性があるためです。

加重最小接続の場合、サービスが開始されたばかりの実サーバは、新しい接続で過負荷にならないように、低速で開始されます(詳細については、「スロー スタート」を参照してください)。そのため、新しい実サーバについて表示される接続カウントは、(新しい実サーバの低いカウントに関係なく)他の実サーバに送信される接続を示します。また、接続カウントは、新しい実サーバに対して「ダミー接続」を示します。ダミー接続は、スロー スタート期間に、IOS SLB が実サーバの接続数を意図的につり上げるために使用されます。

no inservice コマンドで、リソースは直ちにアウト オブ サービスになりますか。

inservice コマンドの no 形式を使用して、ファイアウォール、ファイアウォール ファーム、実サーバ、または仮想サーバをサービスから削除すると、各リソースは通常の手順で削除を実行します。新しい接続が割り当てられなければ、既存の接続は完了できます。

ファイアウォール ファームまたは仮想サーバ全体について、すべての既存の接続を直ちに停止するには、 clear ip slb connections コマンドを使用します。

同じ Catalyst 6500 ファミリ スイッチに IOS SLB と入力 ACL の両方を設定すると、「TCAM Capacity Exceeded」メッセージが表示されます。なぜですか。

同じ Catalyst 6500 ファミリ スイッチに IOS SLB と、入力 ACL またはファイアウォール ロード バランシングを設定すると、ポリシー フィーチャ カード(PFC)の TCAM の容量を超過する可能性があります。この問題を修正するには、mls ip slb search wildcard rp コマンドを使用して、IOS SLB が使用する TCAM 容量を減らします。ただし、このコマンドを使用すると、ルート プロセッサの使用率がやや増加する可能性があります。

IOS SLB VRF をサポートする IOS リリースおよびプラットフォームはどれですか。

IOS SLB の Virtual Private Network(VPN)Routing and Forwarding(VRF)は、Cisco 7600 シリーズ ルータ用の MSFC3(SUP720-MSFC3)を搭載した Supervisor Engine 720 上の IOS リリース 12.2(18)SXE 以降でサポートされます。

スーパーバイザで表示される IOS SLB out-of-sync メッセージによって何が起こる可能性がありますか。

replicate slave を設定して単一のスーパーバイザを使用している場合、スーパーバイザで out-of-sync メッセージを受信することがあります。

IOS SLB は、同じスーパーバイザにファイアウォール ロード バランシングと RADIUS ロード バランシングの両方を提供できますか。

IOS SLB は、同じ Supervisor Engine 720(SUP720-MSFC3)にファイアウォール ロード バランシングと RADIUS ロード バランシングの両方を提供できます。

関連資料

内容
参照先

Cisco IOS コマンド

『Cisco IOS Master Commands List, All Releases』

Cisco IOS 設定の基礎

『Cisco IOS Configuration Fundamentals Configuration Guide』

Cisco IOS IP 設定情報

『Cisco IOS IP Addressing Configuration Guide』

Cisco IOS IP Addressing Command Reference

『Cisco IOS IP Application Services Configuration Guide』

Cisco IOS IP Application Services Command Reference

Cisco IOS モバイル ワイヤレス設定情報

『Cisco IOS IP Mobility Configuration Guide』

Cisco IOS IP Mobility Command Reference

DFP 設定情報

『Dynamic Feedback Protocol Support in Distributed Director』

CFM 設定情報

『Using Content Flow Monitor』

サポートされているプラットフォーム

スイッチまたはルータ
サポートされているプラットフォーム

Cisco 7600 シリーズ ルータ

MSFC2A を搭載した Supervisor Engine 32(SUP32-MSFC2A)

MSFC3 を搭載した Supervisor Engine 720(SUP720-MSFC3)

2 つのギガビット イーサネット ポートを搭載した Distributed Forwarding Card DFC3CXL 付きの Cisco Route Switch Processor 720(RSP720-3CXL-GE)

規格

規格
タイトル

この機能がサポートする新しい規格または変更された規格はありません。また、この機能による既存規格のサポートに変更はありません。

--

MIB

MIB
MIB リンク

CISCO-SLB-MIB

CISCO-SLB-CAPABILITY

と定義されていますが、SNMP SET コマンドを使用して変更することはできません。代わりに、コマンド ラインを使用して関連するコマンド ライン キーワードを設定します。その後に、新しい値が SNMP で反映されます。

選択したプラットフォーム、Cisco IOS リリース、および機能セットの MIB を検索してダウンロードする場合は、次の URL にある Cisco MIB Locator を使用します。

http://www.cisco.com/go/mibs

RFC

シスコのテクニカル サポート

説明
リンク

Cisco Support Web サイトには、豊富なオンライン リソースが提供されており、それらに含まれる資料やツールを利用して、トラブルシューティングやシスコ製品およびテクノロジーに関する技術上の問題の解決に役立てることができます。

以下を含むさまざまな作業にこの Web サイトが役立ちます。

テクニカル サポートを受ける

ソフトウェアをダウンロードする

セキュリティの脆弱性を報告する、またはシスコ製品のセキュリティ問題に対する支援を受ける

ツールおよびリソースへアクセスする

Product Alert の受信登録

Field Notice の受信登録

Bug Toolkit を使用した既知の問題の検索

Networking Professionals(NetPro)コミュニティで、技術関連のディスカッションに参加する

トレーニング リソースへアクセスする

TAC Case Collection ツールを使用して、ハードウェアや設定、パフォーマンスに関する一般的な問題をインタラクティブに特定および解決する

Japan テクニカル サポート Web サイトでは、Technical Support Web サイト(http://www.cisco.com/techsupport)の、利用頻度の高いドキュメントを日本語で提供しています。Japan テクニカル サポート Web サイトには、次の URL からアクセスしてください。http://www.cisco.com/jp/go/tac

http://www.cisco.com/cisco/web/support/index.html

IOS SLB の機能情報

表 2 に、この章に記載されている機能および具体的な設定情報へのリンクを示します。この表には、Cisco IOS リリース 12.2(1) 以降のリリースで導入または変更された機能だけを示します。

ご使用の Cisco IOS ソフトウェア リリースによっては、コマンドの中に一部使用できないものがあります。特定のコマンドのリリース情報については、『 Cisco IOS IP Application Services Command Reference 』を参照してください。

Cisco Feature Navigator を使用すると、プラットフォームおよびソフトウェア イメージのサポート情報を検索できます。Cisco Feature Navigator を使用すると、Cisco IOS、Cisco Catalyst OS、Cisco IOS XE ソフトウェア イメージがサポートする特定のソフトウェア リリース、機能セット、またはプラットフォームを確認できます。Cisco Feature Navigator には、 http://www.cisco.com/go/cfn からアクセスします。Cisco.com のアカウントは必要ありません。


表 2 には、一連の Cisco IOS ソフトウェア リリースのうち、特定の機能が初めて導入された Cisco IOS ソフトウェア リリースだけが記載されています。特に明記していないかぎり、その機能は、一連の Cisco IOS ソフトウェア リリースの以降のリリースでもサポートされます。


 

表 2 IOS SLB の機能情報

機能名
リリース
機能情報

IOS SLB、12.2 の最初のリリース

12.2(1)

IOS SLB 機能は、多様なネットワーク デバイスおよびサービスに適したロード バランシングが用意されている IOS ベースのソリューションです。

アクティブ スタンバイ

12.2(1)

アクティブ スタンバイによって、2 つの IOS SLB は同じ仮想 IP アドレスの負荷を分散すると同時に、相互にバックアップとして動作できます。

この機能に関する詳細については、次の各項を参照してください。

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

「ステートレス バックアップの設定作業リスト」

「アクティブ スタンバイを使用する IOS SLB の設定:例」

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

12.2(1)

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

「加重ラウンド ロビン」

「加重最小接続」

「ルート マップ」

この機能に関する詳細については、次の各項を参照してください。

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

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

代替 IP アドレス

12.2(1)

IOS SLB を使用すると、代替 IP アドレスを使用して、ロード バランシング デバイスに Telnet を使用できます。

この機能に関する詳細については、次の項を参照してください。

「代替 IP アドレス」

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

12.2(1)

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

この機能に関する詳細については、次の項を参照してください。

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

自動サーバ障害検出

12.2(1)

IOS SLB は、実サーバに対して失敗した各 TCP 接続試行を自動的に検出し、そのサーバの障害カウンタを増加します サーバの障害カウンタが設定可能な障害しきい値を超えると、サーバはアウト オブ サービスと見なされ、アクティブな実サーバ リストから削除されます。

この機能に関する詳細については、次の各項を参照してください。

「自動サーバ障害検出」

「自動サーバ障害検出のディセーブル化」

自動アンフェイル

12.2(1)

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

この機能に関する詳細については、次の項を参照してください。

「自動アンフェイル」

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

12.2(1)

高度なセキュア サイトであれば、特定の手順を使用して、サーバ ファームおよびファイアウォール ファームを攻撃から保護できます。

この機能に関する詳細については、次の項を参照してください。

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

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

12.2(1)

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

この機能に関する詳細については、次の各項を参照してください。

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

「IOS SLB 用 Dynamic Feedback Protocol」

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

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

12.2(1)

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

この機能に関する詳細については、次の項を参照してください。

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

クライアント NAT

12.2(1)

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

この機能に関する詳細については、次の各項を参照してください。

「クライアント NAT」

「NAT の設定」

「NAT およびスタティック NAT を使用する IOS SLB の設定:例」

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

12.2(1)

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

この機能に関する詳細については、次の項を参照してください。

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

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

12.2(1)

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

この機能に関する詳細については、次の各項を参照してください。

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

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

IOS SLB 用 Dynamic Feedback Protocol

12.2(1)

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

この機能に関する詳細については、次の各項を参照してください。

「IOS SLB 用 Dynamic Feedback Protocol」

「DFP の設定」

「GPRS ロード バランシングを使用する IOS SLB の設定:例」

「KAL-AP エージェントを使用する IOS SLB の設定:例」

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

12.2(1)

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

この機能に関する詳細については、次の各項を参照してください。

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

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

「ファイアウォール ロード バランシングを使用する IOS SLB の設定:例」

最大接続

12.2(1)

IOS SLB では、サーバおよびファイアウォール ロード バランシングの最大接続数を設定できます。この機能に関する詳細については、次の各項を参照してください。

「最大接続」

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

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

「IOS SLB ネットワーク一式の設定:例」

ポートバインド サーバ

12.2(1)

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

この機能に関する詳細については、次の各項を参照してください。

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

「仮想サーバの設定」

プローブ:HTTP プローブ、ping プローブ、および WSP プローブ

12.2(1)

IOS SLB プローブで、サーバ ファーム内の各実サーバのステータスと、ファイアウォール ファーム内の各ファイアウォールを判断します。

この機能に関する詳細については、次の各項を参照してください。

「プローブ」

「プローブの設定」

「プローブを使用する IOS SLB の設定:例」

プロトコル サポート

12.2(1)

IOS SLB がサポートするプロトコル セットは固定です。

この機能に関する詳細については、次の項を参照してください。

「プロトコル サポート」

サーバ NAT

12.2(1)

サーバ NAT には、仮想サーバの IP アドレスを実サーバの IP アドレスに置換する処理(およびその逆の処理)があります。

この機能に関する詳細については、次の各項を参照してください。

「サーバ NAT」

「NAT の設定」

「NAT およびスタティック NAT を使用する IOS SLB の設定:例」

スロー スタート

12.2(1)

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

この機能に関する詳細については、次の項を参照してください。

「スロー スタート」

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

12.2(1)

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

この機能に関する詳細については、次の各項を参照してください。

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

「冗長ルート プロセッサのステートフル バックアップの設定作業リスト」

「ステートフル バックアップを使用する IOS SLB の設定:例」

「冗長ルート プロセッサのステートフル バックアップを使用する IOS SLB の設定:例」

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

12.2(1)

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

この機能に関する詳細については、次の各項を参照してください。

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

「ステートレス バックアップの設定作業リスト」

「ステートレス バックアップを使用する IOS SLB の設定:例」

スティッキ接続

12.2(1)

クライアント トランザクションには、複数の連続する接続が必要なことがあります。つまり、同じクライアントの IP アドレスまたはサブネットからの新しい接続を、同じ実サーバに割り当てる必要があります。オプションの sticky コマンドを使用すると、同じクライアントからの発信を、サーバ ファーム内の同じロード バランシング サーバに強制的に接続できます。ファイアウォール ロード バランシングの場合、同じクライアント - サーバ ペア間の接続は、同じファイアウォールに割り当てられます。

この機能に関する詳細については、次の各項を参照してください。

「スティッキ接続」

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

「仮想サーバの設定」

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

「スティッキ接続を使用する IOS SLB の設定:例」

サポートされているプラットフォーム

12.2(1)

IOS SLB for 12.2(1) は、次のプラットフォームだけをサポートに含めました。

Cisco 7200 シリーズ ルータ

SynGuard

12.2(1)

SynGuard は、仮想サーバが処理する TCP start-of-connection パケットのレート(SYNchronize Sequence Number(SYN))を制限することで、SYN フラッド サービス拒絶攻撃と呼ばれる種類のネットワークの問題を回避します