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

Производительность GRE поверх IPsec в Samba

Производительность GRE поверх IPsec в Samba, RouterOS

R0bert

Guest

13.07.2015 13:56:00

Здравствуйте! У нас проблема с сетью — очень низкая скорость копирования через GRE или IPIP IPsec туннель. После обновления до последней версии прошивки 6.30 скорость копирования через SCP на Linux-машинах улучшилась. Но если пытаемся копировать файлы по SMB на Windows-машинах — скорость просто ужасно низкая. Если отключаем IPsec, скорость очень хорошая, примерно на уровне максимума ISP.

С обеих сторон у нас CCR1036-8G-2S+
GRE MTU 1426
Don’t Fragment: нет
Clamp TCP MSS включен
IPsec хеш-алгоритм sha1, шифрование aes-128

Мы также пробовали правило mangle, которое меняет TCP MSS в GRE туннеле на 1300 — ничего не изменилось. Возможно, проблема всё ещё связана с перестановкой пакетов. Узлы находятся удалённо, задержка round trip около 120 мс. Пробовали менять GRE MTU на 1400 как с правилом mangle (меняющим MSS на 1300), так и без — результата нет.

Какие идеи?

R0bert Guest	#2 0 04.08.2015 07:15:00 Есть идеи?

doneware

Guest

04.08.2015 09:12:00

Вот несколько общих ответов. Перестановка пакетов может убить производительность IPSEC, как и фрагментация. Проверьте /ip ipsec stat на наличие “state-sequence-errors”. Если таких много, значит пакеты ESP приходят не по порядку, их сбрасывают, а потом содержимое оказывается отсутствующим на уровне TCP. Какой режим IPSEC вы используете? Transport или tunnel? Transport даёт меньше накладных расходов, поэтому вероятность фрагментации зашифрованного пакета, который покидает ваш роутер, меньше. Какой MTU на вашем исходящем интерфейсе? 1500 байт? Без апиксов ваши GRE или IPIP инкапсулированные пакеты будут всего 1446 байт, их можно пересылать куда угодно. Используйте эту ссылку, чтобы рассчитать реальные размеры пакетов: https://cway.cisco.com/tools/ipsec-overhead-calc/ipsec-overhead-calc.html или просто захватите один исходящий пакет с помощью снайфера на WAN-интерфейсе, чтобы увидеть, уходит ли он с роутера целиком или фрагментируется. Если используется tunnel mode, в итоге получите 1512 байт — это слишком много для стандартного MTU 1500 в интернете. Transport mode укладывается в 1496 байт, но если у вас PPPoE на канале в интернет — это может вызвать проблемы. Насколько я понимаю, с TCP MSS 1300 проблем не будет — конечно, если речь о TCP. Зато UDP-трафик будет фрагментироваться, если приходит с LAN, где MTU 1500, и если пакет больше MTU вашего GRE-туннеля (1426).

R0bert

Guest

04.08.2015 10:15:00

статистика IPsec: in-errors: 0, in-buffer-errors: 0, in-header-errors: 0, in-no-states: 66442, in-state-protocol-errors: 178330, in-state-mode-errors: 0, in-state-sequence-errors: 0, in-state-expired: 0, in-state-mismatches: 0, in-state-invalid: 3986, in-template-mismatches: 7461, in-no-policies: 418715, in-policy-blocked: 0, in-policy-errors: 0, out-errors: 0, out-bundle-errors: 0, out-bundle-check-errors: 0, out-no-states: 1900866, out-state-protocol-errors: 5882, out-state-mode-errors: 0, out-state-sequence-errors: 0, out-state-expired: 5882, out-policy-blocked: 0, out-policy-dead: 0, out-policy-errors: 0.

Туннельный режим, транспортный. MTU исходящего интерфейса 1500 байт. MTU на GRE-интерфейсах 1426 с включённой опцией clamp TCP MSS. Я также пробовал менять tcp mss на 1400 и 1300 через правило mangle — проблема осталась той же.

alexjhart Guest	#5 0 17.12.2015 16:17:00 У меня схожая настройка и похожие результаты. Мне тоже дали такой же совет, но я уже применял его, и никаких улучшений не заметил.

ZeroByte

Guest

17.12.2015 16:51:00

Похоже, у вас загружен процессор. Когда у вас настроена гибридная связка Mikrotik/Cisco и она работает нормально, попробуйте передать файл в обратном направлении — посмотрите, упадёт ли скорость или останется высокой. В любом случае следите за загрузкой процессора Mikrotik во время передачи.

alexjhart Guest	#7 0 17.12.2015 18:25:00 Мой случай — CCR1036 к CCR1036. Задержка 0 мс (10 футов Ethernet между ether10 на каждом устройстве). Я уже настроил clamp-tcp-mss на туннеле, использовал iperf3 с MTU, установленным на 1300, но все тесты страдают (smb, iperf, http и так далее). Я пробовал изменить MTU на 2000 и L2MTU на 3000 в моей лабораторной конфигурации между физическими интерфейсами (ether10) и выключил clamp-tcp-mss на GRE-туннеле, так как все остальные интерфейсы теперь имеют MTU меньше, чем у GRE-туннеля (1926). Тем не менее, при UDP-тесте я вижу примерно на 25% больше потерь пакетов, а SMB падает в 10 раз — с 750 Мбит/с (с выключенным шифрованием) до 75 Мбит/с (с включённым). При тестах нагрузка не превышает 20%. Профили показывают более 90% простоя, и ни один процесс не использует больше 3%. По крайней мере, в моём случае я довольно уверен, что не достиг предела CPU или аппаратного шифрования. Хотя mrz говорит, что проблема может быть в драйвере (http://forum.mikrotik.com/t/high-speed-vpn-100mbps/75714/1 http://forum.mikrotik.com/t/gre-over-ipsec-ccr-very-slow/76641/1 http://forum.mikrotik.com/t/solved-ccr-ipsec-rekey-problem/91042/1), Марис из службы поддержки пишет мне: «Драйвер уже улучшен. Нужно избегать фрагментации. Если у вас UDP-трафик, отправляйте более мелкие пакеты, около 1450 байт или меньше. Если TCP — нужно уменьшать MSS, это можно сделать с помощью правил change-mss в mangle».

Читают тему

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