通过IPSec隧道的20Mbps WAN限制为10Mbps

我们最近将远程站点从10 / 10Mbps光纤升级到20 / 20Mbps光纤链路（光纤到地下室，然后从地下室到办公室的VDSL，大约30米）。 在这个网站和一个中心网站之间有一个普通的大型（多个）文件副本，所以理论上说，增加到20/20的链接应该使传输时间减半。

对于复制文件的传输（例如，使用robocopy将文件复制到任何一个方向，或者Veeam备份和恢复的复制），它们都被限制在10Mbps。

升级之前：

• 我可以使用什么工具模拟广域网的HTTPstream量？

升级之后（ robocopy ）：

几乎相同（忽略转移时间长短的差异）。

这些传输是通过Cisco ASA5520和Mikrotik RB2011UiAS-RM之间的IPSec隧道完成的。

第一个想法：

• QoS – 不。 有QoS规则，但不会影响此stream量。 我禁用了所有的规则几分钟，无论如何检查，并没有改变
• 软件定义的限制。 这些stream量中的大部分是Veeam Backup and Recovery在场外运送，但是在那里没有限制。 另外，我只是做了一个直接的robocopy ，看到完全相同的统计数据。
• 硬件没有能力。 那么，5520的公布的性能数据是225Mbps的3DES数据，而Mikrotik没有公布数字，但是会超过10Mbps。 在进行这些转移testing时，Mikrotik的CPU使用率约为25％-33％。 （另外，通过IPSec隧道进行HTTP传输的命中率接近20Mbps）
• 延迟与TCP窗口大小相结合？ 那么这两个站点之间的延迟是15ms，所以即使32*0.015 32KB窗口大小最差也是2.1MB /秒。 另外多个并发传输仍然加起来10Mbps，这不支持这个理论
• 也许来源和目的地都是狗屎？ 那么源码可以推动1.6GB /秒的持续顺序读取，所以不是这样。 目标可以做200MB /秒的持续顺序写入，所以也不是这样。

这是一个非常奇怪的情况。 我以前从来没有见过这样的事情。

我还能在哪里看？

---

在进一步的调查中，我有信心把IPSec隧道作为问题。 我做了一个人为的例子，在两个公共IP地址之间直接做了一些testing，然后用内部IP地址做了完全相同的testing，我能够在未encryption的互联网上复制20Mbps，IPSec上只有10Mbps侧。

---

以前的版本有关于HTTP的红鲱鱼。 忘了这个，这是一个错误的testing机制。

根据Xeon的build议，当我向ISP询问他们的支持时，我build立了一个mangle规则，将IPSec数据的MSS丢弃到1422 – 基于以下计算 ：

  1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12 PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA 

为了适应ISP的1480 MTU。 但是，这并没有产生有效的区别。

---

比较wireshark捕获后，TCP会话两端现在协商1380的MSS（调整了一些东西，并添加一个缓冲区，以防我的math糟透了）提示：它可能会。 无论如何，1380也是ASA的默认MSS，所以无论如何它可能一直在谈判这个问题。

---

我在Mikrotik里面的工具里面看到一些奇怪的数据，我用它来测量stream量。 这可能是没有用的。 我没有注意到这一点，因为我正在使用一个过滤的查询，我只看到这个时，我删除了filter。