串行鏈路故障處理的一般步驟
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報文的協商過程，問題一般可得到滿意的解決。
【編輯推薦】
- 路由器故障：鏈路不穩定
- 路由器故障：鏈路丟包嚴重
- 串行鏈路配置的常見問題 上篇
- 路由器故障：CE1接口網速較慢
- 路由器故障：廣域網故障處理分析
- 路由器故障：MP捆綁鏈路閃斷丟包
- 路由器故障：ATM接口做備份接口鏈路層無法Up
