1. 为什么今天还要聊PPP协议很多人第一次接触PPP协议是在《计算机网络》教材的“数据链路层”那一章。翻过去之后脑子里留下的印象大概就是“拨号上网用的东西”然后就没有然后了。毕竟现在家里都是光纤入户公司里跑的是以太网PPP似乎已经是一个被扫进历史角落的协议。但如果你真的做过路由器配置、搞过广域网接入、或者排查过运营商链路的故障就会发现PPP根本没有消失它只是从“你家的拨号猫”搬到了“运营商的骨干边缘”和“企业专线接入”这些你平时看不见的地方。PPP全称Point-to-Point Protocol中文叫点对点协议。它解决的核心问题非常朴素两个设备之间用一根线或者一条逻辑链路连起来怎么可靠地传数据。注意这里的关键词是“点对点”不是以太网那种“一根总线挂一堆设备”的广播网络。点对点链路的拓扑极其简单就两端没有第三方偷听也不需要复杂的MAC地址寻址。但简单不代表好做因为底层物理介质千差万别——可能是串口线、可能是光猫背后的DSL链路、可能是运营商的SDH/OTN通道甚至可能是你手机里那条看不见的蜂窝数据通道。PPP的价值就在于它在这些五花八门的物理层之上架起了一层统一的“数据链路层”逻辑让上层IP协议不用关心底下到底是什么线。这篇文章我打算从实际工程的角度把PPP协议拆开揉碎讲一遍。不是照本宣科念RFC而是把LCP、NCP、认证、链路建立流程这些核心机制结合我在路由器和专线设备上踩过的坑讲清楚它到底怎么工作、为什么这么设计、配置的时候哪些参数容易翻车。如果你正在学计算机网络、准备网络工程师考试、或者刚接手一条广域网链路需要调试这篇内容应该能帮你省下不少翻文档的时间。2. PPP协议的整体设计思路拆解2.1 点对点链路到底特殊在哪里要理解PPP的设计先得理解点对点链路和以太网链路的本质区别。以太网是广播型网络一根线或者一个交换机上可能挂着几十台设备所以以太网帧必须带源MAC和目的MAC交换机要靠MAC地址表来决定往哪个口转发。点对点链路就两端A发给BB一定能收到不存在“发给谁”的问题。这就意味着PPP帧里不需要目的地址字段省下来的开销可以用来做别的事情。但点对点链路也有自己的麻烦。第一物理介质不统一。串口有V.35、V.24、RS-232、RS-485等各种电气标准DSL跑在电话线上光链路跑在光纤上。PPP必须把这些差异屏蔽掉给上层一个统一的接口。第二链路质量参差不齐。电话线可能有噪声串口线可能接触不良所以PPP需要一套机制来检测链路状态、协商参数、甚至在必要时做认证。第三一条物理链路上可能同时跑多种网络层协议比如IP和IPX虽然IPX现在基本绝迹了PPP需要能区分这些协议并且为每种协议独立协商配置。PPP的解决方案是分层。最底下是物理层PPP不定义你用什么线都行。往上是PPP自己的帧格式负责把数据封装成帧、做差错检测。再往上是一个“链路控制协议”LCP负责建立、配置、测试、关闭数据链路。LCP之上是“网络控制协议”NCP每一种网络层协议都有一个对应的NCP比如IP对应IPCPIPv6对应IPv6CP。这种分层设计的好处是链路层的建立和网络层的配置完全解耦。你可以先把链路建起来认证通过然后再慢慢协商IP地址、DNS地址这些参数。如果IP层协商失败链路层还可以保持方便排查问题。2.2 PPP帧格式里藏着的设计细节PPP帧的格式看起来很简单但每个字段都有讲究。一个标准的PPP帧长这样标志字段0x7E开头地址字段0xFF控制字段0x03协议字段2字节信息字段可变长FCS校验2或4字节最后又是标志字段0x7E结尾。地址字段固定是0xFF控制字段固定是0x03。这两个字段在PPP里其实是“历史遗留”因为HDLC高级数据链路控制协议里有地址和控制字段PPP从HDLC借了帧格式但点对点链路不需要地址所以固定填死。你在抓包的时候看到这两个字节不用管它们不携带任何信息。协议字段才是关键。它标识信息字段里装的是什么。0x0021表示IPv40x0057表示IPv60xC021表示LCP0x8021表示IPCP0xC023表示PAP认证0xC223表示CHAP认证。接收方看到协议字段就知道该把数据交给哪个上层模块处理。这个设计非常灵活新增一种网络层协议只需要分配一个新的协议号不需要改帧格式。信息字段的长度默认最大1500字节这个值叫MRUMaximum Receive Unit和以太网的MTU概念类似。但PPP的MRU是可以协商的LCP阶段双方可以谈一个更大的值比如9000字节的巨帧。不过实际工程中运营商链路通常不会让你改因为中间可能经过一些老设备MRU太大容易分片或者丢包。FCS字段用的是CRC校验2字节的CRC-16或者4字节的CRC-32。默认是2字节但在高质量链路上可以协商用4字节降低漏检概率。我实测下来普通串口链路2字节够用但如果是误码率较高的无线链路4字节更稳妥。还有一个细节是“字节填充”。因为0x7E是帧的起始和结束标志如果信息字段里恰好出现了0x7E接收方会误以为帧结束了。PPP的解决办法是转义把信息字段里的0x7E替换成0x7D 0x5E把0x7D替换成0x7D 0x5D。这个操作叫“字节填充”或者“转义”。同步链路比如SONET/SDH用的是比特填充规则不一样但目的相同。你在调试的时候如果看到抓包工具里显示了一堆0x7D不用慌那是正常的转义字符。2.3 LCP和NCP的分工为什么这么设计LCP和NCP的分工是PPP最精妙的地方。LCP负责链路层的“生老病死”建立链路、协商链路层参数、认证、监测链路质量、关闭链路。NCP负责网络层的“柴米油盐”协商IP地址、DNS地址、压缩方式等等。为什么要把这两件事分开因为链路层和网络层的生命周期不一样。一条物理链路可能一直存在但上面的IP会话可能断断续续。比如你家里的宽带物理链路DSL同步可能一直保持着但PPPoE会话可能因为运营商侧的问题断掉。如果链路层和网络层耦合在一起每次IP会话断开都要重新建立物理链路效率太低。分开之后LCP保持链路IPCP可以独立重新协商用户体验好很多。另一个原因是多协议支持。一条PPP链路上可以同时跑IPv4和IPv6甚至还有MPLS。每种协议有自己的NCP互不干扰。IPv4的IPCP协商失败不影响IPv6的IPv6CP也不影响链路层本身。这种设计在运营商骨干网上非常重要因为一条链路上可能承载多种业务不能因为一种业务出问题就全盘瘫痪。LCP的报文类型主要有几种Configure-Request、Configure-Ack、Configure-Nak、Configure-Reject、Terminate-Request、Terminate-Ack、Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply、Discard-Request。这些报文的名字看起来很学术但实际用起来就是“我提议这些参数”“同意”“不同意我建议改成这样”“这个参数我不认识换一个”“我要关闭链路了”“收到关闭”。你在路由器上开debug ppp negotiation看到的就是这些报文在来回飞。3. LCP协商与认证的实操细节3.1 LCP链路建立的三次握手过程LCP的链路建立过程本质上是一个参数协商过程。发起方通常是拨号方或者客户端发送Configure-Request里面包含一系列配置选项比如最大接收单元MRU、认证协议、魔术字Magic Number、压缩方式等。接收方收到后逐项检查。如果所有选项都认识并且值可以接受就回Configure-Ack链路进入Opened状态。如果有选项不认识回Configure-Reject发起方去掉这些选项后重发。如果有选项认识但值不接受比如MRU太大回Configure-Nak并附上建议的值发起方调整后重发。这个过程可能来回好几次直到双方达成一致。我在实际调试中见过最极端的情况来回协商了七八次才成功原因是两端的MRU和认证方式配置不匹配。所以配置PPP的时候两端的参数最好提前对齐别指望自动协商能解决一切。有一个细节值得注意LCP协商是有超时和重传机制的。默认情况下Configure-Request发出后如果3秒没收到回应会重传最多重传10次。如果10次都没回应链路建立失败。这个超时时间可以调但在运营商链路上通常不建议改因为改大了故障恢复慢改小了容易误判。魔术字Magic Number是LCP的一个可选选项用来检测链路环回。发起方生成一个随机数放在Configure-Request里如果收到的Configure-Ack里的魔术字和自己发出去的一样说明链路可能环回了自己的包绕了一圈又回来了。这个机制在串口线接错或者运营商侧环回测试的时候特别有用。我遇到过好几次“链路看起来通了但就是不通”的情况最后发现是运营商侧做了环回魔术字检测直接暴露了问题。3.2 PAP和CHAP认证的取舍与配置PPP支持两种认证协议PAPPassword Authentication Protocol和CHAPChallenge Handshake Authentication Protocol。PAP是明文传输用户名和密码安全性差但配置简单。CHAP是挑战-响应机制密码不在链路上传输安全性好但配置稍微复杂一点。PAP的流程很简单认证方发送Authenticate-Request里面带用户名和密码。被认证方收到后检查数据库如果匹配就回Authenticate-Ack否则回Authenticate-Nak。整个过程密码是明文抓包就能看到。所以PAP只适合在绝对可信的链路上用比如实验室环境或者两台设备直连的背靠背测试。生产环境千万别用PAP除非上层已经有加密隧道保护。CHAP的流程稍微绕一点。认证方先发一个Challenge里面包含一个随机数和自己的主机名。被认证方收到后用这个随机数加上自己的密码做一个MD5哈希然后把哈希值和自己的主机名发回去。认证方收到后用同样的随机数和数据库里存的密码做MD5对比哈希值。如果一致就认证通过。整个过程密码不在链路上出现即使被抓包也拿不到明文密码。CHAP还有一个变种叫MS-CHAP是微软的扩展版本支持双向认证和密码修改。在Windows的拨号连接和某些运营商的PPPoE认证里会用到。MS-CHAPv2的安全性比标准CHAP好一些但历史上也有过漏洞不过在日常使用中够用了。配置CHAP的时候有一个坑主机名必须匹配。认证方发Challenge的时候会带自己的主机名被认证方回Response的时候也会带自己的主机名。如果两端的hostname配置不一致或者数据库里的用户名和对方的主机名对不上认证就会失败。我见过好几次“密码明明是对的但CHAP就是不过”的情况最后发现是hostname大小写或者拼写不一致。所以配置的时候建议把两端的hostname和用户名统一规划好别随手敲。3.3 认证失败后的排查思路认证失败是PPP调试中最常见的问题之一。排查的时候我一般按这个顺序来先看物理层链路是否Up时钟是否配置正确串口链路的一端必须是DCE提供时钟。再看LCPLCP是否Opened如果LCP都没起来认证根本不会开始。然后看认证报文是PAP还是CHAP报文有没有发出去有没有收到回应。如果LCP起来了但认证失败常见原因有几个用户名密码错误最常见、认证协议不匹配一端PAP一端CHAP、主机名不匹配CHAP、认证数据库没配置、或者中间有设备拦截了认证报文。我遇到过一种比较隐蔽的情况运营商侧的认证服务器挂了但LCP还能正常协商因为LCP不依赖认证服务器。这时候链路看起来是Up的但IP层就是不通因为认证没通过NCP不会开始。所以看到链路Up但业务不通别光盯着IP层先确认认证过了没有。还有一个坑是“认证超时”。CHAP的Challenge发出后如果对方在一定时间内没回Response认证方会认为失败。这个超时时间默认是3秒在跨运营商的长链路上可能不够。如果链路RTT比较大可以适当调大超时时间。但调太大也不好故障恢复慢。我一般建议设在5到10秒之间具体看链路质量。4. NCP协商与IP地址分配的实现4.1 IPCP协商IP地址的完整流程LCP和认证都通过之后链路进入Network阶段NCP开始工作。对于IPv4来说就是IPCPIP Control Protocol。IPCP的报文格式和LCP类似也是Configure-Request、Configure-Ack、Configure-Nak、Configure-Reject那一套。但IPCP协商的选项不一样主要是IP地址、DNS地址、压缩方式。IP地址协商是IPCP最核心的功能。在PPPoE拨号场景里客户端通常没有固定IP需要运营商动态分配。客户端发Configure-RequestIP地址选项填0.0.0.0表示“我不知道我的IP请你告诉我”。运营商侧的服务器收到后从地址池里选一个可用的IP回Configure-Nak里面带上分配的IP地址。客户端收到Nak后用这个IP重新发Configure-Request服务器回Configure-AckIP地址协商完成。这个过程看起来有点绕为什么不能直接Ack因为PPP的协商规则是Configure-Nak表示“你提议的值我不接受但我建议你用这个值”。服务器不能直接Ack一个0.0.0.0的地址因为那不是一个有效的IP。所以它必须用Nak把正确的地址“建议”给客户端客户端接受后再走一遍Ack流程。这个设计保证了双方对参数的理解是一致的。DNS地址协商也是类似的流程。客户端可以在Configure-Request里带上DNS选项填0.0.0.0服务器用Nak返回DNS地址。不过DNS协商不是必须的很多运营商不通过IPCP下发DNS而是通过DHCP或者手动配置。我在实际项目里见过有的客户端不支持IPCP DNS选项这时候就得手动配DNS不然域名解析不了。4.2 地址池配置与分配策略如果你在运营商侧或者企业总部侧配置PPP服务器地址池的规划就很重要。地址池是一组可用的IP地址服务器从里面分配给拨入的客户端。地址池的大小决定了同时能有多少客户端在线。如果地址池满了新的客户端拨入时会收到Nak但Nak里没有可用的IP协商就会失败。地址池的分配策略有几种先进先出、按需分配、静态绑定。先进先出就是谁先拨入谁先拿地址断开后地址回收下一个拨入的客户端可能拿到同一个地址。按需分配是根据客户端的某些属性比如用户名来分配不同的地址段。静态绑定是某个用户名永远拿同一个IP适合需要固定IP的场景。我在配置地址池的时候踩过一个坑地址池里包含了网络地址和广播地址。比如地址池是192.168.1.0/24如果不排除192.168.1.0和192.168.1.255这两个地址也可能被分配出去。网络地址和广播地址不能分配给主机分配出去会导致奇怪的连通性问题。所以配置地址池的时候一定要把这两个地址排除掉。有些设备会自动排除有些不会得手动配。还有一个坑是地址池重叠。如果两个地址池的范围有重叠同一个IP可能被分配给两个不同的客户端导致IP冲突。这种问题在大型网络里特别难排查因为冲突是间歇性的。我的建议是地址池规划的时候画个表把每个池的范围、用途、对应的接口都列清楚避免重叠。4.3 IPv6环境下的NCP变化IPv6环境下NCP变成了IPv6CP。IPv6CP的协商流程和IPCP类似但协商的选项不一样。IPv6CP主要协商接口标识符Interface Identifier而不是完整的IPv6地址。因为IPv6的地址是128位太长不适合在IPCP这种报文里传。IPv6CP只协商低64位的接口标识符高64位的网络前缀通过路由器通告RA或者DHCPv6来获取。这个设计的原因是IPv6的地址自动配置机制。链路本地地址fe80::/10是设备自己生成的不需要协商。全局地址的前缀由运营商或上游路由器通过RA下发接口标识符由IPv6CP协商。这样分工明确效率更高。在实际配置中IPv6CP的调试和IPCP差不多也是看Configure-Request和Configure-Ack的来回。但IPv6CP的选项比较少通常只有接口标识符一个选项。如果IPv6CP协商失败链路层和IPv4可能还是通的只是IPv6不通。所以排查的时候要分开看别把IPv4和IPv6的问题混在一起。5. PPP在实际网络中的典型应用场景5.1 企业专线接入中的PPP配置企业专线接入是PPP最常见的生产环境应用。运营商在企业总部和分支机构之间提供一条点对点链路可能是SDH、MSTP、OTN或者以太网专线。链路两端各有一台路由器通过PPP协议建立连接跑OSPF或者BGP路由协议。这种场景下PPP的配置有几个要点。第一认证方式通常用CHAP因为专线虽然相对可信但多一层认证多一层保障。第二IP地址通常是静态配置的不需要IPCP动态分配因为企业专线的地址是规划好的。第三MRU和MTU要对齐避免分片。运营商的专线设备可能对MTU有限制如果企业侧的路由器MTU设得太大大包会被丢弃导致某些应用比如HTTPS时通时不通。我参与过一个项目企业总部和分支之间走MSTP专线两端路由器配PPP。调试的时候发现ping小包通ping大包不通。排查了半天最后发现是MTU问题。运营商侧的MTU是1500企业侧路由器配了1520大包被运营商设备丢弃了。把MTU改成1500之后问题解决。这个坑很典型专线调试的时候一定要确认两端的MTU和MRU一致。5.2 拨号备份链路的配置要点拨号备份是PPP的另一个经典应用。主链路比如专线或者光纤正常的时候备份链路不工作。主链路故障的时候路由器自动拨号建立PPP连接通过备份链路保持业务不中断。主链路恢复后备份链路自动断开。这种场景下PPP的配置要点是“按需拨号”Dial-on-Demand RoutingDDR。DDR的核心是定义“感兴趣流量”只有感兴趣流量才能触发拨号。比如你可以配置只有去往总部网段的流量才触发拨号去往互联网的流量不触发。这样可以避免备份链路被无关流量占满。DDR还有一个关键参数是“空闲超时”。如果备份链路建立后一段时间内没有感兴趣流量链路会自动断开节省费用。这个超时时间默认是120秒可以根据实际需求调整。我见过有的项目把超时设得太短导致链路频繁建立和断开反而增加了故障率。一般建议设在300秒左右既能节省费用又不会太频繁。拨号备份的认证通常用CHAP因为备份链路可能经过公共网络安全性要求更高。配置的时候要注意主链路和备份链路的认证配置要分开别混在一起。我见过有人把主链路的CHAP配置复制到备份链路结果主机名对不上备份链路一直认证失败。主链路故障的时候备份链路起不来业务中断了好几个小时才发现。5.3 运营商PPPoE接入的底层逻辑虽然PPPoEPPP over Ethernet严格来说不是纯PPP但它的核心还是PPP。PPPoE把PPP帧封装在以太网帧里解决了以太网不能直接跑PPP的问题。家庭宽带拨号就是典型的PPPoE场景。PPPoE的流程分两个阶段发现阶段和会话阶段。发现阶段用PPPoE的Discovery报文客户端广播一个PADIPPPoE Active Discovery Initiation寻找接入集中器AC。AC回PADOPPPoE Active Discovery Offer客户端再发PADRPPPoE Active Discovery RequestAC回PADSPPPoE Active Discovery Session-confirmation会话建立。然后进入PPP阶段LCP、认证、IPCP依次进行。这个流程里PADI是广播的所以同一个以太网段里的所有AC都能收到。如果有多个AC客户端可能收到多个PADO它会选一个。这个机制在运营商网络里很重要因为一个小区可能有多个BRAS宽带远程接入服务器客户端需要找到正确的那个。PPPoE的MTU通常比标准以太网小因为PPPoE头占了8个字节6字节目的MAC2字节PPP协议号不对PPPoE头是6字节加上PPP协议号2字节一共8字节。所以PPPoE的MTU通常是1492而不是1500。这个细节在配置路由器的时候要注意如果MTU设成1500大包会被分片或者丢弃。很多家用路由器默认就是1492但企业级路由器可能需要手动改。6. PPP调试中的常见问题与排查技巧6.1 LCP协商卡住的排查清单LCP协商卡住是PPP调试中最常见的问题。表现是链路一直处于“LCP协商中”状态或者LCP报文发出去没有回应。排查的时候我一般按这个清单来排查项检查方法常见问题物理层查看接口状态检查时钟串口线接错DCE端没配时钟封装类型确认两端都是PPP一端PPP一端HDLC报文不识别认证配置确认认证方式和密码一端PAP一端CHAP或密码错误MRU确认两端MRU一致一端1500一端9000协商失败魔术字查看是否检测到环回运营商侧环回魔术字相同超时重传查看重传次数链路RTT大3秒超时不够这个清单我用了很多年基本上能覆盖90%的LCP问题。剩下的10%可能是设备兼容性问题比如某些老设备对LCP选项的支持不完整需要手动禁用某些选项。遇到这种情况可以在LCP配置里加上“拒绝某些选项”的命令让协商跳过不支持的选项。还有一个比较隐蔽的问题是“单向LCP”。就是A能收到B的LCP报文但B收不到A的。这种情况通常是物理层的收发有问题比如串口线的收发线序接反了或者光模块的收发光纤接反了。排查的时候可以在两端同时抓包看报文是不是只往一个方向走。如果是检查物理连接。6.2 IPCP协商失败但LCP正常的处理LCP正常但IPCP失败说明链路层和认证都没问题问题出在网络层。常见原因有几个地址池满了、IP地址冲突、DNS选项不支持、或者NCP被禁用。地址池满是最常见的。如果服务器侧的地址池只有10个地址已经有10个客户端在线第11个客户端拨入时IPCP会收到Nak但没有可用地址协商失败。排查的时候登录服务器查看地址池的使用情况。如果确实满了要么扩大地址池要么踢掉一些不活跃的会话。IP地址冲突也比较常见。如果服务器分配的IP和客户端本地配置的IP冲突或者和网络里其他设备的IP冲突IPCP协商会失败。排查的时候在客户端和服务器上分别查看IP地址确认没有冲突。我遇到过一种情况客户端的以太网口配了192.168.1.1PPP协商也分配了192.168.1.1两个接口IP冲突导致路由表混乱。这种问题在客户端设备上特别容易发生因为很多人不注意接口IP的规划。DNS选项不支持是另一个坑。有些老旧的客户端不支持IPCP的DNS选项如果服务器强制下发DNS客户端会回Configure-Reject协商失败。解决办法是在服务器侧禁用DNS选项让客户端手动配DNS。或者升级客户端软件支持DNS选项。6.3 链路震荡的根因分析与解决链路震荡是指PPP链路反复建立和断开表现为接口状态在Up和Down之间来回跳。这种问题对业务影响很大因为每次断开都会导致路由重新收敛业务中断。链路震荡的根因有几个物理层不稳定线缆接触不良、光衰太大、LCP Keepalive超时、认证超时、或者NCP协商失败后链路被关闭。排查的时候先看日志确认链路断开的原因。如果是物理层问题检查线缆和光模块。如果是LCP Keepalive超时可能是链路质量差报文丢失严重可以调大Keepalive的超时时间。我遇到过一次比较典型的链路震荡原因是运营商的设备在做主备切换每次切换都会导致PPP链路断开重连。这种问题客户端侧解决不了只能联系运营商。但客户端可以做的是配置“震荡抑制”比如链路断开后等待一段时间再重连避免频繁重连加重运营商设备的负担。还有一个坑是“认证超时导致的震荡”。CHAP认证的超时时间默认是3秒如果链路RTT比较大认证报文可能超时导致认证失败链路被关闭。然后客户端重拨又超时又失败形成震荡。解决办法是调大认证超时时间或者优化链路质量降低RTT。6.4 抓包分析PPP报文的实用技巧抓包是调试PPP最有效的手段。但PPP的抓包和以太网抓包不太一样因为PPP没有MAC地址抓包工具需要能解析PPP帧。Wireshark支持PPP解析但需要正确的链路层封装类型。在串口链路上抓包通常用“PPP”或者“PPP over HDLC”封装。在PPPoE链路上抓包用“PPPoE”封装。抓包的时候我一般先过滤LCP和IPCP报文看协商过程。Wireshark的过滤器可以写“ppp”或者“lcp”或者“ipcp”。看协商过程的时候重点关注Configure-Request和Configure-Ack/Nak/Reject的对应关系。如果发了Request没收到任何回应说明对端没收到或者没处理。如果收到了Nak看Nak里建议的值是什么和本端配置对比。还有一个技巧是看“魔术字”。如果两端的魔术字相同说明链路可能环回了。Wireshark里可以直接看到魔术字的值。如果发现魔术字相同检查物理连接看是不是有环回。抓包的时候要注意PPP的字节填充会让报文看起来有点乱。Wireshark会自动解转义但有时候解得不完整。如果看到奇怪的0x7D字符手动检查一下是不是转义问题。另外PPP的FCS字段Wireshark默认会校验如果FCS错误报文会被标记为“Bad FCS”。如果大量报文FCS错误说明链路质量有问题检查线缆或者光衰。7. 个人实操经验与配置建议7.1 配置PPP时容易忽略的参数配置PPP的时候有几个参数容易被忽略但影响很大。第一个是“Keepalive”。PPP的Keepalive是通过LCP Echo-Request和Echo-Reply实现的用来检测链路是否还活着。默认情况下Keepalive是开启的间隔10秒超时3次认为链路断开。如果链路质量差Keepalive报文可能丢失导致误判断开。这时候可以调大Keepalive的间隔和超时次数比如间隔30秒超时5次。第二个是“MRU”。MRU是最大接收单元默认1500。如果链路对端的MRU比较小比如1492PPPoE场景本端发的大包会被丢弃。所以配置的时候要确认两端的MRU一致。如果不一致LCP协商的时候会Nak但有些设备不处理Nak直接忽略导致大包不通。第三个是“认证超时”。前面提过CHAP的认证超时默认3秒跨运营商链路可能不够。建议根据链路RTT调整一般RTT小于100ms的链路3秒够用。RTT大于100ms的建议调到5到10秒。第四个是“IP地址协商方式”。如果两端都是静态IPIPCP可以配置成“不协商IP地址”直接使用配置的IP。这样可以加快链路建立速度因为省去了IPCP协商的过程。但要注意如果一端协商一端不协商可能会出问题。所以两端的配置要一致。7.2 不同厂商设备的PPP兼容性处理不同厂商的设备在PPP实现上有细微差异这些差异在单厂商环境里没问题但跨厂商环境里可能导致协商失败。我遇到过几次跨厂商的PPP问题总结下来有几个常见的兼容性坑华为和华三的设备在LCP协商时默认会发送“魔术字”选项。思科的设备也支持魔术字但某些老版本的IOS默认不发送。如果一端发魔术字一端不发协商可能会失败。解决办法是在两端都启用魔术字或者都禁用。Juniper的设备在IPCP协商时默认会发送“主DNS”和“备DNS”选项。如果对端不支持DNS选项会回Configure-Reject。Juniper收到Reject后会去掉DNS选项重发但有些设备收到Reject后直接断开链路。解决办法是在Juniper侧禁用DNS选项或者在对端启用DNS支持。还有认证协议的兼容性。有些设备默认只支持CHAP不支持PAP。如果对端只支持PAP协商会失败。解决办法是确认两端的认证协议支持情况选择双方都支持的协议。如果实在不行可以在中间加一个认证转换设备但这种情况很少见。7.3 从零搭建PPP链路的完整步骤如果你要从零搭建一条PPP链路我建议按这个步骤来物理层准备确认线缆类型和接口类型匹配。串口链路要确认DCE和DTE端DCE端配时钟。光链路要确认光模块类型和光衰。配置接口封装两端接口都配置encapsulation ppp。如果是串口还要配置时钟频率DCE端。配置LCP参数配置MRU、魔术字、Keepalive。建议两端参数一致。配置认证选择PAP或CHAP配置用户名和密码。CHAP还要配置主机名。配置IP地址静态IP直接配动态IP配置IPCP协商。如果不需要动态分配可以禁用IPCP。测试链路先看LCP是否Opened再看认证是否通过最后看IPCP是否Opened。每一步都确认后再进行下一步。业务验证ping对端IP跑路由协议验证业务流量。这个步骤看起来简单但每一步都有细节。比如第3步的MRU如果不一致LCP协商会Nak但有些设备不处理Nak直接忽略导致大包不通。所以配置的时候要仔细别跳过任何一步。7.4 长期维护PPP链路的注意事项PPP链路建好之后长期维护也很重要。我一般建议做这几件事第一定期检查链路状态和日志。PPP链路可能会因为各种原因断开重连如果频繁发生说明有问题。日志里会记录断开的原因比如“LCP Keepalive timeout”或者“CHAP authentication failed”。根据日志排查根因。第二监控链路质量。PPP的LCP Echo-Request和Echo-Reply可以用来测量链路RTT和丢包率。如果RTT突然增大或者丢包率上升说明链路质量下降可能需要联系运营商。第三备份配置。PPP的配置涉及很多参数如果设备故障需要更换没有备份配置会很麻烦。建议把配置导出保存最好定期更新。第四关注运营商侧的变更。运营商可能会调整链路参数比如MTU、认证方式、地址池。这些变更可能导致PPP链路异常。如果发现链路突然不通先确认运营商侧有没有变更。第五定期测试备份链路。如果配置了拨号备份定期手动触发备份链路确认备份链路能正常工作。我见过很多项目备份链路配了但从来没测试过真正需要的时候发现备份链路起不来业务中断了好几个小时。PPP协议虽然老但它在广域网接入领域的地位短期内不会被动摇。理解PPP的工作原理和调试方法对网络工程师来说是一项基本功。希望这篇内容能帮你少踩一些坑调试的时候更有底气。 PPP协议深度解析：从LCP协商到NCP配置的工程实践指南
1. 为什么今天还要聊PPP协议很多人第一次接触PPP协议是在《计算机网络》教材的“数据链路层”那一章。翻过去之后脑子里留下的印象大概就是“拨号上网用的东西”然后就没有然后了。毕竟现在家里都是光纤入户公司里跑的是以太网PPP似乎已经是一个被扫进历史角落的协议。但如果你真的做过路由器配置、搞过广域网接入、或者排查过运营商链路的故障就会发现PPP根本没有消失它只是从“你家的拨号猫”搬到了“运营商的骨干边缘”和“企业专线接入”这些你平时看不见的地方。PPP全称Point-to-Point Protocol中文叫点对点协议。它解决的核心问题非常朴素两个设备之间用一根线或者一条逻辑链路连起来怎么可靠地传数据。注意这里的关键词是“点对点”不是以太网那种“一根总线挂一堆设备”的广播网络。点对点链路的拓扑极其简单就两端没有第三方偷听也不需要复杂的MAC地址寻址。但简单不代表好做因为底层物理介质千差万别——可能是串口线、可能是光猫背后的DSL链路、可能是运营商的SDH/OTN通道甚至可能是你手机里那条看不见的蜂窝数据通道。PPP的价值就在于它在这些五花八门的物理层之上架起了一层统一的“数据链路层”逻辑让上层IP协议不用关心底下到底是什么线。这篇文章我打算从实际工程的角度把PPP协议拆开揉碎讲一遍。不是照本宣科念RFC而是把LCP、NCP、认证、链路建立流程这些核心机制结合我在路由器和专线设备上踩过的坑讲清楚它到底怎么工作、为什么这么设计、配置的时候哪些参数容易翻车。如果你正在学计算机网络、准备网络工程师考试、或者刚接手一条广域网链路需要调试这篇内容应该能帮你省下不少翻文档的时间。2. PPP协议的整体设计思路拆解2.1 点对点链路到底特殊在哪里要理解PPP的设计先得理解点对点链路和以太网链路的本质区别。以太网是广播型网络一根线或者一个交换机上可能挂着几十台设备所以以太网帧必须带源MAC和目的MAC交换机要靠MAC地址表来决定往哪个口转发。点对点链路就两端A发给BB一定能收到不存在“发给谁”的问题。这就意味着PPP帧里不需要目的地址字段省下来的开销可以用来做别的事情。但点对点链路也有自己的麻烦。第一物理介质不统一。串口有V.35、V.24、RS-232、RS-485等各种电气标准DSL跑在电话线上光链路跑在光纤上。PPP必须把这些差异屏蔽掉给上层一个统一的接口。第二链路质量参差不齐。电话线可能有噪声串口线可能接触不良所以PPP需要一套机制来检测链路状态、协商参数、甚至在必要时做认证。第三一条物理链路上可能同时跑多种网络层协议比如IP和IPX虽然IPX现在基本绝迹了PPP需要能区分这些协议并且为每种协议独立协商配置。PPP的解决方案是分层。最底下是物理层PPP不定义你用什么线都行。往上是PPP自己的帧格式负责把数据封装成帧、做差错检测。再往上是一个“链路控制协议”LCP负责建立、配置、测试、关闭数据链路。LCP之上是“网络控制协议”NCP每一种网络层协议都有一个对应的NCP比如IP对应IPCPIPv6对应IPv6CP。这种分层设计的好处是链路层的建立和网络层的配置完全解耦。你可以先把链路建起来认证通过然后再慢慢协商IP地址、DNS地址这些参数。如果IP层协商失败链路层还可以保持方便排查问题。2.2 PPP帧格式里藏着的设计细节PPP帧的格式看起来很简单但每个字段都有讲究。一个标准的PPP帧长这样标志字段0x7E开头地址字段0xFF控制字段0x03协议字段2字节信息字段可变长FCS校验2或4字节最后又是标志字段0x7E结尾。地址字段固定是0xFF控制字段固定是0x03。这两个字段在PPP里其实是“历史遗留”因为HDLC高级数据链路控制协议里有地址和控制字段PPP从HDLC借了帧格式但点对点链路不需要地址所以固定填死。你在抓包的时候看到这两个字节不用管它们不携带任何信息。协议字段才是关键。它标识信息字段里装的是什么。0x0021表示IPv40x0057表示IPv60xC021表示LCP0x8021表示IPCP0xC023表示PAP认证0xC223表示CHAP认证。接收方看到协议字段就知道该把数据交给哪个上层模块处理。这个设计非常灵活新增一种网络层协议只需要分配一个新的协议号不需要改帧格式。信息字段的长度默认最大1500字节这个值叫MRUMaximum Receive Unit和以太网的MTU概念类似。但PPP的MRU是可以协商的LCP阶段双方可以谈一个更大的值比如9000字节的巨帧。不过实际工程中运营商链路通常不会让你改因为中间可能经过一些老设备MRU太大容易分片或者丢包。FCS字段用的是CRC校验2字节的CRC-16或者4字节的CRC-32。默认是2字节但在高质量链路上可以协商用4字节降低漏检概率。我实测下来普通串口链路2字节够用但如果是误码率较高的无线链路4字节更稳妥。还有一个细节是“字节填充”。因为0x7E是帧的起始和结束标志如果信息字段里恰好出现了0x7E接收方会误以为帧结束了。PPP的解决办法是转义把信息字段里的0x7E替换成0x7D 0x5E把0x7D替换成0x7D 0x5D。这个操作叫“字节填充”或者“转义”。同步链路比如SONET/SDH用的是比特填充规则不一样但目的相同。你在调试的时候如果看到抓包工具里显示了一堆0x7D不用慌那是正常的转义字符。2.3 LCP和NCP的分工为什么这么设计LCP和NCP的分工是PPP最精妙的地方。LCP负责链路层的“生老病死”建立链路、协商链路层参数、认证、监测链路质量、关闭链路。NCP负责网络层的“柴米油盐”协商IP地址、DNS地址、压缩方式等等。为什么要把这两件事分开因为链路层和网络层的生命周期不一样。一条物理链路可能一直存在但上面的IP会话可能断断续续。比如你家里的宽带物理链路DSL同步可能一直保持着但PPPoE会话可能因为运营商侧的问题断掉。如果链路层和网络层耦合在一起每次IP会话断开都要重新建立物理链路效率太低。分开之后LCP保持链路IPCP可以独立重新协商用户体验好很多。另一个原因是多协议支持。一条PPP链路上可以同时跑IPv4和IPv6甚至还有MPLS。每种协议有自己的NCP互不干扰。IPv4的IPCP协商失败不影响IPv6的IPv6CP也不影响链路层本身。这种设计在运营商骨干网上非常重要因为一条链路上可能承载多种业务不能因为一种业务出问题就全盘瘫痪。LCP的报文类型主要有几种Configure-Request、Configure-Ack、Configure-Nak、Configure-Reject、Terminate-Request、Terminate-Ack、Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply、Discard-Request。这些报文的名字看起来很学术但实际用起来就是“我提议这些参数”“同意”“不同意我建议改成这样”“这个参数我不认识换一个”“我要关闭链路了”“收到关闭”。你在路由器上开debug ppp negotiation看到的就是这些报文在来回飞。3. LCP协商与认证的实操细节3.1 LCP链路建立的三次握手过程LCP的链路建立过程本质上是一个参数协商过程。发起方通常是拨号方或者客户端发送Configure-Request里面包含一系列配置选项比如最大接收单元MRU、认证协议、魔术字Magic Number、压缩方式等。接收方收到后逐项检查。如果所有选项都认识并且值可以接受就回Configure-Ack链路进入Opened状态。如果有选项不认识回Configure-Reject发起方去掉这些选项后重发。如果有选项认识但值不接受比如MRU太大回Configure-Nak并附上建议的值发起方调整后重发。这个过程可能来回好几次直到双方达成一致。我在实际调试中见过最极端的情况来回协商了七八次才成功原因是两端的MRU和认证方式配置不匹配。所以配置PPP的时候两端的参数最好提前对齐别指望自动协商能解决一切。有一个细节值得注意LCP协商是有超时和重传机制的。默认情况下Configure-Request发出后如果3秒没收到回应会重传最多重传10次。如果10次都没回应链路建立失败。这个超时时间可以调但在运营商链路上通常不建议改因为改大了故障恢复慢改小了容易误判。魔术字Magic Number是LCP的一个可选选项用来检测链路环回。发起方生成一个随机数放在Configure-Request里如果收到的Configure-Ack里的魔术字和自己发出去的一样说明链路可能环回了自己的包绕了一圈又回来了。这个机制在串口线接错或者运营商侧环回测试的时候特别有用。我遇到过好几次“链路看起来通了但就是不通”的情况最后发现是运营商侧做了环回魔术字检测直接暴露了问题。3.2 PAP和CHAP认证的取舍与配置PPP支持两种认证协议PAPPassword Authentication Protocol和CHAPChallenge Handshake Authentication Protocol。PAP是明文传输用户名和密码安全性差但配置简单。CHAP是挑战-响应机制密码不在链路上传输安全性好但配置稍微复杂一点。PAP的流程很简单认证方发送Authenticate-Request里面带用户名和密码。被认证方收到后检查数据库如果匹配就回Authenticate-Ack否则回Authenticate-Nak。整个过程密码是明文抓包就能看到。所以PAP只适合在绝对可信的链路上用比如实验室环境或者两台设备直连的背靠背测试。生产环境千万别用PAP除非上层已经有加密隧道保护。CHAP的流程稍微绕一点。认证方先发一个Challenge里面包含一个随机数和自己的主机名。被认证方收到后用这个随机数加上自己的密码做一个MD5哈希然后把哈希值和自己的主机名发回去。认证方收到后用同样的随机数和数据库里存的密码做MD5对比哈希值。如果一致就认证通过。整个过程密码不在链路上出现即使被抓包也拿不到明文密码。CHAP还有一个变种叫MS-CHAP是微软的扩展版本支持双向认证和密码修改。在Windows的拨号连接和某些运营商的PPPoE认证里会用到。MS-CHAPv2的安全性比标准CHAP好一些但历史上也有过漏洞不过在日常使用中够用了。配置CHAP的时候有一个坑主机名必须匹配。认证方发Challenge的时候会带自己的主机名被认证方回Response的时候也会带自己的主机名。如果两端的hostname配置不一致或者数据库里的用户名和对方的主机名对不上认证就会失败。我见过好几次“密码明明是对的但CHAP就是不过”的情况最后发现是hostname大小写或者拼写不一致。所以配置的时候建议把两端的hostname和用户名统一规划好别随手敲。3.3 认证失败后的排查思路认证失败是PPP调试中最常见的问题之一。排查的时候我一般按这个顺序来先看物理层链路是否Up时钟是否配置正确串口链路的一端必须是DCE提供时钟。再看LCPLCP是否Opened如果LCP都没起来认证根本不会开始。然后看认证报文是PAP还是CHAP报文有没有发出去有没有收到回应。如果LCP起来了但认证失败常见原因有几个用户名密码错误最常见、认证协议不匹配一端PAP一端CHAP、主机名不匹配CHAP、认证数据库没配置、或者中间有设备拦截了认证报文。我遇到过一种比较隐蔽的情况运营商侧的认证服务器挂了但LCP还能正常协商因为LCP不依赖认证服务器。这时候链路看起来是Up的但IP层就是不通因为认证没通过NCP不会开始。所以看到链路Up但业务不通别光盯着IP层先确认认证过了没有。还有一个坑是“认证超时”。CHAP的Challenge发出后如果对方在一定时间内没回Response认证方会认为失败。这个超时时间默认是3秒在跨运营商的长链路上可能不够。如果链路RTT比较大可以适当调大超时时间。但调太大也不好故障恢复慢。我一般建议设在5到10秒之间具体看链路质量。4. NCP协商与IP地址分配的实现4.1 IPCP协商IP地址的完整流程LCP和认证都通过之后链路进入Network阶段NCP开始工作。对于IPv4来说就是IPCPIP Control Protocol。IPCP的报文格式和LCP类似也是Configure-Request、Configure-Ack、Configure-Nak、Configure-Reject那一套。但IPCP协商的选项不一样主要是IP地址、DNS地址、压缩方式。IP地址协商是IPCP最核心的功能。在PPPoE拨号场景里客户端通常没有固定IP需要运营商动态分配。客户端发Configure-RequestIP地址选项填0.0.0.0表示“我不知道我的IP请你告诉我”。运营商侧的服务器收到后从地址池里选一个可用的IP回Configure-Nak里面带上分配的IP地址。客户端收到Nak后用这个IP重新发Configure-Request服务器回Configure-AckIP地址协商完成。这个过程看起来有点绕为什么不能直接Ack因为PPP的协商规则是Configure-Nak表示“你提议的值我不接受但我建议你用这个值”。服务器不能直接Ack一个0.0.0.0的地址因为那不是一个有效的IP。所以它必须用Nak把正确的地址“建议”给客户端客户端接受后再走一遍Ack流程。这个设计保证了双方对参数的理解是一致的。DNS地址协商也是类似的流程。客户端可以在Configure-Request里带上DNS选项填0.0.0.0服务器用Nak返回DNS地址。不过DNS协商不是必须的很多运营商不通过IPCP下发DNS而是通过DHCP或者手动配置。我在实际项目里见过有的客户端不支持IPCP DNS选项这时候就得手动配DNS不然域名解析不了。4.2 地址池配置与分配策略如果你在运营商侧或者企业总部侧配置PPP服务器地址池的规划就很重要。地址池是一组可用的IP地址服务器从里面分配给拨入的客户端。地址池的大小决定了同时能有多少客户端在线。如果地址池满了新的客户端拨入时会收到Nak但Nak里没有可用的IP协商就会失败。地址池的分配策略有几种先进先出、按需分配、静态绑定。先进先出就是谁先拨入谁先拿地址断开后地址回收下一个拨入的客户端可能拿到同一个地址。按需分配是根据客户端的某些属性比如用户名来分配不同的地址段。静态绑定是某个用户名永远拿同一个IP适合需要固定IP的场景。我在配置地址池的时候踩过一个坑地址池里包含了网络地址和广播地址。比如地址池是192.168.1.0/24如果不排除192.168.1.0和192.168.1.255这两个地址也可能被分配出去。网络地址和广播地址不能分配给主机分配出去会导致奇怪的连通性问题。所以配置地址池的时候一定要把这两个地址排除掉。有些设备会自动排除有些不会得手动配。还有一个坑是地址池重叠。如果两个地址池的范围有重叠同一个IP可能被分配给两个不同的客户端导致IP冲突。这种问题在大型网络里特别难排查因为冲突是间歇性的。我的建议是地址池规划的时候画个表把每个池的范围、用途、对应的接口都列清楚避免重叠。4.3 IPv6环境下的NCP变化IPv6环境下NCP变成了IPv6CP。IPv6CP的协商流程和IPCP类似但协商的选项不一样。IPv6CP主要协商接口标识符Interface Identifier而不是完整的IPv6地址。因为IPv6的地址是128位太长不适合在IPCP这种报文里传。IPv6CP只协商低64位的接口标识符高64位的网络前缀通过路由器通告RA或者DHCPv6来获取。这个设计的原因是IPv6的地址自动配置机制。链路本地地址fe80::/10是设备自己生成的不需要协商。全局地址的前缀由运营商或上游路由器通过RA下发接口标识符由IPv6CP协商。这样分工明确效率更高。在实际配置中IPv6CP的调试和IPCP差不多也是看Configure-Request和Configure-Ack的来回。但IPv6CP的选项比较少通常只有接口标识符一个选项。如果IPv6CP协商失败链路层和IPv4可能还是通的只是IPv6不通。所以排查的时候要分开看别把IPv4和IPv6的问题混在一起。5. PPP在实际网络中的典型应用场景5.1 企业专线接入中的PPP配置企业专线接入是PPP最常见的生产环境应用。运营商在企业总部和分支机构之间提供一条点对点链路可能是SDH、MSTP、OTN或者以太网专线。链路两端各有一台路由器通过PPP协议建立连接跑OSPF或者BGP路由协议。这种场景下PPP的配置有几个要点。第一认证方式通常用CHAP因为专线虽然相对可信但多一层认证多一层保障。第二IP地址通常是静态配置的不需要IPCP动态分配因为企业专线的地址是规划好的。第三MRU和MTU要对齐避免分片。运营商的专线设备可能对MTU有限制如果企业侧的路由器MTU设得太大大包会被丢弃导致某些应用比如HTTPS时通时不通。我参与过一个项目企业总部和分支之间走MSTP专线两端路由器配PPP。调试的时候发现ping小包通ping大包不通。排查了半天最后发现是MTU问题。运营商侧的MTU是1500企业侧路由器配了1520大包被运营商设备丢弃了。把MTU改成1500之后问题解决。这个坑很典型专线调试的时候一定要确认两端的MTU和MRU一致。5.2 拨号备份链路的配置要点拨号备份是PPP的另一个经典应用。主链路比如专线或者光纤正常的时候备份链路不工作。主链路故障的时候路由器自动拨号建立PPP连接通过备份链路保持业务不中断。主链路恢复后备份链路自动断开。这种场景下PPP的配置要点是“按需拨号”Dial-on-Demand RoutingDDR。DDR的核心是定义“感兴趣流量”只有感兴趣流量才能触发拨号。比如你可以配置只有去往总部网段的流量才触发拨号去往互联网的流量不触发。这样可以避免备份链路被无关流量占满。DDR还有一个关键参数是“空闲超时”。如果备份链路建立后一段时间内没有感兴趣流量链路会自动断开节省费用。这个超时时间默认是120秒可以根据实际需求调整。我见过有的项目把超时设得太短导致链路频繁建立和断开反而增加了故障率。一般建议设在300秒左右既能节省费用又不会太频繁。拨号备份的认证通常用CHAP因为备份链路可能经过公共网络安全性要求更高。配置的时候要注意主链路和备份链路的认证配置要分开别混在一起。我见过有人把主链路的CHAP配置复制到备份链路结果主机名对不上备份链路一直认证失败。主链路故障的时候备份链路起不来业务中断了好几个小时才发现。5.3 运营商PPPoE接入的底层逻辑虽然PPPoEPPP over Ethernet严格来说不是纯PPP但它的核心还是PPP。PPPoE把PPP帧封装在以太网帧里解决了以太网不能直接跑PPP的问题。家庭宽带拨号就是典型的PPPoE场景。PPPoE的流程分两个阶段发现阶段和会话阶段。发现阶段用PPPoE的Discovery报文客户端广播一个PADIPPPoE Active Discovery Initiation寻找接入集中器AC。AC回PADOPPPoE Active Discovery Offer客户端再发PADRPPPoE Active Discovery RequestAC回PADSPPPoE Active Discovery Session-confirmation会话建立。然后进入PPP阶段LCP、认证、IPCP依次进行。这个流程里PADI是广播的所以同一个以太网段里的所有AC都能收到。如果有多个AC客户端可能收到多个PADO它会选一个。这个机制在运营商网络里很重要因为一个小区可能有多个BRAS宽带远程接入服务器客户端需要找到正确的那个。PPPoE的MTU通常比标准以太网小因为PPPoE头占了8个字节6字节目的MAC2字节PPP协议号不对PPPoE头是6字节加上PPP协议号2字节一共8字节。所以PPPoE的MTU通常是1492而不是1500。这个细节在配置路由器的时候要注意如果MTU设成1500大包会被分片或者丢弃。很多家用路由器默认就是1492但企业级路由器可能需要手动改。6. PPP调试中的常见问题与排查技巧6.1 LCP协商卡住的排查清单LCP协商卡住是PPP调试中最常见的问题。表现是链路一直处于“LCP协商中”状态或者LCP报文发出去没有回应。排查的时候我一般按这个清单来排查项检查方法常见问题物理层查看接口状态检查时钟串口线接错DCE端没配时钟封装类型确认两端都是PPP一端PPP一端HDLC报文不识别认证配置确认认证方式和密码一端PAP一端CHAP或密码错误MRU确认两端MRU一致一端1500一端9000协商失败魔术字查看是否检测到环回运营商侧环回魔术字相同超时重传查看重传次数链路RTT大3秒超时不够这个清单我用了很多年基本上能覆盖90%的LCP问题。剩下的10%可能是设备兼容性问题比如某些老设备对LCP选项的支持不完整需要手动禁用某些选项。遇到这种情况可以在LCP配置里加上“拒绝某些选项”的命令让协商跳过不支持的选项。还有一个比较隐蔽的问题是“单向LCP”。就是A能收到B的LCP报文但B收不到A的。这种情况通常是物理层的收发有问题比如串口线的收发线序接反了或者光模块的收发光纤接反了。排查的时候可以在两端同时抓包看报文是不是只往一个方向走。如果是检查物理连接。6.2 IPCP协商失败但LCP正常的处理LCP正常但IPCP失败说明链路层和认证都没问题问题出在网络层。常见原因有几个地址池满了、IP地址冲突、DNS选项不支持、或者NCP被禁用。地址池满是最常见的。如果服务器侧的地址池只有10个地址已经有10个客户端在线第11个客户端拨入时IPCP会收到Nak但没有可用地址协商失败。排查的时候登录服务器查看地址池的使用情况。如果确实满了要么扩大地址池要么踢掉一些不活跃的会话。IP地址冲突也比较常见。如果服务器分配的IP和客户端本地配置的IP冲突或者和网络里其他设备的IP冲突IPCP协商会失败。排查的时候在客户端和服务器上分别查看IP地址确认没有冲突。我遇到过一种情况客户端的以太网口配了192.168.1.1PPP协商也分配了192.168.1.1两个接口IP冲突导致路由表混乱。这种问题在客户端设备上特别容易发生因为很多人不注意接口IP的规划。DNS选项不支持是另一个坑。有些老旧的客户端不支持IPCP的DNS选项如果服务器强制下发DNS客户端会回Configure-Reject协商失败。解决办法是在服务器侧禁用DNS选项让客户端手动配DNS。或者升级客户端软件支持DNS选项。6.3 链路震荡的根因分析与解决链路震荡是指PPP链路反复建立和断开表现为接口状态在Up和Down之间来回跳。这种问题对业务影响很大因为每次断开都会导致路由重新收敛业务中断。链路震荡的根因有几个物理层不稳定线缆接触不良、光衰太大、LCP Keepalive超时、认证超时、或者NCP协商失败后链路被关闭。排查的时候先看日志确认链路断开的原因。如果是物理层问题检查线缆和光模块。如果是LCP Keepalive超时可能是链路质量差报文丢失严重可以调大Keepalive的超时时间。我遇到过一次比较典型的链路震荡原因是运营商的设备在做主备切换每次切换都会导致PPP链路断开重连。这种问题客户端侧解决不了只能联系运营商。但客户端可以做的是配置“震荡抑制”比如链路断开后等待一段时间再重连避免频繁重连加重运营商设备的负担。还有一个坑是“认证超时导致的震荡”。CHAP认证的超时时间默认是3秒如果链路RTT比较大认证报文可能超时导致认证失败链路被关闭。然后客户端重拨又超时又失败形成震荡。解决办法是调大认证超时时间或者优化链路质量降低RTT。6.4 抓包分析PPP报文的实用技巧抓包是调试PPP最有效的手段。但PPP的抓包和以太网抓包不太一样因为PPP没有MAC地址抓包工具需要能解析PPP帧。Wireshark支持PPP解析但需要正确的链路层封装类型。在串口链路上抓包通常用“PPP”或者“PPP over HDLC”封装。在PPPoE链路上抓包用“PPPoE”封装。抓包的时候我一般先过滤LCP和IPCP报文看协商过程。Wireshark的过滤器可以写“ppp”或者“lcp”或者“ipcp”。看协商过程的时候重点关注Configure-Request和Configure-Ack/Nak/Reject的对应关系。如果发了Request没收到任何回应说明对端没收到或者没处理。如果收到了Nak看Nak里建议的值是什么和本端配置对比。还有一个技巧是看“魔术字”。如果两端的魔术字相同说明链路可能环回了。Wireshark里可以直接看到魔术字的值。如果发现魔术字相同检查物理连接看是不是有环回。抓包的时候要注意PPP的字节填充会让报文看起来有点乱。Wireshark会自动解转义但有时候解得不完整。如果看到奇怪的0x7D字符手动检查一下是不是转义问题。另外PPP的FCS字段Wireshark默认会校验如果FCS错误报文会被标记为“Bad FCS”。如果大量报文FCS错误说明链路质量有问题检查线缆或者光衰。7. 个人实操经验与配置建议7.1 配置PPP时容易忽略的参数配置PPP的时候有几个参数容易被忽略但影响很大。第一个是“Keepalive”。PPP的Keepalive是通过LCP Echo-Request和Echo-Reply实现的用来检测链路是否还活着。默认情况下Keepalive是开启的间隔10秒超时3次认为链路断开。如果链路质量差Keepalive报文可能丢失导致误判断开。这时候可以调大Keepalive的间隔和超时次数比如间隔30秒超时5次。第二个是“MRU”。MRU是最大接收单元默认1500。如果链路对端的MRU比较小比如1492PPPoE场景本端发的大包会被丢弃。所以配置的时候要确认两端的MRU一致。如果不一致LCP协商的时候会Nak但有些设备不处理Nak直接忽略导致大包不通。第三个是“认证超时”。前面提过CHAP的认证超时默认3秒跨运营商链路可能不够。建议根据链路RTT调整一般RTT小于100ms的链路3秒够用。RTT大于100ms的建议调到5到10秒。第四个是“IP地址协商方式”。如果两端都是静态IPIPCP可以配置成“不协商IP地址”直接使用配置的IP。这样可以加快链路建立速度因为省去了IPCP协商的过程。但要注意如果一端协商一端不协商可能会出问题。所以两端的配置要一致。7.2 不同厂商设备的PPP兼容性处理不同厂商的设备在PPP实现上有细微差异这些差异在单厂商环境里没问题但跨厂商环境里可能导致协商失败。我遇到过几次跨厂商的PPP问题总结下来有几个常见的兼容性坑华为和华三的设备在LCP协商时默认会发送“魔术字”选项。思科的设备也支持魔术字但某些老版本的IOS默认不发送。如果一端发魔术字一端不发协商可能会失败。解决办法是在两端都启用魔术字或者都禁用。Juniper的设备在IPCP协商时默认会发送“主DNS”和“备DNS”选项。如果对端不支持DNS选项会回Configure-Reject。Juniper收到Reject后会去掉DNS选项重发但有些设备收到Reject后直接断开链路。解决办法是在Juniper侧禁用DNS选项或者在对端启用DNS支持。还有认证协议的兼容性。有些设备默认只支持CHAP不支持PAP。如果对端只支持PAP协商会失败。解决办法是确认两端的认证协议支持情况选择双方都支持的协议。如果实在不行可以在中间加一个认证转换设备但这种情况很少见。7.3 从零搭建PPP链路的完整步骤如果你要从零搭建一条PPP链路我建议按这个步骤来物理层准备确认线缆类型和接口类型匹配。串口链路要确认DCE和DTE端DCE端配时钟。光链路要确认光模块类型和光衰。配置接口封装两端接口都配置encapsulation ppp。如果是串口还要配置时钟频率DCE端。配置LCP参数配置MRU、魔术字、Keepalive。建议两端参数一致。配置认证选择PAP或CHAP配置用户名和密码。CHAP还要配置主机名。配置IP地址静态IP直接配动态IP配置IPCP协商。如果不需要动态分配可以禁用IPCP。测试链路先看LCP是否Opened再看认证是否通过最后看IPCP是否Opened。每一步都确认后再进行下一步。业务验证ping对端IP跑路由协议验证业务流量。这个步骤看起来简单但每一步都有细节。比如第3步的MRU如果不一致LCP协商会Nak但有些设备不处理Nak直接忽略导致大包不通。所以配置的时候要仔细别跳过任何一步。7.4 长期维护PPP链路的注意事项PPP链路建好之后长期维护也很重要。我一般建议做这几件事第一定期检查链路状态和日志。PPP链路可能会因为各种原因断开重连如果频繁发生说明有问题。日志里会记录断开的原因比如“LCP Keepalive timeout”或者“CHAP authentication failed”。根据日志排查根因。第二监控链路质量。PPP的LCP Echo-Request和Echo-Reply可以用来测量链路RTT和丢包率。如果RTT突然增大或者丢包率上升说明链路质量下降可能需要联系运营商。第三备份配置。PPP的配置涉及很多参数如果设备故障需要更换没有备份配置会很麻烦。建议把配置导出保存最好定期更新。第四关注运营商侧的变更。运营商可能会调整链路参数比如MTU、认证方式、地址池。这些变更可能导致PPP链路异常。如果发现链路突然不通先确认运营商侧有没有变更。第五定期测试备份链路。如果配置了拨号备份定期手动触发备份链路确认备份链路能正常工作。我见过很多项目备份链路配了但从来没测试过真正需要的时候发现备份链路起不来业务中断了好几个小时。PPP协议虽然老但它在广域网接入领域的地位短期内不会被动摇。理解PPP的工作原理和调试方法对网络工程师来说是一项基本功。希望这篇内容能帮你少踩一些坑调试的时候更有底气。