Ну, всё правильно.
VID :800

Вот с какого перепуга он должен ловить igmp запросы в любом тэгированном влане и подмешивать туда мультикаст? Он будет делать это только в VID=800.

Ну вообще, осмелюсь с вами не согласиться. ISM технология как раз и предполагает, что приходит IGMP query из любого member порта вне зависимости от того, в каком он VLAN, и переделывает пакет на VLAN 800 и пересылает его в soucre port, если указан просто source port, то добавляется 802.3Q метка с указанием номера Multicast VLAN, если указан untagged source port, то метка не добавляется. Как я предположил, что с member портом должно быть тоже самое, можно указать тегированный трафик в member порту или не теггированный. Но не прокатывает.

А кстати ваше предположение я проверю. Потому что я предполагал, что указываешь ему порт, и что он тегированный, а коммутатор разбирает все пакеты, смотрит где есть multicast, строит карту соответствия запросов и VLAN-ов.

Проверил. Действительно оно так и есть. Настроил кольцо одно в VLAN 800, переключил приставку в этот VLAN и сигнал пошел. Тоесть получается, что tagged_member _port указывает на то, что нужно вычленить из тегированного порта 800 VLAN и в нем найти multicast трафик. Не логично, не очень функционально, ограниченно как-то, но уж как есть. Из-за этого придется увеличить размер широковещательного домена VLAN до 20 колец, а как хотелось сделать VLAN на кольцо, но тогда будет очень много повторяющегося multicast трафика, так как каждый VLAN придется тащить до ядра.

Чтобы не двоился трафик надо юзать PIM. Но для этого задачи больше подходит 3420, у него ipif 256.

Да, я это понимаю, просто эти коммутаторы ставились когда не было задумок об IPTV, и цель их была исключительно съаггрегировать трафик с колец и подать на ядро, я думал можно будет решить задачку без замены коммутаторов. Это в принципе можно, но решение мне не нравится, большой широковещательный домен для приставок из 20 колец в среднем по 5 коммутаторов, не лучшее решение.