Добрый день

Экспериментирую с DES-3828 в качестве мультикаст-маршрутизатора (PIM-SM). Упрощённо схема такая: мультикаст-поток входит в один из vlan'ов коммутатора из linux-машины (на коротой работает PIM-SM) и выходит из другого(других) vlan'ов этого коммутатора клиенту.
На коммутаторе настроены PIM-SM и IGMP(v2).

Вроде бы всё работает. Но есть одно огромное НО:
загрузка CPU коммутатора возрастает пропорционально количеству проходящих сквозь него мультикаст-пакетов в единицу времени, и при уровне порядка всего-то 400-500 пакетов в секунду загрузка CPU составляет 100%!!!

Внимание вопрос: это так и задумано, или всё же мне стоит побороться с кривизной собственных рук?
(Всё же я предполагал, что проброс мультикаста из одного vlan'а в другой осуществляется аппаратно, с минимальным участием CPU. А похоже, что это не так?)

ps. Попробовал использовать cpu_interface_filtering. Как только запрещаю прохождение мультикаст-udp трафика в cpu access_profile, так сразу загрузка CPU падает. Это хорошо. НО вместе с этим прекращается и маршрутизация: входящий трафик есть, исходящий отсутствует.

Boot PROM Version: Build 0.00.008
Firmware Version: Build 3.00.B59
Hardware Version: 1A1

Обнадёжте меня please, скажите что я идиот:D, и чтобы оно заработало надо сделать всего-то...

У Вас реальный IP-адрес сервера или стримера находится в одной подсети с интерфейсом свитча?

Сорри, не вполне понял вопрос.
Вы имеете в виду "не находится ли УПРАВЛЯЮЩИЙ интерфейс коммутатора в одной подсети с вещающим сервером"?
Нет, managemnt vlan коммутатора (он же default vlan) находится в другой подсети, которая используется исключительно для управления.

Более того, даже если вообще исключить все порты подопытного DES-3828 из управляющего vlan'а и запретить management IP-интерфейс (работаю через консоль), проблема остаётся. То есть маршрутизация мультикаст-трафика и в этом случае продолжает идти "нормально", но при этом вся нагрузка ложится на CPU коммутатора.

Вы не могли бы перезвонить в офис по телефону 744-00-99 доб.390.

Проблему удалось решить самостоятельно.
Спасибо за участие
и стимуляцию мозговой активности

Рад слышать!

Неплохо, если бы описали пути решения. Имеется аналогичный аппарат и тоже пытаюсь настроить маршрутизацию Мультикаста. Если можно здесь или на e-mail отпишите пожалуйста суть проблемы (она вроде в общем видна из текста) и пути решения.

Если можно фрагмент конфига с настройками в мыло. Спасибо.

wander1 (....) mail.ru

_________________
OS Freebsd 6.2, D-Link user: DES-3828, DES-3326SR, DGS-1216T, DES-1226G, DES-3010G, DES-2108, DWL-3200AP, DWL-2000AP.

В общем настройка Multicast маршрутизации описана здесь http://www.dlink.ru/technical/faq_hub_switch_85.php Если будут вопросы звоните.

Да пожалуйста, вдруг и впрямь кому поможет. Дело, значит, было так...
I. До недавнего времени у нас работала следующая схема (очень упрощённо):а) мультикаст-поток рождается внутри линукс-машины (1) и отдаётся во вне через работающий на этой же машине PIM-SM маршрутизатор.
Объединение "в одном флаконе" вещателя с маршрутизатором решает проблему загрузки канала передачи данных: в моём варианте из "вещателя" наружу выходят пакеты только тех мультикаст-групп, которые реально запрашиваются клиентами (для сравнения: обычный "тупой" вещатель "выплёвывает" наружу ВСЕ порождаемые внутри него пакеты независимо от того, просил ли их кто-либо или не просил);
б) далее мультикаст-поток поступает на вход другого линукс PIM-SM маршрутизатора, который раздаёт его конечным пользователям (находящимся в разных VLAN'ах)

II. На днях появилась "свободная" сумма "общечеловеческих ценностей", достаточная для приобретения DGS-3612G . К сожалению, эту "железяку" у меня "увели" буквально из-под носа, поэтому пока пришлось ограничиться приобретением DES-3828.
Вышеобозначенный свежеприобретённый девайс (2) был установлен в уже работающую систему "в разрыв", как показано на следующей (опять же сильно упрощённой) схеме:
К слову сказать, DES-3828 - первое Layer-3 устройство в моей практике, но тем не менее весь процесс его настройки (создание VLAN'ов и ip-интерфейсов, поднятие IGMP и PIM-SM и их настройка заняли совсем немного времени). Интерфейс командной строки у DLink'а на высоте, работа не вызывает затруднений, все параметры говорят сами за себя, и при соответствующем понимании сути поставленной задачи и знании соответствующих сетевых протоколов процесс конфигурирования интуитивно понятен, и в общем-то обращение к мануалам и FAQ'ам не требуется. За что, конечно же, благодарность и разработчикам, и отдельное большое спасибо службе техподдержки: ребята, вы - супер!
Ну так вот, система очень быстро "завелась" (единственная оговорка - пришлось обновить Firmware: тот релиз, что выложен в официальном доступе, с завидным постояннством "вылетал" в exception mode).
Но, как я и говорил ранее, "вылезла" проблема зависимости загрузки CPU коммутатра от количества проходящих пакетов.


III. В моём случае решение оказалось совершенно нетривиальным и трудно объяснимым: смотрите следующий рисунок и найдите 10 отличий с предыдущим В двух словах: конфигурация коммутатора совершенно не поменялась. Изменения коснулись расположения Rendez-vous Point (точки встречи - RP) для мультикаст-групп,вещаемых сервером 1.
В предыдущей схеме (там, где наблюдалась огромная загрука CPU) точка встречи располагалась на вещательном сервере, в одной подсети с интерфейсом коммутатора.
В актуальной же схеме точка встречи (RP) ушла "вглубь" вещательного сервера и стала располагаться в той подсети, из которой собственно и исходят мультикаст-пакеты. В этом случае загрузка CPU коммутатора вернулась к норме и перестала зависеть от рэйта (скорости) маршрутизации пакетов.

Другой, тоже нормально работающий вариант размещения точки встречи показан на следующей схеме. В этом случае нагрузка на CPU также остаётся в норме.

Resume.
Если точка встречи (RP) находится в одной сети с PIM-SM-enabled интерфейсом коммутатора, но при этом НЕ совпадает с IP-адресом этого интерфейса (т.е. находится вне коммутатора), то DES-3828 начинает сильно напрягаться.
Это не bug, это - feature!

зы. Информация актуальна для FW 3.00.B59.
ззы. Информация о точках встречи в моей сети передаётся через механизм bootstrap. Причём bootstrap-сервером является DES-3828, rp-серверами являются "вещатели" (на моих схемах показан один, реально их много).

какой софт (демон) используете для PIM роутинга под линуксом?

xorp (ver 1.4)
Ссылка на сайт разработчиков http://xorp.org/

Не мог бы выложить конфиги XORP? А то скомпилил его запустил а заставить работать как надо не могу!

Мог бы, если так надо...Оговорки:
1) реальный конфиг сложнее и интереснее. здесь я привёл только фрагмент, касающийся протоколов pim/sm и igmp. и только для одного интерфейса (в моём случае имя интерфейса - bond0.4094)
2) в секциях protocols/pimsm4 и plumbing/mfea4 обязательно должно присутствовать описание служебного интерфейса register_vif!!! Иначе работать не будет!
3) в секции bootstrap вместо описания кандидата в rendez-vous point (cand-rp) можно для начала поместить описание статической точки встречи (static rps)
4) ну и конечно же в самую первую очередь следует разобраться с теорией работы протокола pimsm

С теорией работы PIM я только и делаю что разбираюсь!!! Вопрос тогда другой как у тебя построен сервер, а именно сама вещалка она передаёт поток на определенный интерфейс? Или же это не имеет значения? Просто для меня не понятно как это реализовать!
Static rps я с самого начала прописал, без него xorp постоянно ругался на его отсутствие!

И ещё куда смотрит этот интерфейс который ты описал в конфиге(Bond....)?Я так понял наружу!

И поясни пожалуйста про служебный интрфейс как он используеться!!

С протоколом igmp я проблем не испытываю всё работает как надо! и igmp snooping в свичах тоже!! Цель моя чтобы с вещающего сервака поток выходил только тот который запрашивают! Просто хочеться доделать всё до конца что бы не испытывать потом проблемы!

Если чё не так спрашиваю прошу прощения я не очень в этом разбираюсь!

Я в вышеприведённом примере для краткости описАл только один интерфейс (bond0.4094). Естественно, что для работы юникс-машины как маршрутизатора, должно быть 2 или более интерфейсов.
Просто опиши в секциях interfaces, protocols/pimsm4/interface, plumbing/mfea4/interface (и при необходимости в protocols/igmp/interface) по образу и подобию все интерфейсы, которые у тебя должны участвовать в pim/sm-обмене, и будет "счастье".
В моём случае итнерфейс bond0.4094 "смотрит" в сторону вещателя (который, впрочем, физически находится на той же машине, что и роутер, хотя это не принципиально).
Служебный интерфейс register_vif - это "сердце" pim/sm маршрутизатора. Почитай соответствующий RFC2362.