WAN : ポイントツーポイント プロトコル(PPP)

マルチシャーシ マルチリンク PPP(MMP)

2005 年 9 月 9 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2008 年 1 月 29 日) | フィードバック

目次

概要
前提条件
      要件
      使用するコンポーネント
      関連用語
      表記法
問題の定義
機能の概要
      SGBP
      バーチャル アクセス インターフェイス
      L2F
エンド ユーザ インターフェイス
      SGBP
      MP

関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

この文書では、シスコシステムズのアクセス サーバ プラットフォームにおけるスタックまたはマルチシャーシ環境での Multilink PPP(MP; マルチリンク PPP)のサポート(Multichassis Multilink PPP(マルチシャーシ マルチリンク PPP)という名称で MMP と呼ばれる場合もあり)のサポートについて説明します。

前提条件

要件

この文書に適用される特定の前提条件はありません。

使用するコンポーネント

この文書は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

この文書で紹介する情報は、特定のラボ環境にあるデバイスを使用して作成されました。この文書内で使用されているデバイスはすべて、クリアな状態(デフォルト)から設定作業を始めています。実稼動中のネットワークで作業する場合は、コマンドの実行によって生じる影響について、事前に理解しておいてください。

関連用語

この文書で使用する用語は、次のとおりです。

  • アクセス サーバ—リモート アクセスを提供する ISDN や非同期インターフェイスなどのシスコのアクセス サーバ プラットフォーム。

  • L2F—レイヤ 2(L2)フォワーディング プロトコル(実験的なドラフト RFC)。 これはマルチシャーシ MP および VPN の両方にとって基礎となるリンクレベルのテクノロジーです。

  • リンク—システムから提供される接続ポイント。 これは専用ハードウェア インターフェイス(非同期インターフェイスなど)またはマルチチャネル ハードウェア インターフェイス(PRI または BRI)である場合があります。

  • MP—マルチリンク PPP プロトコル(RFC 1717 leavingcisco.com を参照)

  • マルチシャーシ MP—MP + SGBP + L2F + Vtemplate。

  • PPP—ポイントツーポイント プロトコル(RFC 1331 leavingcisco.com)。

  • ロータリー グループ—ダイヤル アウトまたはコールの受信用に割り当てられた物理インターフェイスのグループ。 このグループは、ダイヤル アウトやコールの受信に使用されるリンクのプールのように振る舞います。

  • SGBP—スタック グループ ビディング プロトコル。

  • スタック グループ—グループとして動作し、異なるシステムのリンクとの MP バンドルをサポートするよう設定された 2 つ以上のシステムの集合。

  • VPDN—バーチャル プライベート ダイヤルアップ ネットワーク。 Internet Service Provider(ISP; インターネット サービス プロバイダー)から Cisco Home Gateway へ PPP リンクをフォワーディングするもの。

  • Vtemplate—バーチャル テンプレート インターフェイス。

注:この文書で引用されている RFC の詳細については、『Cisco IOS リリース 11.3 でサポートされている RFC』、『製品速報』、『RFC および標準に関する文書の入手方法』、または InterNIC への直接のリンクである『RFC Indexleavingcisco.com』を参照してください。

表記法

文書表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

問題の定義

MP では、要求に応じて新たな帯域幅を提供します。マルチ リンクによって形成された論理パイプ(バンドル)を通過するパケットを分割および再結合する機能も備えています。

この機能によって、速度の遅い WAN リンクを通過するときの伝送の遅延を減らし、受信装置での最大受信量を向上させることができます。

送信側では、MP によって 1 つのパケットを複数のパケットにフラグメント化し、複数の PPP リンクに送信できるようになります。 受信側では、MP によって、複数の PPP リンクから到達したパケットを元のパケットに再構築します。

シスコでは、エンド システムを自律させるために MP をサポートしています。つまり、同じクライアントからの複数の MP リンクをアクセス サーバで終端させることができますが、たとえば ISP では、1 つのロータリー番号を複数のアクセス サーバ上の複数の PRI に割り当て、業務上のニーズに合わせることができるよう、サーバ構造を拡張性と柔軟性が高いものにしています。

Cisco IOS® ソフトウェア リリース 11.2 では、このような機能を搭載し、同じクライアントからの複数の MP リンクを異なるアクセス サーバで終端できるようにしています。 同じバンドル内の個々の MP リンクは実際には異なるアクセス サーバで終端しますが、MP クライアントについては 1 つのアクセス サーバで終端しているように見えます。

これを実現するために、MP ではマルチシャーシ MP を使用しています。

機能の概要

図 1 は、1 台のシスコ アクセス サーバで MP を使用して、この機能をサポートしている仕組みを表しています。

図: 1 台のシスコ アクセス サーバでの MP

figure1-mmp.gif

図 1 では、MP のメンバーであるインターフェイスがバンドル インターフェイスへ接続されている仕組みを示しています。 マルチシャーシ MP がイネーブルにされていないスタンドアローン システムでは、メンバー インターフェイスは常に物理インターフェイスになります。

スタック環境をサポートするには、MP の他に、次に 3 つのサブコンポーネントが必要です。

  • SGBP

  • Vtemplate

  • L2F

次のセクションでは、これのコンポーネントについて詳しく説明します。

SGBP

マルチ アクセス サーバ環境では、ネットワーク管理者がアクセス サーバをスタック グループに属するように指定している場合があります。

スタック グループがシステム A とシステム B で構成されているとします。userx というリモート MP クライアントが、その最初の MP リンクをシステム A で終端させています(systema)。 バンドル userx は、systema で形成されています。 userx からの次の MP リンクは、システム B(systemb)で終端しています。 SGBP では、この userx があるバンドルを systema から探します。 この時点で、他のコンポーネント—L2F—は 2 番目の MP リンクを systemb から systema へと投影します。 投影された MP リンクは、その後 systema でのバンドルと一緒になります。

このようにして、SGBP はスタック メンバーのバンドル位置を、定義したスタック グループ内で探します。 また、SGBP では、指定したスタック メンバーを「調整」して、バンドルを作成します。 上記の例では、systema で最初の MP リンクが受信されたとき、実際には systemasystemb の両方(およびスタック グループの他のすべてのメンバー)がバンドルの作成のために送信権を要求します。 systema からの送信権要求は高く(最初のリンクを受け入れているため)、そのため SGBP からバンドルの作成を指定されます。

上記の説明の SGBP の送信権要求のプロセスは、非常に簡潔なものです。 実際には、スタック メンバーからの SGBP 送信権要求はローカルの機能であり、ユーザが設定可能な重み付けされたメトリック、CPU タイプ、MP バンドルの数などです。 この送信権要求プロセスを使用すると、指定したシステム上にバンドルを作成できます。アクセス インターフェイスがないシステム上でも可能です。 たとえば、スタック環境が 10 台のアクセス サーバ システムと 2 台の 4500 で構成されている場合、これは 12 台のスタック メンバーのグループになります。

注:たとえば、2 台の 4500 との間で送信権要求が等しい場合、SGBP は送信権要求の勝者としてどちらか一方をランダムに指定します。 4500 は、他のスタック メンバーよりも常に高い値で送信権要求をできるように設定できます。 したがって、アクセス サーバより高い CPU パワーを持つ装置に適したタスクである MP パケットのフラグメントと再構築の専用のマルチシャーシ MP サーバの負荷が、4500 によって減らされます。

簡潔に言うと、SGBP は、マルチシャーシ MP の配置および調整を行うメカニズムです。

バーチャル アクセス インターフェイス

バーチャル アクセス インターフェイスは、バンドル インターフェイス(図 1 および 2 を参照)と、投影された PPP リンク(図 2 を参照)の両方を提供します。 これらのインターフェイスは要求に応じて動的に作成され、システムに戻されます。

バーチャル テンプレート インターフェイスは、バーチャル アクセス インターフェイスがクローン化されるときの設定情報のレポジトリとなります。 ダイヤラ インターフェイスの設定は、設定情報の別のソースとなります。 バーチャル アクセス インターフェイスをクローン化するための情報のソースを選択する方法は、『この文書の第 2 部』で説明されています。

L2F

L2F は、実際の PPP リンクを指定されたエンド システムに投影します。

L2F では、標準の PPP の操作を、リモート クライアントを認識する認証段階まで実行します。 この認証段階は、ローカルでは完了しません。 L2F には SGBP から対象とするスタック メンバーが通知され、PPP リンクをその対象とするスタック メンバーに投影します。ここで認証段階が再開され、投影された PPP リンクで完了されます。 したがって、最終的な認証の成功または失敗は、対象とされるスタック メンバー上で決まります。

着信コールを受けた元の物理インターフェイスは、L2F forwarded であると考えられます。 PPP の認証が成功した場合に L2F が動的に作成した、これに対応するインターフェイスは、投影されたバーチャル アクセス インターフェイスです。

注:投影されたバーチャル アクセス インターフェイスは、バーチャル テンプレート インターフェイス(定義されている場合)からもクローンとして作成されます。

図 2 では、systemasystemb、および systemc で構成されているスタック グループ stackq について説明しています。

図 2: クライアントがスタックへコール

figure2-mmp.gif

  1. クライアント userx がコールを行い、systema の最初のリンクで受信されます。 SGBP が userx についてバンドルを既存のスタック グループ メンバーの中から探そうとします。 見つからない場合は、MP が PPP でネゴシエートされているため、バンドル インターフェイスが systema 上に作成されます。

  2. userx からの 2 回目のコールは、systemb で受信されます。 SGBP は、systema にバンドルがあるかどうかの判定に使用されます。 L2F は、このリンクを systemb から systema へ転送するために使用されます。 投影された PPP リンクが systema に作成されます。 その後、投影された MP リンクは、バンドル インターフェイスと一緒になります。

  3. userx からの 3 回目のコールは、systemc で受信されます。 再度、SGBP は、systema にバンドルがあるかどうかの判定をします。 L2F は、このリンクを systemc から systema へ転送するために使用されます。 投影された PPP リンクが systema に作成されます。 その後、投影された MP リンクは、バンドル インターフェイスと一緒になります。

注:systema 上のバンドルは、バンドル インターフェイスで表されます。 個々の発信者ごとに、同じ発信者からの MP メンバー インターフェイスは、あるバンドル インターフェイスで終端するか、そこから発信されます。

エンド ユーザ インターフェイス

Vtemplate ユーザ インターフェイスは、通常はここで指定されます。 詳細については、『Virtual Templateleavingcisco.com』の「Functional Specification」を参照してください。

SGBP

  1. sgbp group <name>

    このグローバル コマンドでは、「スタック グループ」を定義して、これに名前を付け、このシステムをスタック グループのメンバーにしています。

    注: グローバルに定義できるスタック グループは 1 つだけです。

    「stackq」というスタック グループを定義します。

    systema(config)#sgbp group stackq
    

    注:systema から送信された PPP CHAP チャレンジまたは PPP PAP 要求は、「stackq」という名前になります。 アクセス サーバに対してスタック グループ名を定義すると、通常は同じシステムに定義されたホスト名がこの名前で置き換えられます。

  2. sgbp member <peer-name> <peer-IP-address>

    このグローバル コマンドでは、スタック グループ内のピアを指定します。 <peer-name> はリモート スタック メンバーのホスト名で、<peer-IP-address> はその IP アドレスです。 したがって、スタック内の自分自身を除くすべてのスタック グループ メンバのエントリを定義する必要があります。 ピア名は、Domain Name Server(DNS; ドメイン ネーム サーバ)を使用して解決されます。 DNS サーバを使用している場合は、次に示すように、IP アドレスを入力する必要がありません。

    systema(config)#sgbp member systemb 1.1.1.2
       systema(config)#sgbp member systemc 1.1.1.3 
  3. sgbp seed-bid {default | offload | forward-only | <0-9999>}

    スタック メンバーがバンドルに対して送信権要求に使用する、設定変更が可能な重みです。

    すべてのスタック メンバーに対して default パラメータが定義されている場合、ユーザ userx に対する最初のコールを受信したスタック メンバーは、常に送信権要求に勝ち、マスター バンドル インターフェイスをホストします。 同じユーザから他のスタック メンバーへのこの後のすべてのコールは、このスタック メンバーに投影されます。 sgbp seed-bid を定義しない場合は、default を使用することと同じです。

    offload を定義すると、事前に調整されたプラットフォームごとの送信権要求を送信し、「バンドルの負荷」を差し引いた CPU パワーを概算します。

    <0-9999> を設定すると、送信される送信権要求は、ユーザが定義した値から「バンドルの負荷」を差し引いた値になります。

    バンドルの負荷は、スタック メンバー内のアクティブなバンドルの数として定義されます。

    1. 複数の PRI にまたがるロータリー グループ内に、コールを受信するためにスタックされた同一のスタック メンバーがある場合は、sgbp seed-bid default across all stack members コマンドを発行します。 同一のスタック メンバーの例としては、4 台の AS5200 で構成されたスタック グループが考えられます。 ユーザ userx に対する最初のコールを受信したスタック メンバーは、常に送信権要求に勝ち、マスター バンドル インターフェイスをホストします。 同じユーザから他のスタック メンバーへのこの後のすべてのコールは、このスタック メンバーに投影されます。 複数のコールが同時に複数のスタック メンバー宛てに着信した場合は、SGBP のタイブレーキング メカニズムによって、平衡状態が破られます。

    2. スタック メンバーとして、他のスタック メンバーよりも高いパワーの CPU を搭載しているときには、他よりも高いそのスタック メンバーのパワーを活用したい場合があります(たとえば、4500 1 台や AS5200 4 台など、スタック メンバーとして使用できる他の同様のスタック メンバーよりも高性能の CPU 1 台または複数)。sgbp seed-bid offload コマンドを発行すると、指定した高性能のスタック メンバーをオフロード サーバとして設定できます。 この場合、オフロード サーバはマスター バンドルをホストします。 他のスタック メンバーからのすべてのコールは、このスタック メンバーに投影されます。 プラットフォームが同じ(同等)で、送信権要求は同じ場合には、実際には、1 台または複数のオフロード サーバを定義できます。 SGBP のタイブレーキング メカニズムによって、均衡状態が破られ、いずれかのプラットフォームが勝者として指定されます。

      注:異なる種類の 2 台のプラットフォームをオフロード サーバとして指定した場合は、高性能の CPU パワーを持つ方が送信権要求に勝利します。

    3. まったく同じプラットフォームを揃え、1 台または複数のプラットフォームをオフロード サーバとして指定したい場合は、sgbp seed-bid 9999 コマンドを発行して、送信権要求の値を他のプラットフォームよりも著しく高い値に手作業で設定することができます。たとえば、4700 が 1 台(最も高い優先権を持つとして指定)、4000 が 2 台、7000 が 1 台などの場合です。特定のプラットフォームの送信権要求の初期値を調べるには、show sgbp を使用します。

    4. フロントエンドのスタック メンバーが常に 1 台または複数台のオフロード サーバにオフロードするマルチシャーシ環境では、マルチリンクのバンドルがローカルで形成されているような場合には、このフロントエンドのスタック メンバーが実際にはオフロードを行わない場合があります。 このような状況は、すべてのオフロード サーバがダウンしている場合などに発生します。 ネットワーク管理者による基本設定が、着信コールを切断するものである場合には、sgbp seed-bid forward-only コマンドが適しています。

  4. sgbp ppp-forward

    sgbp ppp-forward を定義すると、PPP と MP のコールの両方が、SGBP 送信権要求の勝者に投影されます。 デフォルトでは、MP コールだけが転送されます。

  5. show sgbp

    このコマンドでは、スタック グループ メンバーの状態が表示されます。 状態は、ACTIVE、CONNECTING、WAITINFO、IDLE のいずれかです。 最も好ましいのは、すべてのスタック グループ メンバー ACTIVE と表示されることです。 CONNECTING と WAITINFO は、過渡期にある状態で、ACTIVE に移行する途中にだけ見られます。 IDLE は、スタック グループ systema がリモート スタック メンバーである systemd を検出できないことを示します。 たとえば、メンテナンスのために systemd がダウンしている場合は、疑う必要はありません。 これ以外の場合は、このスタック メンバーと systemd 間のルーティングなどに関する問題を確認する必要があります。

    systema#show sgbp
      Group Name: stack Ref: 0xC38A529
      Seed bid: default, 50, default seed bid setting
         Member Name: systemb State: ACTIVE  Id: 1
         Ref: 0xC14256F
         Address: 1.1.1.2
         Member Name: systemc State: ACTIVE  Id: 2
         Ref: 0xA24256D
         Address: 1.1.1.3 Tcb: 0x60B34439
         Member Name: systemd State: IDLE Id: 3
         Ref: 0x0
         Address: 1.1.1.4
    	
  6. show sgbp queries

    現在シードされている送信権要求の値を表示します。

    systema# show sgbp queries
      Seed bid: default, 50
      systema# debug sgbp queries
      %SGBPQ-7-MQ:    Bundle: userX  State: Query_to_peers   OurBid: 050
      %SGBPQ-7-PB:    1.1.1.2 		State: Open_to_peer  Bid: 000  Retry: 0
      %SGBPQ-7-PB:    1.1.1.3		 State: Open_to_peer  Bid: 000  Retry: 0
      %SGBPQ-7-PB:    1.1.1.4		 State: Open_to_peer  Bid: 000  Retry: 0
      %SGBPQ-7-MQ:    Bundle: userX  State: Query_to_peers   OurBid: 050
      %SGBPQ-7-PB:    1.1.1.2		State: Rcvd     Bid: 000  Retry: 0
      %SGBPQ-7-PB:    1.1.1.3		State: Rcvd     Bid: 000  Retry: 0
      %SGBPQ-7-PB:    1.1.1.4		State: Rcvd     Bid: 000  Retry: 0
      %SGBPQ-7-DONE: Query #9 for bundle userX, count 1, master is local
    

MP

  1. multilink virtual-template <1-9>

    これは、MP バンドル インターフェイスが、自身のインターフェイス パラメータのクローンを作成するときに使用するバーチャル テンプレート番号です。 次の例では、MP とバーチャル テンプレートを関連付ける方法について説明します。 バーチャル テンプレート インターフェイスは、次のように定義する必要があります。

    systema(config)#multilink virtual-template 1
      systema(config)#int virtual-template 1
      systema(config-i)#ip unnum e0
      systema(config-i)#encap ppp
      systema(config-i)#ppp multilink
      systema(config-i)#ppp authen chap
    
  2. show ppp multilink

    このコマンドでは、次に示すように、MP バンドルに関するバンドル情報が表示されます。

    systema#show ppp multilink
      Bundle userx 2 members, Master link is Virtual-Access4
      0 lost fragments, 0 reordered, 0 unassigned, 100/255 load
      0 discarded,  0 lost received, sequence 40/66 rcvd/sent
      members 2
        Serial0:4
        systemb:Virtual-Access6    (1.1.1.2)
    

    この例では、スタック グループ stackq のスタック グループ メンバー systema について、バンドル userx がそのバンドル インターフェイスを Virtual-Access4 として設定していることを示しています。 このバンドル インターフェイスには、2 つのメンバー インターフェイスが属しています。 最初のものは、ローカルの PRI チャネルであり、2 つ目のものはスタック グループ メンバー systemb から投影されたインターフェイスです。

次の例を参照するには、『この文書の第 2 部』に進んでください。

次のセクションも参照してください。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 14942