我的办公室有一台服务器麦克风，通过VPN与远程服务器通信。 有一些似乎与MTU大小有关的各种问题。 Mike是RHEL 3服务器，客户服务器是CentOS 5.我使用tracepath工具尝试查找最大MTU并得到这个奇怪的结果
[root@mike root]# tracepath 192.168.1.4 1: mike (192.168.100.1) 0.170ms pmtu 552 1: mike (192.168.100.1) 0.011ms pmtu 552 1: mike (192.168.100.1) 0.010ms pmtu 552 snip - thousands of lines of the same output 1: mike (192.168.100.1) 0.025ms pmtu 552 1: 192.168.100.252 (192.168.100.252) 0.405ms 2: 192.168.100.253 (192.168.100.253) 0.876ms 3: 192.168.1.4 (192.168.1.4) 97.1000ms reached Resume: pmtu 552 hops 3 back 3 从我们办公室的另一台服务器到不同的客户，我得到了一个更加合理的结果
[root@nora ~]# tracepath 192.168.2.1 1: nora (192.168.100.228) 0.080ms pmtu 1500 1: 192.168.100.253 (192.168.13.253) asymm 2 0.813ms 2: no reply 3: 192.168.11.1 (192.168.11.1) 73.210ms reached Resume: pmtu 1500 hops 3 back 3
所以我认为这是麦克风而不是路由器，防火墙或VPN之间的事情。 有任何想法吗？
为了回应Daniel Lawson的回答，下面是为什么我相信问题是服务器麦克风，因为诺拉能够得到正确的回应
[root@nora ~]# tracepath 192.168.1.4 1: nora (192.168.100.228) 0.101ms pmtu 1500 1: 192.168.100.253 (192.168.100.253) asymm 2 0.863ms 2: no reply 3: 192.168.1.4 (192.168.1.4) 111.601ms reached Resume: pmtu 1500 hops 3 back 3
为了回应Mike Pennington的评论，192.168.100.252和192.168.100.253都是防火墙。 默认网关是192.168.100.252然后有一个静态路由这些客户发送stream量到192.168.100.253。 因为他们在同一个networking上，我认为这就是跳数不增加的原因。
从你所说的话，从服务器“麦克”到一个客户的path被限制为552，而从“诺拉”到另一个客户的不同path不受限制。
你没有比较相同的path，所以除非有更多的信息，否则我怀疑这是特定于服务器“麦克风”。 PMTU是path上受限制的MTU，所以如果这是麦克特定的，那么它应该发生在任何跟踪path的机器上。
考虑到你正在使用VPN连接，虽然你看到一个受约束的PMTU并不奇怪。 我会检查第一个客户的VPNconfiguration的MTU设置，我也试着直接检查MTU到客户的VPN端点（例如终止VPN的公共IP地址）。 其中一个或另一个可能会有你的答案。
来自不同厂商的防火墙和VPN相当常见 – 例如，检查点将某些types的stream量的MTU降低到1500以下。
如果您有一台Windows机器，您可以在traceroute模式下运行mturoute来确定哪个链路/跳具有较低的MTU。
我认为这个问题与Juniper没有返回在PMTUD的一部分的ICMP Unreachable数据包中的MTU值有关。 我以前用juniper看过类似的问题