如何解决 MPLS 线路上站点到站点 VPN 隧道性能缓慢的问题？我应该查看哪些相关报告/统计数据？
背景： 我支持站点到站点 VPN 的一端，用于连接过程控制网络 (PCN) 的两端。PCN 通过 Juniper SRX/SSG 防火墙与企业/公司网络隔离，这些防火墙也提供 VPN 端点。
最初，站点之间的业务网络通过 AT&T GigaMAN 连接，据我所知，这是城域以太网服务的品牌名称。一个站点是主站点（我的站点）的子站点，任何需要从子站点前往除我的站点之外的其他公司站点的流量都会通过主站点，然后再路由到公司的其他站点。
部分出于成本考虑，部分出于增加可靠性考虑，城域以太网被与子站点的公司 MPLS 绑定的 T3 电路所取代。主站点已经与公司其他站点一起采用 MPLS。VPN 的用途之一是站点之间的预定文件传输，由于子站点切换到 MPLS，我们将出现传输间歇性超时的情况。
我无法控制公司的 LAN 或 WAN，只能控制 PCN，所以我必须通过另一个团队来找到根本原因，但不知道要问什么正确的问题。
答案1
我建议你看一下：
- 从 Juniper 盒中提取事件日志，特别查找隧道中的丢失。
- 在 Juniper 机器上运行调试日志，特别是当问题足够一致时，您可以这样做而不必担心调试时的日志翻转或性能问题。
- 获取任何 MPLS 报告，这些报告将在时间范围内尽可能详细地显示连接丢失、带宽利用率等情况
- 进行一些常规测试。在一天中的不同时间测试各种端点、文件大小、MTU 大小、QCheck 测试等。如果可以在间歇性问题期间运行这些测试，那就更好了。
- 如果它可以重现，即使是每天都发生，也请尝试使用 wireshark 日志记录运行端点，然后分析这些日志。
- 尝试不同的文件传输协议。看看问题是否出在协议本身。SMB 在 VPN 隧道上的表现相当差。尝试使用 FTP。测试并收集结果。
总的来说，您从各个角度收集的数据点和日志越多，拼凑谜题就越容易。
答案2
查看 MTU。您使用的值是否大到足以导致碎片化，进而导致延迟。想象一下您的数据包大小大了 5 个字节。因此，发送了两个片段，较小的片段（只有 5 个字节）先到达。然后它必须等到那个讨厌的片段赶上来才能重新组装。如果缓冲区溢出，那么您就会遇到经典的 ATM 情况，即丢失少量片段会导致多次数据包重新传输。
使用特定数据包大小进行一些 ping 测试，特别是使用 MTU 大小和 MTU + 5 之类的值。还要计算封装开销 (OVH) 并使用 MTU - OVH 和 MTU - OVH + 5
获取数据包大小分布的报告，以了解您的平均数据包大小以及分布形状。