如果你的 PPPoE 宽带访问部分因特网服务异常或缓慢

[Tianao]

请检查 PPPoE 接口的 IPv6 TCP MSS adjust 是否正确。
对于 MTU 1492, IPv6 的 TCP MSS 应为 1432.

对于 RouterOS, PPP profile 中的 change-tcp-mss=yes 可能不会对 IPv6 正确生效。
对于 RouterOS, 可以使用如下命令对 IPv6 的 TCP MSS 做正确的 adjust.
/ipv6 firewall mangle add out-interface=pppoe-out1 protocol=tcp tcp-flags=syn action=change-mss new-mss=1432 chain=forward tcp-mss=1433-65535

[veSir]

OpenWrt 23.05 呢?

[OneOfSisters]

OpenWrt 这边自动的 1500 会默认-8 MSS 也不用动会自动计算 但建议把防火墙 V4V6 分开 V6 不要用 MSS 钳制 因为 RA 已经告知设备应该使用 MTU1492 不需要再检测一次 TCP SYN MSS

[gentrydeng]

这应该是 RouterOS 独有的问题，从搜索记录来看，这个问题至少在 2011 年就被用户报告给了 MikroTik ，但是无人关心： https://forum.mikrotik.com/viewtopic.php?t=51117

所以我很好奇 RouterOS 究竟好用在哪里？软路由意味着小包转发性能不佳，但是又有许多人推荐使用 RouterOS 进行 PPPoE 拨号，然后 OpenWrt 进行 DHCP 管理。

[ac169]

目前我使用的其他软硬路由包括光猫都,只要不去对设置无脑骚操作默认状态下都没有这个问题, 所以我也觉得和 3# 说的那样 "...应该是 RouterOS 独有的问题..."

[Tianao]

@OneOfSisters #2 RA 中宣告的 MTU 应当是 link / 三层口的 MTU, 而不是路由器所有接口 MTU 中最小的那个。直接向下联口宣告最保守的小 MTU 是对 IPv6 相关协议设计的错误理解和 RFC 的错误实现，不然如果我要用 ULA 地址跨三层访问内网 PMTU 9000 的 CIFS 存储，也用 1492 的 MTU 这显然不合理。

按 RFC, 针对中间路径 MTU 比源端小这个场景，应当依靠 PMTUD. 但是现网中大量对 RFC 的错误实现和比相关 RFC 更早出现的屎山，导致了 PMTUD 的可用性与可靠性问题。（其实这就是 ICMP 中 C 的用例之一，但是很多网络工程师乃至所谓架构师只看到了其中的 echo (ping)）

没有 IP 路由器高兴在数据面参与 TCP 的事情（ IPv6 路由器不参与 fragment 也是对这一“IP 路由尽可能纯粹化”的思想的推广和贯彻），TCP MSS adjust/clamp 的施加是作为 PMTUD 失效时的兜底，IPv4 尚有中间路由器帮忙 fragment 作为兜底，IPv6 的中间路由器就只能通过帮忙 adjust/clamp 照顾 TCP 了。

[Tianao]

@gentrydeng #3 感谢给出的信息和链接。

我用的是 MikroTik 的硬路由，主要图它既支持 UPnP 和 NAT-PMP 又支持可配置的 SPI 防火墙，对于 IPv6 的 PD 、ND 相关功能也具有相当高的可配置和可诊断（观测）能力。

[Tianao]

@ac169 #4 感谢提供信息。工作原因我平时接触的都是行业产品，在这个问题上是第一次在这种非主流厂商的产品上踩坑，所以想着给大家提个醒。

[szzys]

我习惯了在防火墙上统一 tcpmss1200 ，简单而粗暴