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

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

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2005 年 9 月 9 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次

L2F
MP

概要

このドキュメントでは、Cisco Systems のアクセス サーバ プラットフォームにおける、スタックまたはマルチシャーシ環境(マルチシャーシ マルチリンク PPP(MMP) と呼ばれる場合もある)でのマルチリンク PPP(MP)のサポートについて説明します。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

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

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

関連用語

このドキュメントで使用する用語は次のとおりです。

  • アクセス サーバ - リモート アクセスを提供する ISDN および非同期インターフェイスを含むシスコのアクセス サーバ プラットフォーム。

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

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

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

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

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

  • ロータリー グループ - ダイヤル アウトまたはコールの受信用に割り当てられた物理インターフェイスのグループ。 このグループは、ダイヤル アウトやコールの受信のために使用できるリンクのプールのような役割を果たします。

  • SGBP: Stack Group Bidding Protocol。

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

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

  • Vtemplate - 仮想テンプレート インターフェイス。

注: このドキュメントで参照されている RFC については、Cisco IOS リリース 11.3-No. 523 でサポートされる RFS およびその他の標準ドキュメント、製品速報、 RFC および標準ドキュメントの入手を、 InterNIC への直接リンクについては RFC インデックス leavingcisco.com を参照してください。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

問題の定義

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

この機能によって、速度の遅い WAN リンクの伝送の遅延を低減するとともに、受信ユニットでの最大受信量を向上させることができます。

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

シスコでは自律エンド システムへの MP をサポートしています。つまり、同じクライアントからの複数の MP リンクをアクセス サーバで終端できます。 ただし、たとえば ISP は、1 つのロータリー番号を複数のサーバにまたがる複数の PRI に割り当て、ビジネス ニーズに合わせられるようにサーバ構造をスケーラブルにし、柔軟性を持たせられれば便利だと考えています。

Cisco IOS ではか。 同じクライアントからの複数の MP リンクが異なるアクセス サーバで終端できるように、ソフトウェア リリース 11.2 Cisco はそのような機能性を提供します。 同じバンドル内の個々の MP リンクは実際には異なるアクセス サーバで終端しますが、MP クライアントが接続されている限り、これは 1 つのアクセス サーバで終端するのと同様です。

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

機能概要

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

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

/image/gif/paws/14942/figure1-mmp.gif

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

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

  • SGBP

  • Vtemplate

  • L2F

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

SGBP

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

スタック グループがシステム A およびシステム B で構成されていると仮定します。 userx と呼ばれるリモート MP クライアントでは、システム A(systema)で最初の MP リンクが終端しています。 バンドル userx は、systema で形成されています。 userx からの次の MP リンクは、システム B(systemb)で終端しています。 SGBP は、この userx があるバンドルを systema から探します。 この時点で、もう 1 つのコンポーネントの L2F は systemb から systema への 2 番目の MP のリンクを投影します。 投影された MP リンクは、その後 systema でバンドルを結合します。

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

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

注: たとえば、2 台の 4500 との間で送信権要求が等しい場合、SGBP は送信権要求の勝者としてどちらか一方をランダムに指定します。 常に他のスタック メンバーに競り勝つように 4500 を設定できます。 そのため 4500 は、アクセス サーバと比べて高い CPU パワーで処理されるのに向いている MP パケットのフラグメントと再構築のタスクを専門とするオフロード マルチシャーシ MP サーバとなります。

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

仮想アクセスインターフェイス

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

バーチャル テンプレート インターフェイスは、バーチャル アクセス インターフェイスがクローン化されるときの設定情報のレポジトリとなります。 ダイヤラ インターフェイスの設定は、設定情報の別のソースとなります。 仮想アクセス インターフェイスのクローンを作成する設定のソースを選択する方法は「マルチシャーシ マルチリンク PPP(MMP)(パート2)」で説明します。

L2F

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

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

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

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

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

図 2:スタックにコール中のクライアント

figure2-mmp.gif

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

  2. systemb が userx からの 2 番目のコールを受信します。 SGBP は、systema にバンドルが存在していることを特定するのに役立ちます。 L2F は、このリンクを systemb から systema に転送するのに役立ちます。 投影された PPP リンクが systema に作成されます。 その後、投影された MP リンクは、バンドル インターフェイスと一緒になります。

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

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

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

Vtemplate ユーザ インターフェイスは、通常はここで指定されます。 詳細については、「仮想テンプレート leavingcisco.com 機能仕様」を参照してください。

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 アドレスです。 したがって、スタック内の自分自身を除くすべてのスタック グループ メンバのエントリを定義する必要があります。 ドメイン ネーム サーバ(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 をスタック メンバーとして利用できる場合は、そのスタック メンバーの比較的高いパワーを残りのメンバーに活用できます(たとえば、他の同様なスタック メンバーよりも高いパワーの CPU をスタック メンバーとして利用できる場合、 たとえば、4500 1 台と AS5200 4 台など)。指定した高パワーのスタック メンバーを sgbp seed-bid offload コマンドを使用してオフロード サーバとして設定できます。 この場合、オフロード サーバはマスター バンドルをホストします。 他のスタック メンバーからのすべてのコールは、このスタック メンバーに投影されます。 実際には、1 つ以上のオフロード サーバを定義できます。 プラットフォームが同じ(同等)の場合は、送信権は等しくなります。 SGBP のタイブレーキング メカニズムによって、均衡状態が破られ、いずれかのプラットフォームが勝者として指定されます。

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

    3. 自分で分類したプラットフォーム、またはまったく同じプラットフォームを使用しており、1 台以上のプラットフォームをオフロード サーバとして指定する場合は、sgbp seed-bid 9999 コマンドを使用して送信要求値を残りのプラットフォームよりも大幅に高い値に設定します。 たとえば、4700 が 1 台(最も高い seed-bid で指定)、4000 が 2 台、7000 が 1 台などです。 特定のプラットフォームに関連付けた最初の送信要求値を特定するには、show sgbp を使用します。

    4. フロントエンドのスタック メンバーが常に 1 台または複数台のオフロード サーバにオフロードするマルチシャーシ環境では、マルチリンクのバンドルがローカルで形成されているような場合には、このフロントエンドのスタック メンバーが実際にはオフロードできない場合があります。 このような状況は、すべてのオフロード サーバがダウンしている場合などに発生します。 ネットワーク管理者が着信コールを切断する場合は、切断する代わりに 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 から投影されたインターフェイスです。

これらの例については、「マルチシャーシ マルチリンク PPP(MMP)(パート 2)」を参照してください。

また、次に関するセクションも参照してください。

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

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


関連情報


Document ID: 14942