PPPoE 的 MTU 与 MSS
PPPoE 在以太帧里插入了自己的封装：IPv4 报文可用的最大长度从 1500 降到 1492，另外 8 个字节被 PPPoE 头占用。链路本身能通，但如果接口 MTU 仍按 1500 配置、也没做 TCP MSS 处理，就会出现「大部分网站能开、少数站点加载不出来」的典型现象——问题不在站点，而在于大包发不出去。
基本信息
| 开销 | PPPoE 头 8 字节，因此接口 MTU 通常按 1492 设计 |
|---|---|
| 客户端配置 | 接口下 ip mtu 1492、ip tcp adjust-mss 1452 |
| 1452 的来源 | 1492 减去 IPv4 与 TCP 头 40 字节，避免 TCP 协商出超大报文 |
| 服务端建议 | 同样做 MSS 钳制，链路两端都受益 |
| 探测方法 | ping 配合 size 与 df-bit 比较临界值 |
典型使用场景
- 拨号接入开通：配置时就把 MTU 与 MSS 一起设定，避免后期返工
- 用户反馈部分网站打不开：先探测 MTU，再看是否做了 MSS 处理
- 多拨与负载均衡：多条 PPPoE 链路的 MTU 需保持一致
- 排障取证：用 df-bit 探测确认实际可用最大包长
- 隧道叠加：PPPoE 上再跑隧道时，有效 MTU 需要重新核算
配置与验证
配置与验证
interface Dialer1
ip mtu 1492
ip tcp adjust-mss 1452
!
# 探测：1464 字节载荷加各层头正好 1492，应能通
ping 203.0.113.1 size 1464 df-bit repeat 5
# 对照：按 1500 口径的 1472 字节在 PPPoE 链路上会被丢弃
ping 203.0.113.1 size 1472 df-bit repeat 5
# 核对接口实际生效的 MTU
show interfaces Dialer1 | include MTU数值对照
| 口径 | 数值 | 说明 |
|---|---|---|
| 以太网 MTU | 1500 | 标准以太网报文的最大载荷 |
| PPPoE 承载 IPv4 | 1492 | 扣除 8 字节 PPPoE 头后的可用长度 |
| TCP MSS 建议值 | 1452 | 1492 减去 20 字节 IP 与 20 字节 TCP 头 |
| 探测包长 | 1464 | ICMP 载荷 1464 + 8 + 20 = 1492，用于验证链路临界值 |
只改 MTU 不做 MSS 处理往往解决不彻底：TCP 协商由两端主机决定，中间设备改了接口 MTU 并不会改变主机的 MSS 选择，MSS 钳制才是让 TCP 主动缩小报文的手段。
给一线一条简单判据：小包能通、1464 字节以上的探测包失败，基本可以定位到 MTU 与 MSS 问题。把这条判据写进排查脚本，能减少大量无效上门与来回确认。
不要在客户端单侧看问题：服务端同样做 MSS 处理，整条链路对 TCP 都更友好；两端的 MTU 也要一致，否则单侧调整之后大包方向仍会失败。