debug ppp negotiation の出力について

概要

ダイヤル関連のアプリケーションでは、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 はアップかダウンのいずれかの状態になります。

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

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

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

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

*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 のフェーズの遷移を示しています。

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

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

^{1. NAK = Negative Acknowledge（否定応答）}

^{2. ACK = Acknowledge（確認応答）}

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

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

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

LCP（必須フェーズ）

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

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

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

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

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

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

注：認証はオプションであり、PPPは認証が必要な場合にのみ、この段階に入ります。

NCP（必須フェーズ）

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

RFC 1332では、IPCPは 、次の2つのオプションをネゴシエートすると規定されています。圧縮と 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 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

!--- The Physical Layer (BRI Interface) is up. Only now can PPP !--- negotiation begin.

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

!--- The PPP Phase is ESTABLISHING. LCP negotiation now occurs.

*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

!--- This is the incoming CONFREQ. The ID field is 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)

!--- The peer has requested: !--- Option: Authentication Protocol, Value: PAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.) !--- Option: Callback, Value: 0 (This is for PPP Callback; MS Callback uses 6.)

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

!--- This is an outgoing CONFREQ, with parameters for the peer to implement. !--- Note that the ID Field is 4, so this is not related to the previous !--- CONFREQ message.

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

!--- This router requests: !--- Option: Authentication Protocol, Value: CHAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.)

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

!--- This is an outgoing CONFREJ for message with Field ID 7. !--- This is the response to the CONFREQ received first.

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

!--- The option that this router rejects is Callback. !--- If the router wanted to do MS Callback rather than PPP Callback, it !--- would have sent a CONFNAK message instead.

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

!--- This is an incoming CONFACK for a message with Field ID 4.

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

!--- The peer can support all requested parameters.

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

!--- This is an incoming CONFREQ message; the ID field is 8. !--- This is a new CONFREQ message from the peer in response to the CONFREJ id:7.

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

!--- The peer has requested: !--- Option: Authentication Protocol, Value: PAP !--- Option: MagicNumber (This is used to detect loopbacks and is always sent.)

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

!--- This is an outgoing CONFNACK for a message with Field ID 8.

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

!--- This router recognizes the option Authentication Protocol, !--- but does not accept the value PAP. In the CONFNAK message, !--- it suggests CHAP instead.

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

!--- This is an incoming CONFREQ message with Field ID 9.

*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 authentication is requested.

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

!--- This is an outgoing CONFACK for a message with Field ID 9.

*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

!--- This indicates that the LCP state is Open.

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

!--- The PPP Phase is AUTHENTICATING. PPP Authentication occurs now. !--- Two-way authentication is now performed (indicated by the both keyword).

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

!--- This is the outgoing CHAP Challenge. !--- In LCP the routers had agreed upon CHAP as the authentication protocol.

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

!--- This is an incoming Challenge message from the peer.

*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"

!--- This is an incoming response from the peer.

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

!--- This router has successfully authenticated the peer.

*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

!--- This is an incoming Success message. Each side has !--- successfully authenticated the other.

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

!--- The PPP status is now UP. NCP (IPCP) negotiation begins.

*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)

!--- This is an outgoing CONFREQ message. It indicates that !--- the local machine address is 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

!--- These messages are for CDP Control Protocol (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)

!--- This is an incoming CONFREQ message that indicates that the peer !--- address is 172.22.1.2. An address of 0.0.0.0 indicates that the peer !--- does not have an address and requests the local router to provide it !--- with an address in IPCP negotiation.

*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

!--- The IPCP state is Open. Note that in the IPCP negotiation, each side !--- accepted the IP address of the peer, and one was assigned to the peer.

*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

!--- This indicates that the CDPCP state is Open.

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

!--- A route to the peer is installed.

*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 オプションで、交換されるパケットのサイズをネゴシエートするものです。

[Authentication]

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 メッセージが受信されると、そのプロトコルによるパケットの送信を早急に停止する必要があります。

関連情報

• PPP パスワード認証プロトコル（PAP）の設定とトラブルシューティング
• ppp chap hostname および ppp authentication chap callin コマンドを使用した PPP 認証
• PPP CHAP 認証の理解および設定
• PPP（CHAP または PAP）認証に関するトラブルシューティング
• ダイヤル テクノロジーに関するサポート ページ
• テクニカルサポート - Cisco Systems