简介这是一份面向网络工程师、运维人员及计算机网络学习者的广域网协议技术资料聚焦PPP点对点协议及其扩展技术帮助读者系统理解广域网链路层通信的建立、验证与封装机制。内容涵盖PPP协议组件LCP、NCP、PAP与CHAP两种验证方式、PPP完整运行过程并延伸至多链路PPPMP的协商过程与作用以及PPPoE的Server与Client组件适合备考认证或从事宽带接入、企业远程连接相关工作的人员参考。资源包共1个PDF文件大小约341KB篇幅精炼、结构清晰便于快速查阅与打印学习。目前已有122人学习下载。资料以目录化方式组织从PPP简介、验证机制到MP与PPPoE逐层展开读者可借此掌握链路初始化、身份验证、网络层参数协商及数据传输的完整流程并理解MP如何聚合链路提升带宽与容错能力为实际网络配置与故障排查提供理论支撑。1. 广域网协议 PPP从拨号时代到以太网点对点的底层逻辑很多人第一次接触 PPP是在路由器拨号配置界面里看到encapsulation ppp这一行或者是在抓包里看到一串LCP、PAP、CHAP的交互报文却说不清它到底在干什么。广域网协议 PPPPoint-to-Point Protocol本质上是解决两个节点之间怎么可靠地传数据包这件事它把物理链路上的原始比特流整理成能承载 IP、IPX 等多种网络层协议的帧同时负责链路建立、身份认证、参数协商和错误检测。今天 PPP 并没有消失它演化出的 PPPoE 仍然是家庭宽带拨号的主流封装方式MPMultilink PPP在专线和链路聚合场景里也还有实际价值。这篇文章面向需要配置广域网链路、排查拨号故障、理解 PPPoE 认证流程的网络工程师和运维人员从帧结构讲到 PAP/CHAP 认证再落到 PPPoE 拨号和 MP 捆绑的具体配置与排错把这条链路从理论到落地讲透。2. PPP 链路建立LCP 协商、认证与 NCP 的三段式流程PPP 不是一上来就能传 IP 包的它有一套严格的状态机。理解这套流程是排查拨号拨不上认证失败链路起来了但 ping 不通这三类问题的前提。整个 PPP 链路建立可以拆成三个阶段LCP 协商、认证、NCP 协商。每个阶段失败现象和排查方向完全不同。2.1 LCP先谈好怎么说话再说话LCPLink Control Protocol是 PPP 的第一个阶段它的任务是协商链路层参数最大接收单元 MRU、认证协议类型、魔术字Magic Number用来检测环路、压缩方式等。LCP 报文本身也是 PPP 帧协议字段为 0xC021。LCP 协商的核心是 Configure-Request / Configure-Ack / Configure-Nak / Configure-Reject 这四种报文。发起方发送 Configure-Request里面列出自己希望使用的参数对端如果全部接受就回 Configure-Ack如果有参数不认可但可以协商就回 Configure-Nak带上建议值如果完全不认识某个选项就回 Configure-Reject。这个过程可能来回多次直到双方达成一致LCP 进入 Opened 状态。一个典型的 LCP 协商抓包长这样# 在 Linux 上用 tcpdump 抓 PPPoE 发现阶段的包 tcpdump -i eth0 -n -e pppoes -vv # 关注 LCP Configure-Request 里的选项 # MRU1492, Auth-ProtocolPAP, Magic-Number0x1a2b3c4d这里 MRU1492 是 PPPoE 场景的常见值因为以太网 MTU 是 1500PPPoE 头占 8 字节6 字节目的 MAC 6 字节源 MAC 不算在 PPPoE 头里实际 PPPoE 头是 6 字节加上 PPP 协议字段 2 字节共 8 字节所以 PPP 的 MRU 要减到 1492否则大包会被丢弃表现为能 ping 通小包打不开网页。注意LCP 的 Magic-Number 选项如果两端配成一样的值LCP 会认为存在环路而拒绝协商。这个坑在手工配置时偶尔会踩到。2.2 PAP 与 CHAP认证方式的选择与报文差异LCP 协商完成后如果协商结果里包含认证协议就进入认证阶段。PPP 支持两种主要认证PAPPassword Authentication Protocol和 CHAPChallenge Handshake Authentication Protocol。PAP 是明文两次握手客户端直接发用户名和密码服务端比对后回 Accept 或 Reject。抓包能直接看到密码安全性差但配置简单兼容性好。CHAP 是三次握手服务端先发一个 Challenge含随机数和 ID客户端用这个随机数加上密码做 MD5 哈希把结果发回去服务端用同样算法算一遍比对。密码不在链路上传输安全性高而且支持周期性重认证。对比项PAPCHAP握手次数2 次3 次密码传输明文MD5 哈希重认证不支持支持配置复杂度低中典型场景老旧设备兼容生产环境推荐配置 CHAP 时两端的用户名和密码必须匹配对方的配置。常见做法是本端用ppp chap password配一个密码对端用ppp chap hostname配一个用户名双方交叉对应。如果配反了现象是 LCP 能起来但 CHAP 一直失败日志里会看到CHAP authentication failed。2.3 NCP让 IP 包真正跑起来认证通过后进入 NCPNetwork Control Protocol阶段。PPP 是协议无关的它通过不同的 NCP 来承载不同的网络层协议IP 对应 IPCPIPv6 对应 IPV6CPIPX 对应 IPXCP。IPCP 的主要任务是协商 IP 地址如果一端配了ip address negotiated就会在 IPCP 里请求对端分配一个地址。IPCP 协商成功后链路才真正进入 Opened 状态可以传 IP 包了。这时候如果 ping 不通问题往往不在 PPP 本身而在路由、NAT 或对端配置。排查时先看show interface里 PPP 的状态是不是up再看 IPCP 有没有拿到地址最后才查路由。# Cisco 设备上查看 PPP 链路状态 show interface serial0/0/0 # 关注输出中的 # LCP: state is Open # IPCP: state is Open # Internet address is 10.1.1.2/30如果 LCP 是 Open 但 IPCP 一直是 Negotiation说明 IP 地址协商没成功检查两端 IP 地址是否在同一网段或者是否一端配了ip address negotiated而另一端没配地址池。3. PPPoE 拨号把 PPP 帧塞进以太网的全流程配置PPPoEPPP over Ethernet是把 PPP 帧封装在以太网帧里传输的技术家庭宽带拨号、企业专线接入大量使用。它的核心是在以太网上模拟一个点对点链路让 PPP 的状态机和认证机制能跑在共享介质上。理解 PPPoE 的两个阶段——发现阶段和会话阶段——是配置和排错的关键。3.1 PPPoE 发现阶段PADI/PADO/PADR/PADS 四步握手PPPoE 发现阶段的目标是让客户端找到服务端并建立一个 Session ID。这个过程有四步客户端广播 PADIPPPoE Active Discovery Initiation寻找可用的 PPPoE 服务端。服务端回应 PADOPPPoE Active Discovery Offer带上自己的名字和支持的服务。客户端从多个 PADO 中选一个单播发送 PADRPPPoE Active Discovery Request。服务端回应 PADSPPPoE Active Discovery Session-confirmation分配一个 Session ID发现阶段结束。发现阶段完成后双方进入会话阶段后续的 LCP、认证、IPCP 报文都封装在带 Session ID 的 PPPoE 会话帧里。抓包时发现阶段的 EtherType 是 0x8863会话阶段是 0x8864。# 用 tcpdump 抓 PPPoE 发现阶段 tcpdump -i eth0 -n -e ether proto 0x8863 -vv # 正常应该看到 PADI - PADO - PADR - PADS # 如果只看到 PADI 没有 PADO说明服务端没响应如果只看到 PADI 反复发送没有 PADO 回应常见原因有三个物理链路不通、VLAN 配置不对PPPoE 通常跑在特定 VLAN 上、服务端没启用 PPPoE 服务。排查时先确认物理口 up再确认 VLAN 封装正确最后检查服务端配置。3.2 在 Linux 上跑通 PPPoE 客户端的最小配置Linux 上用pppd配合rp-pppoe可以快速搭一个 PPPoE 客户端。下面是一个最小可用的配置# 安装 rp-pppoe以 Debian/Ubuntu 为例 apt-get install pppoe ppp # 编辑 /etc/ppp/peers/dsl-provider cat /etc/ppp/peers/dsl-provider EOF plugin rp-pppoe.so eth0 noauth persist mtu 1492 mru 1492 user your_username password your_password defaultroute usepeerdns EOF # 启动拨号 pon dsl-provider # 查看状态 plog ip addr show ppp0这里几个参数值得说明plugin rp-pppoe.so加载 PPPoE 插件让 pppd 能处理 PPPoE 帧eth0指定物理接口noauth表示不要求对端认证自己客户端通常不需要persist让链路断开后自动重连mtu 1492和mru 1492是 PPPoE 的标准值设大了会导致大包丢失defaultroute自动添加默认路由usepeerdns自动使用服务端下发的 DNS。启动后用plog看日志正常会看到 LCP、PAP/CHAP、IPCP 依次成功最后ppp0接口拿到 IP。如果卡在某个阶段日志里会有明确提示按前面讲的三个阶段对应排查即可。3.3 路由器上的 PPPoE 服务端配置与地址池如果要在 Cisco 路由器上配 PPPoE 服务端核心是配一个 BBABroadband Access组和虚拟模板# 配置本地地址池 ip local pool PPPOE_POOL 10.10.10.1 10.10.10.100 # 配置虚拟模板 interface Virtual-Template1 ip unnumbered Loopback0 peer default ip address pool PPPOE_POOL ppp authentication chap # 配置 BBA 组 bba-group pppoe MY_BBA virtual-template 1 # 在物理接口上启用 PPPoE interface GigabitEthernet0/0 no ip address pppoe enable group MY_BBA这里ip unnumbered Loopback0让虚拟模板借用 Loopback 接口的地址避免每个用户占用一个网段peer default ip address pool指定地址池ppp authentication chap要求客户端用 CHAP 认证。BBA 组把虚拟模板和物理接口关联起来物理接口收到 PPPoE 报文后交给对应的虚拟模板处理。注意ip unnumbered要求 Loopback 接口有地址且状态 up否则虚拟模板起不来。这个坑在新建 Loopback 时容易忘。4. MP 与认证排错链路捆绑和 PAP/CHAP 翻车现场MPMultilink PPP是把多条 PPP 链路捆绑成一条逻辑链路的技术用来增加带宽或做冗余。它的核心是在 LCP 协商时加上 MP 选项把多个物理链路聚合成一个 Multilink 接口。配置不难但和认证、负载分担结合时容易出问题。4.1 MP 捆绑Multilink 接口的配置与分片MP 的配置分两步先配一个 Multilink 接口再把物理接口加入这个组。# 配置 Multilink 接口 interface Multilink1 ip address 192.168.1.1 255.255.255.252 ppp multilink ppp multilink group 1 # 把物理接口加入组 interface Serial0/0/0 no ip address encapsulation ppp ppp multilink ppp multilink group 1 interface Serial0/0/1 no ip address encapsulation ppp ppp multilink ppp multilink group 1ppp multilink group 1把多个物理接口绑定到同一个组Multilink1 接口负责承载 IP 地址和上层协议。MP 会把大包分片到多条链路上传输接收端重组。分片大小由ppp multilink fragment控制不配的话默认不分片可能导致一条链路拥塞而另一条空闲。MP 的常见问题是两条链路带宽不一致时分片会导致乱序接收端重组消耗 CPU。如果链路质量差异大建议配ppp multilink interleave让小包优先或者干脆不用 MP改用路由层面的负载分担。4.2 PAP 认证失败的四个典型原因PAP 配置简单但失败率不低。下面按现象 → 原因 → 解决列四个常见坑现象一LCP 起来后立刻断开日志显示PAP authentication failed。原因用户名或密码不匹配。PAP 是明文比对大小写、空格、特殊字符都会导致失败。 解决在两端用show running-config核对ppp pap sent-username和本地用户数据库确保完全一致。注意有些设备会把密码加密显示需要重新输入确认。现象二认证成功但马上又发起新的认证。原因一端配了ppp authentication pap另一端配了ppp authentication chap协商时 LCP 选了 PAP但 CHAP 端不接受。 解决两端认证方式必须一致或者配成ppp authentication chap pap让 CHAP 优先、PAP 兜底。现象三PAP 认证通过但 IPCP 不协商。原因认证和 IP 地址分配是两回事PAP 只管身份IPCP 管地址。如果服务端没配地址池IPCP 会一直 Negotiation。 解决检查服务端peer default ip address pool或peer default ip address配置。现象四抓包看到 PAP Authenticate-Request 但没 Response。原因服务端没启用 PAP 认证或者物理链路丢包。 解决确认服务端接口下配了ppp authentication pap并用show interface看是否有 CRC 错误。4.3 CHAP 认证的隐蔽坑主机名和密码方向CHAP 比 PAP 安全但配置方向容易搞反。CHAP 的规则是本端的ppp chap hostname是对端用来认证本端的用户名本端的ppp chap password是对端用来认证本端的密码。也就是说两端的配置是交叉的。# 路由器 A 的配置 interface Serial0/0/0 encapsulation ppp ppp authentication chap ppp chap hostname RouterA ppp chap password Secret123 # 路由器 B 的配置 interface Serial0/0/1 encapsulation ppp ppp authentication chap ppp chap hostname RouterB ppp chap password Secret123如果 A 配了ppp chap hostname RouterAB 上必须有对应的本地用户username RouterA password Secret123否则 B 无法认证 A。反过来也一样。这个交叉关系是 CHAP 最容易配错的地方血泪经验是先在纸上画出两端的用户名密码对应关系再敲命令。注意CHAP 的密码在配置里是加密显示的但ppp chap password后面跟的是明文保存后会自动加密。如果复制配置时直接抄加密后的字符串可能因为加密算法不同而失败。5. 抓包验证与进阶技巧用 Wireshark 定位 PPPoE 断线配置配完了怎么确认真的跑通了最可靠的办法是抓包。PPPoE 的断线问题十有八九能在抓包里找到答案。这一章讲怎么用 Wireshark 过滤 PPPoE 报文以及几个我常用的验证技巧。5.1 Wireshark 过滤 PPPoE 的显示过滤器Wireshark 里 PPPoE 的过滤器分两层发现阶段用pppoed会话阶段用pppoes。常用过滤器过滤器作用pppoed只看发现阶段PADI/PADO/PADR/PADSpppoes只看会话阶段LCP/认证/IPCP/数据pppoes ppp.protocol 0xc021只看 LCP 报文pppoes ppp.protocol 0xc023只看 PAP 报文pppoes ppp.protocol 0xc223只看 CHAP 报文pppoes ppp.protocol 0x8021只看 IPCP 报文抓包时先看发现阶段是否完整PADI 发出后有没有 PADOPADR 发出后有没有 PADS。如果 PADS 里 Session ID 是 0说明服务端拒绝建立会话通常是资源不足或配置错误。会话阶段按 LCP → 认证 → IPCP 的顺序看哪个阶段没有对应的 Response问题就在那里。5.2 用 pppd 的 debug 日志定位协商失败Linux 上跑 pppd 时加debug选项能看到详细的协商过程# 在 /etc/ppp/peers/dsl-provider 里加 debug # 或者直接命令行启动 pppd plugin rp-pppoe.so eth0 user test password test debug dump # 日志会输出到 syslog用 journalctl 查看 journalctl -u pppd -f # 或者直接看 /var/log/syslog tail -f /var/log/syslog | grep pppddebug会打印每个 LCP、IPCP 报文的收发和选项协商结果dump会把报文内容以十六进制打印出来。如果 LCP 一直发 Configure-Request 但收不到 Ack日志里会反复出现sent [LCP ConfReq ...]说明对端没回应检查物理链路或对端配置。如果收到 Configure-Nak日志里会显示对端建议的参数按建议调整即可。5.3 一个我常用的习惯先抓包再改配置这些年排查 PPP 问题我养成了一个习惯不管多急先抓 30 秒包再动手改配置。因为 PPP 的状态机是确定的抓包里能看到完整的协商过程哪个阶段断了、对端回了什么、参数哪里不匹配一目了然。很多时候改配置是盲改改对了不知道为什么对改错了更糊涂。抓包虽然多花两分钟但能省下反复试错的时间。PPPoE 的断线尤其如此发现阶段和会话阶段的报文能直接告诉你问题在链路层还是认证层。希望这个习惯能帮到你。本文还有配套的精品资源点击获取
