マルチシャーシマルチリンク PPP（MMP）（パート 2）

ダウンロードオプション

PDF (274.1 KB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (102.2 KB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (160.2 KB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2005 年 9 月 9 日

Document ID:14945

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

概要

前提条件

例

スタックグループ内のAS5200 (ダイヤラが設定された場合)

オフロードサーバの使用

物理インターフェイスを使用するオフロードサーバ

非同期、シリアルおよび他の非ダイヤラインターフェイス

マルチシャーシからのダイヤルアウト

マルチシャーシへのダイヤル

設定および制限

プロトコルごとのインターフェイス構成の設定

グローバル・プロトコル構成の設定

トラブルシューティング

SGBP が正常に動作していることの確認

PPPマルチリンクのデバッグ

VPN/L2Fのデバッグ

概要

このドキュメントでは、シスコのアクセスサーバプラットフォームにおける「スタック」またはマルチシャーシ環境でのマルチリンク PPP（MP）のサポート（マルチシャーシマルチリンク PPP という名称で MMP と呼ばれる場合もあり）のサポートについて引き続き説明します。

このドキュメントは、2 部で構成されたドキュメントの第 2 部です。詳細については、このドキュメントの第 1 部を参照してください。

前提条件

このドキュメントの前提条件は、このドキュメントの第 1 部に記載されています。

例

スタックグループ内のAS5200 (ダイヤラが設定された場合)

ダイヤラが物理インターフェイスに設定されている場合、仮想テンプレートインターフェイスを指定する必要はまったくありません。仮想アクセスインターフェイスは、ダイヤラインターフェイスと、そのダイヤラインターフェイスに関連付けられている物理インターフェイスとの間を補強するパッシブインターフェイスとして機能します。

つまり、定義する必要があるのは、スタックグループ名、共通パスワード、およびすべてのスタックメンバーにわたるスタックグループメンバーだけです。次の例に示すように、仮想テンプレートインターフェイスは定義されません。

systema#config
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3

  username stackq password therock

  int dialer 1
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  ppp multilink

  controller T1 0
  framing esf                    
  linecode b8zs                  
  pri-group timeslots 1-24

  interface Serial0:23
  no ip address
  encapsulation ppp
  dialer in-band
  dialer rotary 1
  dialer-group 1

次の例は、E1 コントローラからのものです。

controller E1 0
  framing crc4  
  linecode  hdb3
  pri-group timeslots 1-31
  interface Serial0:15
  no ip address
  encapsulation ppp
  no ip route-cache
  ppp authentication chap
  ppp multilink

バンドルインターフェイスが作成されると、ダイヤラインターフェイスから PPP コマンドだけを使用してクローンが作成されます。その後の投影される PPP リンクも、ダイヤラインターフェイスから PPP コマンドを使用してクローンが作成されます。図 3 に、ダイヤラインターフェイスがバンドルインターフェイスの上にどのように配置されるかを示しています。この図をダイヤラインターフェイスがない図 2 と比較してください。

PRI および BRI は、デフォルトではダイヤラインターフェイスです。（dialer rotary コマンドによる）明示的なダイヤラなしで設定された PRI でも、次の例に示すように Serial0:23 のダイヤラインターフェイスです。

interface Serial0:23
  ip unnum e0
  dialer map .....
  encap ppp
  ppp authen chap
  dialer-group 1
  dialer rot 1
  ppp multilink

図 3：systema、systemb、およびsystemcで構成されるスタックグループstackq。systema のリンクは、ダイヤラインターフェイスに設定されています。

オフロードサーバの使用

systema は、（sgbp seed-bid コマンドを使用して）オフロードサーバとして指定されます。 他のスタックグループメンバーはすべて、sgbp seed-bid default コマンドを使用して定義する必要があります（または、sgbp seed-bid コマンドを定義していない場合、デフォルトで sgbp seed-bid default になります）。

systema#config
  multilink virtual-template 1
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3
  sgbp seed-bid offload
  username stackq password therock

  interface virtual-template 1
  ip unnumbered e0
  :

  ppp authen chap
  ppp multilink

図 4：オフロードサーバとしての systema 。

物理インターフェイスを使用するオフロードサーバ

指定されたオフロードサーバに、他のスタックメンバーと同じ通信事業者ハントグループに応答させたい物理インターフェイス（たとえば、PRI）が組み込まれている場合、そのように応答させるには、このドキュメントの「スタック内の AS5200（ダイヤラを設定）」セクションと「オフロードサーバの使用」セクションで示した各設定を組み合わせることで設定できます。

オフロードされ投影される PPP リンクとそのバンドルインターフェイスでは、設定ソースの仮想テンプレートを使用します。最初のリンクがある接続は、ダイヤラインターフェイスに接続されている物理デバイスに達します。また、バンドルインターフェイスとその後の投影される PPP リンクすべての設定のソースは、ダイヤラインターフェイス設定です。このため、これらのバリエーションは最初のリンクが達するスタックメンバーに基づいて共存します。

この設定は、ダイヤラおよび仮想テンプレートインターフェイスに必要な設定が複雑なため、推奨されません。

非同期、シリアルおよび他の非ダイヤラインターフェイス

非同期デバイスおよびシリアルデバイスをダイヤラインターフェイスとして設定できます（この場合は、このドキュメントの「スタック内の AS5200（ダイヤラを設定）」セクションに戻ってください）が、非同期インターフェイス、シリアルインターフェイス、およびその他のダイヤラ以外のインターフェイスのダイヤラ設定なしでマルチシャーシ MP のサポートを選択できます。この場合、すべての設定のソースが次に示すように仮想テンプレートインターフェイスで定義されます。

#config
  multilink virtual-template 1
  sgbp group stackq
  sgbp member systemb 1.1.1.2
  sgbp member systemc 1.1.1.3
  username stackq password therock
  interface virtual-template 1
  ip unnumbered e0
  :
  ppp authen chap
  ppp multilink

  int async 1
  encap ppp 
  ppp multilink 
  ppp authen chap
  :

  line 1
  login 
  autoselect ppp 
  autoselect during-login
  speed 38400
  flow hardware

マルチシャーシからのダイヤルアウト

現在、マルチシャーシの設定ではダイヤルアウトをサポートしていません。Layer 2 Forwarding（L2F; レイヤ 2 転送）プロトコルがダイヤルアウト（発信）をサポートしていないためです。

その結果、オフロードサーバ（ルートがダイヤラプロファイル上などでスプーフィングされるところ）が同じスタックグループでフロントエンドスタックメンバーにダイヤルを開始することはありません。スプーフィングされたすべてのルートは、フロントエンドのスタックメンバーに設定する必要があります。これは、これらのフロントエンドのスタックメンバーが物理的なダイヤル接続（PRI など）があるスタックメンバーであるためです。

次に回避策をいくつか示します。

sgbp ppp-forward コマンドがフロントエンドのスタックメンバーに対して発行されると、これはすべての PPP および PPP マルチリンクコールが Stack Group Bidding Protocol（SGBP）ビディングでのコールの所有権者（オフロードサーバなど）に自動的に転送されることを意味します。

ネットワークアクセスサーバ（NAS）のダイヤルアウト（発信）を利用して、IP ルーティングコンバージェンス（IP 専用）の処理に任せる必要があります。たとえば、次のように、1.1.1.1 にダイヤルし、このアドレスを NAS 上の dialer map ステートメントに配置し、スタティックルートを NAS に配置します。
```
  ip route 1.1.1.1 255.255.255.255 serial0:23
  int serial0:23
  ip address 3.3.3.3 255.0.0.0
  dialer map ip 1.1.1.1 howard 7771234
```
このダイヤルがリモートピアに接続すると、PPP 接続がリモートピアとオフロードサーバ間で形成されます。フロントエンドのスタックメンバーは、完全にバイパスされます。オフロードサーバ上のPPPは、ピアへのホストルート1.1.1.1をインストールします。この時点で、IPルーティングプロトコルはそこからオフロードサーバ上のホストルートに収束します。これは、ルーティングメトリックがルートをそこに集約するためです。

注：ルーティングコンバージェンスでは遅延が発生します。
sgbp ppp-forward コマンドがフロントエンドのスタックメンバーに対して定義されない場合、これはその PPP マルチリンクコールが SGBP ビディングでのコールの所有権者に自動的に転送されることを意味します。このため、フロントエンドのスタックメンバーからリモートピアへのダイヤラは、フロントエンドとリモートピア間の PPP 接続全体に及びます。これは、NAS があたかもスタックグループの一部ではないかのような動作です。

注：これは接続がストレートPPP（PPPマルチリンクではなく）である場合に発生します。

マルチシャーシへのダイヤル

クライアントとスタックメンバーの間でIPルーティング(Enhanced Interior Gateway Routing Protocol(EIGRP)やOpen Shortest Path First(OSPF)など)が流れ、最終的に入札に勝った場合（オフロードサーバなど）、次のヒントを参照してください。

接続済みルートのクライアント側への設定を防ぐ

次に示すように、1.1.1.2 が NAS のアドレスであるクライアントの 1.1.1.2（透過的なフレームフォワーダ）を設定します。

  int bri0

  dialer map 1.1.1.2 ....

たとえば、クライアントとオフロードサーバ間で EIGRP を実行させる場合、オフロードサーバ上のルーティングテーブルで、1.1.1.2 に到達するために、ルートが仮想アクセスインターフェイスを経由する必要があることを示します。これは、クライアント側の PPP IP Control Protocol（IPCP）で BRI インターフェイスへの接続済みルート 1.1.1.2 を設定するためです。次に、EIGRP では、PPP セッションを介した（L2F を介した）オフロードサーバへのこのルートをアドバタイズします。このため、オフロードサーバ上の EIGRP では、1.1.1.2 に到達するために、このクライアントにルーティングする必要があることを指示します。クライアントのルート 1.1.1.1 は仮想アクセスインターフェイスへのルートです。

これで、クライアント1.1.1.1宛てのパケットが作成されました。IPルーティングはパケットを仮想アクセスインターフェイスに送信します。仮想アクセスインターフェイスは、IP/ユーザデータプロトコル(UDP)/L2F/PPPカプセル化をカプセル化し、パケットをL2F NAS(1.1.1.2)に送信します。この時点ではすべてが正常です。次に、IP ルーティングでは、パケットを（たとえば）イーサネットインターフェイスを通じて送出するのではなく、仮想アクセスインターフェイスを通じて再度送出します。これは、ルーティングテーブルで、NAS に到達するためにクライアントを通過する必要があることを示しているためです。これにより、ルーティングループが発生し、L2F トンネルを介した入出力が無効にされます。

これが発生しないようにするために、IPCP で接続済みルートをクライアント側に設定することを許可しないでください。

注：これは、クライアントとCiscoホームゲートウェイの間でIPルーティングプロトコルが実行されている場合にのみ該当します。

クライアント設定は、次のとおりです。

  int bri0

  no peer neighbor-route

クライアント側の dialer map

クライアントがマルチシャーシ環境にダイヤルする場合、マルチリンクバンドルのそれぞれの潜在的なビディングでのコールの所有権者に対してダイヤラを定義します。たとえば、マルチシャーシスタックにオフロードサーバが 4 つ存在する場合、クライアント側に 4 つの dialer map を定義する必要があります。

以下に、いくつかの例を示します。

  client 1.1.1.1

  int bri0

  dialer map 1.1.1.3 ...

この例では、1.1.1.3 がただ 1 つのオフロードサーバです。

1.1.1.2 宛てのパケットは BRI にルーティングされ、ダイヤラは、dialer map の一致があるため、この宛先にダイヤルします。オフロードサーバの 1.1.1.4 は実際にビディングでのコールの所有権者となり、そこに PPP セッションが投影されます。EIGRP は、クライアントとオフロードサーバとの間で交換されます。クライアントのIPルーティングテーブルには、BRI0へのルート1.1.1.4（オフロードサーバ）が設定されています。クライアントでは、1.1.1.4宛てのパケットがBRI0にルーティングされます。ただし、ダイヤラは一致しないためダイヤルできません。

注：オフロードサーバへのアクセスがクライアントの要件である場合は、常にクライアント上のすべての潜在的なSGBP送信権獲得に対してダイヤラマップを定義してください。

設定および制限

マルチシャーシ MP には、エンタープライズ j イメージが必要です。
アクセスサーバごとに定義できるスタックグループは 1 つだけです。
MP リアセンブル遅延の原因となる、スタックメンバー間の高遅延 WAN リンクによって、マルチシャーシ MP の効率が低下するおそれがあります。
インターフェイスは、PRI、[M]BRI、シリアル、および非同期の各デバイスでサポートされます。
ダイヤルアウト（発信）はサポートされません。

プロトコルごとのインターフェイス構成の設定

実用上は、仮想テンプレートに特定のプロトコルのアドレスを設定しないでください。

  interface virtual-template 1

  ip address 1.1.1.2 255.0.0.0

  :

仮想テンプレートインターフェイスは、任意の数の仮想アクセスインターフェイスのクローンをダイナミックに作成するための元になるテンプレートとして役立ちます。インターフェイスごとのプロトコル固有のアドレスを仮想テンプレートインターフェイスに指定しないでください。IP アドレスはネットワークインターフェイスごとに一意でなければならないため、仮想テンプレートインターフェイスに一意の IP アドレスを指定することは誤りです。代わりに、以下のことを行います。

  interface virtual-template 1

  ip unnum e0

  :

グローバル・プロトコル構成の設定

単一のアクセスルータにダイヤルし、アクセスサーバに一意のグローバルアドレスがある（DECnet など）と想定するクライアントでは、いくつかのアクセスサーバで構成されたマルチシャーシマルチリンクのスタックグループに実際にダイヤルするようになりました。この種の状況では、単一のアクセスサーバにあるスタックグループの終了を決定してください。この終了を行うには、指定されたアクセスサーバで sgbp seed-bid offload コマンドを発行します（または、最も高いビディングを指定します）。

トラブルシューティング

問題がある場合、まず最初に 1 つのスタックメンバーに集中し、他のすべてのスタックメンバーを無効にします。次に PPP マルチリンク接続をテストし、通常の Challenge Handshake Authentication Protocol（CHAP）認証を実行し、設定の誤りがないかインターフェイス設定をチェックしたりなどします。そのスタックメンバーが機能していることを確認できた場合は、他のスタックメンバーを有効にして、次のようにトラブルシューティングを続けます。

SGBP が正常に動作していることを確認します。
PPP マルチリンクをデバッグします。
VPN および L2F をデバッグします。

SGBP が正常に動作していることの確認

show sgbp コマンドを発行して、すべてのメンバーの状態が ACTIVE であることを確認します。あるいは、状態が IDLE、AUTHOK、または ACTIVE のものがないか探します。前に述べたように、IDLE は、意図的に非アクティブ状態にしているすべてのリモートスタックメンバーにとっては有効な状態です。

上記のような問題が見つかった場合、コマンドの debug sgbp hellos と debug sgbp error をオンにします。2 つのスタックメンバー（たとえば、systema と systemb）間の認証は、（systema 上で）次のようでなければなりません。

  systema# debug sgdp hellos

  %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq
  %SGBP-7-CHALLENGED: Hello Challenge message from member systemb (1.1.1.2)
  %SGBP-7-RESPONSE: Send Hello Response to systemb group stackq
  %SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stackq
  %SGBP-7-RESPONDED: Hello Response message from member systemb (1.1.1.2)
  %SGBP-7-AUTHOK: Send Hello Authentication OK to member systemb (1.1.1.2)
  %SGBP-7-INFO: Addr = 1.1.1.2 Reference = 0xC347DF7
  %SGBP-5-ARRIVING: New peer event for member systemb

systema は CHAP スタイルのチャレンジを送信し、systemb から応答を受信します。同様に、systemb もチャレンジを送信し、systema から応答を受信します。

認証に失敗すると、次のメッセージが表示されます。

  %SGBP-7-AUTHFAILED - Member systemb failed authentication

このメッセージは、リモートの systemb の stackq のパスワードが systema で定義されているパスワードと一致しないことを示しています。

  %SGBP-7-NORESP -Fail to respond to systemb group stackq, may not have password

このメッセージは、systema でユーザ名またはパスワードが TACACS+ によってか、またはローカルに定義されていないことを意味しています。

通常、スタックグループの stackq のすべてのスタックメンバー間で共通のシークレットを定義します。このシークレットは、ローカルで定義でき、また TACACS+ によっても定義できます。

それぞれのスタックメンバーに定義されるローカルユーザ名は、次のようになります。

  username stackq password blah

この共通のシークレットは、スタックメンバーの SGBP ビディングと調停を容易にするためのものです。

リモートクライアントがスタックメンバーにダイヤルインする際の PPP リンクの認証については、このドキュメントの「PPP マルチリンクのデバッグ」セクションを参照してください。

配線またはルーティングの問題の場合、よくあるエラーの 1 つ（このエラーは実際上 SGBP hello メッセージで受信されます）は、スタックメンバーのローカルで定義された IP アドレスとは異なる、同じスタックメンバーの送信元 IP アドレスを使用することです。

  systema#debug sgbp error
  %SGBP-7-DIFFERENT - systemb's addr 1.1.1.2 is different from hello's addr 3.3.4.5

このメッセージは、systemb から受信した SGBP hello の送信元 IP アドレスが、systemb に対して（sgbp member コマンドを使用して）ローカルで設定された IP アドレスと一致していないことを意味しています。 これを修正するには、systemb に移動し、複数のインターフェイス（これらのインターフェイスによって、SGBP hello でこのメッセージを送信できます）がないかを調べます。

もう 1 つのよくあるエラーの原因は、次のようなエラーの原因です。

  %SGBP-7-MISCONF, Possible misconfigured member routerk (1.1.1.6)

このメッセージは、systemk をローカルに定義していませんが、別のスタックメンバーを定義していることを示しています。

PPPマルチリンクのデバッグ

まず、PPP でクライアントとスタックメンバーが正しく認証されたかどうかを調べます。

次の例では、CHAP 認証について、より複雑なため具体的に説明しています。よくある例として、CHAP 認証でシスコプラットフォームがローカルユーザ名とともにクライアントとして使用されることがあります（Terminal Access Controller Access Control System Plus（TACACS+）もサポートされていますが、ここでは示していません）。

クライアントの userx	スタック `stackq のすべてのメンバー`
#config username stackq password blah	#config username userx password blah

ダイヤラインターフェイスが含まれていない

オフロードサーバにはダイヤラインターフェイスがないため、仮想アクセスインターフェイスのインターフェイス設定の別のソースが必要になります。解決策は、仮想テンプレートインターフェイスを使用することです。

まず、それぞれのスタックメンバーにマルチリンクのグローバル仮想テンプレート番号を定義します。
```
  #config
  Multilink virtual-template 1
```
対象の物理インターフェイス（PRI、BRI、非同期、同期シリアルなど）にダイヤラインターフェイスを設定していなかった場合、次のように定義できます。
```
  interface virtual-template 1
  ip unnumbered e0
  ppp authen chap
  ppp Multilink
```
注：仮想テンプレートに特定のIPアドレスを定義しないでください。これは、投影される仮想アクセスインターフェイスが、必ず仮想テンプレートインターフェイスからのクローンとして作成されるためです。その後の PPP リンクも、仮想アクセスインターフェイスのクローンを作成済みでアクティブにして、スタックメンバーに投影される場合、2 つの仮想インターフェイスに同じ IP アドレスがあると、それらの間で IP を誤ってルーティングさせる原因となります。

ダイヤラインターフェイスが含まれている

ダイヤラが物理インターフェイスに設定されている場合、インターフェイス設定がダイヤラインターフェイスにあるため、仮想テンプレートインターフェイスを指定する必要はありません。この場合、仮想アクセスインターフェイスは、ダイヤラインターフェイスと、そのダイヤラインターフェイスに関連付けられているメンバーのインターフェイスとの間を補強するパッシブインターフェイスとして機能します。

注：ダイヤラーインターフェイスDialer 1は、PPPマルチリンクセッションで次のように表示されます。

  systema#show ppp Multilink
  Bundle userx 2 members, Master link is Virtual-Access4
  Dialer interface is Dialer1
  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.1)

LCP および NCP

すべてのメンバーのインターフェイスの LCP 状態は「up」でなければなりません。IPCP、ATCP、および他の NCP は、バンドルインターフェイスでのみ up でなければなりません。

バンドルインターフェイス Virtual-Access4 の show int の出力は、次のようになります。

  router#show int  Virtual-Access4
  Virtual-Access4 is up, line protocol is up 
          :
      LCP Open, Multilink Open
      Open: ipcp
              :

他のすべてのメンバーのインターフェイスの show int の出力は、次のようになります。

  router# show int Serial0:4
  Serial0:4 is up, line protocol is up 
          :
  LCP Open, Multilink Open
  Closed:  ipcp

VPN/L2Fのデバッグ

次のコマンドをオンにします。

  debug vpn event
  debug vpn error

物理インターフェイスで着信コールを受け付けて、そのコールをターゲットのスタックメンバーに転送する際に、次のように表示されます。

  Serial0:21 VPN Forwarding 
  Serial0:21 VPN vpn_forward_user userx is forwarded

ターゲットのスタックメンバーで、次のように表示される場合は、

  Virtual-Access1 VPN PPP LCP not accepting rcv CONFACK
  Virtual-Access1 VPN PPP LCP not accepting sent CONFACK

仮想テンプレートインターフェイスの定義をチェックしてください。通常、仮想テンプレートインターフェイスは、着信コールを受け付ける物理インターフェイスの PPP インターフェイスのパラメータと一致している必要があります。

次の最小設定を覚えておいてください（例として CHAP を使用）。

  #config
  multilink virtual template 4
  int virtual-template 4
  ip unnum e0
  encap ppp
  ppp authen chap 
  ppp Multilink

次のように表示される場合があります。

Virtual-Access1 VPN PPP LCP accepted sent & rcv CONFACK

上記のメッセージが表示された場合、最初に着信コールを受けたスタックメンバーから、同じクライアントのバンドルインターフェイスが存在する（またはオフロードのシナリオでのように、バンドルインターフェイスをこれから作成する）スタックメンバーに、L2F で PPP リンクを正常に投影したことを意味しています。

よくあるエラーとしては、共通のスタック名（stackq）のユーザ名を定義しないことや、すべてのスタックメンバーに対するスタックのパスワードを一致させないことです。

次のコマンドを実行します。

  debug vpdn l2f-error

この結果、次のメッセージが表示されます。

  L2F Tunnel authentication failed for stackq

この場合、各スタックメンバーでユーザ名とパスワードの一致について修正します。

マルチシャーシマルチリンク PPP（MMP）（パート 2）

ダウンロードオプション

偏向のない言語

翻訳について

内容

概要

前提条件

例

スタックグループ内のAS5200 (ダイヤラが設定された場合)

オフロードサーバの使用

物理インターフェイスを使用するオフロードサーバ

非同期、シリアルおよび他の非ダイヤラインターフェイス

マルチシャーシからのダイヤルアウト

マルチシャーシへのダイヤル

接続済みルートのクライアント側への設定を防ぐ

クライアント側の dialer map

設定および制限

プロトコルごとのインターフェイス構成の設定

グローバル・プロトコル構成の設定

トラブルシューティング

SGBP が正常に動作していることの確認

PPPマルチリンクのデバッグ

ダイヤラインターフェイスが含まれていない

ダイヤラインターフェイスが含まれている

LCP および NCP

VPN/L2Fのデバッグ

関連情報

更新履歴

このドキュメントは役に立ちましたか?

シスコに問い合わせ

このドキュメントは次の製品に対応しています

マルチシャーシ マルチリンク PPP（MMP）（パート 2）

ダウンロード オプション

偏向のない言語

翻訳について

内容

更新履歴

このドキュメントは役に立ちましたか?

シスコに問い合わせ

このドキュメントは次の製品に対応しています

マルチシャーシマルチリンク PPP（MMP）（パート 2）

ダウンロードオプション