串行鏈路故障處理的一般步驟
LCP (鏈路控制協(xié)議)是PPP協(xié)議的一個子集，在PPP通信中，發(fā)送端和接收端通過發(fā)送LCP包來確定那些在數(shù)據(jù)傳輸中的必要信息。LCP檢查鏈接設(shè)備的標(biāo)識，決定是接受還是拒絕；確定傳輸中可接收的包字節(jié)數(shù)；核對雙方配置是否匹配，如果不匹配則斷開鏈接。只有在LCP包鏈接是可用的情況下，數(shù)據(jù)才能實現(xiàn)網(wǎng)絡(luò)通信。 LCP負(fù)責(zé)設(shè)備之間鏈路的創(chuàng)建，維護(hù)和終止。
串行鏈路故障處理的一般步驟如下：
1. 物理層問題分析
設(shè)備表現(xiàn)為廣域網(wǎng)接口無法正常使用時，首先應(yīng)該從物理層開始檢查。使用display interface命令查看接口信息，例如執(zhí)行命令display interface bri 0(BRI接口 0）或display interface serial 1 (串口 1)，根據(jù)顯示信息中的“硬件設(shè)備的狀態(tài)”和“LCP的狀態(tài)”判斷物理層是否正常。
如下是一個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,表明物理層狀態(tài)UP，,此外Serial0可能為down, administratively down,standby，其中down說明物理層工作異常，應(yīng)檢查物理層配置及設(shè)備問題。administratively down，說明物理層被人為關(guān)閉。此時可以執(zhí)行no shutdown命令手工打開此端口。 standby是在使用接口備份功能，備份口的一種狀態(tài)，也表示接口物理層不可用。
LCP狀態(tài)也表明了物理層是否向鏈路層上報lowerup消息，從PPP狀態(tài)轉(zhuǎn)移圖可知。
物理層未發(fā)送lowerup，PPP未發(fā)送open消息，LCP應(yīng)處于initial狀態(tài)；如物理層發(fā)送了lowerup，PPP已發(fā)送 open消息，發(fā)出CONFREQ報文LCP應(yīng)處于req-send狀態(tài)；如物理層發(fā)送了lowerup，PPP已發(fā)送 open消息，發(fā)出CONFREQ報文和CONFACK報文， LCP應(yīng)處于ACKSENT狀態(tài)，如物理層發(fā)送了lowerup，PPP未發(fā)送 open消息，LCP應(yīng)處于starting狀態(tài)。如物理層未通，應(yīng)先查找物理層未通的原因。
2. LCP問題的分析
執(zhí)行如上命令display interface bri 0(BRI接口 0）或display interface serial 1 (串口 1)，如顯示LCP協(xié)議未進(jìn)入OPENED狀態(tài)，可考慮為LCP的問題。此方面的問題一般較少出現(xiàn)，如出現(xiàn)應(yīng)該打開debug ppp packet或debug ppp negotiation，首先檢查物理接口的報文收發(fā)是否正常，如果確認(rèn)接口的報文收發(fā)正常，并且有大量的CONFNAK、CONFREJ報文出現(xiàn)，或者出現(xiàn)TERMACK、CODEREJ、PROTREJ只類的報文，可以說明是協(xié)商的問題，再根據(jù)報文協(xié)商項內(nèi)容分析無法協(xié)商成功的原因。
3. 驗證問題的分析
使用display interface命令查看接口信息，如顯示LCP協(xié)議進(jìn)入OPENED狀態(tài)，而IPCP依然為Initial狀態(tài)，或者LCP變?yōu)镺PENED狀態(tài)后又很快重新開始協(xié)商，可考慮為驗證的問題，由于此狀態(tài)為臨時狀態(tài)，不易觀察，也可通過debug ppp packet 或debug ppp negotiation 來觀察。如果成功協(xié)商了驗證，PPP會打印出PAP或CHAP驗證的報文，如果驗證失敗，會打印出“PPP authentication failed”信息，可以根據(jù)報文的具體內(nèi)容分析驗證失敗的原因。有時配置了驗證，但是LCP協(xié)商過程中該協(xié)商項被拒掉，LCP進(jìn)入OPENED狀態(tài)會立即重新協(xié)商，此時若通過debug ppp event觀察，可以看到對端未通過驗證的提示信息，例如“The opposite terminal haven't pass the chap authentication!”。
4. IPCP問題的分析
使用display interface命令查看接口信息，如顯示LCP協(xié)議進(jìn)入OPENED狀態(tài)，而IPCP處于REQ_SEND或ACK_RCVD，并觀察PPP報文有大量的IPCP報文收發(fā)，可說明路由器IPCP協(xié)商有問題。若IPCP處于STOPPED狀態(tài)，也可能是收到IPCP的TERMREQ或CODEREJ導(dǎo)致狀態(tài)遷移。閱讀IPCP報文，可分析出問題原因。由于IPCP必須協(xié)商的參數(shù)為IP地址，其他為可選擇參數(shù)，一般來說是IP地址配置有問題，無法進(jìn)行IPCP協(xié)商。此時應(yīng)給兩端接口配置IP地址，此外如果是訪問Internet網(wǎng)，可不配置IP地址，但應(yīng)該配置IP address ppp-negotiate。
5. 其他問題
如LCP、IPCP均已經(jīng)進(jìn)入OPENED狀態(tài)，但是Ping報文無法互通，可考慮路由的原因，可采用直接ping此接口對端的IP地址，如能夠互通，證明PPP對IP報文的封裝情況正常。如依然有問題，但LCP和IPCP始終處于OPENED狀態(tài)，可考慮是否鏈路誤碼率較高，此情況比較少見。
有時在路由器上配置了aaa-enable之后，LCP和IPCP均已經(jīng)進(jìn)入OPENED狀態(tài)，但很快又重新開始LCP協(xié)商，因為配置了aaa-enable之后，缺省要進(jìn)行計費，如果沒有設(shè)置計費服務(wù)器，AAA會將PPP鏈路掛斷。如果要使用AAA，又不需要計費，可以配置aaa accounting-schem optional，允許不計費使用。
PPP協(xié)議的應(yīng)用比較廣泛，以上只是一些常見問題的分析，但實際應(yīng)用中問題復(fù)雜得多，但如果能夠閱讀PPP報文，了解PPP協(xié)商所處于的階段，和PPP報文的協(xié)商過程，問題一般可得到滿意的解決。
【編輯推薦】
- 路由器故障：鏈路不穩(wěn)定
- 路由器故障：鏈路丟包嚴(yán)重
- 串行鏈路配置的常見問題 上篇
- 路由器故障：CE1接口網(wǎng)速較慢
- 路由器故障：廣域網(wǎng)故障處理分析
- 路由器故障：MP捆綁鏈路閃斷丟包
- 路由器故障：ATM接口做備份接口鏈路層無法Up
