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

Медленная скорость через gre+ipsec туннель

Медленная скорость через gre+ipsec туннель, RouterOS

mikruser

Guest

18.03.2019 16:49:00

Привет, CHR, 6.44.1, 2 vcpu Xeon Gold CCR1009, 6.44.1 WAN с задержкой 45 мс [CHR]—wan(tunnel gre+ipsec)wan—[CCR1009] aes128cbc/sha1, фактический MTU = 1426 (Авто) ИЛИ aes128ctr/sha1, фактический MTU = 1446 (Авто) Тест пропускной способности на CHR к CCR (tcp, получение, 1 соединение): между публичным IP = до 300 Мбит/с между приватным IP (по туннелю) = до 120 Мбит/с и нестабильно. Почему скорость через туннель такая низкая?

anschluss

Guest

03.11.2019 13:05:00

Привет, такая же проблема здесь - два ccr1009 через 1 Gbit/сек оптоволоконные каналы, подключенные к одному коммутатору. Это результат теста пропускной способности, выполненного в выходные без другой нагрузки на сеть: Тест получения через GRE/IPsec туннель (с загрузкой ЦП):

Тест отправки через GRE/IPsec туннель (с загрузкой ЦП):

Текущая конфигурация: RouterOS 6.44.6 Оптоволоконный WAN-канал, задержка менее 1 мс CCR1009-7G-1C—GRE/IPsec (aes256cbc/sha256, фактический MTU = 1422 (Авто)—CCR1009-7G-1C. Поверьте, я потратил дни, экспериментируя с алгоритмами шифрования и другими советами с форума. Я могу прийти только к выводу, что это связано с однопоточной производительностью процессора tile GX. Кроме ошибок конфигурации (я отнюдь не эксперт в сетях), я считаю, что это не будет решено, пока не появится больше многопоточности и/или лучшая поддержка аппаратного шифрования.

anschluss

Guest

04.11.2019 02:00:00

Без проблем, вот, хотя это и не меняет дела: iperf3 -s -f M Сервер слушает на 5201 Принято соединение с 192.168.55.55, порт 61613 [ 5] локально 192.168.1.22 порт 5201 подключен к 192.168.55.55 порт 61614 [ ID] Интервал Передача Полоса [ 5] 0.00-1.00 сек 15.4 MBytes 15.4 MBytes/сек [ 5] 1.00-2.00 сек 16.9 MBytes 16.9 MBytes/сек [ 5] 2.00-3.00 сек 16.8 MBytes 16.8 MBytes/сек [ 5] 3.00-4.00 сек 17.0 MBytes 17.0 MBytes/сек [ 5] 4.00-5.00 сек 17.0 MBytes 17.0 MBytes/сек [ 5] 5.00-6.00 сек 17.0 MBytes 17.0 MBytes/сек [ 5] 6.00-7.00 сек 17.0 MBytes 17.0 MBytes/сек [ 5] 7.00-8.00 сек 16.3 MBytes 16.3 MBytes/сек [ 5] 8.00-9.00 сек 16.4 MBytes 16.4 MBytes/сек [ 5] 9.00-10.00 сек 16.7 MBytes 16.7 MBytes/сек [ 5] 10.00-10.01 сек 169 KBytes 18.7 MBytes/сек [ ID] Интервал Передача Полоса [ 5] 0.00-10.01 сек 0.00 Bytes 0.00 MBytes/сек отправитель [ 5] 0.00-10.01 сек 167 MBytes 16.7 MBytes/сек получатель К сожалению, это все еще чрезвычайно медленно по сравнению с доступной полосой.

mkx

Guest

04.11.2019 09:45:00

Результаты тестов IPsec для CCR1009, доступные на страницах с характеристиками продукта, говорят о том, что с маленькими пакетами достижимая пропускная способность составляет около 130 Мбит/с (это примерно 16 Мбайт в секунду). Проблема с тестовыми результатами, опубликованными для продуктов MT, заключается в том, что они показывают лишь абсолютный максимум... но в реальной жизни значительно меньшая цифра будет более актуальной. Например, результат теста для одного туннеля IPSec с использованием больших пакетов показывает достижимую пропускную способность более 400 Мбит/с (даже больше, чем 1 Гбит/с). Но опыт многих участников форумов показывает, что актуальная цифра для реальных случаев — это та, что с пакетами средних размеров и большим количеством правил обработки (правил фильтрации IP). Производительность IPsec не подчиняется тем же самым правилам, но в общем плане она все же схожа. Кстати, показывает ли CHR туннель IPsec с аппаратным ускорением? В любом случае, какая там загрузка ЦП? Возможно, именно CHR является узким местом. А если используются два CCR, что показывает профиль загрузки ЦП, какие процессы используют больше всего ресурсов ЦП?

anschluss

Guest

05.11.2019 00:43:00

Я не инженер по тестированию сетевых устройств — я просто консультант, настраивающий сетевое оборудование. Если после более чем суток возни с советами от более осведомленных людей мне не удается достичь приличной скорости, мне просто приходится сдаться по экономическим причинам. Хотя может быть верно, что при каких-то теоретических условиях можно достичь скорости, близкой к спецификации, для меня это не практично, если это нельзя сделать без специализированных знаний. В IPSEC вы используете DES или 3 DES? Если это 3 DES, поменяйте на DES. Вы, должно быть, шутите. Это 2019 год. Никто не должен использовать DES, если в оборудовании доступен AES. Поэтому у меня вопрос: кто-нибудь когда-нибудь достигал скорости более 17 мегабайт в секунду через туннель GRE/IPSEC? Если да, пожалуйста, расскажите форуму, как это было сделано, чтобы другие могли учиться.

KENYx120

Guest

14.01.2020 12:23:00

У меня такая же проблема (тикет службы поддержки SUP-3459) с IPSec между CCR1036 (ROS/ROB 6.44.6) и StrongSwan на CentOS 7, подключенными к 1Gbp/s каналам с пропускной способностью 300Mbit/s (скачать/загрузить). Задержка между сторонами около 18.0ms. Проверял с помощью iperf3: если активирована аппаратная AEAD (enc-algorithms aes128-cbc-aes256-cbc/aes128-ctr-aes256-ctr с auth-algorithms md5/sha1-sha256), скорость TCP загрузки (CCR → CentOS) нестабильная и колеблется от 3 до 45Mbit/s, скорость UDP загрузки фиксируется на 57Mbit/s с большим количеством пакетов вне порядка и высокой потерей пакетов (около 80% на полосе 300m). Скорость скачивания (CCR ← CentOS) с теми же настройками колеблется между 220-280Mbit/s. Если активирована программная шифрование (enc-algorithms aes128-cbc-aes256-cbc/aes128-ctr-aes256-ctr/aes128-gcm-aes256-gcm с auth-algorithms null/sha512), я получаю около 180Mbit/s на скорости TCP/UDP (UDP всё еще имеет пакеты вне порядка и потерю пакетов около 61%). Протестировано на: CCR1036-12G-4S с RouterOS 6.44.6 ↔ StrongSwan - LibreSwan (ядра от 3.10 до 5.4) - проблема присутствует; RB1100AHx2 с RouterOS 6.44.6 ↔ StrongSwan - LibreSwan (ядра от 3.10 до 5.4) - проблема присутствует; RB4011 с RouterOS 6.46 ↔ StrongSwan - LibreSwan (ядра от 3.10 до 5.4) - проблема присутствует, но средняя скорость до 80-100Mbit/s; CHR 6.46 ↔ StrongSwan - LibreSwan (ядра от 3.10 до 5.4) проблема не присутствует, всё работает прекрасно; StrongSwan ↔ StrongSwan - LibreSwan (ядра от 3.10 до 5.4) - проблема не присутствует, всё работает прекрасно; Также, эта проблема не возникает, если задержка 0-3ms.

pukkita

Guest

17.01.2020 13:09:00

Наблюдается такое же поведение с 6.46.1 между CCR1032 и 4011: на тесте скорости TCP загрузка иногда не проходит, огромные пики загрузки ЦП на 4011 (>70%), которые не отражаются на тесте скорости, и очевидные потери пакетов. EOIP+IPSec не показывает такого поведения, tcp_download начинается и завершается плавно. Измеренные скорости действительно близки, я бы сказал, на 0.5-1% меньше пропускная способность с EOIP.

KENYx120 Guest	#8 0 20.01.2020 11:45:00 Мы перешли на CHR 6.46.2. TCP и UDP работают отлично, теперь tcp_window_size на хостах Windows увеличивается корректно.

UniversitOfMurciaNOC

Guest

30.04.2020 09:08:00

Такое же поведение наблюдалось в CCR1072 и нескольких десятках IPsec туннелей в конфигурации road warrior (клиент-сайт) SHA-1 AES-CBC-256 Hardware AEAD. Использование CPU номер 15 почти всегда достигает 99%, когда трафик на интерфейсе WAN превышает 100 Мбит/с (автоопределение 1000 Мбит/с). Остальные 72 ядра находятся ниже 8-10%, а некоторые даже на уровне 0%.

andriys

Guest

#10

30.04.2020 09:49:00

Ваш случай, видимо, отличается. Исходная проблема, о которой здесь говорилось, касалась комбинации GRE+IPsec (и позже было сказано, что EoIP+IPsec не затрагивается). У вас случай "дорожного воина", и, скорее всего, это просто IPsec, без GRE. Так что... Пожалуйста, начните новую тему. И перед публикацией проверьте с помощью /tools profile, является ли это IPsec (шифрование) или что-то другое, что потребляет процессор.

mikruser Guest	#11 0 15.07.2020 20:29:00 Проблема все еще наблюдается в версии 6.47.1: первое изображение - тест с CCR до CHR по публичному IP, второе изображение - тест с CCR до CHR по приватному IP (через туннель).

mikruser Guest	#12 0 24.12.2020 21:17:00 Проблема все еще не исправлена в версии 6.48: mikrotik техническая поддержка молчит…

mikruser

Guest

#13

29.01.2021 10:21:00

KENYx120 У меня такая же проблема (заявка в службу поддержки SUP-3459) с IPSec между CCR1036 (ROS/ROB 6.44.6) и StrongSwan на CentOS 7, подключёнными к каналам 1Gbp/s с пропускной способностью интернет-провайдера 300Mbit/s (скачивание/загрузка). Задержка между сторонами около 18,0 мс. Ты получил ответ от технической поддержки? Или они отказались решать проблему?

mikruser Guest	#14 0 24.10.2021 21:15:00 Проблема все еще не решена в 6.49.

amirmahdi81 Guest	#15 0 27.02.2024 18:32:00 почти та же проблема на ccr2000/chr серии V7.13, есть какие-нибудь новости или обновления?

hubber Guest	#16 0 11.08.2024 08:19:00 pc - ccr1036 - провод - ccr1036 - pc routerOS 7.15.3 TCP - тест bandwidth и iperf3 от pc до pc eoip ipsec 238Mbit - 1 ядро 82%, top - сеть ipip ipsec - 260Mbit 1 ядро 95%, top - сеть gre ipsec - 240Mbit 1 ядро 90% wireguard - 550Mbit

inteq Guest	#17 0 03.11.2019 23:36:00 Тестируйте с помощью iperf3 с клиента, находящегося за каждым из ваших роутеров. Не используйте сами роутеры.

Читают тему

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