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

Плохая производительность IPSec между двумя CCR1036.

Плохая производительность IPSec между двумя CCR1036., RouterOS

mvnet

Guest

27.01.2015 23:43:00

Текущая конфигурация: два CCR1036 с последней версией routerOS 6.25. Ноутбук подключается к каждому CCR1036 как к LAN-устройству. WAN-интерфейс CCR1036 настроен на авто-определение 1000M full-duplex. Хочу запускать IPsec и OSPF, поэтому используется GRE.

Первый тест: без IPsec и GRE, только OSPF. Производительность отличная, FTP файла на 200М за менее чем 3 секунды, 88Мбайт/с.
Второй тест: добавляем GRE с OSPF. Тоже всё хорошо, FTP показал похожий результат.
Третий тест: IPsec, GRE и OSPF вместе. Производительность ухудшилась. FTP того же 200М файла занял 23 секунды, 8.6Мбайт/с.
Четвёртый тест: IPsec, GRE, OSPF и меняю WAN на 100M full-duplex. Производительность лучше, чем в третьем тесте. FTP того же 200М файла занял 18 секунд, 11Мбайт/с.

Пробовал тесты на routerOS 6.23, производительность примерно такая же. Интересно, почему 100M работает лучше, чем 1G. Какую производительность можно ожидать от CCR1036? Спасибо.

mvnet

Guest

18.02.2015 21:12:00

Только что обновился до последней версии 6.27, а производительность по-прежнему ужасная, когда у меня оба CCR подключены подряд с использованием auto-negotiate (связь на 1G). Конфигурация с фиксированной скоростью 100M full duplex работает гораздо лучше. Ещё один момент, забыл упомянуть: если интерфейс настроен на no negotiate и фиксирует 1G full-duplex с каждой стороны, они просто не подключаются.

sergejs Guest	#3 0 19.02.2015 07:59:00 Пожалуйста, убедитесь, что на обеих сторонах используется aes-256. Если на обеих сторонах действительно применяется 256, отправьте нам файл с результатами поддержки с обоих маршрутизаторов на support@mikrotik.com.

mvnet Guest	#4 0 19.02.2015 15:36:00 Привет, Sergejs, отправь по электронной почте последние файлы конфигурации и результаты тестов на support@mikrotik.com. Заранее спасибо.

sergejs Guest	#5 0 19.02.2015 17:36:00 Большое спасибо. Жду файл с результатами поддержки, чтобы выяснить, в чём проблема.

hellbringer Guest	#6 0 16.06.2015 22:27:00 Итак, что здесь произошло? Проблема с настройкой? С прошивкой? Вопрос решился? Или просто невозможно обеспечить высокую производительность IPSEC между двумя CCR1036?

mvnet

Guest

17.06.2015 15:20:00

Поддержка Mikrotik помогла мне добиться скорости гигабитного интерфейса с IPSec близкой к 100 Мбит/с, выбрав опцию AES-GCM. Стало лучше, но я ожидал, что скорость превысит 100 Мбит/с. Я отправил несколько писем в поддержку, но ответа не получил. Обновил прошивку до версии 6.28 — тоже никакого эффекта.

mikruser Guest	#8 0 04.06.2016 18:34:00 Mikrotik поддержка серьёзно рекомендует GCM на CCR??? 🤦‍♂️

mvnet

Guest

06.06.2016 15:16:00

Меня попросили попробовать. На самом деле я уже сдался с этой темой — на работу с их техникой ушёл больше года, и всё равно не смог решить свою проблему. Последнее сообщение от Mikrotik было, что у меня проблема с железом, и меня попросили проверить на другом оборудовании. У меня было два CCR1036 и один CCR1016, пробовал разные их комбинации — результат один и тот же. Так что я не думаю, что это связано с железом.

pe1chl

Guest

#10

06.06.2016 16:27:00

Думаю, проблема хорошо понятна, о ней уже говорилось в других обсуждениях. При использовании режима aes-cbc шифрование ускоряется аппаратно, при этом в оборудовании много ядер, которые могут работать параллельно. При распределении ускорения между ядрами пакеты прибывают в другом порядке из-за деталей синхронизации, и в итоге они приходят немного не так, как отправлялись. На самом деле это не должно влиять на пропускную способность, ведь так устроен интернет — он может переупорядочивать пакеты как угодно. Но на практике многие сломанные реализации TCP/IP просто слепо считают, что если между двумя пакетами отсутствует один, значит его потеряли, и его нужно переслать — при этом сразу же прилетает запрос на повторную отправку. Из-за этого при переупорядочивании тратится много канала на дублирующие пакеты. Это не ошибка маршрутизатора, а проблема конечных устройств.

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

Конечно, это могло бы снизить производительность в других случаях, особенно при бенчмаркинге. Производители обычно этого не любят, потому что именно на бенчмарках сравнивают их маршрутизаторы с конкурентами.

mvnet

Guest

#11

06.06.2016 16:42:00

Мой вопрос: какое шифрование не поддерживается аппаратным ускорением? Если используется шифрование без аппаратного ускорения, значит ли это, что задействован только один процессор? Именно поэтому производительность будет низкой. В моей конфигурации я хочу поставить Mikrotik на обоих концах радиорелейной точки-точка для улучшения безопасности. Канал способен работать на скорости 150 Мбит/с в полном дуплексе. Есть какие-нибудь советы?

pe1chl Guest	#12 0 06.06.2016 17:15:00 Похоже, aes-gcm — один из них.

mikruser

Guest

#13

06.06.2016 18:02:00

Бла-бла-бла. Много слов, но мало смысла.
>>При использовании режима aes-cbc шифрование аппаратно ускоряется, и в железе много ядер, которые могут делать это параллельно.
Никакой разницы. Много ядер параллельно можно использовать в любом режиме, с аппаратным ускорением и без него. Но одно ядро с аппаратным ускорением работает в 10–100 раз быстрее, чем одно ядро без него. И один ipsec туннель aes-cbc на одном ядре должен быть быстрее, чем любой aes-xxx туннель на любом количестве ядер!
Однако ipsec на CCR почему-то работает очень медленно. Команда Mikrotik уже много лет не может это исправить!
Возможные причины: программисты Mikrotik очень плохие или выбор процессора TILERA для RB оказался катастрофической ошибкой.

kujo Guest	#14 0 19.06.2016 07:30:00 Есть какие-то успехи с этой проблемой? Сейчас на CCR1009 работает несколько IPSec туннелей, но производительность оставляет желать лучшего Отправлено с моего iPhone через Tapatalk

Читают тему

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