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

debug ppp negotiation の出力について

2010 年 10 月 12 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2010 年 2 月 4 日) | フィードバック

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
PPP ネゴシエーションの各フェーズ
PPP ネゴシエーションのパケット:説明
LCP、認証、および NCP ステージ
debug ppp negotiation の出力を使用したトラブルシューティング
debug ppp negotiation の出力の読み方
debug ppp negotiation の出力例
用語集と一般的なメッセージ
      全般
      LCP
      認証
      NCP
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

ダイヤル関連のアプリケーションでは、PPP が最も一般的に使用されるカプセル化のタイプです。PPP では、ポイントツーポイントによる通信リンクに接続された 2 台のマシン間で、認証用、圧縮用、そして IP などのレイヤ 3(L3)プロトコル用のさまざまなパラメータのネゴシエーションが行われます。2 台のルータ間で PPP ネゴシエーションに失敗すると、その接続は確立できません。

debug ppp negotiation コマンドを実行すると、PPP ネゴシエーションのトランザクションが表示されるため、問題や、エラーが発生したステージを特定し、解決策を講じることができます。ただし、このためには debug ppp negotiation コマンドの出力を理解する必要があります。このドキュメントでは、debug ppp negotiation コマンドの出力の読み方全般について説明しています。



前提条件

要件

このドキュメントの読者は、次の条件に適合していることを確認する必要があります。

  • 両方のルータのインターフェイスで PPP がイネーブルになっていること。PPP をイネーブルにするには、encapsulation ppp コマンドを発行します。

  • 次のコマンドを発行して、ルータ上でミリ秒のタイムスタンプをイネーブルにします。

    Router(config)# service timestamp debug datetime msec
    

    debug コマンドについての詳細は、『debug コマンドの重要な情報』を参照してください。

注:2 つのピア間での PPP ネゴシエーションは、PPP の下位レイヤ(ISDN、物理インターフェイス、ダイヤルアップ回線など)が正しく機能しない場合は、開始できません。たとえば、ISDN 上で PPP を実行する場合は、すべての ISDN レイヤがアップ ステートになっている必要があります。そうでない場合は、PPP を開始できません。



使用するコンポーネント

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



表記法

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



PPP ネゴシエーションの各フェーズ

PPP ネゴシエーションの処理中、リンクは次の表に示すようないくつかのフェーズを経過します。最終的な結果として、PPP はアップかダウンのいずれかの状態になります。

フェーズ

説明

DOWN

このフェーズでは、PPP はダウンしています。このメッセージは、リンクと PPP が完全にダウン状態になった後に表示されます。

*Mar  3 23:32:50.296: BR0:1 PPP: Phase is DOWN

ESTABLISHING

物理レイヤがアップ状態になり、使用できるようになったことが示されると、PPP はこのフェーズに移行します。LCP1 ネゴシエーションは、このフェーズで行われます。

*Mar  3 23:32:06.884: BR0:1 PPP: Phase is ESTABLISHING

AUTHENTICATING

リンクで PPP 認証(CHAP2 または PAP3)が必要な場合は、PPP はこのフェーズに移行します。PPP 認証はオプションであることに注意してください。

*Mar 3 23:32:06.952: BR0:1 PPP: Phase is AUTHENTICATING

UP

認証が完了すると、PPP は UP フェーズに移行します。NCP4 ネゴシエーションは、このフェーズで行われます。

*Mar  3 23:42:53.412: BR0:1 PPP: Phase is UP

TERMINATING

このフェーズでは、PPP がシャットダウンします。

*Mar  3 23:43:23.256: BR0:1 PPP: Phase is TERMINATING

1. LCP = Link Control Protocol(リンク制御プロトコル)

2. CHAP = Challenge Handshake Authentication Protocol(チャレンジ ハンドシェイク認証プロトコル)

3. PAP = Password Authentication Protocol(パスワード認証プロトコル)

4. NCP = Network Control Protocol(ネットワーク制御プロトコル)

次の図は、PPP のフェーズの遷移を示しています。

debug_ppp_negotiation3.gif



PPP ネゴシエーションのパケット:説明

次の表では、LCP ネゴシエーションと NCP ネゴシエーションの両方で使用される PPP ネゴシエーション パケットを説明しています。

パケット

コード

説明

CONFREQ

Configure-Request

ピアに対する接続をオープンするために、デバイスからこのメッセージが送信されます。このメッセージと一緒に、この送信元がピアにサポートさせたい設定オプションと値も送信されます。すべてのオプションと値は、同時にネゴシエートされます。ピアから CONFREJ メッセージまたは CONFNAK メッセージで応答が返された場合は、ルータは次の CONFREQ を別のオプションや値の組み合せとともに送信します。

CONFREJ

Configure-Reject

CONFREQ メッセージで受信された設定オプションが許容可能または認識可能でない場合、ルータからは CONFREJ メッセージが返されます。(CONFREQ メッセージから送られた)許容不可能なオプションは、CONFREJ メッセージに取り込まれています。

CONFNAK

Configure-NAK1

受信した設定オプションが認識可能および許容可能であるものの、いくつかの値が許容不可能である場合は、ルータから CONFNAK メッセージが送信されます。ルータでは、許容可能なオプションと値を CONFNAK メッセージに付加して、ピアが次の CONFREQ メッセージにそのオプションを含めることができるようにします。

CONFACK

Configure-ACK2

CONFREQ メッセージ内のすべてのオプションが認識可能であり、すべての値が許容可能であった場合は、ルータから CONFACK メッセージが送信されます。

TERMREQ

Terminate-Request

このメッセージは、LCP のクローズを開始するために使用されます。

TERMACK

Terminate-ACK

このメッセージは、TERMREQ メッセージへの応答として送信されます。

1. NAK = Negative Acknowledge(否定応答)

2. ACK = Acknowledge(確認応答)

注:各ピアからは、相手側のピアにサポートさせたいオプションと値を添えた CONFREQ を送信できます。これによって、各方向でネゴシエートされるオプションが異なることになります。たとえば、一方がピアの認証を必要としても、他方は必要としない場合があります。



LCP、認証、および NCP ステージ

上で説明したいくつかの PPP フェーズでは、PPP が LCP ネゴシエーション、認証、NCP ネゴシエーションなどの特定のステージに入ることがあります。詳細は、RFC 1548 leavingcisco.com および RFC 1661 leavingcisco.com を参照してください。

LCP(必須フェーズ)

LCP は、データリンク接続の確立、設定、およびテストのためのパラメータがネゴシエートされるフェーズです。LCP がオープンになった状態は、LCP の処理が正しく完了したことを示します。また、LCP がクローズした状態は、LCP の失敗を意味します。

次の図は、LCP ハンドシェイクの概念を表しています。

debug_ppp_negotiation1.gif

LCP ネゴシエーションでは、MagicNumber というパラメータも使用します。これは、そのリンクでループ バックが起きているかどうかを決定するために使用します。ランダムなストリングがリンクに送信され、同じ値が戻ってきた場合には、ルータではそのリンクでループ バックが起きていると判断します。

認証(デフォルトではオプションのフェーズ)

このステージでは、LCP ネゴシエーションで合意した認証プロトコル(CHAP または PAP)を使用して、認証が行われます。PAP に関する情報は、『PPP パスワード認証プロトコル(PAP)の設定とトラブルシューティング』を参照してください。

CHAP に関する情報は、『PPP CHAP 認証の説明と設定』を参照してください。

注:認証はオプションであり、PPP では認証の必要がある場合にだけ、このステージに入ります。

NCP(必須フェーズ)

このフェーズは、さまざまなネットワーク層プロトコルを確立および設定するために使用されます。ネゴシエートされる最も一般的な L3 プロトコルは IP です。ルータでは、IP Control Protocol(IPCP; IP 制御プロトコル)メッセージを交換して、プロトコル(この例では IP)に特有のオプションをネゴシエートします。

RFC 1332 leavingcisco.com によれば、IPCP ネゴシエーションには、圧縮と IP アドレスの割り当てという 2 種類のオプションがあります。しかし、IPCP は、プライマリまたはバックアップ用の Windows Name Service(WINS)サーバや Domain Name System(DNS; ドメイン ネーム システム)サーバなど、ネットワークに関する情報の受け渡しにも使用されます。

ネゴシエーションは、このドキュメントの「PPP ネゴシエーションのパケット: 説明」セクションで説明されている CONF メッセージを使用して行われます。



debug ppp negotiation の出力を使用したトラブルシューティング

トラブルシューティングの目的で、debug ppp negotiation コマンドの出力を読む場合は、次の指示に従ってください。

  1. debug コマンドの出力で、フェーズの遷移を識別します。接続処理で到達した一番最後のフェーズを判別します。たとえば、UP、AUTHENTICATING などです。これが、接続に失敗したフェーズを識別する手がかりになります。フェーズに関する詳細は、「PPP ネゴシエーションの各フェーズ」セクションを参照してください。

  2. 障害が発生したフェーズについて、場合に応じて LCP、認証、または NCP が正常に処理されていることを示すメッセージを探します。

    • LCP の状態はオープンである必要があります。また、最後に着信および発信した CONFACK メッセージを探して、必要とするパラメータがネゴシエートされていることを確認します。

    • 認証は正しく行われている必要があります。双方向の認証を使用する場合は、それぞれのトランザクションが正しく処理されている必要があります。PPP 認証失敗のトラブルシューティングに関する詳細は、『トラブルシューティング:PPP(CHAP または PAP)認証』を参照してください。

    • IPCP の状態はオープンである必要があります。アドレッシングが正しくて、ピアへのルートが設定されていることを確認します。



debug ppp negotiation の出力の読み方

debug ppp negotiation コマンドの出力の主要な行は、次の特徴があります。

  1. タイムスタンプ:ミリ秒のタイムスタンプを使用すると便利です。詳細は、このドキュメントの「前提条件」セクションを参照してください。

  2. インターフェイスおよびインターフェイス番号:このフィールドは、デバッグする接続が複数の接続を使用する場合、または、接続が複数のインターフェイスを通過する場合に便利です。たとえば、ある接続(マルチリンク コールなど)は最初は物理インターフェイスで制御されますが、その後はダイヤラ インターフェイスまたは仮想アクセス インターフェイスで制御されます。

  3. PPP メッセージのタイプ:このフィールドは、その行が一般的な PPP、LCP、CHAP、PAP、または IPCP メッセージのどれであるかを示しています。

  4. メッセージの方向I は着信パケット、O は発信パケットであることを示します。このフィールドは、メッセージがそのルータで生成されたものか、受信したものかを判断するために使用できます。

  5. メッセージ:このフィールドにはネゴシエーションの際の特定のトランザクションが含まれます。

  6. ID:このフィールドは、要求メッセージを適切な応答メッセージと照合し、組み合せるために使用されます。この ID フィールドを使用して着信メッセージに応答を関連付けられます。このオプションは、着信メッセージとその応答がデバッグ出力の中で遠く離れている場合に特に便利です。

  7. 長さ:長さフィールドでは、情報フィールドの長さが定義されます。このフィールドは一般的なトラブルシューティングに際しては、特に重要ではありません。

注:フィールドの 4 から 7 は、メッセージの目的によって表示されるものであり、すべての PPP メッセージに表示されるものではありません。

注:次の例は、フィールドを説明しています。

debug_ppp_negotiation2.gif



debug ppp negotiation の出力例

次に debug ppp negotiation コマンドの出力を注釈付きで説明します。

maui-soho-01#debug ppp negotiation
PPP protocol negotiation debugging is on
maui-soho-01#
*Mar  1 00:06:36.645: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

!--- 物理レイヤ(BRI インターフェイス)がアップしています。この状態で、PPP 
!--- ネゴシエーションが開始されます。

*Mar  1 00:06:36.661: BR0:1 PPP: Treating connection as a callin
*Mar  1 00:06:36.665: BR0:1 PPP: Phase is ESTABLISHING, Passive Open 
[0 sess, 0 load]

!--- PPP のフェーズは ESTABLISHING です。LCP ネゴシエーションが行われます。

*Mar  1 00:06:36.669: BR0:1 LCP: State is Listen
*Mar  1 00:06:37.034: BR0:1 LCP: I CONFREQ [Listen] id 7 len 17

!--- これは着信 CONFREQ です。ID フィールドは 7 になっています。

*Mar  1 00:06:37.038: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:06:37.042: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.046: BR0:1 LCP:    Callback 0  (0x0D0300)

!--- ピアからは次の項目が要求されています。 
!--- オプション:認証プロトコル、値:PAP
!--- オプション:MagicNumber(これはループバックを検出するために使用され、常に送信されます)
!--- オプション:Callback、値:0 (これは PPP コールバック用です。MS コールバックには 6 が使用されます)

*Mar  1 00:06:37.054: BR0:1 LCP: O CONFREQ [Listen] id 4 len 15

!--- これは発信 CONFREQ であり、ピアに実装するパラメータが含まれています。
!--- D フィールドが 4 であるため、直前の CONFREQ メッセージとは無関係であることに
!--- 注意してください。

*Mar  1 00:06:37.058: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.062: BR0:1 LCP:    MagicNumber 0x1081E7E1 (0x05061081E7E1)

!--- このルータは次の項目を要求しています。 
!--- オプション:認証プロトコル、値:CHAP
!--- オプション:MagicNumber(これはループバックを検出するために使用され、常に送信されます)

*Mar  1 00:06:37.066: BR0:1 LCP: O CONFREJ [Listen] id 7 len 7

!--- これはフィールド ID 7 のメッセージに対する発信 CONFREJ です。
!--- これは最初に受信した CONFREQ に対する応答です。

*Mar  1 00:06:37.070: BR0:1 LCP:    Callback 0  (0x0D0300)

!--- このルータが拒否したオプションは、Callback です。
!--- ルータが PPP コールバックではなく、MS コールバックを行いたいとしている場合は、
!--- 代わりに CONFNAK メッセージを送っています。

*Mar  1 00:06:37.098: BR0:1 LCP: I CONFACK [REQsent] id 4 len 15

!--- これはフィールド ID 4 のメッセージに対する着信 CONFACK です。

*Mar  1 00:06:37.102: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.106: BR0:1 LCP:    MagicNumber 0x1081E7E1 (0x05061081E7E1)

!--- このピアでは、要求されたパラメータすべてをサポートできます。

*Mar  1 00:06:37.114: BR0:1 LCP: I CONFREQ [ACKrcvd] id 8 len 14

!--- これは CONFREQ メッセージの着信です。ID フィールドは 8 になっています。
!--- これはピアから ID 7 の CONFREJ に対して送られた新たな CONFREQ メッセージです。

*Mar  1 00:06:37.117: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:06:37.121: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

!--- ピアからは次の項目が要求されています。 
!--- オプション:認証プロトコル、値:PAP
!--- オプション:MagicNumber(これはループバックを検出するために使用され、常に送信されます)

*Mar  1 00:06:37.125: BR0:1 LCP: O CONFNAK [ACKrcvd] id 8 len 9

!--- これはフィールド ID 8 のメッセージに対する発信 CONFNACK です。

*Mar  1 00:06:37.129: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)

!--- このルータは、オプションの認証プロトコルを認識しましたが、
!--- その値である PAP は受け入れないとしています。その代わりに、CONFNAK メッセージで 
!--- CHAP を提案しています。

*Mar  1 00:06:37.165: BR0:1 LCP: I CONFREQ [ACKrcvd] id 9 len 15

!--- これはフィールド ID 9 の着信 CONFREQ メッセージです。

*Mar  1 00:06:37.169: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.173: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)

!--- CHAP 認証が要求されています。

*Mar  1 00:06:37.177: BR0:1 LCP: O CONFACK [ACKrcvd] id 9 len 15

!--- これはフィールド ID 9 のメッセージに対する発信 CONFACK です。

*Mar  1 00:06:37.181: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:06:37.185: BR0:1 LCP:    MagicNumber 0x507A214D (0x0506507A214D)
*Mar  1 00:06:37.189: BR0:1 LCP: State is Open

!--- これは LCP の状態がオープンであることを示しています。

*Mar  1 00:06:37.193: BR0:1 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load]

!--- PPP のフェーズは AUTHENTICATING です。PPP 認証が行われています。
!--- 双方向の認証が行われています(both というキーワードでそれが示されています)。

*Mar  1 00:06:37.201: BR0:1 CHAP: O CHALLENGE id 4 len 33 from "maui-soho-01"

!--- これは CHAP Challenge の発信です。 
!--- LCP の処理の際に、ルータは認証プロトコルとして CHAP を使用することに同意しています。

*Mar  1 00:06:37.225: BR0:1 CHAP: I CHALLENGE id 3 len 33 from "maui-soho-03"

!--- これはピアからの Challenge メッセージの着信です。

*Mar  1 00:06:37.229: BR0:1 CHAP: Waiting for peer to authenticate first
*Mar  1 00:06:37.237: BR0:1 CHAP: I RESPONSE id 4 len 33 from "maui-soho-03"

!--- これはピアからの応答の着信です。

*Mar  1 00:06:37.244: BR0:1 CHAP: O SUCCESS id 4 len 4

!--- このルータはピアの認証に成功しました。

*Mar  1 00:06:37.248: BR0:1 CHAP: Processing saved Challenge, id 3
*Mar  1 00:06:37.260: BR0:1 CHAP: O RESPONSE id 3 len 33 from "maui-soho-01"
*Mar  1 00:06:37.292: BR0:1 CHAP: I SUCCESS id 3 len 4

!--- これは Success メッセージの着信です。両方の側が 
!--- 相手側の認証に成功しました。

*Mar  1 00:06:37.296: BR0:1 PPP: Phase is UP [0 sess, 0 load]

!--- PPP のステータスは現在は UP になっています。NCP(IPCP)ネゴシエーションが開始されます。

*Mar  1 00:06:37.304: BR0:1 IPCP: O CONFREQ [Closed] id 4 len 10
*Mar  1 00:06:37.308: BR0:1 IPCP:    Address 172.22.1.1 (0x0306AC160101)

!--- これは CONFREQ メッセージの発信です。これは、 
!--- ローカル マシンのアドレスが 172.22.1.1 であることを示しています。

*Mar  1 00:06:37.312: BR0:1 CDPCP: O CONFREQ [Closed] id 4 len 4
*Mar  1 00:06:37.320: BR0:1 CDPCP: I CONFREQ [REQsent] id 4 len 4
*Mar  1 00:06:37.324: BR0:1 CDPCP: O CONFACK [REQsent] id 4 len 4

!--- これらのメッセージは、CDP 制御プロトコル(CDPCP)のためのものです。

*Mar  1 00:06:37.332: BR0:1 IPCP: I CONFREQ [REQsent] id 4 len 10
*Mar  1 00:06:37.336: BR0:1 IPCP:    Address 172.22.1.2 (0x0306AC160102)

!--- CONFREQ メッセージの着信であり、ピアのアドレスが 
!--- 172.22.1.2 であることを示しています。アドレスが 0.0.0.0 の場合は、そのピアがアドレスを持たず、 
!--- PCP ネゴシエーションの際にローカル ルータ側からのアドレスの付与を 
!--- 要求していることを意味します。

*Mar  1 00:06:37.344: BR0:1 IPCP: O CONFACK [REQsent] id 4 len 10
*Mar  1 00:06:37.348: BR0:1 IPCP:    Address 172.22.1.2 (0x0306AC160102)
*Mar  1 00:06:37.356: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
*Mar  1 00:06:37.360: BR0:1 IPCP:    Address 172.22.1.1 (0x0306AC160101)
*Mar  1 00:06:37.363: BR0:1 IPCP: State is Open

!--- PCP の状態がオープンになっています。IPCP ネゴシエーションでは、それぞれの側でピアの IP アドレスが
!--- 受け入れられ、1 つがピアに割り当てられます。

*Mar  1 00:06:37.371: BR0:1 CDPCP: I CONFACK [ACKsent] id 4 len 4
*Mar  1 00:06:37.375: BR0:1 CDPCP: State is Open

!--- これは CDPCP の状態がオープンであることを示しています。

*Mar  1 00:06:37.387: BR0 IPCP: Install route to 172.22.1.2

!--- ピアへのルートが設定されました。

*Mar  1 00:06:38.288: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
 changed state to up
*Mar  1 00:06:42.609: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to
 maui-soho-03


用語集と一般的なメッセージ

全般

CONFREQ(Configure-Request):

下位のレイヤが使用可能(アップ)な状態になったときに、CONFREQ が送信され、最初の PPP フェーズ(LCP フェーズ)が開始されます。これは LCP フェーズと NCP フェーズで、接続を設定する試みとして使用されます。ピアに対する接続をオープンするために、デバイスからこのメッセージが送信されます。このメッセージと一緒に、この送信元がピアにサポートさせたい設定オプションと値も送信されます。すべてのオプションと値は、同時にネゴシエートされます。ピアから CONFREJ メッセージまたは CONFNAK メッセージで応答が返された場合は、ルータは次の CONFREQ を別のオプションや値の組み合せとともに送信します。

CONFACK(Configure-Acknowledge):

CONFREQ メッセージ内のすべてのオプションが認識可能であり、すべての値が許容可能であった場合は、ルータから CONFACK メッセージが送信されます。

CONFREJ(Configure Reject):

CONFREQ で受信した設定オプションが許容可能または認識可能でない場合、ルータは CONFREJ メッセージを返します。(CONFREQ メッセージで送られた)許容不可能なオプションは、CONFREJ メッセージに取り込まれています。

CONFNAK(Configure Negative Acknowledge):

受信した設定オプションが認識可能および許容可能であるものの、いくつかの値が許容不可能である場合は、ルータから CONFNAK メッセージが送信されます。ルータでは、許容可能なオプションと値を CONFNAK メッセージに付加して、ピアが次の CONFREQ メッセージにそのオプションを含めることができるようにします。

ECHOREQ(Echo Request)と ECHOREP(Echo Reply):

PPP では、接続の完全性を維持するために、キープアライブが使用されます。このキープアライブには、リモートの PPP ピアに送られる ECHOREQ フレームと、リモートの PPP ピアが ECHOREQ フレームの受信に対して応答する ECHOREP フレームがあります。デフォルトでは、ルータから ECHOREP フレームが 5 回送信されなかった場合に、そのリンクはダウンしたと判断され、PPP がダウン状態になります。

TERMREQ(Termination Request):

このフレームは、このフレームを送信した PPP ピアで PPP 接続が終了されたことを意味します。

TERMACK(Termination Acknowledge):

このメッセージは、TERMREQ メッセージへの応答として送信されます。このメッセージによって、PPP 接続がクローズされます。

TERMINATING

このメッセージは、PPP 接続がダウン状態になっていることを示します。LCP 接続または NCP 接続は、次の場合に切断できます。

  • 管理クローズが行われた場合(LCP の場合だけ)。

  • 下位レベル(ダイヤルアップ回線、ISDN など)がアウト オブ サービスの状態になった場合。

  • ネゴシエーションが成立しなかった場合。

  • 回線のループが検出された場合。



LCP

ACCM(Asynchronous Control Character Map):

これは CONFREQ フレーム内の LCP でネゴシエートされるオプションの 1 つです。ACCM は、エスケープ シーケンス文字を設定します。ACCM から、ポートに対して、データ ストリーム内の特定の制御文字を無視するよう通知されます。接続の一方の端のルータで ACCM ネゴシエーションがサポートされていない場合は、そのポートは FFFFFFFF を使用するよう強制されます。この場合は、次のコマンドを発行します。

ppp accm match 000a000

ACFC(Address and Control Field Compression):

ACFC は、より効率的なメッセージの双方向送信をエンドポイントで可能にする LCP オプションです。

AuthProto(Authentication Protocol):

AuthProto は認証プロトコルのタイプで、認証フェーズで使用されるように双方の PPP 接続ピア間において CONFREQ フレーム内でネゴシエートされるものです。PPP 認証が設定されていない場合は、CONFREQ フレームのネゴシエーション パラメータにこの出力は現れません。使用される値は CHAP または PAP です。

Callback "#":

このメッセージは、コールバック オプションがネゴシエーション中であることを示しています。Callback の構文に続く番号は、ネゴシエートされるコールバック オプションの種類を示しています。番号 0 は通常の PPP コールバックで、番号 6 は Microsoft コールバックのオプションです(Cisco IOS® ソフトウェア リリース 11.3(2)T 以降では自動的に使用可能になります)。

CHAP(Challenge Handshake Authentication Protocol):

このメッセージは、ネゴシエーション中の認証プロトコルが CHAP であることを示しています。

EndpointDisc(End Point Discriminator):

これは PPP マルチリンク接続で PPP ピアを識別するために使用する LCP オプションです。詳細は、『マルチリンク PPP バンドルの命名基準』を参照してください。

LCP:State is Open

このメッセージは、LCP ネゴシエーションが正しく完了したことを示します。

LQM(Link Quality Monitoring)

LQM は、PPP が実行されるすべてのシリアル インターフェイス上で使用可能です。LQM は、リンクの品質を監視し、その品質が設定されている割合以下になったときにリンクをダウンさせます。この割合は、着信と発信の両方向について計算されます。発信の品質は、送信された全パケットとバイトの数を、そのピアで受信した全パケットとバイトの数と比較して計算されます。着信の品質は、受信された全パケットとバイトの数を、そのピアで送信した全パケットとバイトの数と比較して計算されます。

LQM がイネーブルの場合、Link Quality Report(LQR)がキープアライブの間隔ごとに送信されます。LQR はキープアライブの代わりとして送信されます。着信するキープアライブは、すべて適切に応答されます。LQM が設定されていない場合は、キープアライブの間隔ごとにキープアライブが送信され、着信するすべての LQR には LQR で応答が返されます。

MagicNumber

マジック ナンバーは、シリアル インターフェイスでサポートされています。PPP では、常にマジック ナンバーのネゴシエートを試みます。これは、ループバックしているネットワークの検出に使用されます。ランダムなストリングがリンクに送信され、同じ値が戻ってきた場合には、ルータではそのリンクでループ バックが行われていると判断します。

ループバックが検出されたときにリンクがダウンするかどうかは、down-when-looped コマンドの使用によって決まります。

PAP(Password Authentication Protocol)

このメッセージは、PPP ピアによる使用をネゴシエーション中の認証プロトコルが、PAP であることを示しています。PAP についての詳細は、『PPP パスワード認証プロトコル(PAP)の設定とトラブルシューティング』を参照してください。

PFC(Protocol Field Compression)

このオプションは、プロトコル フィールドに対する圧縮をオンまたはオフにします。

MRRU(Max Receive Reconstructed Unit)

これは PPP マルチリンク LCP 設定の処理中にネゴシエートされる LCP オプションです。このオプションは、フレームの構成が可能な最大バイト数を判断します。LCP で MRRU がネゴシエートされない場合は、Multilink PPP(MPPP; マルチリンク PPP)をリンク上で実行することはできません。

MRU(Maximum Received Unit)

MRU は、CONFREQ フレームでネゴシエートされる LCP オプションで、交換されるパケットのサイズをネゴシエートするものです。



認証

AUTH-REQ(Authentication Request)

このフレームは、認証がイネーブルになっている場合に、ローカルの PPP ピアからリモートのピアに送信されます。リモート ピアに対して、PPP 接続の認証に有効なユーザ名とパスワードの送信を要求します。このフレームは PAP でだけ使用されます。

AUTH-ACK(Authentication Acknowledge)

このフレームは、認証される側の PPP ピアから、認証する側の PPP ピアへ送られるものです。このフレームは、有効なユーザ名とパスワードのペアを搬送します。このフレームは、PPP 接続の認証用に PAP が使用されている場合にだけ使用されます。

AUTH-NAK または FAILURE

このフレームは、認証する側の PPP ピアで認証に失敗したときに、その PPP ピアから送信されます。

CHALLENGE

これは、認証する側の PPP ピアから、認証される側の PPP ピアへ送られる CHAP チャレンジ フレームです。チャレンジ フレームは、ID、乱数、およびローカルの通信サーバのホスト名かリモート デバイスのユーザ名のいずれかで構成されます。このフレームは、PPP 接続の認証用に CHAP が使用されている場合にだけ使用されます。

RESPONSE

このフレームは、認証される側の PPP ピアから、認証する側の PPP ピアへ送られる CHAP レスポンスです。

要求されるレスポンスは、次の 2 つの部分で構成されます。

  • 共有秘密鍵の MD5 ハッシュ出力

  • リモート デバイスのホスト名か、リモート デバイス上のユーザ名のいずれか

このフレームは、PPP 接続の認証用に CHAP が使用されている場合にだけ使用されます。



NCP

Address a.b.c.d

  • 発信 CONFREQ メッセージでは、この値はローカル ルータが使用を望んでいる IP アドレスを示します。このアドレスが 0.0.0.0 の場合、このローカル マシンは、ピアに対して使用可能な IP アドレスを提供することを要求しています。

  • 着信 CONFREQ メッセージでは、この値はピアが使用を望んでいる IP アドレスを示します。このアドレスが 0.0.0.0 の場合、このピアは、ローカル マシンに対して使用可能な IP アドレスを提供することを要求しています。

  • 発信 CONFNAK メッセージでは、この値は CONFREQ メッセージでピアから提示されたアドレスの代わりとして、ピアに使用させたい IP アドレスを示しています。

  • 着信 CONFNAK メッセージでは、この値は直前の CONFREQ メッセージで提示されたアドレスの代わりとして、このローカル マシンで使用する IP アドレスを示しています。

  • 発信 CONFACK メッセージでは、この値は、ピアから要求された IP アドレスがローカル マシンで許容可能であることを示します。

  • 着信 CONFACK メッセージでは、この値は、ローカル マシンから要求された IP アドレスがピアで許容可能であることを示します。

CCP(Compression Control Protocol)

このメッセージは、PPP ピア間で圧縮プロトコルがネゴシエーション中であることを示します。Cisco IOS ソフトウェアでは、これらの圧縮プロトコルが PPP 接続でネゴシエートされるようにサポートされています。

  • MS-Point-to-Point Compression(MS-PPC)

  • スタッカ

  • プレディクタ

CDPCP(Cisco Discovery Protocol Control Protocol)

このメッセージは、NCP フェーズで CDP ネゴシエーションが行われることを示しています。ルータで CDP をオフにするには、no cdp run コマンドを発行します。

CODEREJ(Code Reject)

CODEREJ パケットは、解釈不可能なパケットをリモート PPP ピアから受信した場合に送信されます。

Install route to a.b.c.d

ルータでは、IPCP(IP の L3 プロトコルに対する NCP フェーズ)の終了時に、与えられた IP アドレスをルーティング テーブル内のリモートの PPP ピアに設定し、そのルーティング テーブル内で接続されたルートとして見なすようにする必要があります。このメッセージが表示されない場合は、no peer neighbor-route コマンドが設定されていないことを確認してください。

IPCP(IP Control Protocol)

この値は、IP が NCP フェーズでネゴシエーション中のネットワーク レイヤであることを示します。

IPCP State is Open

このメッセージは IPCP(IP の L3 プロトコルに対する NCP フェーズ)が正しく完了したことを示します。

PROTREJ(Protocol Reject)

PPP ピアは、未知のプロトコル フィールドを持つ PPP パケットを受信したときに、PROTREJ メッセージを使用して、サポートされていないプロトコルの使用がピアで試みられたことを示します。PPP デバイスで PROTREJ メッセージが受信されると、そのプロトコルによるパケットの送信を早急に停止する必要があります。



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

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


関連情報


Document ID: 25440