Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • 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
    Правило переключения CRS: скорость

    Правило переключения CRS: скорость

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Правило переключения CRS: скорость, RouterOS
     
    ahmdzaki
    Guest
    #1
    0
    06.02.2023 12:31:00
    Мы работаем на CRS-326-24S+2Q+ с ROS v7.6. Все порты загружены примерно на 80%. Все порты выполняют аппаратную фильтрацию VLAN в режиме моста. Некоторые порты настроены на аппаратное объединение (bonding). Аппаратное ускорение для L3 не включено. Агрегированный трафик составляет примерно 25–32 Гбит/с.

    Но почему-то лимитер скорости на чипе коммутатора не ограничивает трафик так точно, как ожидалось при высокой пропускной способности. Мы применяем ограничение только по входящему трафику, основываясь на VLAN ID. При установке лимита в 2000 Мбит/с на другой стороне получаем только 1930–1935 Мбит/с. Мы ожидали 1995–2000 Мбит/с, потому что при тестировании QoS на Cisco N9K и N3K получаем ровно 2000 Мбит/с.

    Мы используем формулу (1024 × 2G) × 102% для достижения около 2000 Мбит/с (не меньше). Клиенты жалуются, что при заявленных 3 Гбит/с трафик фактически только около 2500 Мбит/с, причем время от времени возникают тайм-ауты на линии.

    Судя по цифрам, 3 Гбит/с — это как бы меньше 2000 Мбит/с, и теряется где-то 50–70 Мбит/с. Возможно, это баг при использовании большого количества правил на коммутаторе? Это ошибка в QoS MikroTik, основанном на чипе коммутатора? Или это проблема с настройками? Мы пробовали ограничивать по src-dst IP, VLAN, src-dst IP — результат всегда одинаковый.

    Примечание: если тестировать с помощью Mikrotik btest, когда коммутатор стоит посредине, он показывает точную пропускную способность. Но при использовании реального трафика скорость снижается на 10–50 Мбит/с на каждый Гбит/с.



     
     
     
    joshhboss
    Guest
    #2
    0
    14.02.2024 02:26:00
    Как именно ты это сделал? Я пытаюсь измерять скорость входящего и исходящего трафика на портах, но они работают просто ужасно... Исходящий вроде норм, а вот входящий вообще не совпадает.
     
     
     
    blacksnow
    Guest
    #3
    0
    05.06.2024 03:25:00
    Просто поднимаю эту тему, у меня точно такая же проблема, как и описано выше. Egress shaper работает как и ожидалось. Но ingress policer ограничивает скорость примерно до 1/10 от того значения, которое вы задаёте в rate. Например, при rate 1G с iperf3 вы получаете 100 Мбит/с. Увеличьте rate до 10G — и всё равно остаётся 100 Мбит/с. Поднимаете до 50G — и коммутатор перестаёт работать, скорость 0 Мбит/с. Всё это на версии 7.15 CCR2216.
     
     
     
    mkx
    Guest
    #4
    0
    05.06.2024 03:54:00
    Какой тип трафика это был, TCP или UDP? Попробуйте UDP... проблема с ingress policer в том, что он может только сбрасывать лишние кадры, а сброс пакетов сильно портит TCP (egress shaper может задерживать пакеты, что для TCP довольно неплохо). У вас включён контроль потока на порту с ограничением скорости? Если нет, попробуйте его включить (и на другой стороне тоже), в теории это должно помочь, так как сигнализирует передатчику замедлиться без фактического сброса кадров.
     
     
     
    chechito
    Guest
    #5
    0
    05.06.2024 04:26:00
    В версии 7.15 у вас теперь новые возможности https://help.mikrotik.com/docs/pages/viewpage.action?pageId=189497483
     
     
     
    blacksnow
    Guest
    #6
    0
    05.06.2024 06:31:00
    Думаю, QoS — это вариант, хотя у меня в голове QoS больше про качество и приоритет пакетов, которые передаются, а не как ограничитель в плане контроля трафика, типа очередей или лимитирования пропускной способности порта. К тому же у него нет такой точечности, чтобы контролировать пропускную способность для конкретных адресов или с них. Я тестирую iperf3 с TCP-трафиком, и даже при использовании BBR для контроля перегрузки, который по сути просто пытается пропустить через канал максимум, я всё равно вижу сильно сниженный throughput вне зависимости от поставленного лимита на входе. Что-то точно не так.
     
     
     
    chechito
    Guest
    #7
    0
    05.06.2024 06:42:00
    Посмотрите на этот пример работы QoS-HW http://forum.mikrotik.com/t/qos-hardware-offloading-qos-hw/166573/1
     
     
     
    mkx
    Guest
    #8
    0
    05.06.2024 07:24:00
    Как я уже писал: потеря пакетов творит хаос для TCP. Другой момент, с которым должен справляться контроль перегрузок, — это изменяющееся или долгое время задержки (RTT)… и с этим довольно успешно работают разные алгоритмы (если не сказать «хорошо»). Поэтому первое, что нужно сделать, — протестировать с помощью UDP, который не реагирует на потерю пакетов и не зависит от двунаправленной связи, так что четко покажет, действительно ли входной полисер ведет себя так неконтролируемо, как это кажется по твоим тестам… или нет. И ты так и не ответил на мой вопрос по управлению потоком.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры