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

前端之家收集整理的这篇文章主要介绍了Windows – 20Mbps WAN通过IPSec隧道限制为10Mbps前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们最近将一个远程站点从10 / 10Mbps光纤升级到20 / 20Mbps光纤链路(它是到地下室的光纤,然后是从地下室到办公室的VDSL,大约30米).在这个站点和一个中心站点之间有常规的大型(多gig)文件副本,因此理论上将链接增加到20/20应该将传输时间减半.

对于复制文件的传输(例如,使用robocopy以任意方向复制文件,或Veeam Backup and Recovery的复制),它们的上限为10Mbps.

升级前:

升级后(robocopy):

几乎完全相同(忽略转移时间的差异).

传输通过Cisco ASA5520和Mikrotik RB2011UiAS-RM之间的IPSec隧道完成.

初步想法:

> QoS – 不.有QoS规则,但没有一个应该影响这个流程.无论如何我禁用所有规则几分钟检查,没有变化
>软件定义的限制.大部分流量都是异地备份和恢复运输,但没有定义限制.另外,我刚做了一个直的robocopy,看到了完全相同的统计数据.
>硬件无法使用.嗯,5520发布的性能数据是225Mbps的3DES数据,而Mikrotik没有发布数字,但它将超过10Mbps.在进行这些传输测试时,Mikrotik的cpu使用率约为25%-33%. (另外,通过IPSec隧道进行HTTP传输确实接近20Mbps)
>延迟与TCP窗口大小相结合?那么站点之间的延迟是15ms,因此即使是最坏的情况,32 * 0.015的32KB窗口大小也是最大2.1MB /秒.此外,多个并发传输仍然只能达到10Mbps,这不支持这一理论
>也许源头和目的地都是狗屎?那么源可以推动1.6GB /秒的持续顺序读取,所以不是这样.目标可以执行200MB /秒的持续顺序写入,因此也不是这样.

这是一个非常奇怪的情况.我以前从未见过以这种方式表现出来的东西.

我还能在哪儿看?

在进一步调查中,我有信心将IPSec隧道指向问题.我做了一个人为的例子和两个公共IP地址之间没有直接一些测试的网站,然后使用内部IP地址做了完全相同的测试,我能够通过未加密的网络复制20Mbps的,只有10Mbps的上的IPSec侧.

以前的版本有一个关于HTTP的红色鲱鱼.忘记这一点,这是一个错误的测试机制.

根据Xeon的建议并在我向他们寻求支持时我的ISP回应,我已经设置了一个规则来将IPSec数据的MSS丢弃到1422 – based on this calculation

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会话现在在两端协商MSS为1380(在调整了一些内容添加缓冲区以防我的数学很糟糕.提示:它可能会这样做).无论如何,1380也是ASA的默认MSS,所以无论如何它可能一直在谈判这个问题.

我看到一些我用来测量流量的奇怪数据in the tool inside the Mikrotik.它可能没什么.之前我没有注意到这一点,因为我使用的是过滤后的查询,而我只是在删除过滤器时看到了这一点.

即使cpu是我检查的第三件事,我写了这个:

The Mikrotik is at around 25%-33% cpu usage when doing these transfer tests

这由cpu图确认

我已经通过外部资源(即一堆其他支持论坛and blogs)证实了大多数Mikrotik路由器无法通过3DES或AES加密推送超过11Mbps的IPSec流量,除非您获得具有硬件加密卸载的模型.

所以看起来这只是硬件限制.我应该早些时候抓住它,但由于某种原因,Mikrotik没有告诉我它是受cpu限制的.

我去购物.

原文链接:https://www.f2er.com/windows/370167.html

猜你在找的Windows相关文章