Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • 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
    [6.41rc52] Проблемы с потоками в IGMP Snooping

    [6.41rc52] Проблемы с потоками в IGMP Snooping

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    [6.41rc52] Проблемы с потоками в IGMP Snooping, RouterOS
     
    NetflashTechnical
    Guest
    #1
    0
    20.11.2017 20:06:00
    Я столкнулся с интересной проблемой при тестировании IGMP Snooping на мосту версии 6.41rc52. Похоже, когда кто-то листает каналы или когда порт внезапно отключается от моста, поток начинает раздаваться на все каналы в течение от 2 до 20 секунд. Это может быстро стать настоящим бедствием, если несколько человек переключают каналы или даже если один человек быстро меняет каналы — до сотен мегабит трафика внезапно заполняют каждый порт моста. Такое ощущение, что Mikrotik вдруг не понимает, что делать с исходным потоком, и по умолчанию просто рассылает его на все интерфейсы, вместо того чтобы отбрасывать пакеты.

    На самом деле, когда устройство отключается от моста, ситуация самая плохая, потому что тогда это происходит целых 10-20 секунд. Или, если я вручную что-то меняю в мосте, например отключаю Fast Forward — бац, все потоки получают весь мультикастный трафик на десяток секунд. Включаю Fast Forward обратно — снова бац, все потоки получают весь мультикастный трафик примерно на десяток секунд.

    Для справки, тестирую на CCR1017-12S-1S+, IGMP snooping включен, Fast Forward включен, протокол STP установлен в «none». Есть идеи?
     
     
     
    w0lt
    Guest
    #2
    0
    06.12.2017 18:29:00
    Только что попробовал обновить CRS-125 до ROS 6.41 rc61… Всё по-прежнему. Примерно через 5 минут сбрасывает адреса IGMP-Snooping. Возвращаемся к началу, парни…
     
     
     
    w0lt
    Guest
    #3
    0
    18.12.2017 23:44:00
    Проблема с ROS 6.41 rc66 всё та же. Мультикаст-адреса пропадают примерно через пять минут. Mikrotik, вы собираетесь это проверить?
     
     
     
    NetflashTechnical
    Guest
    #4
    0
    04.01.2018 19:06:00
    Проблема сохраняется в финальной версии 6.41. Также пробовал на CRS226-24G-2S+RM, та же беда при использовании аппаратного оффлоадинга. По сути, это делает Mikrotik бесполезным для IGMP snooping: если кто-то слишком быстро переключает каналы, я могу заполнить каждый 1G-интерфейс на свиче за пару секунд.

    ПРИМЕЧАНИЕ: похоже, я понял, в чем загвоздка. Есть задержка между отправкой запроса на мультикаст-поток и добавлением группы в MDB. В этот промежуток поток идет и распространяется на все интерфейсы, которые участвуют в мосте или switchchip. Возможно, опция, которая бы блокировала весь трафик, не входящий в группу из MDB, могла бы решить проблему? Или может быть, сделать опцию «есть в MDB» для фаервола, чтобы пользователи могли добавить её вручную?
     
     
     
    Misi
    Guest
    #5
    0
    08.01.2018 10:35:00
    У меня такая же проблема на CCR1036-12G-4S, но она не связана с железом. В моей конфигурации разные типы туннелей (openvpn, l2tp) подключены к мосту. В таблице MDB всё вроде нормально. Но если туннель внезапно падает (клиент теряет интернет или что-то в этом роде) и виртуальный интерфейс исчезает, то мультикаст-адрес тоже пропадает из таблицы, и мост начинает рассылать трафик на все остальные интерфейсы. При нормальной работе IGMP snooping блокирует трафик, если оборудование не получило IGMP join или report через интерфейс. По моему мнению, Mikrotik блокирует только в том случае, если адрес есть в таблице MDB.
     
     
     
    NetflashTechnical
    Guest
    #6
    0
    11.01.2018 14:12:00
    100% точно то, что я тоже думаю!
     
     
     
    105547111
    Guest
    #7
    0
    05.02.2018 22:25:00
    [Ticket#2018011122005578] RE: IGMP Snooping ломает [...] В моём случае это ломает DLNA по всей сети. На любом коммутаторе, где включён IGMP snooping на мосту, клиенты начинают терять серверы. Вскоре на сети вообще не остаётся ни одного DLNA-сервера.
     
     
     
    Misi
    Guest
    #8
    0
    28.02.2018 14:34:00
    Я провел несколько тестов на своем CCR с версией 6.42rc35, и, похоже, проблема была решена.
     
     
     
    a4x4kiwi
    Guest
    #9
    0
    26.03.2018 06:34:00
    Привет, у меня такая же проблема. RB1100AHx4 на версии 6.41.3 (текущей). Та же история. Есть ли уже зарегистрированный тикет по этому поводу или кто-то знает последнюю стабильную версию? Спасибо, Мал
     
     
     
    a4x4kiwi
    Guest
    #10
    0
    28.03.2018 22:18:00
    Всем привет! Вот решение, которое сработало у меня, его предоставили в MT. По умолчанию неизвестный мультикастовый трафик распространяется по сети, но это можно изменить. Вам стоит обновиться до версии 6.42rc и на всех портах моста, через которые проходит любой IGMP-трафик, установить параметр unknown-multicast-flood=no. Всем удачи, Мал.
     
     
     
    smarag
    Guest
    #11
    0
    15.07.2018 12:30:00
    У меня такая настройка на CRS328-24P-4S+. На ether5 подключён IP streamer, на ether24 — Samsung IPTV, а на ether23 — мой ПК с VLC, который корректно показывает IPTV с стримера. Проблема в том, что после подключения или отключения кабеля с любого порта этого коммутатора IPTV с других портов зависает и начинает воспроизводиться только после переключения канала. Пожалуйста, подскажите, как исправить эту проблему.

    У меня RouterOS 6.42.5

    /interface bridge  
    add admin-mac=02:BD:3F:3F:6D:8E auto-mac=no fast-forward=no igmp-snooping=yes name=bridge protocol-mode=none vlan-filtering=yes  

    /interface bridge port  
    add bridge=bridge interface=ether1 pvid=11  
    add bridge=bridge interface=ether2  
    add bridge=bridge interface=ether3  
    add bridge=bridge interface=ether5 pvid=110 unknown-multicast-flood=no  
    add bridge=bridge interface=ether6  
    add bridge=bridge interface=ether7 pvid=11  
    add bridge=bridge interface=ether8 pvid=200  
    add bridge=bridge interface=ether9 pvid=200  
    add bridge=bridge interface=ether10 pvid=200  
    add bridge=bridge interface=ether11 pvid=200  
    add bridge=bridge interface=ether12 pvid=200  
    add bridge=bridge interface=ether13 pvid=200  
    add bridge=bridge interface=ether14 pvid=200  
    add bridge=bridge interface=ether15 pvid=200  
    add bridge=bridge interface=ether16 pvid=200  
    add bridge=bridge interface=ether17 pvid=500  
    add bridge=bridge interface=ether18 pvid=200  
    add bridge=bridge interface=ether19 pvid=200  
    add bridge=bridge interface=ether20 pvid=200  
    add bridge=bridge interface=ether21 pvid=500  
    add bridge=bridge interface=ether22 pvid=500  
    add bridge=bridge interface=ether23 pvid=110 unknown-multicast-flood=no  
    add bridge=bridge interface=ether24 pvid=110 unknown-multicast-flood=no  
    add bridge=bridge interface=sfp-sfpplus1  
    add bridge=bridge interface=sfp-sfpplus2 unknown-multicast-flood=no  
    add bridge=bridge interface=sfp-sfpplus3 unknown-multicast-flood=no  
    add bridge=bridge interface=sfp-sfpplus4  
    add bridge=bridge interface=ether4 pvid=110 unknown-multicast-flood=no  

    /interface bridge vlan  
    add bridge=bridge untagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4,ether2,ether3,ether24 vlan-ids=1  
    add bridge=bridge tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 untagged=ether1 vlan-ids=11  
    add bridge=bridge tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 vlan-ids=200  
    add bridge=bridge tagged=sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 untagged=ether4,ether5 vlan-ids=110  
    add bridge=bridge tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 vlan-ids=500  
    add bridge=bridge tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 vlan-ids=510  

    /routing igmp-proxy interface  
    add alternative-subnets=0.0.0.0/0 interface=ether5 upstream=yes  
    add interface=bridge
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры