+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Очень низкая скорость передачи TCP при использовании IPIP+IPsec на CCR1009 и CCR1036

Очень низкая скорость передачи TCP при использовании IPIP+IPsec на CCR1009 и CCR1036, RouterOS

dev246

Guest

01.04.2016 11:09:00

Привет. У меня несколько офисов, и я хочу соединить их с помощью IPIP-туннеля с IPsec, поэтому купил несколько MT CCR1036 и CCR1009, так как у них есть аппаратное ускорение IPsec и очень хорошая производительность (согласно ruouterbord.com). Но когда я всё настроил, очень удивился низкой скорости при копировании файлов между двумя офисами (в каждом офисе симметричный канал 500/500 Мбит/с по оптоволокну). Скорость передачи файлов была около 4-10 МБ/с, что примерно соответствует 40-80 Мбит/с.

Потом я создал лабораторную среду с очень простой конфигурацией, без каких-либо правил файрвола. Только IP-адреса, базовая статическая маршрутизация и IPIP-туннель с IPsec-шифрованием по умолчанию. Схема:

Client1 -> CCR1009 <----- IPIP+IPsec ------> CCR1009 <- Client2

Результат был тот же самый (копирование файлов в Windows, FTP, HTTP) — максимум около 40-80 Мбит/с, что странно для такого мощного железа.

Далее я провёл серию тестов с помощью Iperf — надёжной программы для тестирования, которая запускается на клиентских машинах, чтобы не нагружать Mikrotik генерацией трафика. После нескольких тестов выяснилось, что проблема не в ресурсах Mikrotik, а в количестве соединений. Если отправлять данные через IPIP+IPsec туннель одним соединением, то скорость 40-80 Мбит/с. Но если использовать 20 одновременных соединений — скорость поднимается до 800 Мбит/с, что уже хороший результат (передача идёт в одном направлении: client1 -> client2).

Я прикрепляю несколько файлов с диаграммой моей лабораторной сети, конфигурацией и таблицей с результатами тестов. Может, кто-то знает, как решить эту проблему и улучшить скорость передачи на одном соединении?

Я понимаю, что на ruouterbord.com результаты были для UDP-трафика и выглядят очень неплохо, но в реальной жизни большинство пользователей используют TCP, и когда пользователь пытается скопировать файл из одного офиса в другой или скачать файл с корпоративного сайта через IPsec-туннель, а скорость составляет всего 50 Мбит/с — это уже не лучший показатель, особенно учитывая, что я купил почти самое мощное устройство у производителя.

alexjhart

Guest

28.04.2016 15:44:00

Жаль, что у меня нет более подробного поста, чтобы отправить тебя туда, но пока посмотри это: http://forum.mikrotik.com/t/v6-36rc-release-candidate-is-released-wireless-fp-package-is-discontinued/97337/96 Скорее всего, у тебя проблемы с драйвером аппаратного шифрования, из-за которого пакеты неправильно передаются. При TCP это часто приводит к плохой производительности на одном потоке. Можешь проверить, переключившись на программное шифрование.

mortar8

Guest

29.04.2016 11:01:00

О, парень, ты попал в точку. Аппаратное шифрование у меня сломано на всех версиях с 6.23.1 по 6.35.1 на CCR1016 и на одноядерном режиме практически бесполезно. Это значит, что при копировании файлов через туннель… Спасибо, что упомянул об этом.

chechito

Guest

02.05.2016 03:21:00

Этот тест подтверждает проблему http://forum.mikrotik.com/t/10-gig-over-eoip-tunnel-it-is-possible/92210/1 1,7 Гбит IPSec с шифрованием (MTU 1500) — минимум 25 соединений, чтобы добиться максимальной пропускной способности. Где-то около 68 Мбит/с на одно TCP-соединение, возможно, использование SMB 3.0 улучшит ситуацию за счёт нескольких соединений на передачу https://blogs.technet.microsoft.com/josebda/2012/06/28/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0/

Engitech Guest	#5 0 07.05.2016 05:59:00 Привет! Я вижу, что для теста iperf ты используешь Windows — не мог бы ты повторить тест на Linux? Я сделал такое же оформление и заметил большую разницу в результатах между Windows и Linux.

alexjhart

Guest

20.05.2016 16:07:00

Общаясь с Mikrotik, выяснилось, что текущая проблема с железом заключается в том, что пакеты из одного и того же соединения обрабатываются разными ядрами, из-за чего инкапсулированные пакеты уходят в неправильном порядке. В результате устройство на другом конце туннеля получает повторяющиеся подтверждения, пакеты не по порядку и так далее (TCP думает, что пакеты потеряны, пытается компенсировать, но это занимает дополнительное время и использует больше пропускной способности). Всё это приводит к плохой скорости передачи данных по одному потоку. Конечно, для некоторых соединений (с высокой задержкой) и сервисов вроде SMB, которые изначально не рассчитаны на ошибки в соединении (особенно старые версии), ситуация ещё хуже. Часто нельзя контролировать, какой трафик и сервисы будут использоваться на соединении, поэтому лучше исправлять проблему прямо на устройстве, которое шифрует и вызывает эти баги. Думаю, одним из решений, которое они рассматривают, может быть закрепление соединения за одним ядром. Хорошая новость в том, что чипсет Tile сможет аппаратно шифровать несколько сотен мегабит в секунду на одном ядре — это лучше, чем программное шифрование без ускорения. Я пока обхожусь несколькими софтовыми туннелями с балансировкой нагрузки в качестве временной меры, пока не выпустят исправление драйвера для аппаратного шифрования. Это даёт около 150 Мбит/с на поток, умноженное на количество туннелей, и это лучше, чем то, что я получаю сейчас с плохим аппаратным шифрованием. Я запросил обновление по своему тикету у Mikrotik, и они говорят, что работают над исправлением — отличные новости. Надеюсь, это не займет слишком много времени.

nathan1

Guest

13.06.2016 04:09:00

Привет, Алекс! Похоже, я воюю с той же раздражающей проблемой: http://forum.mikrotik.com/t/eoip-packet-reordering-with-ipsec-load-balancing-across-cores-per-packet-vs-per-flow/96935/1 У меня тоже открыт тикет в MT с 7 апреля (#2016040766000158), и мне продолжают отвечать расплывчато «мы работаем над этим», но без каких-либо сроков. С любопытством, когда ты им сообщил об этой проблеме для своего тикета?

alexjhart

Guest

13.06.2016 04:23:00

Да, скорее всего, это та же проблема. Я гоняю с ними переписку с декабря прошлого года. Только в марте они признали и поняли в чём дело. В апреле, когда я с ними говорил, казалось, что у них есть идеи, как это исправить. Последнее обновление было 20 мая, тогда они сказали: «Мы работаем над исправлением».

nathan1

Guest

13.06.2016 04:29:00

Моё последнее обновление было 10 июня: мы работаем над этой проблемой. Она появится в одном из ближайших обновлений. Вы точно увидите это в списке изменений. Боюсь, ждать придётся очень долго. Похоже, вы использовали aes-256-ctr, чтобы обойти проблему и переключиться на программное шифрование? Это ваша окончательная стабильная конфигурация? Я запускал с аппаратным ускорением, и для TCP всё было нормально, но теперь у нас есть потоки UDP, которые страдают из-за перестановок пакетов.

alexjhart

Guest

#10

13.06.2016 04:33:00

Да, вот этим я пока и пользуюсь. ПО гораздо лучше по качеству, но, к сожалению, страдает из-за узкого места в производительности. Я с тобой, как бы там ни было; надеюсь, вскоре это решат, чтобы мы получили и высокое качество, и высокую пропускную способность (то есть больший полезный объём данных).

mikruser Guest	#11 0 16.06.2016 08:58:00 CCR выпускается уже 4 года. 4 года, Карл! Ты правда думаешь, что у них не было времени разобраться с этой проблемой?

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры