Pull to refresh

Comments 34

На самом деле на физическом интерфейсе надо поставить получение по dhcp без днс и шлюза по умолчанию. Так будет правильнее для верной работы мультикаста.

Ну и есть вариант без прокси. Покинуть трафик с физ интерфейса бриджом до приставки. Она уже сама все получит и разберётся.

Это слишком просто, на статью хабра не хватит.

А если приставка не на отдельном порту? Или вообще на вайфае?

Зачем вообще передавать мультикаст по вафле на приставку? Он же полностью забьет канал. Ни одно другое устройство не будет иметь нормальной скорость на таком коннекте. Хотя если юзать Multicast Helper, то ситуация будет лучше. Хотя мне не особо помогло. Возможно прямолинейности рукам пока не хватает)
Не у всех проводов хватает :) Периодически наблюдаю на форуме про одного минского провайдера вопросы о подключении приставки по wi-fi.

С чего это мультикаст забьет канал? Допустим, видеопоток ~5-10 Мбит (это FullHD уже). Полоса wifi сейчас позволяет что на 2.4, что на 5ггц выдавать далеко за 100мбит. Конечно от зашумленности и эфира зависит, но тем не менее. Неужели у вас ноутбук, подключенный по wifi выдает меньше 10мбит? Чем приставка хуже?
В эфир что уникаст, что мультикаст по wifi вещается широковещательно, то есть забивает полосу.

IP-юникаст в вайфае передаётся wifi-юникастом, с подтверждением получения. IP-мультикаст от от клиента к точке доступа передаётся wifi-юникастом, а вот от точки доступа к wifi-клиенту — wifi-бродкастом, без подтверждения передачи. Для увеличения надёжности передачи без подтверждения канальная скорость wifi при передаче мультикаста снижается до минимума (6 mbps для a/g?).

Как результат (дальше цифры сравнительные в идеальных условиях, просто иметь представление о порядке масштабов катастрофы) — если у вас поток мультикаста 5 Мбит/с, то он занимает 83% эфирной полосы на скорости 6 Мбит/с. Остаётся 17% эфира, что на канальной скорости в 150 Мбит/с составляет 25 Мбит/с. Вот так от 5 Мбит/с мультикаста на ровном месте теряется 125 Мбит/с «хорошего» канала.

Как ещё одно следствие — если у wifi-оборудования для беспроводного p2p-моста нет тонких настроек для мультикаста (вроде Multicast Helper у MikroTik RouterOS), то рекомендуется настраивать так, чтобы мультикаст шёл от клиента к точке доступа, а не наоборот. Тогда мультикаст не будет давать таких больших просадок трафика.
Чуть ниже в комментариях видел уже ваши выкладки на предмет того, что скорость передачи WiFi понижается для отправки broadcast пакетов. Это для меня стало открытием (мне кажется, скорость передачи никак не связана с типом отправляемого пакета, иначе бы были постоянные «провалы» при отправке тех же arp who has и т.д.), и беглый гуглеж не дал ничего полезного. Вернее встречал аналогичные комментарии в духе «Real multicast is a form of broadcast at layer-2, and Wi-Fi can do that (send to a multicast group instead of individual unicast MAC addresses), but you are limited to the lowest available speed on the WAP», но без объяснения, почему так.
Не могли бы дать ссылки на источники?
Не то, чтобы источник, просто первый результат из Гугла: gtacknowledge.extremenetworks.com/articles/How_To/How-to-use-Wireless-Radio-Multicast-Settings-on-the-ExtremeWireless-solution, первый абзац в Additional notes

UPD: вот теперь и я обещаю обновлять комментарии перед ответом…
Сейчас уже не помню точно, но как я помню Ростелеком не давал по dhcp адрес на WAN пока не поднята PPPoE сессия.
Это если подключение по Docsis. Если PON проведён, то там от коммутатора сразу все идет без PPPoE.
Решал эту же задачу на OpenWrt для случая PPPoE от Ростелеком на WAN.

Для хождения мультикаст-пакетов добавляется маршрут на 224.0.0.0/4 (возможно он отличается в разных регионах).
И как вы верно подметили на WAN-интерфейсе нужен IP адрес.

Мне кажется, могу ошибаться, у вас не учтен случай пропадания и появления интернета на WAN-интерфейсе и соответственно тогда произойдет сброс таблицы маршрутов. Что бы это учесть я использовал скрипт на событие поднятия WAN-интерфейса /etc/hotplug.d/iface/40-myroute.
Содержимое файла 40-myroute
#!/bin/sh

[ "$ACTION" = ifup ] && {
#if [ "${$DEVICE}" = «pppoe-wan» ]; then
logger -t myroute ADD Device: $DEVICE / Action: $ACTION
route add -net 224.0.0.0/4 dev eth1 metric 1
echo «1» > /sys/devices/virtual/net/br-lan/bridge/multicast_snooping
#fi
}

Т.к. для IPTV на WAN-интерфейсе нужно что был IP адрес.
Я использовал вот такой финт ушами
config interface 'wan'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.2.2'
option netmask '255.255.255.0'
option bcast '192.168.2.255'

config interface 'wpppoe'
option ifname 'eth1'
option proto 'pppoe'
option username 'пользователь'
option password 'пароль'
option keepalive '5'

wan — это наш wan с статическим адресом для IPTV, wpppoe — это наше PPPoE соединение.

igmpproxy — использовал вместе с udpxy. От igmpproxy отказался т.к. udpxy можно и через Wi-Fi смотреть (IPTV плеер должен поддерживать проксироdание через udpxy).

Вешать на роутер адрес DNS-сервера от CloudFlare? Вы реально не нашли более полезного применения для него?

На самом деле на интерфейс можно повесить любой адрес, чтобы "от его имени" отправился ip-igmp пакет и на коммутаторе провайдера засветился. То что выбран 1.0.0.1 — это как я понял копипаста с китайской прошивки длинка(о чем в статье и написано). Не раз видел, что 1.0.0.0/8 сеть используют как приватную, не только китайцы, так что использовать ДНС клаудфларе как раз и будет "так себе решением", непонятно же через что трафик побежит не вами контролируемое. Правильно было бы написать 10.11.12.13 или что-то подобное из 10.0.0.0/8

Как «на самом деле» — это я отлично понимаю. А вот подавать плохой пример в туториалах — это уже другое. Целенаправленное вредительство, хоть, возможно, и неосознанное.
Да, можно выбрать любой адрес из 192.168.0.0/16, 172.16.0.0/20, 10.0.0.0/8 или 100.64.0.0/10 — но всё равно автор умудрился промахнуться :)

По поводу 'использовать ДНС клаудфларе как раз и будет «так себе решением»' — расскажите это всем, кто уже оценил его скорость. Не надо обсуждать, как плохо бывает, когда криворучки используют чужие диапазоны, CloudFlare уже давно писал об осознанности своего выбора. Надо хотя бы сегодня начинать делать по-нормальному.
Эта инструкция не идеальна, но автор позаботился о том, чтобы сделать её своими силами. Есть перспективы, поэтому я и выдал приглашение.
Знаю вас как отличного специалиста по микротикам и хотелось бы видеть ваши статьи здесь, как делать правильно со всеми нюансами. Если вы решитесь переступить барьер, который называется «всё можно нагуглить», статьи будут первоклассными.
Далее нужно блокировать прохождение мультикаст — траффика в беспроводную сеть

Я понимаю, что пошаговые инструкции — они такие пошаговые, но это ведь хабр — хотя бы пару слов напишите о том, зачем это делать. А то при наличии IGMP Snooping'а и Multicast Helper'а данный шаг вызывает поднятие брови.

Wi-Fi от мультикаст-потока просто падает, если не использовать IGMP Snooping.
IGMP Snooping поддерживает MicroTik? OpenWrt поддерживает.

Просто падает на OpenWRT?
Под "наличием IGMP Snooping'а", естественно, подразумевалось его наличие в RouterOS, а не в энциклопедиях по сетевым технологиям. Что значит "просто падает"? Для передачи бродкаст-пакетов (коими являются мультикастовые пакеты) вайфай переключается на самую низкую скорость — возможно, вы это и имеете в виду под "просто падает" (удивительно технический термин!). Но тут на сцену выходит RouterOS Multicast Helper — он преобразует мультикастовые пакеты в юникастовые (с подтверждением приёма), поэтому всё продолжает работать на обычных скоростях.

Омг, как все сложно. Год назад этот вопрос решал простым объединением портов в мост и отключением rstp на нем. Что изменилось сейчас ?)

Расскажите поподробнее. Объединение портов в мост и навешивание на мост адреса локалки? Что-нибудь делали для того, чтобы пакеты из локалки не утекали к провайдеру? А то некоторые провайдеры могут за такое и порт заблокировать.

Объединялся порт WAN с LAN1, в который и подключалась приставка. С локальной сетью эти пакеты никак не смешивались — для неё оставались прочие порты. Впрочем, такая конструкция работала не только на микротиках, но и на бытовых роутерах.
Ну, это слишком простой случай. В статье более общее решение :)
… которое безусловно создаёт нагрузку на процессор, в то время как бридж работает на уровне встроенного свитча. Любопытно было бы посмотреть на загрузку процессора при просмотре HD-канала.
Кстати, побочкой является «залипание» картинки на приставке при переключении каналов: дело в том, что отписывание от предыдущего потока может и не пройти мгновенно, и через snooping (который делается посредством ЦПУ) пойдут несколько потоков мультикаста. Свитч подобную красоту выдерживает без малейших проблем… В общем надо очень точно знать, зачем включается igmp-snooping и трафик приставки пробрасывается во внутреннюю сеть.

Ну, про дополнительную нагрузку на процессор — тут не поспоришь. Но насколько она значительная… Вот включил три HD-канала, суммарно 20 Мбит/с. Скриншот сделан в тот редкий момент, когда строчка igmp-proxy изредка появляется — её практически нет в профайлере.

Скрытый текст

Про залипание не понял. Как оно связано с отписыванием? Один, два, три потока будет идти через роутер — пережуёт, куда денется. Может, вы за Fast Leave опасаетесь? Так его выключить можно.


А то, что надо что-то точно знать — так я выше уже писал: сейчас понастраивают себе, не зная точно, но по инструкции — а потом будут удивляться, что второй адрес CloudFlare DNS не работает :)

Про залипание — это как раз в те моменты, когда не хватает пропускной способности ЦПУ. У вашего устройства с этим всё в порядке, вы ничего и не заметите. На более слабых устройствах при использовании igmp snooping такое бывает, не раз нарывался.
Кстати, ради интереса: остановите полностью IPTV и оцените нагрузку на процессор — у самого CPU (не igmp-proxy) цифры понизятся? Не сразу после остановки, а примерно через минуту.
Да, разговор именно про fast leave идёт.
У вашего устройства с этим всё в порядке, вы ничего и не заметите

Спасибо. Только это несчастный RB951-2n, который на MUM'ах раздавали всем просто так :) Какие ещё [значительно] более слабые устройства вы хотите делать основным шлюзом к провайдеру и насколько это адекватное решение?


Без нагрузки в виде трафика процессор, естественно, простаивает. Но нагрузка в виде пары десятков мегабит обычного интернет-трафика с котиками даёт сравнимую нагрузку на CPU.

В мост объединяются порт в который смотрит кабель провайдера и порт в который смотрит приставка, на него же вешается пппое, чтобы не блокировался на стороне провайдера, отключается rstp. Мог что то забыть, но вроде это все.

А после обновление прошивки — перезагружаемся еще раз для обновления загрузчика, если в System — Routerboard — Settings стоит Auto Upgrade. Если не стоит — ставим галочку, нажимаем Upgrade и перезагружаем роутер.

DaveRylenkov, подскажите, у вас инет по какой технологии получается от провайдера? Gpon или медь?
Sign up to leave a comment.

Articles