瞭解debug ppp negotiation輸出

簡介

在撥號相關應用中，PPP是最常用的封裝型別。PPP允許點對點通訊連結上的兩台機器交涉用於驗證、壓縮以及第3層(L3)通訊協定（例如IP）的各種引數。兩台路由器之間的PPP協商失敗會導致連線失敗。

debug ppp negotiation命令可讓您檢視PPP協商事務、確定問題或錯誤發生時的階段，並制定解決方案。但是，您必須瞭解debug ppp negotiation指令輸出。本文提供讀取debug ppp negotiation命令輸出的全面方法。

必要條件

需求

本文檔的讀者必須確保滿足以下條件：

• 必須在兩台路由器的介面上啟用PPP。發出encapsulation ppp命令可完成此操作。

• 發出以下命令以在路由器上啟用毫秒時間戳：

  Router(config)# service timestamp debug datetime msec
  

  有關debug命令的更多資訊，請參閱有關Debug命令的重要資訊。

注意：兩個對等體之間的PPP協商無法啟動，除非在PPP下的較低層（ISDN、物理介面、撥號線路等）功能正常。例如，如果要通過ISDN運行PPP，則所有ISDN層都必須為up;否則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 =鏈路控制協定}

^{2. CHAP =質詢握手身份驗證協定}

^{3. PAP =口令驗證協定}

^{4. NCP =網路控制協定}

此圖顯示PPP相變：

PPP協商資料包：說明

下表包含在LCP和NCP協商中使用的PPP協商資料包的說明：

^{1. NAK =否定確認}

^{2. ACK =確認}

注意：每個對等體都可以使用希望對等體支援的選項或值來傳送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控制協定(IPCP)消息以協商特定於協定（本例中為IP）的選項。

RFC 1332 表示IPCP會交涉兩個選項：壓縮和IP地址分配。但是，IPCP還用於傳遞網路相關資訊，如主要和備份Windows名稱服務(WINS)和域名系統(DNS)伺服器。

交涉會使用CONF訊息進行，如PPP Negotiation Packets:本檔案的「說明」部分。

使用debug ppp negotiation輸出進行故障排除

當您出於故障排除目的閱讀debug ppp negotiation命令輸出時，請遵循以下說明：

1. 在debug命令輸出中識別相變。確定連線實現的最遠階段，例如UP或AUTHENTICATION。這有助於您確定連線失敗的階段。有關這些階段的更多資訊，請參見PPP協商的階段部分。

2. 對於發生故障的階段，查詢指示LCP、身份驗證或NCP（視情況而定）成功運行的消息：

   • LCP狀態應處於開啟狀態。您還可以檢視最後傳入和傳出CONFACK消息，以驗證所需的引數是否已協商。

   • 身份驗證應成功。如果使用雙向身份驗證，則每個事務都必須成功。如需更多有關疑難排解PPP驗證失敗的資訊，請參閱疑難排解PPP（CHAP或PAP）驗證。

   • IPCP狀態應處於開啟狀態。驗證地址是否正確以及是否安裝了到對等裝置的路由。

讀取debug ppp negotiation輸出

debug ppp negotiation命令輸出中的大多數行都具有以下特徵：

1. 時間戳 — 毫秒時間戳很有用。如需詳細資訊，請參閱本檔案的必要條件一節。

2. Interface and Interface number — 當調試連線使用多個連線時或連線通過多個介面轉換時，此欄位非常有用。例如，某些連線（例如多鏈路呼叫）在開始時由物理介面控制，但之後由撥號器介面或虛擬訪問介面控制。

3. PPP消息的類型 — 此欄位指示線路是常規PPP、LCP、CHAP、PAP還是IPCP消息。

4. 消息的方向- I表示傳入資料包，O表示傳出資料包。此欄位用於確定該消息是由路由器生成還是接收的。

5. Message — 此欄位包含正在協商的特定事務。

6. ID — 此欄位用於將請求消息與相應的響應消息進行匹配和協調。可以使用ID欄位將響應與傳入消息相關聯。當傳入消息和響應在調試輸出中相距很遠時，此選項尤其有用。

7. 長度(Length) — 長度欄位定義資訊欄位的長度。此欄位對於常規故障排除不重要。

注意：欄位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):

當下層可用(Up)時，會傳送CONFREQ以開始第一個PPP階段（LCP階段）。 它用於LCP和NCP階段，以嘗試配置連線。要開啟與對等體的連線，裝置會傳輸此消息以及傳送方希望對等體支援的配置選項和值。所有選項和值是同時協商的。如果對等體使用CONFREJ或CONFNAK消息進行響應，則路由器將傳送包含另一組選項或值的另一個CONFREQ。

CONFACK(Configure-Acknowledge):

如果CONFREQ消息中的所有選項均可識別，並且所有值均可接受，則路由器會傳送CONFACK消息。

CONFREJ（配置拒絕）：

如果CONFREQ中收到的某些配置選項不可接受或無法識別，路由器將使用CONFREJ消息進行響應。不可接受的選項（來自CONFREQ）包含在CONFREJ消息中。

配置（配置否定確認）：

如果收到的配置選項可識別且可接受，但某些值不可接受，則路由器會傳送CONFNAK消息。路由器在CONFNAK消息中附加可以接受的選項和值，以便對等體可以在下一個CONFREQ消息中包含該選項。

ECHOREQ（回應請求）和ECHOREP（回應回覆）：

PPP使用keepalive來維護連線的完整性。這些keepalive是傳送到遠端PPP對等體的ECHOREQ幀，遠端PPP對等體在收到ECHOREQ幀後應使用ECHOREP幀進行響應。預設情況下，如果路由器遺漏五個ECHOREP幀，則認為鏈路已關閉且PPP已關閉。

TERMREQ（終止請求）：

此幀表示傳送此幀的PPP對等體終止PPP連線。

TERMACK（終止確認）：

響應於所述TERMREQ消息而傳送該消息。這將關閉PPP連線。

正在終止

此消息表示PPP連線已關閉。可以斷開LCP或NCP連線：

• 管理關閉（僅限LCP）。

• 當較低級別停止服務（撥號線路、ISDN等）時。

• 當談判失敗時。

• 線上環路檢測。

LCP

ACCM（非同步控制字元對映）：

這是CONFREQ幀中由LCP協商的一個選項。ACCM設定字元轉義序列。ACCM告知埠忽略資料流中的指定控制字元。如果連線另一端的路由器不支援ACCM交涉，則連線埠會強制使用FFFFFFFF。在這種情況下，發出以下命令：

ppp accm match 000a000

ACFC（地址和控制欄位壓縮）：

ACFC是一種LCP選項，允許終端更有效地來回傳送消息。

AuthProto（驗證通訊協定）：

AuthProto是在兩個PPP連線對等體之間的CONFREQ幀中協商的身份驗證協定型別，用於身份驗證階段。如果未配置PPP身份驗證，則在CONFREQ幀協商引數中看不到此輸出。可能的值為CHAP或PAP。

回撥「#」：

此消息表示回撥選項正在進行協商。回撥語法後的數字表示協商哪個回撥選項。數字0是正常的PPP回撥，而數字6表示Microsoft回撥選項(在Cisco IOS®軟體版本11.3(2)T或更高版本中自動可用)。

CHAP（質詢握手身份驗證協定）：

此訊息表示正在交涉中的驗證通訊協定是CHAP。

EndpointDisc（端點鑑別器）：

這是一個LCP選項，用於標識PPP多鏈路連線中的PPP對等體。有關詳細資訊，請參閱命名多鏈路PPP捆綁的標準。

LCP:狀態為開啟

此消息表示LCP協商已成功完成。

LQM（鏈路品質監控）

LQM可用於運行PPP的所有串列介面。LQM會監控連結品質，並在品質下降到設定的百分比以下時關閉連結。計算傳入和傳出方向的百分比。傳出品質通過比較傳送的資料包和位元組總數與對等體接收的資料包和位元組總數來計算。傳入品質的計算方法是將收到的資料包和位元組總數與對等體傳送的資料包和位元組總數進行比較。

啟用LQM後，會在每個保持連線期間傳送鏈路品質報告(LQR)。LQRs將代替keepalive傳送。所有傳入的keepalive都得到正確回應。如果沒有設定LQM，則會每隔keepalive期間傳送keepalive，且所有傳入的LQR都會使用LQR進行回應。

幻數

所有串列介面均提供幻數支援。PPP總是嘗試協商用於檢測環回網路的幻數。在鏈路上傳送一個隨機字串，如果返回相同的值，則路由器確定鏈路已環回。

偵測回送時，連結可能會被關閉，也可能不會；這取決於是否使用down-when-looped 命令。

PAP（密碼驗證通訊協定）

此訊息表示正在交涉以供PPP對等體使用的驗證通訊協定是PAP。有關PAP的詳細資訊，請參閱PPP口令身份驗證協定(PAP)的配置與故障排除。

PFC（通訊協定欄位壓縮）

此選項可開啟或關閉協定欄位的壓縮。

MRRU（最大接收重建單元）

這是PPP多鏈路LCP設定過程中協商的一個LCP選項。此選項確定可構成幀的最大位元組數。如果沒有在LCP中協商MRRU，則多鏈路PPP(MPPP)無法在鏈路上運行。

MRU（最大接收單位）

MRU是在CONFREQ幀中協商的LCP選項，用於協商交換的資料包大小。

驗證

AUTH-REQ（驗證請求）

此幀從本地PPP對等體（已啟用身份驗證）傳送到遠端對等體。它要求遠端對等體傳送用於PPP連線身份驗證的有效使用者名稱和密碼。此幀僅用於PAP。

AUTH-ACK（驗證確認）

此幀從經過身份驗證的PPP對等體傳送到身份驗證PPP對等體。此幀包含有效的使用者名稱和密碼對。此幀僅在將PAP用於PPP連線身份驗證時使用。

AUTH-NAK或失敗

當身份驗證PPP對等體上的身份驗證失敗時，會從身份驗證PPP對等體傳送此幀。

挑戰

這是從身份驗證PPP對等體傳送到身份驗證PPP對等體的CHAP質詢幀。質詢幀包括ID、隨機數、本地通訊伺服器的主機名或遠端裝置上的使用者名稱。此幀僅在將CHAP用於PPP連線身份驗證時使用。

響應

此幀是從經過身份驗證的PPP對等體傳送到身份驗證PPP對等體的CHAP響應。

所需的響應包括兩部分：

• 共用金鑰的MD5雜湊輸出。

• 遠端裝置的主機名或遠端裝置上的使用者名稱。

此幀僅在將CHAP用於PPP連線身份驗證時使用。

NCP

地址a.b.c.d

• 在傳出CONFREQ消息中，此值表示本地路由器希望使用的IP地址。如果包含的地址為0.0.0.0，則本地電腦會請求對等裝置為其提供可以使用的IP地址。

• 在傳入CONFREQ消息中，此值表示對等體希望使用的IP地址。如果包含的地址為0.0.0.0，則對等體請求本地電腦提供其可以使用的IP地址。

• 在傳出CONFNAK消息中，此值表示對等體應使用的IP地址，而不是對等體在CONFREQ消息中建議的IP地址。

• 在傳入CONFNAK消息中，此值表示本地電腦應使用的IP地址，而不是它在上一個CONFREQ消息中建議的地址。

• 在傳出CONFACK消息上，此值表示對等體請求的IP地址對於本地電腦是可接受的。

• 在傳入CONFACK消息中，此值表示本地電腦請求的IP地址對對等裝置是可接受的。

CCP（壓縮控制協定）

此訊息表示兩個PPP對等點之間的壓縮通訊協定正在交涉。Cisco IOS軟體支援透過PPP連線交涉的壓縮通訊協定：

• MS點對點壓縮(MS-PPC)

• 堆垛機

• 預測器

CDPCP（思科探索通訊協定控制通訊協定）

此訊息指出CDP交涉發生在NCP階段。要在路由器上關閉CDP，請發出no cdp run命令。

CODEREJ（代碼拒絕）

一旦從遠端PPP對等體接收到無法解釋的封包，就傳送CODEREJ封包。

安裝通往a.b.c.d的路由

當路由器完成IPCP（IP L3協定的NCP階段）時，它必須將給定IP地址安裝到路由表中的遠端PPP對等體中，並且將被視為路由表中的已連線路由。如果您沒有看到此訊息，請確認no peer neighbor-route指令未設定。

IPCP（IP控制通訊協定）

此值表示IP是NCP階段中正在協商的網路層。

IPCP狀態為開啟

此訊息指出IPCP（IP L3通訊協定的NCP階段）已順利完成。

PROTREJ（協定拒絕）

PPP對等體在收到帶有未知協定欄位的PPP資料包時，使用PROTREJ消息指示對等體嘗試使用不受支援的協定。PPP裝置收到PROTREJ消息時，必須儘早停止傳送指定協定的資料包。

相關資訊

• 設定PPP密碼驗證通訊協定(PAP)並疑難排解
• 使用ppp chap hostname和ppp authentication chap callin命令進行PPP身份驗證
• 瞭解和設定 PPP CHAP 驗證
• 排除PPP（CHAP或PAP）身份驗證故障
• 撥號技術支援頁
• 技術支援 - Cisco Systems