Итак, начал экспериментировать с iptv. Схема подключения такая:

[источник мультикаста - другой оператор]
||
<vlan 208, 192.168.208.0/30>
||
[cisco-like switch ]
||
<vlan 108, 172.28.254.0/24>
||
[DXS-3326GSR]
||
<клиентский vlan>
||
[DES-3028]
||
[клиент]

На цисковском коммутаторе поднят pim-sm на интерфейсах в сторону другого оператора, с которого идет мультикаст, и в сторону dxs. Прописан статический RP, допустим, 111.111.111.111. Во влане 208 только два устройства - мой коммутатор и коммутатор другого оператора. Во влане 108 тоже только циска и dxs.
На dxs поднят pim-sm на интерфейсе клиентского и 108 влана, включен igmp, в клиентском влане - igmp snooping. Прописан статический RP тот же, что указан выше, и статический маршрут к этому RP через 108 влан на циску.
На 3028 включен igmp snooping.

Все, в принципе, отрабатывается нормально: клиент подключается/отключается к группам, iptv бодренько отображается на мониторе.... Правда, каналы медленно переключаются, но это косяк циски (при тестовом включении компьютера в 208 влан все переключается моментально, при включении в 108 через циску - тормозит, по мониторингу видно, что циска быстро шлет все join'ы но почему-то сам мультикаст в 108 влан начинает отправлять с большой задержкой) и это нас сейчас не интересует... А интересует нас то, что при просмотре одного несчастного канала одним несчастным клиентом (мегабита 2 или типа того) загрузка процессора на DXS не опускается ниже 60 процентов, что вызывает подтормаживания работы в целом, выпадение кадров ТВ-потока в частности и обоснованные сомнения в том, что вся эта конструкция может работать в продакшене. Как только нажимаю stop в VLC, клиент выходит из группы и поток перестает поступать - загрузка возвращается к нормальным 8-10 процентам.

Пожалуйста, подскажите, в каком направлении копать. Поиском по форуму, например, видел, что возможны какие-то проблемы, если вещание идет не с адреса, находящегося непосредственно на интерфейсе коммутатора (viewtopic.php?p=276216#276216). Может в этом проблема?
Заранее спасибо!

Версия прошивки?

4.40-B16
В принципе, 4.50-B09 у меня залита вторым image'ем, могу в нее попробовать завтра перезагрузиться... Просто, на самом деле, не хотелось терять web-интерфейс... LBD мне не нужен - его на уровне доступа/агрегации делают 3526/3028... Какие там еще изменения в 4.50? На память сейчас не помню... А в web-интерфейсе бывает удобно по быстрому что-то глянуть.
Конечно, если это конкретный баг в 4.40, то придется загружаться в 4.50, но если есть какой-то workaround без замены прошивки - было бы хорошо...
Хотелось бы, главным образом, понять, из-за чего именно мультикаст вызывает такую загрузку. Ясное дело, что он обрабатывается процессором, но у других ведь людей нормально все...

По настоящему основных причин такого поведения любого PIM роутера две:

1) Интерфейс смотрящий в сторону источника находится не в той же подсети что интерфейс ближайшего uplink устройства.

2) TTL Multicast пакетов при входе на устройство равен 0.

Но похоже что в вашем случае всё нормально в этом плане. Но всё-таки попробуйте прошивку без WEB-интерфейса, которую я вам выслал.

Поставил высланную прошивку 4.50-B12 - ничего не изменилось...
Посмотрел ttl - нормальный. Начал осмысливать первую причину, которую вы озвучили, но пока не осмыслил... Тот факт, что мультикаст поступает не с какого-то локального источника, а из интернета, ни на что не влияет?
Вот пример пакетов потока в 108 влане (т.е. непосредственно то, что льется на dxs):

11:26:58.380838 IP (tos 0x0, ttl 24, id 0, offset 0, flags [DF], proto UDP (17), length 1344) 77.246.100.186.34639 > 224.0.42.53.5000: UDP, length 1316
11:26:58.383478 IP (tos 0x0, ttl 24, id 0, offset 0, flags [DF], proto UDP (17), length 1344) 77.246.100.186.34639 > 224.0.42.53.5000: UDP, length 1316
11:26:58.385906 IP (tos 0x0, ttl 24, id 0, offset 0, flags [DF], proto UDP (17), length 1344) 77.246.100.186.34639 > 224.0.42.53.5000: UDP, length 1316
11:26:58.387336 IP (tos 0x0, ttl 24, id 0, offset 0, flags [DF], proto UDP (17), length 1344) 77.246.100.186.34639 > 224.0.42.53.5000: UDP, length 1316
11:26:58.389264 IP (tos 0x0, ttl 24, id 0, offset 0, flags [DF], proto UDP (17), length 1344) 77.246.100.186.34639 > 224.0.42.53.5000: UDP, length 1316
11:26:58.391240 IP (tos 0x0, ttl 24, id 0, offset 0, flags [DF], proto UDP (17), length 1344) 77.246.100.186.34639 > 224.0.42.53.5000: UDP, length 131

Удалил предыдущее сообщение, в котором думал, что решил вопрос - оно было ложное.
Проблема по прежнему актуальна. Чтобы убрать лишние звенья засунул dxs прямо в 208 влан, т.е. он напрямую смотрит в подсеть, откуда идет мультикаст от вышестоящего оператора. Ситуация та же - постоянная загрузка более 50% при просмотре одного канала одним пользователем (но зато каналы стали переключаться моментально - а то Циска, как я и говорил, тормозила процесс до десятка секунд).... Какие еще будут советы по решению вопроса?
Буду очень признателен за помощь!
Или, может, имеет смысл сразу клянчить что-нибудь из серии 36хх на тест и на них экспериментировать? В принципе, готов сменить оборудование, если на этом проблема по любому не решается...

Я Вам почтой ответил.

Я думаю проблема актуальна для многих.

Складывается такое ощущение что свич начинает коммутировать пакеты при помощи CPU. Прошивка 4.50-B08

У меня на тестовом стенде схема аналогичная






единственное в m_cast втыкаются 3526 с ISM VLAN.

Собственно, для своей проблемы я нашел workaround и уже давно его успешно использую. По словам Демина Ивана в HQ признали наличие проблемы и в будущем возможен фикс. Извиняюсь, что в ветку не отписался...
Как оказалось, проблема была действительно в том, что адрес источника мультикаста (именно источника, а не соседнего роутера, с которым шло общение по pim-sm) не был из той подсети, откуда мультикаст шел. Т.е. мультикаст шел вообще с каких-то там интернетовских адресов 77.246.х.х или типа того, на них специального маршрута не было и по идее связность должны была идти через дефолтный маршрут, который был в другом vlan'е. И когда свич видел трафик с этих адресов с vlan'е с ТВ - он вешался.
Workaround очень простой: добавить руками статические маршруты на адреса источников через vlan, откуда поступает мультикаст. Эти адреса после этого для свича, ясное дело, станут недоступны (но они ему и не нужны), зато он, очевидно, вносить определенную запись в свои хардварные маршрутные таблицы, CPU перестает задействоваться и загрузка снижается до 10% или типа того.
У меня так уже работает около месяца без каких-либо проблем.

Основной вопрос, какой остается в результате: как ведут себя в аналогичной ситуации dgs-36xx. Иван мне, по-моему, ничего не ответил - наверное, нет возможности воспроизвести ситуацию на стенде. Но вопрос, ИМХО, актуальный и было бы неплохо, чтобы владельцы 36xx отписались, если у кого-то работает аналогичная конфигурация мультикаста.

Да Вы правы - выше все было разжевано...

Вобще проблема действительно общая: на телесинах и цисках наблюдается такой же эффект.

Спасибо.

Не помню чтобы не ответил. Ну ладно!:) Это особенность всех PIM-роутеров. В любом случае решение проблемы описано.

Я не в том смысле. Мы эту проблему обсудили, но на dgs-36xx, если я правильно помню, вы воспроизвести не пробовали. По крайней мере, ничего потом на эту тему не отписали. Но в принципе, это не принципиально, раз уж вопрос изучен и ясно, откуда ноги растут и что делать.