1. 為什么還要啃HDLC和PPP這兩塊“老骨頭”剛?cè)胄心菚?huì)兒我第一次在設(shè)備上敲show interface serial看到一行encapsulation HDLC心里想的是“這玩意兒不是上古時(shí)代的產(chǎn)物嗎學(xué)它干嘛”。后來跟著做專線割接、排查鏈路起不來、對(duì)接運(yùn)營商廣域網(wǎng)才發(fā)現(xiàn)這兩個(gè)二層協(xié)議根本沒退場(chǎng)——它們藏在運(yùn)營商最后一公里的串口鏈路上、藏在某些行業(yè)專網(wǎng)的窄帶通道里、藏在老設(shè)備的默認(rèn)封裝里。你平時(shí)在以太網(wǎng)里待久了會(huì)覺得二層就是MAC地址加VLAN但一旦鏈路換成點(diǎn)對(duì)點(diǎn)串行線路游戲規(guī)則完全變了沒有廣播、沒有ARP、沒有MAC地址表兩端怎么認(rèn)出對(duì)方、怎么協(xié)商參數(shù)、怎么保證幀不丟不亂全靠HDLC和PPP這套機(jī)制撐著。這篇筆記就是把我這些年踩過的坑、翻過的手冊(cè)、抓過的包整理出來。**HDLCHigh-Level Data Link Control高級(jí)數(shù)據(jù)鏈路控制和PPPPoint-to-Point Protocol點(diǎn)對(duì)點(diǎn)協(xié)議**是廣域網(wǎng)串行鏈路上最常見的兩種二層封裝前者是ISO標(biāo)準(zhǔn)體系里的老牌選手后者是IETF在它基礎(chǔ)上演化出來的實(shí)用派。學(xué)它們不是為了考試而是為了在鏈路不通的時(shí)候你能從物理層一路往上定位到“到底是封裝不匹配、還是認(rèn)證沒過、還是MTU掐了包”。適合誰看剛接觸廣域網(wǎng)的新人、需要對(duì)接運(yùn)營商專線的網(wǎng)絡(luò)運(yùn)維、以及想把二層原理補(bǔ)扎實(shí)的老手。下面我按“設(shè)計(jì)思路—核心細(xì)節(jié)—實(shí)操過程—排障實(shí)錄”的順序展開中間穿插參數(shù)計(jì)算和現(xiàn)場(chǎng)記錄盡量讓你看完就能上手復(fù)現(xiàn)。2. 整體設(shè)計(jì)與思路拆解兩種封裝到底在解決什么問題2.1 從“點(diǎn)對(duì)點(diǎn)鏈路”的特殊性說起先建立一個(gè)基本認(rèn)知點(diǎn)對(duì)點(diǎn)鏈路和以太網(wǎng)共享鏈路是兩種世界。以太網(wǎng)里一臺(tái)主機(jī)發(fā)幀總線上所有設(shè)備都能收到靠MAC地址區(qū)分你我而點(diǎn)對(duì)點(diǎn)鏈路只有兩端物理上就是一根線連著兩個(gè)接口不存在“發(fā)給誰”的問題反而要解決另外三件事——幀邊界怎么定一串連續(xù)的比特流里哪里是幀頭哪里是幀尾、差錯(cuò)怎么發(fā)現(xiàn)線路質(zhì)量差的時(shí)候比特翻轉(zhuǎn)很常見、鏈路怎么管理兩端速率、封裝、認(rèn)證參數(shù)要不要協(xié)商一致。HDLC和PPP本質(zhì)上都是圍繞這三個(gè)問題設(shè)計(jì)的區(qū)別在于HDLC更“裸”、更貼近底層PPP更“全”、把認(rèn)證和協(xié)商做成了標(biāo)準(zhǔn)流程。我習(xí)慣用一個(gè)類比HDLC像兩個(gè)人用對(duì)講機(jī)通話約定好“我說‘開始’你就聽說‘結(jié)束’就?！敝虚g內(nèi)容錯(cuò)了靠重復(fù)校驗(yàn)發(fā)現(xiàn)但誰先說話、說多快沒有統(tǒng)一規(guī)矩PPP則像兩個(gè)人先握手確認(rèn)“你用中文還是英文、語速多少、要不要對(duì)暗號(hào)”協(xié)商完了再正式通話而且支持中途換人多協(xié)議復(fù)用。這個(gè)差異決定了它們的適用場(chǎng)景HDLC配置簡(jiǎn)單、開銷小適合兩端設(shè)備同廠商、鏈路穩(wěn)定的場(chǎng)景PPP功能全、標(biāo)準(zhǔn)化程度高適合跨廠商對(duì)接、需要認(rèn)證和多協(xié)議承載的場(chǎng)景。2.2 HDLC的幀結(jié)構(gòu)設(shè)計(jì)與取舍邏輯HDLC的幀格式是理解一切的基礎(chǔ)我把它拆成六個(gè)字段來看字段長度作用實(shí)操關(guān)注點(diǎn)標(biāo)志F8bit幀起始/結(jié)束定界固定為01111110連續(xù)多個(gè)F可做填充抓包時(shí)看到一串7E別慌地址A8bit可擴(kuò)展標(biāo)識(shí)從站地址點(diǎn)對(duì)點(diǎn)場(chǎng)景常固定為全1或特定值控制C8bit可擴(kuò)展幀類型與序號(hào)區(qū)分信息幀、監(jiān)控幀、無編號(hào)幀信息I可變承載上層數(shù)據(jù)長度受MTU約束幀校驗(yàn)FCS16/32bitCRC校驗(yàn)?zāi)J(rèn)16位誤碼率高時(shí)可考慮32位標(biāo)志F8bit幀結(jié)束定界與起始標(biāo)志相同這里最值得說的是比特填充bit stuffing。因?yàn)闃?biāo)志字段是01111110如果信息字段里恰好出現(xiàn)連續(xù)6個(gè)1接收方會(huì)誤認(rèn)為是幀邊界。HDLC的解決辦法是發(fā)送方在信息字段中每遇到連續(xù)5個(gè)1就自動(dòng)插入一個(gè)0接收方收到連續(xù)5個(gè)1后的0就刪掉。這個(gè)機(jī)制保證了標(biāo)志序列在數(shù)據(jù)區(qū)永遠(yuǎn)不會(huì)自然出現(xiàn)。我當(dāng)年抓包看到數(shù)據(jù)里莫名其妙多出0一度以為是設(shè)備bug后來才明白這是填充。理解這一點(diǎn)你在分析HDLC抓包時(shí)就不會(huì)被“數(shù)據(jù)長度對(duì)不上”困擾?？刂谱侄蔚娜N幀類型也需要分清**信息幀I幀**帶序號(hào)承載數(shù)據(jù)并支持滑動(dòng)窗口**監(jiān)控幀S幀**不帶數(shù)據(jù)用于確認(rèn)和請(qǐng)求重傳**無編號(hào)幀U幀**用于鏈路建立、拆除等控制。序號(hào)是3位模8意味著窗口最大7這個(gè)限制在老式低速鏈路上夠用但在高速場(chǎng)景下會(huì)成為瓶頸——這也是后來PPP改用擴(kuò)展序號(hào)的原因之一。2.3 PPP的分層設(shè)計(jì)與功能增強(qiáng)PPP的設(shè)計(jì)思路明顯更“工程化”它把自己拆成了三個(gè)組件封裝組件負(fù)責(zé)把上層數(shù)據(jù)包封進(jìn)PPP幀**LCPLink Control Protocol鏈路控制協(xié)議**負(fù)責(zé)建立、配置、測(cè)試、關(guān)閉鏈路**NCPNetwork Control Protocol網(wǎng)絡(luò)控制協(xié)議**負(fù)責(zé)為每種網(wǎng)絡(luò)層協(xié)議做獨(dú)立協(xié)商比如IP對(duì)應(yīng)IPCP。這種分層的好處是擴(kuò)展性強(qiáng)——要支持一種新協(xié)議加一個(gè)NCP就行不用動(dòng)LCP。PPP幀格式和HDLC很像但有幾個(gè)關(guān)鍵差異地址字段固定為0xFF表示廣播點(diǎn)對(duì)點(diǎn)里其實(shí)無意義但保留兼容控制字段固定為0x03無編號(hào)信息幀協(xié)議字段2字節(jié)用來標(biāo)識(shí)承載的是什么協(xié)議0x0021是IP0xC021是LCP0x8021是IPCP。這個(gè)協(xié)議字段是PPP多協(xié)議復(fù)用的核心也是它比HDLC靈活的地方。PPP最實(shí)用的增強(qiáng)是認(rèn)證。PAPPassword Authentication Protocol明文傳密碼兩次握手簡(jiǎn)單但不安全CHAPChallenge Handshake Authentication Protocol三次握手服務(wù)端發(fā)隨機(jī)挑戰(zhàn)客戶端用密碼哈希后回傳且支持周期性重認(rèn)證安全性高得多。我在對(duì)接運(yùn)營商專線時(shí)對(duì)方幾乎清一色要求CHAPPAP只在極老的設(shè)備上見過。選CHAP的理由很直接密碼不在鏈路上明文傳輸且挑戰(zhàn)值每次不同重放攻擊無效。另一個(gè)容易被忽略的設(shè)計(jì)是LCP協(xié)商參數(shù)包括最大接收單元MRU、認(rèn)證協(xié)議、魔術(shù)字Magic Number用于檢測(cè)鏈路環(huán)路、壓縮選項(xiàng)等。協(xié)商過程是“請(qǐng)求—應(yīng)答—確認(rèn)”的來回任何一方不認(rèn)可就發(fā)Configure-Nak或Configure-Reject。我見過鏈路起不來最后定位到MRU不一致的案例——一端配了1500另一端只支持1492LCP協(xié)商階段就卡住了。2.4 選型考量什么時(shí)候用HDLC什么時(shí)候用PPP這個(gè)問題沒有絕對(duì)答案但有幾條經(jīng)驗(yàn)規(guī)則。同廠商設(shè)備直連、鏈路質(zhì)量穩(wěn)定、不需要認(rèn)證HDLC是更輕的選擇配置就一行encapsulation hdlc開銷小、轉(zhuǎn)發(fā)快?？鐝S商對(duì)接、需要認(rèn)證、需要承載多種網(wǎng)絡(luò)層協(xié)議、需要鏈路質(zhì)量監(jiān)測(cè)LQRPPP是標(biāo)準(zhǔn)答案。還有一個(gè)現(xiàn)實(shí)因素很多運(yùn)營商專線默認(rèn)封裝就是PPP你改不了只能適配。我個(gè)人的取舍邏輯是只要鏈路涉及第三方運(yùn)營商、不同廠商設(shè)備一律上PPP因?yàn)闃?biāo)準(zhǔn)化程度高、排障時(shí)有據(jù)可依純內(nèi)部實(shí)驗(yàn)室或同品牌設(shè)備背靠背測(cè)試HDLC省事。這個(gè)選擇背后是對(duì)“互操作性成本”的權(quán)衡——PPP多出來的協(xié)商開銷換來的是跨廠商時(shí)的確定性這筆賬在現(xiàn)網(wǎng)里通常劃算。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 HDLC配置的關(guān)鍵參數(shù)與操作禁忌HDLC在主流網(wǎng)絡(luò)設(shè)備上的配置極簡(jiǎn)但極簡(jiǎn)不代表沒有坑。以串行接口為例基本配置就兩步進(jìn)入接口視圖指定封裝為HDLC。真正需要注意的是keepalive?；顧C(jī)制。HDLC的keepalive是通過周期性發(fā)送無編號(hào)幀實(shí)現(xiàn)的默認(rèn)間隔10秒連續(xù)3次收不到就認(rèn)為鏈路down。這個(gè)參數(shù)在跨設(shè)備對(duì)接時(shí)經(jīng)常出問題——一端配了keepalive、另一端關(guān)了結(jié)果一端認(rèn)為鏈路正常、另一端反復(fù)up/down。注意兩端HDLC的keepalive配置必須一致要么都開、要么都關(guān)。對(duì)接第三方設(shè)備時(shí)先問清楚對(duì)方是否啟用?；顒e想當(dāng)然用默認(rèn)值。另一個(gè)細(xì)節(jié)是MTU與串口物理特性的匹配。串行鏈路的MTU默認(rèn)通常是1500但某些低速鏈路如64Kbps上大包傳輸時(shí)間過長會(huì)導(dǎo)致keepalive超時(shí)誤判。我遇到過一條低速專線頻繁閃斷最后把MTU降到1200、keepalive間隔放寬到20秒才穩(wěn)定。這里的計(jì)算邏輯是一個(gè)1500字節(jié)的包在64Kbps鏈路上傳輸約需187毫秒如果鏈路上還有排隊(duì)keepalive幀可能被延遲到超過超時(shí)閾值。所以低速鏈路要適當(dāng)放寬?；顓?shù)這不是玄學(xué)是排隊(duì)論的基本常識(shí)。HDLC還有一個(gè)“廠商私有擴(kuò)展”的坑。標(biāo)準(zhǔn)HDLC的地址和控制字段是固定的但部分廠商為了實(shí)現(xiàn)多協(xié)議承載或鏈路管理對(duì)HDLC做了私有擴(kuò)展比如在幀里塞類型字段。這意味著兩家不同廠商的HDLC封裝可能不兼容即使都叫HDLC。我吃過這個(gè)虧兩臺(tái)不同品牌設(shè)備背靠背配HDLC物理層up、協(xié)議層down抓包發(fā)現(xiàn)幀結(jié)構(gòu)對(duì)不上。后來查手冊(cè)才知道一方用的是標(biāo)準(zhǔn)HDLC、另一方是私有變體。解決辦法要么統(tǒng)一廠商要么改用PPP。這個(gè)教訓(xùn)讓我養(yǎng)成了一個(gè)習(xí)慣跨廠商對(duì)接前先確認(rèn)封裝的具體實(shí)現(xiàn)別被“都支持HDLC”這句話騙了。3.2 PPP的LCP協(xié)商流程拆解PPP鏈路建立分三個(gè)階段鏈路建立LCP協(xié)商→ 認(rèn)證可選→ 網(wǎng)絡(luò)層協(xié)商N(yùn)CP。LCP協(xié)商是整個(gè)PPP的靈魂搞懂它大部分PPP問題都能定位。LCP協(xié)商的本質(zhì)是雙方交換Configure報(bào)文內(nèi)容包括最大接收單元MRU、認(rèn)證協(xié)議及參數(shù)、魔術(shù)字、協(xié)議字段壓縮、地址控制字段壓縮、鏈路質(zhì)量監(jiān)測(cè)等選項(xiàng)。流程是一端發(fā)Configure-Request列出自己希望啟用的選項(xiàng)另一端逐項(xiàng)檢查全部認(rèn)可就回Configure-Ack有不認(rèn)可但可協(xié)商的就回Configure-Nak附帶建議值完全不支持的就回Configure-Reject附帶拒絕項(xiàng)。發(fā)起方收到Nak或Reject后調(diào)整參數(shù)重發(fā)直到收到Ack。這里的關(guān)鍵理解是LCP協(xié)商是雙向獨(dú)立的。A向B發(fā)請(qǐng)求的同時(shí)B也向A發(fā)請(qǐng)求兩個(gè)方向的參數(shù)可以不同比如MRU可以不對(duì)稱。我見過有人以為“協(xié)商一次就完事”結(jié)果只看到單向Ack就以為鏈路好了實(shí)際上反方向還在協(xié)商。抓包時(shí)看到Configure-Request和Configure-Ack成對(duì)出現(xiàn)才算一個(gè)方向完成。魔術(shù)字Magic Number這個(gè)選項(xiàng)值得單獨(dú)說。它的作用是檢測(cè)鏈路環(huán)路——如果一端收到的Configure-Request里的魔術(shù)字和自己發(fā)出去的一樣說明報(bào)文繞了一圈回來了鏈路存在環(huán)路LCP會(huì)采取相應(yīng)動(dòng)作。在背靠背直連場(chǎng)景里魔術(shù)字通常正常但在某些環(huán)回測(cè)試或配置錯(cuò)誤時(shí)魔術(shù)字沖突會(huì)導(dǎo)致協(xié)商反復(fù)失敗。排查時(shí)如果看到LCP在Configure-Request和Configure-Nak之間循環(huán)優(yōu)先懷疑魔術(shù)字或MRU不匹配。3.3 認(rèn)證階段PAP與CHAP的實(shí)操差異認(rèn)證階段在LCP之后、NCP之前。PAP的流程簡(jiǎn)單粗暴客戶端直接發(fā)用戶名密碼服務(wù)端比對(duì)后回Accept或Reject。配置上認(rèn)證方要指定ppp authentication pap并建本地用戶庫被認(rèn)證方要配ppp pap sent-username。PAP的坑在于密碼明文傳輸任何能抓包的位置都能看到密碼所以現(xiàn)網(wǎng)基本淘汰。CHAP的流程是三次握手服務(wù)端發(fā)Challenge含隨機(jī)數(shù)和自己的名字客戶端用“隨機(jī)數(shù)密碼”做哈希通常是MD5后回Response含哈希值和自己的名字服務(wù)端本地做同樣計(jì)算比對(duì)一致則回Success。配置上認(rèn)證方指定ppp authentication chap并建用戶庫被認(rèn)證方配ppp chap hostname和ppp chap password。CHAP的關(guān)鍵細(xì)節(jié)是名字匹配——服務(wù)端用收到的Response里的名字去本地用戶庫查密碼所以被認(rèn)證方配置的hostname必須和服務(wù)端用戶庫里的用戶名一致。我見過太多“密碼明明對(duì)但認(rèn)證不過”的案例最后都是hostname對(duì)不上。實(shí)操心得CHAP排障第一步永遠(yuǎn)是核對(duì)兩端的名字。認(rèn)證方的用戶庫里用戶名 被認(rèn)證方配置的chap hostname這個(gè)等式不成立密碼再對(duì)也沒用。還有一個(gè)隱蔽的坑是認(rèn)證方向。PPP認(rèn)證是單向的可以只讓一端認(rèn)證另一端也可以雙向認(rèn)證。配置時(shí)ppp authentication chap寫在認(rèn)證方接口上被認(rèn)證方不需要寫這行但要配發(fā)送的用戶名密碼。如果兩端都寫了authentication但都沒配發(fā)送憑據(jù)就會(huì)互相挑戰(zhàn)、互相失敗鏈路永遠(yuǎn)起不來。我建議在筆記里畫個(gè)箭頭圖誰認(rèn)證誰、誰發(fā)憑據(jù)一目了然。3.4 NCP協(xié)商與IPCP的地址分配認(rèn)證通過后進(jìn)入NCP階段IP場(chǎng)景下就是IPCP。IPCP協(xié)商的內(nèi)容包括IP地址、DNS地址、壓縮選項(xiàng)等。最常見的場(chǎng)景是一端通過IPCP從另一端獲取IP地址類似撥號(hào)時(shí)代的地址分配。配置上分配方要配地址池或在接口上指定對(duì)端地址獲取方配ip address negotiated。IPCP有個(gè)細(xì)節(jié)容易被忽略地址協(xié)商是雙向的即使一端已經(jīng)有固定IPIPCP也會(huì)交換地址信息做確認(rèn)。抓包時(shí)看到IPCP Configure-Request里帶地址0.0.0.0表示“我還沒有地址請(qǐng)你分配”帶具體地址則表示“我希望用這個(gè)地址”。如果兩端都配了固定地址且不一致IPCP可能協(xié)商失敗或產(chǎn)生地址沖突。現(xiàn)網(wǎng)里專線兩端通常都是固定地址IPCP主要起確認(rèn)作用但配置不一致時(shí)它照樣會(huì)攔你。3.5 幀結(jié)構(gòu)與字段的實(shí)操對(duì)照把HDLC和PPP的幀結(jié)構(gòu)放一起對(duì)比能看清演化邏輯對(duì)比項(xiàng)HDLCPPP標(biāo)志字段0111111001111110相同地址字段可變標(biāo)識(shí)從站固定0xFF控制字段可變含幀類型序號(hào)固定0x03協(xié)議標(biāo)識(shí)無靠私有擴(kuò)展2字節(jié)標(biāo)準(zhǔn)多協(xié)議復(fù)用校驗(yàn)16/32bit CRC16/32bit CRC認(rèn)證無標(biāo)準(zhǔn)認(rèn)證PAP/CHAP標(biāo)準(zhǔn)認(rèn)證鏈路協(xié)商無LCP完整協(xié)商多協(xié)議支持依賴廠商擴(kuò)展NCP標(biāo)準(zhǔn)支持這張表解釋了一個(gè)核心問題為什么PPP能跨廠商而HDLC不能。PPP把“地址控制字段”固定下來0xFF 0x03把多協(xié)議標(biāo)識(shí)標(biāo)準(zhǔn)化協(xié)議字段把鏈路管理標(biāo)準(zhǔn)化LCP所有廠商按同一套規(guī)則實(shí)現(xiàn)互操作自然沒問題。HDLC把這些留給廠商自由發(fā)揮標(biāo)準(zhǔn)只規(guī)定了骨架血肉各填各的跨廠商就露餡了。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 實(shí)驗(yàn)環(huán)境搭建與基礎(chǔ)配置我用模擬器搭一個(gè)背靠背串行鏈路來復(fù)現(xiàn)兩種封裝。拓?fù)浜芎?jiǎn)單兩臺(tái)路由器通過Serial接口直連先配HDLC跑通再切PPP加認(rèn)證。接口地址規(guī)劃為10.0.0.1/30和10.0.0.2/30這個(gè)/30的掩碼計(jì)算是點(diǎn)對(duì)點(diǎn)鏈路只需要2個(gè)可用地址30位掩碼提供4個(gè)地址減去網(wǎng)絡(luò)號(hào)和廣播號(hào)正好2個(gè)是最省地址的選擇。HDLC側(cè)配置以一端為例interface Serial0/0/0 encapsulation hdlc ip address 10.0.0.1 255.255.255.252 keepalive 10 no shutdown另一端對(duì)稱配置10.0.0.2。配完檢查show interface Serial0/0/0重點(diǎn)看兩行Line protocol is up表示二層通了Encapsulation HDLC確認(rèn)封裝。再用ping 10.0.0.2驗(yàn)證三層。這一步如果line protocol起不來先查物理層線序、時(shí)鐘再查封裝是否兩端一致。PPP側(cè)配置先跑無認(rèn)證的基礎(chǔ)PPPinterface Serial0/0/0 encapsulation ppp ip address 10.0.0.1 255.255.255.252 no shutdown兩端都切PPP后show interface里會(huì)看到LCP Open表示LCP協(xié)商完成。此時(shí)如果配了IP地址IPCP也會(huì)完成show ppp interface能看到IPCP狀態(tài)?；A(chǔ)PPP跑通后再加CHAP認(rèn)證。4.2 CHAP認(rèn)證的完整配置與驗(yàn)證認(rèn)證方假設(shè)為A端配置username B password Cisco123 interface Serial0/0/0 encapsulation ppp ppp authentication chap ip address 10.0.0.1 255.255.255.252被認(rèn)證方B端配置interface Serial0/0/0 encapsulation ppp ppp chap hostname B ppp chap password Cisco123 ip address 10.0.0.2 255.255.255.252注意A端的username B里的B必須等于B端ppp chap hostname配的B。這個(gè)對(duì)應(yīng)關(guān)系是CHAP認(rèn)證的命門。配完用debug ppp authentication觀察過程正常會(huì)看到Challenge發(fā)出、Response收到、Success返回。如果看到Failure先核對(duì)名字再核對(duì)密碼最后看是否兩端都開了authentication導(dǎo)致雙向挑戰(zhàn)但只配了單向憑據(jù)。驗(yàn)證命令我常用這幾個(gè)show ppp interface Serial0/0/0看LCP和IPCP狀態(tài)show interface Serial0/0/0看line protocolshow running-config interface Serial0/0/0復(fù)核配置。三層通了再ping對(duì)端地址全通才算完。4.3 參數(shù)計(jì)算MTU、MRU與低速鏈路的匹配前面提到低速鏈路要調(diào)MTU這里把計(jì)算過程寫清楚。假設(shè)鏈路速率64Kbpskeepalive間隔10秒、重試3次那么?；顜仨氃?0秒內(nèi)完成往返。一個(gè)keepalive幀很小幾十字節(jié)傳輸時(shí)間可忽略但如果鏈路上有大包排隊(duì)最壞情況是一個(gè)最大包1500字節(jié)的傳輸時(shí)間1500×8/64000≈187.5毫秒。看起來遠(yuǎn)小于30秒似乎沒問題。但實(shí)際鏈路往往有多個(gè)隊(duì)列、有協(xié)議開銷且低速鏈路的串行化延遲會(huì)累積。更穩(wěn)妥的做法是把MTU降到1200傳輸時(shí)間降到150毫秒同時(shí)把keepalive間隔放寬到20秒、重試5次給足余量。MRU的協(xié)商也遵循類似邏輯。PPP的MRU默認(rèn)1500如果一端設(shè)備緩沖區(qū)小只能收1492LCP協(xié)商時(shí)就會(huì)Nak。配置上可以顯式指定ppp mru 1492讓兩端一致。這個(gè)數(shù)字不是隨便定的1492常見于某些封裝開銷較大的場(chǎng)景比如需要預(yù)留頭部空間點(diǎn)對(duì)點(diǎn)鏈路本身沒有以太網(wǎng)那種14字節(jié)頭但設(shè)備實(shí)現(xiàn)可能有差異以實(shí)際協(xié)商結(jié)果為準(zhǔn)。4.4 抓包驗(yàn)證從幀結(jié)構(gòu)確認(rèn)封裝行為模擬器里可以做端口鏡像或用內(nèi)置抓包工具。抓HDLC時(shí)重點(diǎn)看幀以7E開始結(jié)束、地址控制字段的值、FCS是否正確。抓PPP時(shí)重點(diǎn)看協(xié)議字段0xC021是LCP、0x8021是IPCP、0x0021是IP、LCP報(bào)文的Code字段1是Configure-Request、2是Ack、3是Nak、4是Reject。我習(xí)慣在認(rèn)證階段抓包能清楚看到CHAP的ChallengeCode1帶隨機(jī)數(shù)和ResponseCode2帶哈希值這比看debug輸出更直觀。抓包還有一個(gè)用處是驗(yàn)證比特填充。在HDLC信息字段里故意構(gòu)造連續(xù)多個(gè)1的數(shù)據(jù)抓包能看到發(fā)送側(cè)插入了0、接收側(cè)還原了。這個(gè)實(shí)驗(yàn)做一次比特填充就再也不會(huì)忘。5. 常見問題與排查技巧實(shí)錄5.1 鏈路起不來的分層排查法串行鏈路故障排查我遵循“從下往上”的順序每一層確認(rèn)后再往上走層級(jí)檢查項(xiàng)典型現(xiàn)象排查命令物理層線序、時(shí)鐘、接口狀態(tài)接口物理downshow interface看serial狀態(tài)二層封裝兩端封裝是否一致物理up、協(xié)議downshow interface看encapsulationLCP協(xié)商參數(shù)是否匹配LCP在Request/Nak循環(huán)debug ppp negotiation認(rèn)證名字密碼是否對(duì)應(yīng)認(rèn)證Failuredebug ppp authenticationNCP地址是否沖突IPCP不完成debug ppp negotiation三層路由、ACLping不通show ip route、show access-lists這個(gè)表是我排障時(shí)的“路線圖”。物理層down先查線別急著看配置物理up協(xié)議down八成是封裝不一致或keepalive問題LCP卡住看協(xié)商參數(shù)認(rèn)證失敗看名字密碼NCP卡住看地址。按順序走基本不會(huì)漏。5.2 五個(gè)高頻問題與解決思路問題一一端HDLC一端PPP現(xiàn)象是什么物理層up協(xié)議層down因?yàn)閮啥藥Y(jié)構(gòu)對(duì)不上收到的幀解析失敗。解決就是統(tǒng)一封裝。這個(gè)錯(cuò)誤新手常犯尤其是接手別人配置的時(shí)候。問題二CHAP認(rèn)證反復(fù)失敗但密碼確認(rèn)無誤。九成是hostname不匹配。認(rèn)證方用戶庫的用戶名必須等于被認(rèn)證方的chap hostname。另一個(gè)可能是兩端都配了authentication但只配了單向憑據(jù)導(dǎo)致雙向挑戰(zhàn)時(shí)一方?jīng)]有應(yīng)答憑據(jù)。問題三LCP協(xié)商在Configure-Request和Configure-Nak之間循環(huán)。常見原因是MRU不一致或魔術(shù)字沖突?？磀ebug輸出里Nak攜帶的建議值把兩端參數(shù)調(diào)一致。魔術(shù)字沖突通常意味著鏈路有環(huán)或配置了環(huán)回。問題四PPP鏈路頻繁up/down。低速鏈路上keepalive超時(shí)是主因調(diào)大keepalive間隔、降低MTU。另一個(gè)可能是物理線路質(zhì)量差導(dǎo)致誤碼看接口的CRC錯(cuò)誤計(jì)數(shù)持續(xù)增長就要查線路。問題五IPCP完成但ping不通。檢查兩端地址是否在同一網(wǎng)段、掩碼是否一致。點(diǎn)對(duì)點(diǎn)鏈路用/30掩碼時(shí)兩端地址必須是同一/30網(wǎng)段內(nèi)的兩個(gè)可用地址配錯(cuò)網(wǎng)段IPCP可能仍完成但三層不通。5.3 獨(dú)家避坑技巧匯總第一條跨廠商對(duì)接前先問封裝實(shí)現(xiàn)。都叫HDLC不代表兼容都叫PPP也要確認(rèn)認(rèn)證方式PAP還是CHAP和是否啟用其他擴(kuò)展選項(xiàng)。對(duì)接前把參數(shù)清單發(fā)給對(duì)方確認(rèn)比事后抓包省時(shí)間。第二條debug命令要配合日志級(jí)別和過濾。debug ppp negotiation輸出量大在現(xiàn)網(wǎng)設(shè)備上直接開可能刷屏甚至影響性能。我習(xí)慣先配logging buffered把日志存本地再開debug看完及時(shí)undebug all。模擬器里隨便開生產(chǎn)設(shè)備上務(wù)必謹(jǐn)慎。第三條配置變更前備份、變更后驗(yàn)證。串行鏈路一斷可能影響業(yè)務(wù)改封裝或認(rèn)證前先show running-config存檔改完立即驗(yàn)證line protocol和ping確認(rèn)無誤再離開。這個(gè)習(xí)慣救過我很多次。第四條理解“協(xié)商”是雙向的。LCP、IPCP、CHAP都是雙向交互只看單向狀態(tài)容易誤判。抓包時(shí)確認(rèn)兩個(gè)方向的報(bào)文都正常才算真正通了。第五條低速鏈路參數(shù)要“松”不要“緊”。keepalive間隔放寬、重試次數(shù)加多、MTU適當(dāng)降低給鏈路留余量。高速鏈路可以按默認(rèn)值走低速鏈路按默認(rèn)值往往出問題。6. 從HDLC到PPP一條鏈路上的協(xié)議演化觀察把這兩個(gè)協(xié)議放在一起學(xué)最大的收獲不是記住配置命令而是理解“標(biāo)準(zhǔn)”和“實(shí)現(xiàn)”的關(guān)系。HDLC是標(biāo)準(zhǔn)的骨架但標(biāo)準(zhǔn)留白太多廠商各填各的導(dǎo)致互操作困難PPP在HDLC基礎(chǔ)上把留白填滿——固定地址控制字段、增加協(xié)議字段、定義LCP和NCP、標(biāo)準(zhǔn)化認(rèn)證用更多的協(xié)商開銷換來了確定性。這個(gè)演化邏輯在今天的網(wǎng)絡(luò)協(xié)議里依然成立越是需要跨域協(xié)作的場(chǎng)景越需要把規(guī)則寫死、把協(xié)商做全。我在實(shí)際對(duì)接中還有一個(gè)體會(huì)排障能力取決于你對(duì)協(xié)議狀態(tài)機(jī)的熟悉程度。HDLC簡(jiǎn)單狀態(tài)少出問題無非封裝和keepalivePPP狀態(tài)多LCP、認(rèn)證、NCP三個(gè)階段每個(gè)階段都有獨(dú)立的失敗模式但正因?yàn)闋顟B(tài)清晰反而更容易定位——看卡在哪個(gè)階段就知道問題在哪一層。這種“用狀態(tài)機(jī)思維排障”的方法比死記命令有用得多。最后分享一個(gè)我常做的練習(xí)在模擬器里故意制造故障——改一端封裝、配錯(cuò)CHAP名字、調(diào)不一致的MRU——然后不看答案只用debug和show命令定位。做上十幾遍這兩個(gè)協(xié)議的行為模式就刻在腦子里了。真到現(xiàn)網(wǎng)遇到鏈路不通你的排查路徑會(huì)非常清晰物理層、封裝、LCP、認(rèn)證、NCP、三層一層層往上不慌不亂。