Проштудировал ftp://ftp.dlink.ru/pub/Trainings/D-Link ... ticast.zip + faq по настройке ISM VLAN. Возникли некоторые вопросы.

Тестируем следующую связку dlink свичей под интернет + iptv.

мультикаст соска->des3200(igmp querier, 10.10.1.1)->dgs3120(core, 192.168.0.1)->канал->dgs3120(агрегация, 192.168.0.2)->des1228me(доступ, ISM VLAN, 10.10.1.10)->STB/PC

des3200(igmp querier, 10.10.1.1)
igmp querier, поднят только vlan мультикаста vid=100

dgs3120(core, 192.168.0.1)
поднят vlan мультикаста vid=100 и интернета от NATa vid=200. Просто транслирует трафик. igmp snooping включен для vid=100

dgs3120(агрегация, 192.168.0.2)
поднят vlan мультикаста vid=100 и интернета от NATa vid=200. Просто транслирует трафик. igmp snooping включен для vid=100

des1228me(доступ, ISM VLAN, 10.10.1.10)
настроен ISM VLAN vid=100 и vlan интернета vid=200.

Есть несколько непонятных моментов:
1) Нужно ли производить какие-нить дополнительные действия на свиче агрегации? Согласно интернетам свич на доступе des1228me с ISM VLAN будет накапливать все IGMP-сообщения (включая дублирующие) о вступлении в группу и от имени vid=100 отправлять один запрос на IGMP querier на предоставление необходимого многоадресного потока. Т.е. вопрос с несколькими копиями мультикаст потока в канале между доступом и агрегацией, по идее, будет решен. Но, как избежать несколько копий мультикаст потока в канале агрегация <-> IGMP querier, если свичей доступа много, и свич на агрегации просто транслирует тегированный трафик.

2) Согласно мульонам статей в инете igmp querier в сети должен быть один/иметь наименьший ip/расположен ближе к источнику мультикаста.
У нас сейчас все так и есть: ip свича сконфигурен на vlanе мультикаста vid=100 и равен = 10.10.1.1. Роль querier igmp querier установлена. Поток мультикаст вещания идет в нетегированный порт vid=100, цепочка свичей - в тегированный. Но на практике, после непродолжительного времени этот свич находит в сети (очевидно со стороны мультикаст вещания) левый ip с 172.X.X.X и переходит из querier в non-querier. Отсюда вопрос: останеться ли он в этом случае querierом для свичей на доступе (des1228me(доступ, ISM VLAN, 10.10.1.10)), где ip свича так же поднят в мультикаст vlan (vid=100)? Или свичи на доступе так же будут расценивать левый 172.X.X.X как querier? Почему возникает такая ситуация и по какому принципу свич с 10.10.1.1 нашел в качестве querier свич с 172.X.X.X?

3) Правильно ли мы используем связку свичей? Не логично бы было, поставить igmp querier на каждой точке агрегации? Нужно ли в этом случае будет настраивать PIM между core и свичами агрегации?

DES-3200-28:admin#show igmp_snooping
Command: show igmp_snooping

VLAN Name : iptv
Query Interval : 125
Max Response Time : 10
Robustness Value : 2
Last Member Query Interval : 1
Querier State : Enabled
Querier Role : Non-Querier
Querier IP : 172.X.X.X
Querier Expiry Time : 210 secs
State : Enabled
Fast Leave : Disabled
Rate Limit : No Limitation
Report Suppression : Enabled
Version : 3
Data Driven Learning State : Enabled
Data Driven Learning Aged Out : Disabled
Data Driven Group Expiry Time : 260

На всех коммутаторах доступа настраиваете ism vlan с vid=100 и копий потока не будет.
Свитч может переходить в non querier если в сегменте сети есть еще один querier, и он(172.X.X.X) будет querier-ом для всех свитчей.

сейчас так и сделано. копий потока не будет в канале свич доступа<->свич агрегации. Но так как к свичу агрегации подключено много свичей доступа, как избежать повторяющихся потоков в канале свич агрегации<->свич ядра?

version 2 делайте

У вас на всех уровнях включен igmp snooping в одном влане, так что копий потока между ними быть не должно, собственно он для того и придуман, копии появятся если на одном свиче агрегации будет несколько транслирующих вланов.
Использовать des3200 в качестве Querier не самое лучшее решение, но если сеть не большая то пойдет.
А вообще в свое время поддержка дэлинк нам рекомендовала максимально сегментировать мультикаст влан, в идеале один на кольцо/плечо и PIM до узла агрегации.
Но нормально работало и в другой схеме:
PIM до ядра и в ядре(хуавеи и циски) далее от них подключались узлы концентраиции и агрегации (DGS3627/3420) на каждый конечный узел агрегации приходилось по одному мультикастному влану, они его просто транзитили со включенным снупингом.
А для того что-бы у вас не менялся Querier, нужно узнать на кого он меняется, понять нужен ли он оттуда, если не нужен зафильтровать, это раз. А если же внешний квериер нормально справляется со своими обязанностями так может тогда проще его оставить и не мучить des3200, т.к. может это ваша мультикаст соска так устроена и сама управляет потоками.
Два, пока на вашем des3200 все впорядке и Querier не поменялся, посмотрите аналогичное поле на коммутаторах доступа, чему оно равно, и соответственно после того как сменится.

А вот насчет версий это на самом деле не так важно, я думаю v3 в современном мире все же предпочтительнее. Мало ли, несколько источников появится у человека с пересекающимися группами. Плюс как показала практика от версии работоспособность от версии не зависит.