Недостаточная скорость туннелей

[ss141120]

Тут дело не в провайдере, а в "длинном" канале с пингом более 40 мс. Каналы то - 100, 1000 и 1000 МБит/с, синтетический BTest гоняет скорость между интерфейсами на уровне скорость канала минус 5-15%.

Похоже, размер кадра (64К) и TCP накладывает свои ограничения. Вопрос - как это все ускорить?

 

Цитата с Хабра, про OpenVPN, думаю, что это схоже:

 

 

Немного технической информации

Если вы пользовались OpenVPN, вы знаете, что он может работать как через UDP, так и через TCP. Если на TCP-сокете установить какое-то маленькое значение буфера, в нашем случае 64 КБ, то алгоритм подстройки TCP-окна просто не сможет выйти за это значение.
Что же это значит? Предположим, вы подключаетесь к серверу в США из России через OpenVPN со стандартными значениями буферов сокета. У вас широкий канал, скажем, 50 МБит/с, но в силу расстояния, пинг составляет 100 мс. Как вы думаете, какой максимальной скорости вы сможете добиться? 5.12 Мбит/с. Вам необходим буфер размером как минимум 640 КБ, чтобы загрузить ваш 50 Мбитный канал.
OpenVPN через UDP будет работать несколько быстрее из-за собственной реализации пересылки пакетов, но тоже далеко не идеально.

Edited September 24, 2018 by ss141120

[McSea]

@ss141120 

 

Хорошо, возьмем "длинный". 

Имеем туннель IPsec через LTE с такими задержками:

Ping statistics for 192.168.1.3:
    Packets: Sent = 27, Received = 27, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 74ms, Maximum = 98ms, Average = 83ms

С одной стороны LTE Megafon, закачка плавает от 30 до 50 мбит/с; с другой стороны Ростелеком оптика 30 мбит/с

Файл размером 718 мегабайт был скопирован проводником Виндовс за 271 сек, т.е. скорость составила 21 мбит/с.

21 мбит/с от макс. 30 для SMB, никак не расчитанного на такие задержки, вполне прилично.

 

iperf по TCP в пару потоков выдает максимум. 

[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-39.41  sec  0.00 Bytes  0.00 bits/sec                  sender
[  4]   0.00-39.41  sec  74.5 MBytes  15.8 Mbits/sec                  receiver
[  6]   0.00-39.41  sec  0.00 Bytes  0.00 bits/sec                  sender
[  6]   0.00-39.41  sec  67.6 MBytes  14.4 Mbits/sec                  receiver
[SUM]   0.00-39.41  sec  0.00 Bytes  0.00 bits/sec                  sender
[SUM]   0.00-39.41  sec   142 MBytes  30.2 Mbits/sec                  receiver

 

[ss141120]

У меня были подобные ограничения скорости, когда я делал туннель между Kerio и Zyxel Zywall, Россия - Европа. Тогда был чистый IPSec, и скорость по нему, несмотря на гигабитный канал с одной стороны и 100-мегабитный с другой, колебалась в районе 8-10 МБит/с. Канал был...я делал его чисто для себя, для интереса. Но были нюансы - при доступе к серверу через внешний IP по RDP большим количеством сессий не было никаких проблем со скоростью, а точнее, с инерционностью сеансов. А вот если сеансы переносил в тоннель - вот тогда они были инерционны, задержки мышки, замедленное обновление картинки.

Но опять же, BTest дает вполне приличную картину по внутренним интерфейсам.

 

В общем, я перестал что-либо понимать :(

[ss141120]

@McSea 

Сейчас опять построил схему, и воткнул в транзитный узел сервак, для чистоты эксперимента. Получилось вот такое:

 

роутер1(Россия) <-- (EoIP)--> роутер2 (Европа)<--(EoIP)-->роутер3(Россия)

 

Роутер1 - 100Мбит/с, Роутер2 и Роутер3 - гигабит.

 

Один широковещательный домен, во всех роутерах воткнуто по серваку, назову их соответственно сервер1, сервер2 и сервер3

Обмен между сервер1 и сервер2 - норм. Обмен между сервер2 и сервер 3 - норм. Обмен между сервер1 и сервер3 - не норм.

 

[stefbarinov]

На мой взгляд имеет место быть DPI провайдера, который может резать скорость определённого трафика, либо плохая связность между разными bras. Такое часто бывает - провайдеру ведь платят за скорость в Интернет, а не к соседу. Была похожая проблема между двумя роутерами Zyxel Giga 2, один в качестве vpn-сервера, другой клиент. Так вот скорость от сервера до клиента выше 10-12 Мбит/с в тоннеле (и без тоннеля) не поднималась, обратная скорость была 40-50 Мбит/с. Пробовал разные тоннели (IPIP, GRE, L2TP, с IPSec`ом и без) ничего не помогало до тех пор, пока на vpn-сервере не сменил провайдера. Проблема сразу ушла.

[maa1]

On 9/24/2018 at 4:15 PM, ss141120 said:

Тут дело не в провайдере, а в "длинном" канале с пингом более 40 мс.

 

Именно так. У аппаратных маршрутизаторов Mikrotik на таких каналах сильно ухудшается скорость и стабильность VPN канала.

Что примечательно, у CHR такой проблемы нет.

Техподдержка Микротика игнорирует/замалчивает наличие проблемы, не решая её годами. Хотя чего еще от них ждать, если они проблему с out-of-order пакетами ipsec в CCR решали 5 лет.

[iStranger]

Приветствую!

Забрел на эту тему в поисках решения проблемы. 

У меня все гораздо проще: два микротика: один в городе, другой в деревне. Везде канал 100Мбит. Но в городе IP белый, в деревне - серый. В деревне стоит старенький RB951Ui-2hnd, в городе - hap ac lite. Настроен l2tp-туннель клиент-сервер.

В деревне стоит тв-приставка vontar на которой, в том числе и ftp-сервер поднят. Соединена проводом. И вот решил я закинуть сериал на приставку с городского компа. Привычно соединился через FTP-клиент в Total Commander, копирую... и скорость в районе 10-12 Мбит/с. Посмотрел на микротики - загрузка процессоров небольшая. На городском максимум был процентов 15, на деревенском не помню. В общем, стал курить эту тему. Пробовал менять настройки, картина не поменялась. 

И тут мне в голову пришла мысля: а может, попробовать другим клиентом? Подключился через FileZill'у - и вуаля! 90 Мбит/с средняя скорость при передаче около 10 гигов. И тут уже да, загрузка процессоров на микротиках подскакивает и доходит временами до 80%. Так что, видимо, дело не в микротиках. В моем случае, по крайней мере, так. 

[fractal]

42 минуты назад, iStranger сказал:

Приветствую!

Забрел на эту тему в поисках решения проблемы. 

У меня все гораздо проще: два микротика: один в городе, другой в деревне. Везде канал 100Мбит. Но в городе IP белый, в деревне - серый. В деревне стоит старенький RB951Ui-2hnd, в городе - hap ac lite. Настроен l2tp-туннель клиент-сервер.

В деревне стоит тв-приставка vontar на которой, в том числе и ftp-сервер поднят. Соединена проводом. И вот решил я закинуть сериал на приставку с городского компа. Привычно соединился через FTP-клиент в Total Commander, копирую... и скорость в районе 10-12 Мбит/с. Посмотрел на микротики - загрузка процессоров небольшая. На городском максимум был процентов 15, на деревенском не помню. В общем, стал курить эту тему. Пробовал менять настройки, картина не поменялась. 

И тут мне в голову пришла мысля: а может, попробовать другим клиентом? Подключился через FileZill'у - и вуаля! 90 Мбит/с средняя скорость при передаче около 10 гигов. И тут уже да, загрузка процессоров на микротиках подскакивает и доходит временами до 80%. Так что, видимо, дело не в микротиках. В моем случае, по крайней мере, так. 

Стандартная ситуация Total качает в один поток, Filezilla в несколько

Проблемы обычно две:

1. Интернет, на нем плавает mtu, микрот с этим плохо работает

2. Загрузка в 1 поток

[HarDik]

Привет всем! Тоже попал в странную ситуацию.... Не обходимо реализовать обмен трафика SMB через тунели GRE между офисами  Москва-Владивосток, пинги больше 150 мс, каналы 1 гбит, для юриков... маршрутизация между офисами L3, загрузки на процов нет почти 1-3%, с обоих сторон CCR, трафик ходит норма, но скорость больше 10 мбит по SMB не поднимается... менял MTU на GRE и Запустил правку MSS через mangle, не помогает. Не ужели ни как SMB не ускорить? 

[jffulcrum]

GRE с IPSEC или голое?

[fractal]

6 часов назад, HarDik сказал:

Привет всем! Тоже попал в странную ситуацию.... Не обходимо реализовать обмен трафика SMB через тунели GRE между офисами  Москва-Владивосток, пинги больше 150 мс, каналы 1 гбит, для юриков... маршрутизация между офисами L3, загрузки на процов нет почти 1-3%, с обоих сторон CCR, трафик ходит норма, но скорость больше 10 мбит по SMB не поднимается... менял MTU на GRE и Запустил правку MSS через mangle, не помогает. Не ужели ни как SMB не ускорить? 

Smb не работает адекватно с большой задержкой, на любом железе

[HarDik]

В 09.04.2024 в 14:12, jffulcrum сказал:

GRE с IPSEC или голое?

GRE+IPSEC, но пробывал и голым, разницы нет, игры с mtu тоже не помогают... 

 

В 09.04.2024 в 19:22, fractal сказал:

Smb не работает адекватно с большой задержкой, на любом железе

Да я уже понял... к сожалению тоже самое можно сказать и про FTP

[jffulcrum]

HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\DisableBandwidthThrottling - 1

Лучше в консоли: Set-SmbClientConfiguration -EnableBandwidthThrottling 0

 

HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\MaxCmds -32 - если обе стороны умеют SMB3

 

Все делается на клиенте

[naves]

После обновления микротиков до 7 версии на разных моделях замечали резкое падение скорости почти в ноль в VPN-каналов IPSec IKEv2 с клиентом Strongswan. Приходилось откатывать версию.

В очередной раз наткнулись на это на новом роутере.

CCR2116-12G-4S+

al64v3

7.16

 

Помогло выключить fasttrack для IPSec

https://saputra.org/threads/mikrotik-fasttrack-with-ipsec.34/

Quote

• 7 Jan 2019

Fasttrack is a new feature introduced in RouterOS v6.29 that allows you to forward packages in a way that they are not handled by the Linux Kernel which greatly improves the throughput of your router as well as lowering the CPU load.

Fasttrack allows all packages that have the state Established or Related to bypass the Kernel and be directly forwarded to the target. So, once a connection is marked as established or related, it won’t go through any firewalling or processing and will directly forwarded to the target. Of course – a connection gains the state of established or related once it went through the firewall so it will still be secure.

But there’s a known issue that Fasttrack will not work with IPsec connections, it will result in a rather wonky experience or very unstable IPsec connection. So if you have IPsec connections in your MikroTik but want to take the advantages of Fasttrack, here’s the resolution for you!

Firstly, we want to mark all IPsec connections:

Code:

/ip firewall mangle add action=mark-connection chain=forward comment="mark ipsec connections" ipsec-policy=out,ipsec new-connection-mark=ipsec
/ip firewall mangle add action=mark-connection chain=forward comment="mark ipsec connections" ipsec-policy=in,ipsec new-connection-mark=ipsec

Secondly, we want to create a new Fasttrack rule but excluding all IPsec connections that we have marked with the two mangle rules above:

Code:

/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related connection-mark=!ipsec
/ip firewall filter add chain=forward action=accept connection-state=established,related

If any, don’t forget to delete your old Fasttrack rule.

I’ve been using this rule in my live IPsec site-to-site tunnel and the result is just simply amazing!

 

До:

iperf -c 10.129.20.200 -t 60
------------------------------------------------------------
Client connecting to 10.129.20.200, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 10.133.6.99 port 57872 connected with 10.129.20.200 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-62.7 sec   105 KBytes  13.7 Kbits/sec

Стало:

iperf -c 10.129.20.200 -t 60
------------------------------------------------------------
Client connecting to 10.129.20.200, TCP port 5001
TCP window size:  348 KByte (default)
------------------------------------------------------------
[  3] local 10.133.6.99 port 57580 connected with 10.129.20.200 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  2.72 GBytes   390 Mbits/sec

а нужно было всего лишь прочитать документацию некротика от корки до корки
 

Quote

 

Random packet drops or connections over the tunnel are very slow, enabling packet sniffer/torch fixes the problem?

Problem is that before encapsulation packets are sent to Fasttrack/FastPath, thus bypassing IPsec policy checking. The solution is to exclude traffic that needs to be encapsulated/decapsulated from Fasttrack, see configuration example here.

 

 

Edited October 10, 2024 by naves

[hdzz]

Помогло

[HarDik]

17 часов назад, hdzz сказал:

Помогло

Расскажи подробнее, что сделал\прописал? как было\стало?