我一直在使用接口绑定、VLAN 和桥接接口的组合来为 xen domU 提供冗余和不同的逻辑网络层。
这个设置运行良好，但是我有点不确定这些接口上的不同设置如何影响彼此。为了说明，这是我在典型 dom0 上的设置：
/- vlan10 -- br10
eth0 -\ /
> bond0 <--- vlan20 -- br20
eth1 -/ \
\- vlan30 -- br30
考虑到绑定、VLAN 和桥接接口是逻辑接口而不是物理接口，如果物理（eth0、eth1）接口具有不同的 MTU 集，那么在这些接口上设置 MTU 是否有任何影响？
我找到了不同链路的各种 MTU 列表，但它们从未包含 UMTS、LTE、EDGE、HSPA、GPRS。
上述技术的 MTU 是多少？
如何在 Linux 2.6 上增加MTU大小？
这样的事情可能吗？如果是，哪些文件（在/etc其他地方）必须编辑？
我试图了解与 NFS 和各种缓冲区大小相关的网络设置（并且有很多）。
我正在运行wireshark并检查到达NFS服务器的TCP数据包。Wireshark 在扩展写入操作（客户端-> 服务器）期间显示最大 32626 的数据包大小，假设我正确解释（“线路上的字节”，我认为包括所有网络层标头等）
导出存储的“rsize”和“wsize”NFS 设置在两个 C/S 上都设置为 32k，因此我认为上述结果是此设置的结果。但是，增加这些值不会增加 Wireshark 显示的数据包大小。
所以我的问题是，还有哪些其他限制可以到位？我已经做了大量的研究，这就是我迄今为止所遇到的。在我看来，以下网络限制都不会将传输大小限制为 32k：
从 sysctl：
net.ipv4.tcp_mem = 4096 87380 4194304
net.ipv4.tcp_{r,w}mem = 4096 87380 4194304
net.core.{r,w}mem_max = 131071
net.core.rmem_default = 229376
我的 MTU 目前是 8K
我的服务器的 ssh 出现了一些问题，我无法上传大于 10 KB 的文件，因为 scp 在复制过程中会挂起。我在这里找到了解决这个问题的方法，我正在更改 MTU，但我不小心这样做了sudo ip link set eth0 mtu 0。
现在没有人可以 ssh 进入服务器。我该怎么办？
我有与这里描述的完全相同的问题，但我不能要求作者澄清，因为我是一个新用户，我不能对此发表评论，所以我发布了一个新问题（我尝试在该问题下发布作为在同一线程上参考的答案，它被删除，因为它没有提供答案......）。
问题：是否有人对如何排除故障和/或确定该线程中描述的 TCP 问题的根本原因有任何建议？就好像远程端不接受 VPN 客户端发送的 ACK 消息一样。
我的设置和原问题一模一样：CentOS服务器（拓扑子网），两台客户端，一台CentOS，一台Ubuntu14.03。当我从 ubuntu-client 到 centos-client 执行 'ssh cat abc.txt' 时，centos 的 vpn 连接停止。恢复它的唯一方法是重新启动 openvpn 服务器（在 centos 机器上）和 centos 上的 openvpn 客户端 - 只是重新启动 centos 客户端连接并不能使其运行（它会在 ~ 1-2 分钟，但我无法再通过 vpn ping 或 ssh 盒子）。我还尝试了在其他线程（tun-mtu 1300 / fragment 1100 / mssfix 等）中找到的所有 MTU 调整建议，但没有一个有帮助。
更奇怪的是，如果我从 Ubuntu 执行相同的 ssh-cat，使用 CentOS 服务器 vpn 连接到 centos-client 的公共 IP 地址（从而绕过 centos-client<->centos-server vpn 腿），一切正常（永远没有摊位）。
更新 1：我发现有一种解决方法可以解决此问题，但它非常难看。在这里发布，以防万一有人提出任何其他想法/提示。当我在 openvpn 服务器（不是在客户端，仅在服务器上）上将详细级别设置为 9 时，问题再也不会发生。动词 9 导致 …
我ip link set eth0 mtu 1000在链接 eth0 上将MTU 大小配置为 1000 。我禁用了通用接收卸载（gro）ethtool -K gro off（因为这会导致 tcpdump 中的“错误”帧长度（参见此处））但是如果我现在使用 tcpdump 捕获，我仍然会得到大于 1000 的数据包，例如 1500 字节。
我做错了什么？
在 MTU 设置为 1000 的接收端：
eth0：mtu 1000
14:27:38.361168 IP XXXXXX > YYYYYY：ICMP echo > request，id 3273，seq 1，长度 1480 14:27:38.361495 IP YYYYYY > XXXXXX：ICMP echo 回复，id 3273，长度 seq 6 1
我管理了几个 Web 服务器，它们的 MTU 设置默认设置为 1500。有些机器的 MTU 设置为 576。我已经阅读了很多关于 MTU 的文章，我觉得我对它的了解已经足够了，但我对路由器和用户 PC 之间的当前硬件状态没有很好的了解。1500 是在公共 Web 服务器上运行的正常 MTU，还是会给某些用户带来问题？谢谢！fz
我知道 TCP 封装在 TCP 上通常是一个糟糕的想法，但我可以处理偶尔降低的性能和 MTU 问题，并且 TCP 中的滚雪球效应 TCP 提供了在两个层上进行错误控制的地方。
Windows 7 x64 上最新的 OpenVPN 客户端存在严重的延迟问题，ping 隧道内的主机会导致 ping 时间超过 500 毫秒，并且总体性能非常糟糕。吞吐量看起来不错，实际上只是延迟。
但是，在同一台计算机上，Linux 64 位（ubuntu 10.04，相同的 OpenVPN 版本，相同的 OpenVPN 配置，没有不同的设置）上的 OpenVPN 客户端可以完美运行。~30ms，一切都非常好用。
在相同的交换机上，相同的 OpenVPN 客户端版本，相同的配置文件，在 Mac OS X 10.5 (PowerPC) 上也可以完美运行。
我根本无法解释这一点。我尝试了各种方法，例如将虚拟适配器的 MTU 值降低到 1400（因为可怕的商业交换机文档提到这不是在 Windows 上动态设置的，并推荐了这样的操作），我尝试过在全局 TCP 设置中禁用 ECN、烟囱和 CTCP，打开和关闭 lzo 压缩，牺牲一只山羊，没有什么比这更好的了。
有任何想法吗？起初我认为 Windows 上的 OpenVPN 中缺少 PMTU 支持是造成此问题的原因，但我尝试使用 Windows XP，它也可以完美运行。我从用户那里得到报告，它在 Windows 7 32 位上也能完美运行。此外，文档似乎还说 MTU 设置对于 TCP 连接毫无价值，并且适用于 UDP。
tl; dr：TCP 上的 OpenVPN 速度很慢，但仅在 Windows 7 x64 中，其他一切正常。是什么赋予了？ …
在编写网络软件时，是否有默认的、典型的或其他事实上的 MTU 大小标准，我应该注意哪些？如果是，那是什么？
1500 的 MTU 大小（如此处建议：DSL 标准中支持的最大 MTU 是多少）是一个好的经验法则吗？
另外，我是不是想多了这个问题？这是人们在编写网络软件时认为很重要的事情之一，但实际上，在现实世界中，由于 TCP 会为您处理细节，因此最终并不重要吗？
我在这里提问，而不是在 StackOverflow 上提问，因为在涉及与 MTU 大小相关的实际支持问题时，我想要系统管理员的观点。
更新：根据一些反馈和初步答案，我稍微缩小了重点：