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

LCP (鏈路控制協議)是PPP協議的一個子集，在PPP通信中，發送端和接收端通過發送LCP包來確定那些在數據傳輸中的必要信息。LCP檢查鏈接設備的標識，決定是接受還是拒絕；確定傳輸中可接收的包字節數；核對雙方配置是否匹配，如果不匹配則斷開鏈接。只有在LCP包鏈接是可用的情況下，數據才能實現網絡通信。 LCP負責設備之間鏈路的創建，維護和終止。

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

　　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報文的協商過程，問題一般可得到滿意的解決。