跳至主要内容

PPPoE 接口的 MTU/TCP-MSS

2026/10/27接口设置7.0.157.2.10大约 16 分钟

PPPoE 接口的 MTU/TCP-MSS

适用范围

PPPoE 拨号成功后，需要在实际承载流量的 PPPoE 接口上检查 MTU 和 TCP MSS。拨号物理口、动态生成的 ppp 接口和手工创建的 PPPoE 接口作用不同，排查网页加载缓慢或大包丢失时，应先确认拨号方式和接口关系，再对比两个方向的 MSS。

相关信息

案例设备为 FortiGate-90G，环境记录的版本为 FortiOS 7.0.15、7.2.10。普通物理接口的补充测试使用 FortiGate-101F，版本为 7.2.10。

接口与方向

两种拨号方式

  • 传统物理口模式：在物理接口 port2 下配置 mode pppoe，拨号后动态生成 ppp 接口，本例为 ppp1。

  • 独立 PPPoE 接口模式：在 config system pppoe-interface 下手工创建 pppoe 接口，并绑定底层物理接口 port2。

    config system pppoe-interface
    edit "pppoe"
        set device "port2"
        set username "<pppoe_username>"
        set password "<pppoe_password>"
    next
end
接口角色本文中的用途
port2PPPoE 底层物理口两种拨号方式均使用该物理口承载 PPPoE
ppp1动态 PPPoE 接口传统物理口模式拨号后生成，在该接口查看实际 MTU 和转发报文
pppoe独立 PPPoE 接口手工创建并绑定 port2，在该接口配置 tcp-mss 并验证结果
port3内网接口连接内网客户端，与 PPPoE 接口的抓包结果进行对比
wan1不使用 PPPoE 的普通物理接口仅用于补充对照测试，不属于上述 PPPoE 接口关系

入方向与出方向

下文的入方向、出方向均相对于实际 PPPoE 接口，即传统物理口模式的 ppp1 或独立模式的 pppoe。

  • PPPoE 出方向：报文从内网经 FortiGate 发往 PPPoE 线路。
  • PPPoE 入方向：报文从 PPPoE 线路进入 FortiGate，再转发到内网。

相关信息

由内网客户端主动建连时，SYN 经过 PPPoE 出方向，SYN/ACK 经过入方向。由外部终端主动建连时，两种报文的方向相反。因此，应按报文经过接口的方向判断 MSS 处理，不能把 SYN 固定对应为出方向，或把 SYN/ACK 固定对应为入方向。

相关信息

MSS 是端点向对端通告的接收能力。客户端 SYN 中的 MSS 主要约束服务器发送的数据，服务器 SYN/ACK 中的 MSS 主要约束客户端发送的数据。实际发送段大小还受到发送端 IP 层允许的报文大小、路径 MTU 及 TCP/IP 选项长度限制，不能简单理解为整条连接共用双方 MSS 的最小值。相关规则见 RFC 9293 → Maximum Segment Size Option。

故障案例

问题现象

  • FortiGate 通过三条 PPPoE 线路上网，其中一条联通线路、两条电信线路。接口 MTU 和 TCP MSS 均保持默认配置。
  • 长时间运行正常后，两条电信线路突然出现网页加载缓慢，等待约 3~5 秒或刷新后才能完全显示，联通线路未出现相同问题。
  • 故障期间带宽未占满，CPU 和内存占用正常。

  1. 后续 MSS 配置验证采用独立 PPPoE 接口，将 pppoe 绑定到底层物理口 port2，并在 pppoe 接口上设置 tcp-mss 1400。拨号账号、密码使用实际值替换占位符。

    config system pppoe-interface
    edit "pppoe"
        set device "port2"
        set username "<pppoe_username>"
        set password "<pppoe_password>"
    next
end

config system interface
    edit "pppoe"
        set tcp-mss 1400
        set interface "port2"
    next
end

    相关信息

    以上为后续验证使用的配置，故障发生时 MTU 和 MSS 保持默认。下文故障与恢复过程中的 ppp1 为现场记录的接口名，独立 PPPoE 接口的验证结果见“MSS 配置验证”。

故障期间

  1. 查看动态 PPPoE 接口的实际 MTU。此处接口名为 ppp1，输出中的 mtu=1442 表明协商后的 MTU 为 1442 字节。

    FortiGate # diagnose netlink interface list name ppp1

if=ppp1 family=00 type=512 index=27 mtu=1442 link=4 master=0
flags=up p2p run noarp multicast
Qdisc=pfifo_fast
stat: rxp=6 txp=4 rxb=70 txb=64 rxe=0 txe=0 rxd=0 txd=0 mc=0 collision=0 @ time=1739434710
re: rxl=0 rxo=0 rxc=0 rxf=0 rxfi=0 rxm=0
te: txa=0 txc=0 txfi=0 txh=0 txw=0
misc rxc=0 txc=0

    相关信息

    ppp1 是该次拨号生成的接口名称，重新拨号或多线路环境中的名称可能不同。应先确认实际承载目标会话的 PPPoE 接口，不能只查看底层物理口的 MTU。

  2. 在 FortiGate 的内网口 port3 和动态 PPPoE 接口 ppp1 同时抓取 TCP 握手，对比同一连接经过设备前后的 MSS。

    相关信息

    对应抓包：故障期间 FortiGate 抓包（failure_fgt.pcapng）。

    报文观察位置MSS
    Client → Server，SYN内网 port3 收到1460
    Client → Server，SYNppp1 发出1402
    Server → Client，SYN/ACKppp1 收到1460
    Server → Client，SYN/ACK内网 port3 发出1460
    故障期间 PPPoE 出方向 SYN 的 MSS 从 1460 调整为 1402

    相关信息

    此时 FortiGate 按 1442 - 20 - 20 = 1402 调整 PPPoE 出方向的 MSS，入方向的 SYN/ACK 没有被修改。仅查看客户端发出的 SYN，不能判断反方向是否也受到了限制。

  3. 检查后续 Client Hello 报文。客户端收到的 SYN/ACK 仍通告 MSS 1460，发送了 IP 总长度为 1500 字节且设置 DF 标志的报文，超过 PPPoE 接口的 1442 字节 MTU。FortiGate 丢弃该报文，向客户端返回 ICMP Destination unreachable (Fragmentation needed)，其中 MTU of next hop 为 1442。

    FortiGate 返回需要分片的 ICMP 消息并通告 MTU 1442

  4. 检查客户端后续重传。客户端收到 ICMP 通知后，按 1442 字节路径 MTU 重新分段，TCP 数据长度降为 1402，后续 Client Hello 得以继续传输。

  5. 对比服务器抓包。服务器收到的客户端 SYN 已被调整为 MSS 1402，服务器自身发出的 SYN/ACK 为 MSS 1460。服务器向客户端发送数据时受对端通告的 1402 限制，因此本例主要异常发生在客户端发送较大报文的方向。

    相关信息

访问恢复后

  1. 再次查看 ppp1，MTU 仍为 1442，FortiGate 对出方向 SYN 的处理也没有变化，仍将 MSS 1460 调整为 1402。

    FortiGate # diagnose netlink interface list name ppp1

if=ppp1 family=00 type=512 index=27 mtu=1442 link=4 master=0
flags=up p2p run noarp multicast
Qdisc=pfifo_fast
stat: rxp=6 txp=4 rxb=70 txb=64 rxe=0 txe=0 rxd=0 txd=0 mc=0 collision=0 @ time=1739434710
re: rxl=0 rxo=0 rxc=0 rxf=0 rxfi=0 rxm=0
te: txa=0 txc=0 txfi=0 txh=0 txw=0
misc rxc=0 txc=0

  2. 对比 FortiGate 和服务器两端的抓包，发现两者之间的网络还会修改 MSS。

    相关信息

    对应抓包：访问恢复后 FortiGate 抓包（normal_fgt.pcapng）、访问恢复后服务器抓包（normal_server.pcap）。

    方向上游观察值下游观察值
    Client → Server，SYNFortiGate 发出时为 1402服务器收到时为 1400
    Server → Client，SYN/ACK服务器发出时为 1460FortiGate 收到时为 1400
    正常期间服务器收到的 SYN MSS 为 1400 而发出的 SYN ACK MSS 为 1460

  3. 检查业务报文。客户端和服务器在各自发送方向上受到 1400 字节 MSS 的限制，报文没有超过 PPPoE 的 1442 字节 MTU，网页可以正常加载。

  4. 将测试客户端的 MTU 降到 1400，对应 MSS 1360，并重新建立 TCP 连接。

    >netsh interface ipv4 set subinterface "以太网" mtu=1400 store=persistent
确定。
    • FortiGate 抓包：客户端发出的 MSS 1360 未被提高到 1402。
    • 服务器抓包：中间网络也未将 MSS 1360 提高到 1400。
    • 测试结论：上述 MSS 调整是限制上限，低于目标值的 MSS 保持原值。

    相关信息

    对应抓包：客户端 MSS 1360 的 FortiGate 抓包（1360_fgt.pcapng）、客户端 MSS 1360 的服务器抓包（1360_server.pcap）。

    重要

    该命令会持久修改测试终端的接口 MTU。测试前应记录原值，结束后将 mtu 恢复为原值。

相关信息

本例三条线路均观察到了中间网络修改 MSS 的情况，但未定位具体设备及配置变化原因。抓包可以证明 FortiGate 与服务器之间存在 MSS 修改，不能据此推断所有 ISP 都会自动调整 MSS，或将问题归因于某台已确定的运营商设备。

原因分析

  • 正常期间，FortiGate 将 PPPoE 出方向 MSS 限制为 1402，中间网络又将两个方向的 MSS 限制为 1400。
  • 故障期间，路径中的 MSS 修改不再出现。客户端收到的 SYN/ACK 为 MSS 1460，随后发出的较大 DF 报文超过 PPPoE 的实际 MTU。
  • FortiGate 对这些报文返回 ICMP “需要分片”，客户端再调整发送大小，过程中出现丢包、重新分段和重传，与网页加载卡顿相对应。

MSS 配置验证

使用独立 PPPoE 接口设置 MSS

  1. 在维护窗口内，使用独立 PPPoE 接口模式，将手工创建的 pppoe 接口绑定到 port2，并在 pppoe 接口上设置 tcp-mss 1400。以下为接口关系和 MSS 配置示例，拨号账号、密码使用实际值替换占位符。

    config system pppoe-interface
    edit "pppoe"
        set device "port2"
        set username "<pppoe_username>"
        set password "<pppoe_password>"
    next
end

config system interface
    edit "pppoe"
        set tcp-mss 1400
        set interface "port2"
    next
end

    重要

    从传统物理口模式迁移到独立 PPPoE 接口时，应同步检查默认路由、防火墙策略、SD-WAN 等接口引用，并保留原有配置以便回退。

    相关信息

    PPPoE 接口的完整配置方法参见部署前注意事项 → PPPoE 接口配置。

  2. 查看独立 PPPoE 接口的 MTU。此时仍与上游协商得到 1442，设置 tcp-mss 1400 没有改变接口 MTU。

    FortiGate # diagnose netlink interface list name pppoe

if=pppoe family=00 type=512 index=18 mtu=1442 link=0 master=0
flags=up p2p run noarp multicast
Qdisc=pfifo_fast
stat: rxp=19665 txp=13658 rxb=20524137 txb=1358139 rxe=0 txe=0 rxd=0 txd=0 mc=0 collision=0 @ time=1739440689
re: rxl=0 rxo=0 rxc=0 rxf=0 rxfi=0 rxm=0
te: txa=0 txc=0 txfi=0 txh=0 txw=0
misc rxc=0 txc=0

  3. 重新建立 TCP 连接并对比两个方向。客户端发出的 SYN 仍从 1460 调整为 1402，服务器返回的 SYN/ACK 则从 1460 调整为 1400。

    • PPPoE 出方向：仍按接口 MTU 减去 40 字节，即 1402，限制 MSS。
    • PPPoE 入方向：按接口手工设置的 tcp-mss 1400 限制 MSS。

    相关信息

    对应抓包：独立 PPPoE 接口设置 MSS 1400（1400_fgt_pppoe.pcapng）。

    独立 PPPoE 接口出方向按 MTU 调整为 1402 入方向按配置调整为 1400

  4. 将测试服务器的 MTU 调整为 1400，使其 SYN/ACK 通告 MSS 1360。经过 FortiGate 转发后仍为 1360，说明小于配置上限的 MSS 不会被提高。测试结束后恢复服务器原有 MTU。

    相关信息

    对应抓包：服务器 MSS 1360 的 PPPoE 抓包（1360_fgt_pppoe.pcapng）。

  5. 从 PPPoE 外侧主动向内网测试终端建立 TCP 连接，验证处理依据是接口方向，而不是 SYN 或 SYN/ACK 的报文类型。

    • 外部测试终端 MTU 为 1600，发出的 SYN MSS 为 1560，进入 PPPoE 接口后调整为 1400。
    • 内网终端返回的 SYN/ACK MSS 为 1460，从 PPPoE 接口发出时调整为 1402。

    相关信息

    对应抓包：独立 PPPoE 接口反向建连（1560_pppoe_reverse.pcapng）。

    反向建连时入方向 SYN 的 MSS 从 1560 降到 1400 出方向 SYN ACK 从 1460 降到 1402

  6. 测试结束后恢复外部测试终端原有 MTU。

测试结果对照

下表中的入方向、出方向均相对于独立 PPPoE 接口，描述的是上述案例环境中的结果。

pppoe 接口配置PPPoE 出方向PPPoE 入方向
未配置 tcp-mss大于 MTU - 40 时降低不修改
设置 tcp-mss 1400仍按 MTU - 40 限制大于 1400 时降低为 1400

相关信息

以上 MTU - 40 对应案例中的 IPv4 和基础 IPv4/TCP 头部长度。所有限制均只降低大于目标值的 MSS，小于或等于目标值时不修改。SYN 和 SYN/ACK 都需要按经过接口的实际方向判断。

补充测试

PPPoE MTU 的获取

最大接收单元（Maximum Receive Unit，MRU）通过 PPP LCP 报文通告。MRU 表示本端愿意接收的最大 PPP 信息字段大小，双方分别通告和确认，不能把两个方向的 MRU 混为一个值。

  1. 在默认配置下抓取拨号协商。FortiGate 的 LCP Configuration Request 通告 MRU 1492，上游 PPPoE Server 的 Configuration Request 通告 MRU 1442。

    相关信息

    对应抓包：默认 MTU 下的 PPPoE 协商（pppoe.pcapng）。

    FortiGate 在 LCP Configuration Request 中通告 MRU 1492PPPoE Server 在 LCP Configuration Request 中通告 MRU 1442

  2. 对比双方的 Configuration Ack。FortiGate 确认服务器的 MRU 1442，服务器确认 FortiGate 的 MRU 1492。最终 diagnose netlink interface list name ppp1 显示 FortiGate 的 PPPoE 接口 MTU 为 1442。

    PPPoE Server 的 LCP Configuration Ack 确认 FortiGate 通告的 MRU 1492
    FortiGate # diagnose netlink interface list name ppp1

if=ppp1 family=00 type=512 index=27 mtu=1442 link=4 master=0
flags=up p2p run noarp multicast
Qdisc=pfifo_fast
stat: rxp=6 txp=4 rxb=70 txb=64 rxe=0 txe=0 rxd=0 txd=0 mc=0 collision=0 @ time=1739434710
re: rxl=0 rxo=0 rxc=0 rxf=0 rxfi=0 rxm=0
te: txa=0 txc=0 txfi=0 txh=0 txw=0
misc rxc=0 txc=0

  3. 在隔离测试环境中，将承载 PPPoE 的物理口 MTU 调整为 1100，并重新拨号。

    相关信息

    对应抓包：本端 MTU 1100 的 PPPoE 协商（pppoe2.pcapng）。

    config system interface
    edit "port2"
        set mtu-override enable
        set mtu 1100
    next
end

    • FortiGate 在 LCP Configuration Request 中通告 MRU 1100。

      物理口 MTU 调整为 1100 后 FortiGate 使用 MRU 1100 参与协商

    • 拨号成功后的 PPPoE 接口 MTU 为 1100。

      FortiGate # diagnose netlink interface list name ppp1

if=ppp1 family=00 type=512 index=29 mtu=1100 link=4 master=0
flags=up p2p run noarp multicast
Qdisc=pfifo_fast
stat: rxp=47 txp=54 rxb=23810 txb=12255 rxe=0 txe=0 rxd=0 txd=0 mc=0 collision=0 @ time=1739435081
re: rxl=0 rxo=0 rxc=0 rxf=0 rxfi=0 rxm=0
te: txa=0 txc=0 txfi=0 txh=0 txw=0
misc rxc=0 txc=0

  4. 将物理口 MTU 调整为 1600，再次拨号。上游仍通告 MRU 1442，最终 PPPoE 接口 MTU 仍为 1442。

    config system interface
    edit "port2"
        set mtu-override enable
        set mtu 1600
    next
end

FortiGate # diagnose netlink interface list name ppp1

if=ppp1 family=00 type=512 index=31 mtu=1442 link=4 master=0
flags=up p2p run noarp multicast
Qdisc=pfifo_fast
stat: rxp=7 txp=5 rxb=384 txb=135 rxe=0 txe=0 rxd=0 txd=0 mc=0 collision=0 @ time=1739435153
re: rxl=0 rxo=0 rxc=0 rxf=0 rxfi=0 rxm=0
te: txa=0 txc=0 txfi=0 txh=0 txw=0
misc rxc=0 txc=0

  5. 在独立 PPPoE 接口模式下重复测试，得到相同的 MTU 选择结果。测试结束后恢复物理口原有 MTU 和覆盖状态，并重新确认拨号及业务正常。

重要

1100 和 1600 是用于验证边界的实验值，不是生产推荐配置。本次测试中，FortiGate PPPoE 接口最终使用的 MTU 不超过本端配置限制和上游通告的 MRU，调大物理口 MTU 不会绕过运营商的接收限制。

普通物理接口的对照测试

  1. 在 FortiGate-101F、FortiOS 7.2.10 上，为不使用 PPPoE 的 wan1 接口设置 MSS 1300，其他 MTU/MSS 参数保持默认。

    config system interface
    edit "wan1"
        set ip 192.0.2.2 255.255.255.0
        set tcp-mss 1300
    next
end

  2. 重新建立 TCP 连接并抓包。客户端 SYN 和服务器 SYN/ACK 中原为 1460 的 MSS，经过该接口后均被限制为 1300。

    相关信息

    对应抓包：普通物理接口设置 MSS 1300（tcp-mss_phy_int_wan1_1300.pcapng）。

    FortiOS 7.2.10 普通物理接口将两个方向的 MSS 限制为 1300

  3. 将测试客户端的接口 MTU 调整为 1200，对应 MSS 1160。客户端发出的 MSS 1160 经过 FortiGate 后保持不变，服务器方向大于 1300 的 MSS 仍被限制为 1300。

    相关信息

    对应抓包：普通物理接口 MSS 1300、客户端 MSS 1160（tcp-mss_phy_int_wan1_1300_client_1160.pcapng）。

    # sudo ifconfig en7 mtu 1200
    客户端 MSS 1160 小于接口配置上限 1300 时保持原值

  4. 测试结束后，恢复测试终端原有 MTU，以及 wan1 原有的地址和 MSS 配置。

相关信息

  • 普通接口的 MSS 处理存在版本差异。FortiOS 6.0.x、6.2.x、6.4.x 和 7.0.0 仅在接口入方向调整，FortiOS 7.0.1 及 7.2.x 改为双向调整。相关行为参见 Behavior of TCP-MSS setting under system interface。
  • 案例记录同时指出普通接口的 MSS 设置可影响 FortiGate 本机出方向 TCP 流量，涉及版本变更记录为 Mantis 0717170。

总结

  1. 建议使用独立 PPPoE 接口承载拨号，将拨号参数和 tcp-mss 配置在该接口上，底层物理口用于承载 PPPoE 流量。

    相关信息

    完整配置方法参见部署前注意事项 → PPPoE 接口配置。修改现有拨号配置时，应在维护窗口内同步检查默认路由、防火墙策略、SD-WAN 等接口引用，并保留回退配置。

  2. MTU 以拨号后独立 PPPoE 接口的实际值为准，同时检查本端配置限制和上游通告的 MRU。本例 MTU 为 1442，设置 tcp-mss 1400 不会改变该 MTU。

  3. MSS 按 PPPoE 接口的实际方向分别处理，配置时应区分需要限制的方向。

    • 出方向：本例按实际 PPPoE MTU 减去 40 字节限制，MTU 1442 对应 MSS 上限 1402。需要降低出方向 MSS 时，应根据路径限制调整相应 MTU，并重新确认拨号后的实际值。
    • 入方向：通过独立 PPPoE 接口上的 tcp-mss 限制，本例配置 1400 后，将大于 1400 的 MSS 降为 1400。
    • 两个方向均只降低超过目标值的 MSS，小于或等于目标值时不修改。SYN 和 SYN/ACK 都应按经过接口的方向判断。

  4. 修改后重新建立 TCP 连接，对比内网口、PPPoE 接口及服务器端的 SYN、SYN/ACK，确认两个方向的 MSS。复测 Client Hello、网页加载和较大数据传输，并检查 ICMP “需要分片”报文，确认不再持续出现超 MTU 丢包及重传。

    提示

    不要依赖中间网络始终代为修改 MSS。升级、更换型号后，应重新验证接口 MTU 和两个方向的 MSS。

最近更新: