Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    EOIP TCP проблема

    EOIP TCP проблема

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    EOIP TCP проблема, RouterOS
     
    felix84
    Guest
    #1
    0
    10.03.2019 13:31:00
    Привет. Мы сталкиваемся с проблемами при попытке обеспечить хорошую L2-связь через WAN-соединение. С одной стороны у нас CCR1009, с другой — x86 виртуальная машина на базе Mikrotik KVM. Версия прошивки 6.42.12. Мы настроили EOIP + IPsec. На обоих концах статические IP-адреса, скорость соединения 1 Гбит/с, задержка 60 мс. Знаю, что это действительно плохо для такой сети, но на данный момент это действительно плохо. Услуги, зависящие от TCP, показывают очень низкую производительность, копирование файлов SMB — 20-30 Мбит/с, rsync, nfs, scp примерно то же самое. Я знаю о размере TCP-окна, и многие люди работают с соединениями с высокой задержкой таким образом, но iperf -w не помогает и показывает те же результаты, что и я упоминал выше. Я думал, что проблема в MTU, но настройки довольно стандартные: 1500 на lan-bridge и авто MTU на интерфейсе EOIP (1308, рассчитанный по PMTUD). Буду признателен за любую помощь.
     
     
     
    vecernik87
    Guest
    #2
    0
    09.05.2019 12:08:00
    Без eoip, при той же задержке, получаешь лучшие результаты? Не могу представить, как можно добиться хоть какой-то приемлемой скорости на tcp с задержкой 60 мс. Эта задержка просто убивает все.
     
     
     
    konstantinJFK
    Guest
    #3
    0
    08.05.2019 20:44:00
    Я могу подтвердить ту же проблему с TCP-сессиями через EOIP-соединения с IPSEC и без него. На данный момент не найдено ни решения, ни обходного пути.
     
     
     
    sup5
    Guest
    #4
    0
    09.05.2019 12:20:00
    Пока нет потерь пакетов, TCP сможет увеличить пропускную способность даже на каналах с высокой задержкой. Но даже малейшая потеря пакетов на таких каналах убьет throughput.
     
     
     
    internetolog
    Guest
    #5
    0
    13.02.2021 20:37:00
    Есть ли какие-то обновления по этому вопросу? У меня последняя версия routeros с двумя CCR1009 и гигабитным соединением. При этом UDP показывает 980 Мбит/с, а TCP всего 380 Мбит/с.
     
     
     
    mikruser
    Guest
    #6
    0
    15.02.2021 09:54:00
    это известная проблема с роутерами mikrotik на ссылках с высоким латентностью. об этом уже много раз говорили на форуме. вам нужно связаться с поддержкой.
     
     
     
    skraw
    Guest
    #7
    0
    25.02.2021 08:17:00
    L2TP вообще не является решением для чего-либо на Mikrotik, так как он нестабилен. Смотрите мой соответствующий вопрос от 15 февраля. L2TP на IPSec очень медленный при одиночных TCP потоках. И я не нашел никаких решений для обеих этих проблем. У кого-то есть? Это не зависит от высокой задержки. L2TP имеет проблему стабильности сам по себе.
     
     
     
    vikinggeek
    Guest
    #8
    0
    25.02.2021 09:12:00
    @internetolog Мои результаты тестирования совпадают с твоими. Я связался с поддержкой, но решения пока нет. Не понимаю, почему TCP так медленнее, чем UDP. Судя по опубликованным техническим данным, возможно, что туннель IPSec с аппаратным ускорением ограничен примерно 500 Мбит/с даже на больших CCR. Перепроверяю ветки http://forum.mikrotik.com/t/l2tp-ipsec-vpn-performance-on-1g-links/146938/1
     
     
     
    internetolog
    Guest
    #9
    0
    25.02.2021 19:25:00
    @vikinggeek, я решил свою проблему с несколькими соединениями l2tp без безопасности. Я разделил трафик на 4 части и теперь могу обрабатывать более 1 Гб. Надеюсь, это поможет.
     
     
     
    JohnTRIVOLTA
    Guest
    #10
    0
    25.02.2021 20:55:00
    Решение очень простое — просто используйте протокол Multilink на соединении ppp = установите mrru на 1600 на обеих сторонах и отключите tcp mss в профиле ppp тоже!
     
     
     
    vikinggeek
    Guest
    #11
    0
    27.02.2021 07:37:00
    @internetolog и @JohnTRIVOLTA: У меня никогда не было проблем со стабильностью подключения L2TP (за исключением 6.48, но это уже другая история, 6.48.1 всё исправила). Моя задача — добиться адекватной производительности IPSec на одном потоке. Нам нужна высокая скорость передачи файлов по одному каналу. Смотрю на конфигурацию PPP MultiLink, кажется, она создана для агрегации по двум или более устройствам. У меня есть только один интерфейс SPF волокна или ONT для работы. Возможно, CCR не могут обеспечить такую производительность? Вы оба, похоже, считаете, что агрегация решит проблему. Я понимаю, что агрегация увеличит общую емкость, но разве мы всё равно не ограничены примерно 300 Мбит/с на один поток?
     
     
     
    JohnTRIVOLTA
    Guest
    #12
    0
    27.02.2021 08:07:00
    Не только физические соединения, MLP может передавать полный размер пакета, а не ограничиваться TCP MSS на уровне L4! Наконец, нужно использовать AES 128 CBC для аппаратного шифрования!
     
     
     
    sindy
    Guest
    #13
    0
    27.02.2021 09:37:00
    Можешь объяснить, почему скрытая фрагментация TCP-пакетов размером 1500 байт (т.е. 2 PPP-пакета на каждый загрузочный пакет) должна обеспечивать большую пропускную способность TCP, чем передача TCP-пакетов размером 1462 байта с одним PPP-пакетом на каждый загрузочный пакет? Я понимаю, что MLPPP снимает headache, связанную с проблемами PMTUD, позволяя 1500-байтовым пакетам проходить без IP-фрагментации на уровне загрузки, но я никогда не рассматривал это как способ улучшить пропускную способность (в рамках одного соединения, конечно).
     
     
     
    JohnTRIVOLTA
    Guest
    #14
    0
    27.02.2021 11:32:00
    Нагрузка на ЦП меньше при фрагментации L3 по сравнению с сегментацией L4, это также отражается на задержках... это мой опыт. Не будем забывать о качестве интернета между двумя локациями!
     
     
     
    sindy
    Guest
    #15
    0
    27.02.2021 11:51:00
    Не только. Он делит пакет полезной нагрузки на несколько транспортных, и может использовать ту же связь для транспортировки всех этих пакетов, что обеспечивает скрытую фрагментацию полезной нагрузки. Таким образом, протоколы полезной нагрузки, не обладающие возможностью фрагментации, могут передаваться без ограничений по размеру пакетов/кадров. Если что-то не изменилось в последнее время, RouterOS поддерживает настоящую многосоединительную способность только в качестве PPPoE-клиента; в остальных случаях (PPPoE-сервер, L2TP и т.д.) он поддерживает только односоединение, но с MLPPP, если это настроено соответствующим образом (mrru установлено на определенное значение). И, как вы и сказали, снаружи, а значит, и с точки зрения IPsec, сессия L2TP с использованием MLPPP все еще представляет собой один UDP-стрим.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры