疑難排解POS介面上的「線路協定關閉」問題

下載選項

  • PDF     (500.1 KB)
    在多種裝置上使用 Adobe Reader 檢視
已更新: 2006 年 5 月 19 日
文件 ID:16152

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本檔案介紹如何對線路通訊協定狀態為「down」的SONET(POS)路由器介面上的封包進行疑難排解。

除了幫助確定線路協定已關閉以外，還說明了用於解決點對點協定(PPP)和高級資料鏈路控制(HDLC)封裝問題的show和debug命令。它還指導您根據已記錄的實驗設定完成典型的故障排除場景。

解釋show interface pos命令

在文檔中，show interface pos的輸出與以下輸出所示。請注意顯示的突出部分和註釋：

RTR12410-2#show interface pos 6/0 
   POS6/0 is up, line protocol is down 

!--- The line protocol is down
.
     Hardware is Packet over SONET 
  MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 255/255, load 1/255 
     Encapsulation HDLC, crc 32, loopback not set 

!--- The loopback has not been set.

     Keepalive set (10 sec) 

!--- The keepalive is set as every ten seconds.

     Scramble disabled 
  Last input never, output 00:00:05, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     0 packets input, 0 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
              0 parity 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     3 packets output, 1074 bytes, 0 underruns 
     0 output errors, 0 applique, 1 interface resets 
     0 output buffer failures, 0 output buffers swapped out 
     2 carrier transitions

Cisco IOS® Command Reference命令指出，線路協定欄位狀態「表示處理線路協定的軟體進程是否考慮線路是否可用（即keepalive成功），或者是否已被管理員關閉。」

show interface pos 輸出中的其他重要欄位如下：

  • Encapsulation — 分配給介面的封裝方法。

  • loopback — 指示是否已設定環回。

  • keepalive — 指示是否已設定keepalive。

POS協定棧概述

此圖說明POS介面上使用的協定棧。

gspos_a0.gif

POS介面支援多種封裝 — HDLC、PPP和幀中繼。因此，使用SONET的資料包更準確地說是PPP over SONET或HDLC over SONET。本文檔不介紹幀中繼封裝。

PPP和HDLC密切相關，並共用以下特徵：

  • 提供具有標頭和標尾的幀結構。尾部提供錯誤檢查。

  • 提供幀劃分，它確切地為接收方定義資料包和幀的開始和結束位置。在HDLC和PPP中，幀描述通過特殊的幀間填充圖案或空閒圖案來提供。模式為0x7E或0111 110。

  • 定義最小和最大資料包長度。

  • 傳輸IP資料包，並為接收方提供一種方法，以確定到達幀內的資料包的準確型別。

但是，儘管密切相關，PPP和HDLC並不相同，並且使用不同的debug命令對線路協定問題進行故障排除。

使用debug指令

各種debug特權EXEC命令的輸出為許多網際網路事件提供與協定狀態和網路活動相關的診斷資訊。

caution 注意：由於調試輸出在CPU進程中分配了高優先順序，因此可能導致系統不可用。因此，請僅使用debug指令對特定問題進行疑難排解，或在與思科技術支援人員進行疑難排解作業期間使用。此外，最好在網路流量較低和使用者較少的時段使用debug命令。在這些時間段進行調試會降低以下可能性：debug命令處理開銷的增加會影響系統使用。完成使用debug命令後，請記得使用特定的no debug命令或no debug all命令將其禁用。

排查POS介面問題時，以下debug命令非常有用。有關這些命令的功能和輸出的詳細資訊，請參閱《Cisco Debug命令參考》出版物：

  • debug serial interface — 驗證HDLC keepalive資料包是否正在遞增。如果沒有，則介面卡或網路中可能存在計時問題。

  • debug ppp negotiation — 顯示在PPP啟動期間傳輸的PPP資料包，其中協商了PPP選項。

  • debug ppp packet — 顯示正在傳送和接收的PPP資料包。此命令顯示低級別資料包轉儲。

  • debug ppp errors — 顯示與PPP連線協商和操作關聯的PPP錯誤（如非法或格式錯誤的幀）。

如需詳細資訊，請參閱序列線路問題疑難排解。

使用HDLC的線路協定關閉

HDLC是POS路由器介面上的預設封裝型別。HDLC是國際標準，但供應商的實施在大小和格式上會有所不同，一個或多個欄位或報頭或報尾。定義SONET的Telecordia GR-253規範討論了HDLC-over-SONET對映（請參閱問題3，第3.4.2.3節，第3.3-59頁）。 它指定HDLC幀與SONET幀進行位元組對齊，還指定自同步擾頻器、循環冗餘校驗(CRC)，並使用HDLC標誌圖案作為幀間填充來解釋到達HDLC幀的可變性質。

如果show interface pos命令顯示使用HDLC封裝的線路和協定已關閉，則可以使用debug serial interface命令將線路問題確定為連線故障的原因。HDLC使用keepalive並在調試輸出中報告三個計數器的值：

  • myseq — 路由器每次向遠端路由器傳送keepalive資料包時增加1。

  • mineseen -mineseen計數器的值反映遠端路由器確認從路由器接收的最後myseq序列號。遠端路由器會將此值儲存在自己的計數器中，並將該值通過keepalive資料包傳送到路由器。

  • yourseen — 反映路由器從遠端路由器收到的keepalive資料包中的myseq序列號值。

如果mineseq、yourseen和myseen欄位中的keepalive值在後續輸出的每一行中沒有遞增，則連線的一端存在問題。當myseq和mineseen欄位中的值差超過三時，線路會關閉，介面會重置。

以下是在兩端正確接收keepalive時，HDLC連線的debug serial interface指令的輸出範例。 

hswan-12008-2a#debug serial interface 
Serial network interface debugging is on 
hswan-12008-2a# 
Oct 31 11:47:16: POS4/0: HDLC myseq 180, mineseen 0*, yourseen 1, line up 
Oct 31 11:47:17: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!--- Local router sees a remote keepalive with a sequence number of 1. 

Oct 31 11:47:26: POS4/0: HDLC myseq 181, mineseen 181*, yourseen 2, line up 
Oct 31 11:47:36: POS4/0: HDLC myseq 182, mineseen 182*, yourseen 3, line up 
Oct 31 11:47:46: POS4/0: HDLC myseq 183, mineseen 183*, yourseen 4, line up 
Oct 31 11:47:56: POS4/0: HDLC myseq 184, mineseen 184*, yourseen 5, line up 
Oct 31 11:48:06: POS4/0: HDLC myseq 185, mineseen 185*, yourseen 6, line up 

!--- Keepalives are sent every 10 seconds by default. !--- Both sides report incrementing sequence numbers.

以下是在HDLC連線遠端介面關閉且本地介面丟失三個以上的keepalive時，debug serial interface命令的輸出示例。 

hswan-12008-2a# 
Oct 31 11:49:46: POS4/0: HDLC myseq 195, mineseen 192, yourseen 13, line down 
Oct 31 11:49:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to down 

!--- The local router has failed to receive three keepalives and !--- brings down the line protocol. Note the difference between !--- "myseq 195" and "mineseen 192". 

Oct 31 11:49:56: POS4/0: HDLC myseq 196, mineseen 192, yourseen 13, line down 
Oct 31 11:50:06: POS4/0: HDLC myseq 197, mineseen 192, yourseen 13, line down 
Oct 31 11:50:16: POS4/0: HDLC myseq 198, mineseen 192, yourseen 13, line down 
Oct 31 11:50:26: POS4/0: HDLC myseq 199, mineseen 192, yourseen 13, line down 
Oct 31 11:50:36: POS4/0: HDLC myseq 200, mineseen 0*, yourseen 1, line up 
Oct 31 11:50:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!--- After you execute the no shut command on the remote router, !--- the local router receives a keepalive again and brings up !--- the line protocol. 

Oct 31 11:50:46: POS4/0: HDLC myseq 201, mineseen 201*, yourseen 2, line up 
Oct 31 11:50:56: POS4/0: HDLC myseq 202, mineseen 202*, yourseen 3, line up 
Oct 31 11:51:06: POS4/0: HDLC myseq 203, mineseen 203*, yourseen 4, line up 
Oct 31 11:51:16: POS4/0: HDLC myseq 204, mineseen 204*, yourseen 5, line up 
Oct 31 11:51:26: POS4/0: HDLC myseq 205, mineseen 205*, yourseen 6, line up 
Oct 31 11:51:36: POS4/0: HDLC myseq 206, mineseen 206*, yourseen 7, line up 

!--- After the shut/no shut, the remote router re-initialized its !--- sequence number.

使用PPP時線路協定關閉

RFC 1661 leavingcisco.com將PPP定義為協定。根據RFC 1662 leavingcisco.com中的規定，POS介面支援類似高級資料鏈路控制(HDLC)的成幀中的PPP，用於第2層的資料封裝。HDLC成幀中的PPP幀格式如圖所示。

gspos_a2.gif

RFC 2615指定在SONET或SDH連結上使用PPP封裝。PPP設計用於點對點鏈路，並適用於SONET或SDH鏈路，這些鏈路即使是在環拓撲中也被配置為點對點電路。

建立點對點鏈路時，PPP會經歷幾個不同的階段，這些階段可以在狀態圖中繪製。當外部事件（如載波檢測或網路管理員配置）表示物理層已準備好被使用時，PPP將進入鏈路建立階段。向此階段的過渡會生成一個到鏈路控制協定(LCP)的UP事件，該協定提供多種功能。一種功能是確定鏈路何時工作正常以及何時發生故障。為了通過點對點鏈路建立通訊，PPP鏈路的每一端都必須首先傳送LCP資料包來配置和測試資料鏈路。

然後，PPP必須傳送網路控制協定(NCP)資料包以選擇並配置一個或多個網路層協定。在配置了每個所選網路層協定後，可以通過鏈路傳送來自每個網路層協定的資料包。

下表列出三類LCP資料包：

LCP資料包類 LCP資料包型別 目的
連結組態 Configure-Request、Configure-Ack、Configure-Nak和Configure-Reject 用於建立和配置鏈路。
連結終止 Terminate-Request和Terminate-Ack 用於終止鏈路。
連結維護 Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply和Discard-Request 用於管理和調試連結。

連結組態

LCP用於通過交換Configure資料包建立連線。一旦傳送和接收Configure-Ack資料包，此交換完成，LCP已開啟。

此輸出示例捕獲POS介面上的LCP鏈路配置階段：

4d01h: PO3/1 LCP: State is Open 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 LCP_UP 
(0x639FCAD8) id 0 (0s.) queued 1/1/2 
4d01h: PO3/1 PPP: Phase is UP 
4d01h: PO3/1 IPCP: O CONFREQ [Closed] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 
4d01h: PO3/1 IPCP: I CONFREQ [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: O CONFACK [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: I CONFACK [ACKsent] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 IPCP: State is Open 
4d01h: PO3/1 IPCP: Install route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to up

註：配置PPP封裝的POS介面會不斷嘗試建立PPP會話。因此，您會看到線路協定在持續出現問題時會定期短暫出現，即使光纖已移除。

連結維護（使用Keepalive）

LCP Echo-Request和Echo-Reply資料包為鏈路的兩個方向提供第2層環回機制。在接收處於LCP Open狀態的回應要求時，必須傳送回應要求消息。

RFC 1661中的此圖說明PPP keepalive資料包的格式。

16152a.gif

這些LCP資料包包括以下關鍵欄位：

  • Code - 9表示Echo-Request，10表示Echo-Reply。

  • Identifier — 在傳輸時，只要Data欄位的內容發生變化，並且已收到前一個請求的有效答覆，就必須更改Identifier欄位。對於重新傳輸，識別符號可以保持不變。在接收時，回應要求的Identifier欄位被複製到Echo-Reply資料包的Identifier欄位。

  • Magic-Number - Magic-Number欄位為四個八位數，可幫助檢測處於環回狀態的鏈路。在成功協商幻數配置選項之前，必須將幻數作為零進行傳輸。如需進一步的說明，請參閱RFC 1661中的幻陣列態選項。

  • Data - Data欄位為零個或多個八位數，並包含供傳送方使用的未解釋資料。資料可由任何二進位制值組成。欄位的末尾由Length表示。

以下是啟用keepalive時debug ppp negotiation的範例：

4d01h: PO3/1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x1A45933B 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 16 
4d01h: PO3/1 LCP: I ECHOREP [Open] id 1 len 12 magic 0x00000002 
4d01h: PO3/1 LCP: Received id 1, sent id 1, line up

連結終止

PPP可以隨時終止鏈路。可能的觸發包括載波丟失、身份驗證失敗、鏈路品質失敗、空閒週期計時器到期或鏈路的管理關閉。

LCP使用Terminate packets關閉鏈路。Terminate-Request的傳送方應在收到Terminate-Ack後或Restart計數器到期後斷開連線。Terminate-Request的接收方應等待對等體斷開連線，並且在傳送Terminate-Ack後至少經過一個重新啟動時間之前不得斷開連線。

16152a.gif

終止LCP資料包包括以下關鍵欄位：

  • Code - 5表示Terminate-Request，6表示Terminate-Ack。

  • Identifier — 在傳輸時，只要Data欄位的內容發生更改，並且已收到前一個請求的有效答覆，就必須更改Identifier欄位。對於重新傳輸，識別符號可以保持不變。在接收時，將Terminate-Request的Identifier欄位複製到Terminate-Ack資料包的Identifier欄位。

Data欄位為零個或多個八位數，並包含供傳送方使用的未解釋資料。資料可由任何二進位制值組成。欄位的末尾由Length表示。

以下是接收TERMREQ封包時debug ppp negotiation輸出的範例：

4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 8 
4d01h: PO3/1 LCP: I TERMREQ [Open] id 4 len 4 
4d01h: PO3/1 LCP: O TERMACK [Open] id 4 len 4 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 18 
4d01h: PO3/1 IPCP: State is Closed 
4d01h: PO3/1 PPP: Phase is TERMINATING 
4d01h: PO3/1 LCP: I CONFREQ [TERMsent] id 1 len 14 
4d01h: PO3/1 LCP:    MRU 1500 (0x010405DC) 
4d01h: PO3/1 LCP:    MagicNumber 0x00000002 (0x050600000002) 
4d01h: PO3/1 LCP: Dropping packet, state is TERMsent 

!--- While in the TERMsent state, PPP should drop all other packets. 

4d01h: PO3/1 IPCP: Remove route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to down

故障排除順序示例

本節介紹使用PPP封裝的POS鏈路故障排除示例場景。它使用以下配置：

路由器A的配置 
interface POS1/0 
 ip address 1.1.1.6 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16 
 clock source internal

路由器B配置 
interface POS2/0 
 ip address 1.1.1.5 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16

注意：這些調試是在背對背實驗設定中的兩台路由器上捕獲的。因此，時鐘在一端設定為內部，而在另一端設定為預設線路。

debug ppp negotiation

此輸出說明在LCP的鏈路建立階段使用debug ppp negotiation捕獲的資料包交換。

路由器A的調試輸出 
Router A Debug Output  
(1)  

!--- The router sends an outgoing confreq.

hswan-12008-2a#
*Nov  7 08:27:00: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 08:27:00: PO1/0 PPP: Treating connection as a dedicated line
*Nov  7 08:27:00: PO1/0 PPP: Phase is ESTABLISHING, Active Open
*Nov  7 08:27:00: PO1/0 LCP: O CONFREQ [Closed] id 7 len 14 
*Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D)
 
(4)  

!--- Router A receives an incoming confreq from router B. 

*Nov  7 08:27:00: PO1/0 LCP: I CONFREQ [REQsent] id 45 len 14 
*Nov  7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2)
 
(5) 

!--- Router A responds with a confack and receives a !--- confack from Router B. The LCP state is open. 
 
*Nov  7 08:27:00: PO1/0 LCP: O CONFACK [REQsent] id 45 len 14 
*Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2) 
*Nov  7 08:27:00: PO1/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176)
*Nov  7 08:27:00: PO1/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
*Nov  7 08:27:00: PO1/0 LCP: State is Open
*Nov  7 08:27:00: PO1/0 PPP: Phase is UP
 
(7) 

!--- Router A begins the IPCP stage and negotiates an IP address. !--- In this setup, the peer router already has an address and !--- sends it in a confreq. If the peer router accepts the address, !--- it responds with a confack.

*Nov  7 08:27:00: PO1/0 IPCP: O CONFREQ [Closed] id 7 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106)
*Nov  7 08:27:00: PO1/0 CDPCP: O CONFREQ [Closed] id 7 len 4 
*Nov  7 08:27:00: PO1/0 IPCP: I CONFREQ [REQsent] id 9 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105)
*Nov  7 08:27:00: PO1/0 IPCP: O CONFACK [REQsent] id 9 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105)
*Nov  7 08:27:00: PO1/0 CDPCP: I CONFREQ [REQsent] id 9 len 4 
*Nov  7 08:27:00: PO1/0 CDPCP: O CONFACK [REQsent] id 9 len 4 
*Nov  7 08:27:00: PO1/0 IPCP: I CONFACK [ACKsent] id 7 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106)
*Nov  7 08:27:00: PO1/0 IPCP: State is Open
*Nov  7 08:27:00: PO1/0 CDPCP: I CONFACK [ACKsent] id 7 len 4 
*Nov  7 08:27:00: PO1/0 CDPCP: State is Open
*Nov  7 08:27:00: PO1/0 IPCP: Install route to 1.1.1.5
*Nov  7 08:27:01: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface POS1/0, changed state to up

路由器B調試輸出 
(2) 

!--- Router B receives an incoming confrq from Router A. 

hswan-12008-2b#
Nov  7 10:29:19.043: PO2/0 LCP: I CONFREQ [Open] id 7 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
Nov  7 10:29:19.043: PO2/0 IPCP: State is Closed
Nov  7 10:29:19.043: PO2/0 CDPCP: State is Closed
Nov  7 10:29:19.043: PO2/0 PPP: Phase is TERMINATING
Nov  7 10:29:19.043: PO2/0 PPP: Phase is ESTABLISHING
 
(3) 

!--- Router B sends its own LCP confreq.
  
Nov  7 10:29:19.043: PO2/0 LCP: O CONFREQ [Open] id 45 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2)
 
(6) 

!--- Router B responds with a confack and receives a confack from Router A. 
 
The LCP state is open.  
Nov  7 10:29:19.043: PO2/0 LCP: O CONFACK [Open] id 7 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
Nov  7 10:29:19.043: PO2/0 IPCP: Remove route to 1.1.1.6
Nov  7 10:29:19.047: PO2/0 LCP: I CONFACK [ACKsent] id 45 len 14 
Nov  7 10:29:19.047: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.047: PO2/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2) 
Nov  7 10:29:19.047: PO2/0 LCP: State is Open
Nov  7 10:29:19.047: PO2/0 PPP: Phase is UP
 
(8) 

!--- Router B also begins the IPCP stage and negotiates an IP address.
  
Nov  7 10:29:19.047: PO2/0 IPCP: O CONFREQ [Closed] id 9 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 10:29:19.047: PO2/0 CDPCP: O CONFREQ [Closed] id 9 len 4 
Nov  7 10:29:19.047: PO2/0 IPCP: I CONFREQ [REQsent] id 7 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 10:29:19.047: PO2/0 IPCP: O CONFACK [REQsent] id 7 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 10:29:19.047: PO2/0 CDPCP: I CONFREQ [REQsent] id 7 len 4 
Nov  7 10:29:19.047: PO2/0 CDPCP: O CONFACK [REQsent] id 7 len 4 
Nov  7 10:29:19.047: PO2/0 IPCP: I CONFACK [ACKsent] id 9 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 10:29:19.047: PO2/0 IPCP: State is Open
Nov  7 10:29:19.047: PO2/0 CDPCP: I CONFACK [ACKsent] id 9 len 4 
Nov  7 10:29:19.047: PO2/0 CDPCP: State is Open
Nov  7 10:29:19.047: PO2/0 IPCP: Install route to 1.1.1.6
*Nov  7 10:29:19.048: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface POS2/0, changed state to up

debug ppp packet

此輸出說明在建立鏈路時使用debug ppp packet捕獲的資料包交換。此偵錯會擷取PPP封包中通訊協定欄位的值。RFC 1661將Protocol欄位定義為一個或兩個八位元。此欄位中的值標識封裝在資料包「資訊」欄位中的資料包。

「0***」到「3***」範圍內的協定欄位值標識特定資料包的網路層協定，而「8***」到「b***」範圍內的值標識屬於關聯網路控制協定(NCP)的資料包（如果有）。「c***」到「f***」範圍內的協定欄位值將資料包標識為鏈路層控制協定（如LCP）。 還有各種特定於供應商的值。按一下此處檢視PPP協議欄位值的完整清單leavingcisco.com。

路由器A的調試輸出 
(1) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 

!--- 0xC021 identifies LCP. 

*Nov  7 10:19:58: PO1/0 LCP: I CONFREQ [Closed] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFREQ [Closed] id 57 len 14^Z
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFACK [REQsent] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 
*Nov  7 10:19:58: PO1/0 LCP: I CONFACK [ACKsent] id 57 len 14ppp
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 

!--- 0x8021 identifies IPCP, PPP internet protcol control protocol. 
 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 

!--- 0x8207 identifies Cisco discovery protocol control.
  
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFREQ [Closed] id 15 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFREQ [Closed] id 13 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFREQ [REQsent] id 14 len 10packet
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFACK [REQsent] id 14 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFREQ [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFACK [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFACK [ACKsent] id 15 len 10 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFACK [ACKsent] id 13 len 4 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 

!--- 0x0207 identifies Cisco Discovery Protocol (CDP). 
 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
POS1/0, changed state to up
 
(3) 

!--- ECHOREQand ECHOREP packets for PPP keepalives use packet type values !--- of 0xC021.
 
*Nov  7 10:20:05: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:05: PO1/0 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:05: PO1/0 LCP: O ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:07: PO1/0 PPP: O pkt type 0x0207, datagramsize 376 
*Nov  7 10:20:07: PO1/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:07: PO1/0 LCP: Received id 1, sent id 1, line up

路由器B調試輸出 
(2) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFREQ [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: O CONFACK [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
Nov  7 12:22:16.947: PO2/0 IPCP: O CONFREQ [Closed] id 14 len 10 
Nov  7 12:22:16.947: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.947: PO2/0 CDPCP: O CONFREQ [Closed] id 15 len 4 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFREQ [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 IPCP: O CONFACK [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFREQ [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 CDPCP: O CONFACK [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFACK [ACKsent] id 14 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFACK [ACKsent] id 15 len 4 
Nov  7 12:22:17.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up
 
(4) 

!--- ECHOREQ and ECHOREP packets for PPP keepalives use packet type !--- values of 0xC021. 

Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:23.403: PO2/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
Nov  7 12:22:23.403: PO2/0 PPP: I pkt type 0xC021, datagramsize 16 
Nov  7 12:22:23.403: PO2/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
Nov  7 12:22:23.403: PO2/0 LCP: Received id 1, sent id 1, line up
Nov  7 12:22:25.595: PO2/0 PPP: I pkt type 0xC021, datagramsize 16

疑難排解說明

採用PPP或HDLC封裝的POS介面支援兩種機制，可提醒您鏈路故障：第2層keepalive和SONET層警報。Keepalive報告問題所花費的時間比固有的SONET警報結構長。但是，第2層keepalive非常有用，因為它們會檢查從線卡CPU到線卡CPU的路徑，而不是像SONET級別警報那樣檢查幀器到幀器的路徑。由於LCP立即關閉，PPP對鏈路狀態更改的反應更快。相反，HDLC必須超時keepalive。

在兩台路由器之間的背靠背設定中，拉動其中一個光纖絞線會中斷第1層連線，兩個POS介面的狀態都將變為關閉/關閉。但是，當兩個路由器POS介面通過Telco雲與SONET/SDH裝置連線時，第1層丟失資訊不會傳播到遠端端。在此組態中，keepalive是使連結關閉的機制。

請考慮此設定。

16152b.gif

將鏈路上的傳輸光纖絞線從SDHb拉到SDHa時，會出現以下情況：

  • 路由器7507a沒有收到任何keepalive。

  • 路由器7507b可看到來自7507a的keepalive，因為接收光纖仍在工作。使用debug serial interface確認這一點。

或者，在執行此測試時，執行show controller pos命令，該命令顯示SONET警報。您應該會看到路由器7507a上的路徑警報指示訊號(P-AIS)和路由器7507b上的路徑遠端缺陷指示(P-RDI)。

環回測試

如果show interfaces pos命令的輸出表明串列線路已開啟，但線路協定已關閉，則使用環回測試確定問題的根源。先執行本地環路測試，然後執行遠端測試。請參閱瞭解Cisco路由器上的環回模式以獲得指南。

注意：使用環回時，將封裝從PPP更改為HDLC。使用PPP配置的介面上的線路協定僅在成功協商所有LCP和NCP會話時才啟動。

使用APS的線路協定狀態

如果自動保護交換(APS)介面是保護通道而不是工作通道，則配置用於自動保護交換(APS)的POS介面使線路協定關閉。請考慮以下拓撲示例：

16152c.gif

刪除GSRb的POS 1/0介面上的光纖佈線後，捕獲了此日誌輸出示例。注意APS切換發生時，兩個介面上的線路協定狀態變化。另請注意開放最短路徑優先(OSPF)鄰接狀態的變化。(有關詳細資訊，請參閱APS技術支援頁。) 

*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: SLOS 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS2/0: APS enabling channel 
*Sep  5 17:41:46: %SONET-6-APSREMSWI: POS2/0: Remote APS status now Protect 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: APS disabling channel 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, 
changed state to down 
*Sep  5 17:41:48: %LINK-3-UPDOWN: Interface POS1/0, changed state to down 
*Sep  5 17:41:48: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS1/0 
from FULL to DOWN, Neighbor Down: Interface down or detached 
*Sep  5 17:41:56: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS2/0 
from LOADING to FULL, Loading Done

避免使用PPP封裝在POS介面上配置APS。PPP不知道APS。如果某個介面因APS取消選擇而開啟/關閉，PPP會嘗試重置介面並繼續傳輸PPP協商資料包。

此外，請禁用keepalive以避免不必要的線路協定擺動。大多數POS路由器硬體上都會自動禁用Keepalive。

當禁用APS時，處於APS工作或保護模式的Cisco 12000系列POS介面可能會停滯在開啟/關閉狀態（即使使用環回）。插入同一插槽的另一張卡遇到此問題。將卡移至新插槽以恢復正確的線路協定狀態。此問題在Cisco IOS軟體版本12.0(19)S中在Cisco錯誤ID CSCdt43759(僅限註冊客戶)下得到解決。

使用以下步驟作為解決方法：

  1. 配置aps protect命令。

  2. 發出aps force 1命令。

  3. 配置no aps protect命令。

已知的問題

排除POS介面線路協定故障時，請注意以下注意事項：

  • 將封裝從PPP更改為HDLC後，PA-POS介面可能會連續重置。此問題報告針對Cisco錯誤ID CSCdk30893(僅限註冊客戶)中的PA-POS，已在支援PPP和HDLC封裝的各種介面的Cisco錯誤ID CSCdk1877(僅限註冊客戶)和Cisco錯誤ID CSCdk13757(registered customers)中解決。更改封裝時，PPP沒有完全關閉時，就會導致此問題。

  • 當沒有從遠端收到keepalive時，使用HDLC封裝和keepalive設定的POS介面會進行重複的介面翻動，而不是關閉線路通訊協定。此問題已在Cisco錯誤ID CSCdp86387(僅限註冊客戶)中解決。

相關資訊

修訂記錄

修訂 發佈日期 意見
1.0
30-Dec-2001
初始版本

貢獻者

  • amdavis
    pdockeri

這份文件是否有所幫助？

Feedback意見

讓思科協助您

本文件適用於這些產品