串行鏈路故障處理的一般步驟

串行鏈路故障處理的一般步驟如下：

1. 物理層問題分析

設備表現為廣域網接口無法正常使用時，首先應該從物理層開始檢查。使用display interface命令查看接口信息，例如執行命令display interface bri 0(BRI接口 0）或display interface serial 1 (串口 1)，根據顯示信息中的“硬件設備的狀態”和“LCP的狀態”判斷物理層是否正常。

如下是一個Quidway R2631路由器的例子：

[Router]display interface serial 0  
 
Serial0 is up, line protocol is up  
 
physical layer is synchronous  
 
interface is DTE, clock is DTECLK1, cable type is V35  
 
Maximum Transmission Unit is 1500  
 
Internet address is 192.168.1.1   255.255.0.0  
 
Encapsulation is PPP  
 
LCP opened, IPCP opened, IPXCP initial, CCP initial, BRIDGECP initial  
 
1 minutes input rate 2102.86 bytes/sec, 1.75 packets/sec  
 
1 minutes output rate 5549.86 bytes/sec, 3.90 packets/sec  
 
Input queue :(size/max/drops)  
 
0/50/0  
 
Queueing strategy: FIFO  
 
Output queue: (size/max/drops) 47/75/5702  
 
3943 packets input,   212485 bytes, 0 no buffers  
 
4101 packets output, 465119 bytes, 0 no buffers  
 
0 input errors, 0 CRC, 0 frame errors  
 
0 overrunners, 0 aborted sequences, 0 input no buffers  
 
DCD=UP   DTR=UP   DSR=UP   RTS=UP   CTS=UP 

Serial0 is up,表明物理層狀態UP，,此外Serial0可能為down, administratively down,standby，其中down說明物理層工作異常，應檢查物理層配置及設備問題。administratively down，說明物理層被人為關閉。此時可以執行no shutdown命令手工打開此端口。 standby是在使用接口備份功能，備份口的一種狀態，也表示接口物理層不可用。

LCP狀態也表明了物理層是否向鏈路層上報lowerup消息，從PPP狀態轉移圖可知。

物理層未發送lowerup，PPP未發送open消息，LCP應處于initial狀態；如物理層發送了lowerup，PPP已發送 open消息，發出CONFREQ報文LCP應處于req-send狀態；如物理層發送了lowerup，PPP已發送 open消息，發出CONFREQ報文和CONFACK報文， LCP應處于ACKSENT狀態，如物理層發送了lowerup，PPP未發送 open消息，LCP應處于starting狀態。如物理層未通，應先查找物理層未通的原因。

2. LCP問題的分析

執行如上命令display interface bri 0(BRI接口 0）或display interface serial 1 (串口 1)，如顯示LCP協議未進入OPENED狀態，可考慮為LCP的問題。此方面的問題一般較少出現，如出現應該打開debug ppp packet或debug ppp negotiation，首先檢查物理接口的報文收發是否正常，如果確認接口的報文收發正常，并且有大量的CONFNAK、CONFREJ報文出現，或者出現TERMACK、CODEREJ、PROTREJ只類的報文，可以說明是協商的問題，再根據報文協商項內容分析無法協商成功的原因。

3. 驗證問題的分析

使用display interface命令查看接口信息，如顯示LCP協議進入OPENED狀態，而IPCP依然為Initial狀態，或者LCP變為OPENED狀態后又很快重新開始協商，可考慮為驗證的問題，由于此狀態為臨時狀態，不易觀察，也可通過debug ppp packet 或debug ppp negotiation 來觀察。如果成功協商了驗證，PPP會打印出PAP或CHAP驗證的報文，如果驗證失敗，會打印出“PPP authentication failed”信息，可以根據報文的具體內容分析驗證失敗的原因。有時配置了驗證，但是LCP協商過程中該協商項被拒掉，LCP進入OPENED狀態會立即重新協商，此時若通過debug ppp event觀察，可以看到對端未通過驗證的提示信息，例如“The opposite terminal haven't pass the chap authentication!”。

4. IPCP問題的分析

使用display interface命令查看接口信息，如顯示LCP協議進入OPENED狀態，而IPCP處于REQ_SEND或ACK_RCVD，并觀察PPP報文有大量的IPCP報文收發，可說明路由器IPCP協商有問題。若IPCP處于STOPPED狀態，也可能是收到IPCP的TERMREQ或CODEREJ導致狀態遷移。閱讀IPCP報文，可分析出問題原因。由于IPCP必須協商的參數為IP地址，其他為可選擇參數，一般來說是IP地址配置有問題，無法進行IPCP協商。此時應給兩端接口配置IP地址，此外如果是訪問Internet網，可不配置IP地址，但應該配置IP address ppp-negotiate。

5. 其他問題

如LCP、IPCP均已經進入OPENED狀態，但是Ping報文無法互通，可考慮路由的原因，可采用直接ping此接口對端的IP地址，如能夠互通，證明PPP對IP報文的封裝情況正常。如依然有問題，但LCP和IPCP始終處于OPENED狀態，可考慮是否鏈路誤碼率較高，此情況比較少見。

有時在路由器上配置了aaa-enable之后，LCP和IPCP均已經進入OPENED狀態，但很快又重新開始LCP協商，因為配置了aaa-enable之后，缺省要進行計費，如果沒有設置計費服務器，AAA會將PPP鏈路掛斷。如果要使用AAA，又不需要計費，可以配置aaa accounting-schem optional，允許不計費使用。

PPP協議的應用比較廣泛，以上只是一些常見問題的分析，但實際應用中問題復雜得多，但如果能夠閱讀PPP報文，了解PPP協商所處于的階段，和PPP報文的協商過程，問題一般可得到滿意的解決。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]