Здравствуйте.

Есть коммутатор:

Device Type : DES-3200-28 Fast Ethernet Switch
Boot PROM Version : Build 4.00.002
Firmware Version : Build 4.35.B014
Hardware Version : C1

Схема его включения такова (он в центре)*:


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

На DGS создан вилан с VID: 3004. Этот вилан добавлен на порт №1 тегированым. В этом вилане поднят ipif, настроен PIM. С этой стороной вопросов нет.

На целевом DES-3200-28 раздача multicast потока реализована посредством ISM VLAN, настройки следующие:




Абоненты подключённые в пользовательские порты (1-24) работают нормально, получают multicast поток без проблем во всём сегменте, жалоб нет.
Однако, недавно, я заметил вот какую штуку (подозреваю что она была и раньше просто никто на неё не обращал внимания) - если на целевом коммутаторе (тот который подключён непосредственно к DGS), абонент подключённый, допустим, во второй порт, запросит какой-нибудь multicast поток, то он, этот поток, будет литься не только во 2-й порт (куда подключён абонент), но и в 25,26 и 28 порт согласно вышеприведённой схеме (в 27 порт поток вливается от вышестоящего DGS).

Вопросы:
1. Это нормальное поведение при заданных настройках?
2. Какие настройки и как можно (и нужно) изменить, чтобы поток не лился туда, куда не нужно? Ведь если на, скажем, DES-3526 нет ни одного получателя multicast, то зачем нагружать канал зазря?

Спасибо.

Пометьте даунлинки как Tagged Member Port

Тоже замечал данное поведение, причём не только на описанном коммутаторе.
Alexey Mishenko: при такой настройке, если включен FastLeave, на нижестоящих коммутаторах будет прекращаться поток, если кто из абонентов переключит канал. Я не прав?

Хотелось бы услышать внятные разъяснения инженеров D-Link.

_________________
Народ и партия - едины!

Так дело в том, что, как я указал в своём первоначальном сообщении, топология данного сегмента - кольцо, поэтому, в общем случае, указать какой из портов будет источником, а какой приёмником мультикаста невозможно.
Собственно у нижнего DES-3200-28 (на схеме), 25 порт находится в состоянии "Alternate", при этом на этот порт льётся поток, так как 28 порт целевого DES-3200-28 в состоянии "Designated". Именно поэтому я обратил внимание на такое поведение - порт "Alternate", а на нём куча multicasta. Конечно, все эти пакеты дропаются, но оптимизма данная ситуация не прибавляет.


Присоединяюсь к пожеланию.

Я уже где-то про такое читал. Неоднократно собирал у себя стенд. Но повторить это так и не смог.Подождём длинк, в кольцевой топологии такой алгоритм работы мне кажется логичным. В случае перестройки кольца потеря мультикаста будет минимальна

Давайте рассмотрим следующую схему (как всегда сильно упрощаю):


sw на этой схеме пусть будут DES-3200-28/C1 с настройками приведёнными в первом посте. В данной схеме включен и работает протокол RSTP, значени е "Priority" для всех sw одинаково и больше (по абсолютной величине) чем у DGS. Таким образом DGS будет являтся корнем STP дерева.
Шаг1:
Пусть в такой конфигурации порт 26 у sw2 будет в состоянии "Alternate" (это часть реального сегмента и так есть на самом деле, так что данное допущение считаю верным). Тогда абонент подключённый к sw1 запросив multicast поток будет получать его через 27 порт от DGS. При этом коммутатор sw1 будет пересылать этот поток в свой 28 порт, а следовательно поток будет поступать на 26 порт коммутатора sw2 где эти мультикастовые пакеты будут уничтожаться. При этом проблем с предоставлением услуги пользователю не возникает.
Шаг2:
Рассмотрим воздействие на указанную выше схему внешних сил. Пусть некое воздействие повредило линию связи между DGS и sw1. Тогда Фиг. 1 преобразовывается в следующую:


Вопрос: если в момент воздействия действовала ситуация описанная мною в первом шаге, то каким образом передача multicast потока от sw1 к sw2 до момента воздействия, способствует "минимальной потере мультикаста" в случае перестройки кольца, каковая неизбежно происходит при описанном мною внешнем воздействии.

Хороший пример.

_________________
Народ и партия - едины!

А я не понял. А что не так то? А на дгс у вас как порты настроены, которые смотрят в сторону десов? Ну отвалился у вас на время мультикаст, но ведь это аварийная ситуация.

Аварийная ситуация - да.
Мультикаст отвалится на время - случаются вещи и похуже.
Меня интересует не это.

По шкале времени:
-3: 1-й и 5-й порты DGS в состоянии "Designated", 27-е порты sw в состоянии "Root", 28-й порт sw1 в состоянии "Designated", 26-й порт sw2 в состоянии "Alternate". Подписчиков multicast групп нет, multicast потока нет. (Фиг.1)
-2: Состояния портов RSTP такие же как и в момент времени "-3". На втором порту sw1 клиент посылает "IGMP Membership Report" - запрос на присоединение к группе. Далее, я так понимаю, при моих настройках (см. первый пост), этот пакет копируется на 25-28 порты, но уходит на DGS только через 27-й порт sw1. Пересылка этого пакета на любой другой порт sw1, в данном случае, приведёт в конце концов лишь к уничтожению этого пакета. На DGS "IGMP Membership Report" приходит в 1-й порт. Multicast поток начинает выливаться только из этого 1-го порта со стороны DGS и вливаться в 27-й порт sw1. sw1 знает, что клиент запросивший этот поток находится на втором порту (IGMP Snooping же) и копирует полученные на 27-м порту multicast пакеты на второй порт на выход. При этом тот же самый multicast поток (ещё одна его копия), передаётся с 28-го порта sw1 в сторону 26-го порта sw2, а если в 25 и 26 порты коммутатора sw1 подключены какие-либо устройства, то, при моих настройках, multicast польётся и на них (по факту сейчас так и происходит). На 26-м порту sw2 приходящие multicast пакеты будут дропаться (по факту сейчас так и происходит). Услуга предоставляется пользователю. (Фиг.1)
-1: Состояния портов RSTP такие же как и в момент времени "-3". DGS периодически посылает "IGMP Query", клиент отвечает "IGMP Report". Маршрут прохождения этих пакетов подробно описывать я не буду ( в кратком виде 2:sw1:27<->1:DGS). Multicast поток передаётся с 28-го порта sw1 в сторону 26-го порта sw2. Услуга предоставляется пользователю. (Фиг.1)
-0: Состояния портов RSTP такие же как и в момент времени "-3". Линия связи между DGS и sw1 разорвана. Поток перестал литься из DGS в sw1 -> на sw1 не создаются его (потока) копии -> в сторону пользователя и sw2 multicast поток отсутствует. Аварийная ситуация. (Фиг.2)
0: Работает RSTP. (Фиг.2)
1: 5-й порт DGS в состоянии "Designated", 27-й порты sw2 в состоянии "Root", 28-й порт sw1 в состоянии "Root", 26-й порт sw2 в состоянии "Designated". Подписчик multicast группы есть, это наш пользователь подключённый во второй порт sw1. Но multicast потока нет, так как клиент по собственной инициативе "IGMP Report" не посылает, а "IGMP Query" от DGS пока не пришёл. Мulticast потока нет. (Фиг.2)
2: Состояния портов RSTP такие же как и в момент времени "1". DGS рассылает "IGMP Query", его получает наш пользователь и отвечает на него своим "IGMP Report". Маршрут прохождения этих пакетов подробно описывать я не буду ( в кратком виде 2:sw1:27-26:sw2:27-5:DGS). DGS начинает слать поток из своего 5-го порта в сторону sw2. Далее, картина, на мой взгляд, ясна. (Фиг.2)


А вот теперь, смотрим:
1. Перестройка кольца будет? Будет.
2. Мультикаст отвалится? Отвалится.
3. После перестройки кольца мультикаст снова заработает? Заработает.

Вопрос: Какая взаимосвязь между тремя вышеуказаными пунктами и тем фактом что в момент времени "-1" multicast поток передаётся с 28-го порта sw1 в сторону 26-го порта sw2?
Если ответ на вопрос звучит как "никакой взаимосвязи нет", тогда

в этой ситуации то, что такое поведение (тупое размножение мультикаста во все порты указанные как "Source", если я всё правильно понимаю), рушит всю концепцию распространения multicast трафика. Получается, что в данном случае, "умный" коммутатор ничем не лучше дешёвой мыльницы. Ну зачем пихать поток в тот порт, откуда не приходил запрос на присоединение и не приходит подтверждение о чьём-либо членстве в вещаемой группе?

Очень хотелось бы.

To Alexey Mishenko: Про настройку портов на DGS - не совсем понял что именно Вас интересует, уточните пожалуйста. Со своей стороны готов предоставить всю необходимую информацию. Весь конфиг DGS пока не считаю нужным выкладывать.

P.S. Я мог где-то ошибиться, замечания приветствуются.

Ну на дгс просто снупинг? Просто как я понимаю Source Port = router_port в обычной терминологии. Поэтому, как я понимаю, так и происходит.

Да, как я и писал в первом посте на DGS вилан с VID: 3004, его VLAN Name: iptv.



Но происходящее же не совсем нормально. Нетрудно представить ситуацию, когда для резервного магистрального линка по каким-либо причинам используется 100Mbit порты. Всего 5-6 пользователей просматривающих iptv каналы в HD качестве без проблем перегрузят его несмотря на то, что том сегменте, куда смотрит этот линк, может даже не быть ни одного подписчика.

Если с порта пришёл IGMP Report для группы, значит там клиент, коммутатор добавляет его в список нисходящих для этой группы.
Если с порта пришёл IGMP Query для группы, значит там маршрутизатор, коммутатор добавляет его в список восходящих.
(c) Не моё.

А ширина резервного линка в 100 мбит это тоже неправильно. На такой линк логичнее вообще не подавать IPTV, а не помечать его как source

А вы не пробовали собрать тоже самое, только использовать ERPS?

Не спорю, но бывает всякое.


ERPS не использую по 2-м причинам:
1. Есть RSTP, она работает, претензий к ней нет, всё устраивает.
2. В сети много DES-3526, а они эту технологию не поддерживают.

Собственно, а при чём здесь ERPS, STP или другие подобные технологии? Проблема же не в них.

А разве при ерпс он не блокирует протекдед вланы? Просто по моему тут он литься не будет.

Не знаю. Я с ERPS никогда не работал. Опять таки - проблема не в ERPS или STP.