Настройка мультикаста на коммутаторе
До недавнего времени большая часть абонентов в нашей сети обеспечивалась прелестями IPTV посредством unicast'а. Это просто, не требует какой-либо сложной настройки, но как ни крути куда более оптимальным способом трансляции телевидения является мультикаст и протокол IGMP.
Для начала стоит уточнить управляющий интерфейс, пусть это будет. Назовем этот влан просто default. Исходя из найденного мануала, нужно запилить на uplink-порту switchport pvid multicast-vlan, где multicast-vlan - это собственно и есть мультикаст-влан. Но тогда мы потеряем управление коммутатором. Что делать? В таком случае пойдем на хитрость, и используем для подачи на коммутатор мультикаста другой интерфейс. Оставим управляющий и клиентский vlan на gi0/1, а multicast поднимем на gi0/2. Но сначала произведем настройки на вышестоящем коммутаторе. Пусть это будет случайный Cisco Catalyst с такой же нумерацией портов.
На gi1/0/2 я оставил только multicast-vlan влан, тегированный:
Conf t
Int gi1/0/2
description Multicast for BDcom – описание
switchport mode trunk – делаем порт транковым
switchport trunk allowed vlan multicast-vlan – добавил multicast-vlan на порт
На gi1/0/1 я убрал multicast-vlan влан:
Conf t
Int gi1/0/1
description BDCom – описание
switchport trunk allowed vlan remove multicast-vlan – убил multicast-vlan на порту, так как он там был настроен
Заходим на BDCOM
Добавил multicast-vlan на gi0/2 согласно мануалу, приложенному к статье.
switchport trunk vlan-allowed multicast-vlan
switchport trunk vlan-untagged none
switchport mode trunk
switchport pvid multicast-vlan
Дальше добавляем multicast-vlan на порт EPON, за которым находится наш абонент:
Например, Epon0/4.
Conf
Int epon 0/1
switchport trunk vlan-allowed add multicast-vlan
Далее включил мультикаст на bdcom:
ip mcst enable
ip mcst mrouter interface GigaEthernet0/2
ip mcst mc-vlan multicast-vlan range 239.255.0.1 - 239.255.0.254 – к сожалению на bdcom надо прописывать все мультикаст группы, в которых есть каналы, иначе работать не будет.
Ну и напоследок настройки на абоненской приставке, в нашем случае это интерфейст epon 0/4:10:
Conf
Int epon 0/4:10
epon onu description Svetlaya3 – описание приставки
epon onu port 1 ctc vlan mode tag 245 – влан для интернета
epon onu port 1 ctc mcst tag-stripe enable – разрешаем «склеивать» влан для интернета и мультикастный
epon onu port 1 ctc mcst mc-vlan add multicast-vlan – говорим, что multicast-vlan мультикастный
Внимание! Указанный в статье multicast-vlan меняем на использующийся в вашей сети VLAN!
- Group Destination Address (GDA)
- Unicast Source Address (USA)
| Тип | Group Destination Address | Unicast Source Address | Значение |
|---|---|---|---|
| Join | MAC-адрес группы | MAC-адрес хоста | Добавить USA порт в группу |
| Leave | MAC-адрес группы | MAC-адрес хоста | Удалить USA порт из группы |
| Join | 0 | MAC-адрес маршрутизатора | Выучить к какому порту подключен CGMP-маршрутизатор |
| Leave | 0 | MAC-адрес маршрутизатора | Освободить порт CGMP-маршрутизатора |
| Leave | MAC-адрес группы | 0 | Удалить группу из CAM |
| Leave | 0 | 0 | Удалить все группы из CAM |
Cisco Router Port Group Management Protocol (RGMP) -- предназначен для того чтобы коммутатор мог взаимодействовать с маршрутизаторами в сети и отслеживать трафик каких групп необходимо передавать маршрутизаторам.
Если RGMP включается на маршрутизаторе или коммутаторе, то CGMP отключается, и наоборот.
Информация о протоколе:
- Хоть протокол и проприетарный, но есть информационное RFC3488
- RGMP: Cisco Router Port Group Management Protocol
- Using RGMP: Basics and Case Study
- Поддерживается на Catalyst 6000 [1]
В PIM трафик конкретной мультикаст группы передается в соответствии с правилами режима настроенного для этой группы.
Реализация PIM в Cisco поддерживает четыре режима для мультикаст групп:
Значения таймеров для маршрутизаторов Cisco отличаются от значений RFC 2236:
По умолчанию маршрутизатор отправляет General Query каждые 60 секунд. Изменить это значение можно с помощью команды ip igmp query-interval:
Изменение значения таймера Max Response Time:
Изменить это значение можно с помощью команды ip igmp querier-timeout:
Есть две команды, которые позволяют интерфейсу маршрутизатора присоединиться к группе:
- ip igmp static-group:
- fast-switched traffic,
- настраивает статическую принадлежность интерфейса группе, которая позволяет маршрутизатору присоединиться к группе,
- после указания команды upstream маршрутизатор будет считать, что ниже есть участник группы,
- не обрабатывается пакеты, а только присоединяет маршрутизатор к группе.
- process-switched traffic,
- настраивает статическую принадлежность интерфейса группе, которая позволяет маршрутизатору присоединиться к группе,
- после указания команды upstream маршрутизатор будет считать, что ниже есть участник группы,
- позволяет маршрутизатору обрабатывать и отвечать на ping.
Настройка принадлежности интерфейса маршрутизатора к группе:
Ping с соседнего маршрутизатора:
Информация об интерфейсах относящаяся к IGMP:
Показать multicast-группы, которые непосредственно присоединены к маршрутизатору и были выучены по IGMP:
Потребовалось однажды из одной точки сети пропустить транзитом multicast трафик в другую часть сети.
![]()
1. Alcatel lucent Omniswitch 6800 series
Создаем отдельный vlan на первом коммутаторе, где будем принимать трафик и отправлять его транком дальше:
Настройка портов для приема трафика :
Настройка порта для отправки трафика:
Настраиваем igmp-snooping(просто multicast в alcatel), так, что бы трафик не уходил по всем портам, а только на те, что его запрашивают:
Так как изначально ip multicast включается глобально, то лучше на всех других vlan его отключать:
2. Cisco Nexus 3000 series
На остальных портах лучше заблокируем прохождение:
3. EX Juniper series
Создаем vlan и настраиваем порты входа-выхода multicast-трафика:
4. Alcatel lucent Omniswitch 6800 series
Теперь самое интересное. На этом коммутаторе нужно принять весь multicast трафик и раздать его нужным клиентам, что на порт не придет никакого лишнего multicast.
Настраиваем порты и vlan:
Выводы
Без правильной настройки multicast-трафика могут возникнуть проблемы, с тем, что трафик либо вообще не будет проходить через коммутатор, либо будет расходиться по всем портам. Последнее грозит тем, что вырастит нагрузка как и на управляемый коммутатор, так и на порты устройств клиентов (а дальше повлияет и на загрузку CPU). Это все может негативно влиять как и на работу отдельных устройств, так и на работу всей сети (сегмента) в целом.
UPDATE 04.07.2018
Настройка multicast на cisco catalist series (3500, 3700, 6500)
Настраиваем multicast-vlan 324:
Настроить порты для приема multicast:
Настраиваем uplink-порт, добавив vlan на передачу muticast трафика:
Настроить igmpsnooping глобально и на интерфейсах:
UPDATE 01.10.2018
Juniper
Если на какой-то порт нужно подавать мультикаст, но не весь, а только с определенных ip адресов вещания (например, если у вас во влане 1Gb мультикаст трафика, а нужно всего несколько источников принять на 20-30 мб), то лучше напрямую указать ip, только с которых будет приниматься трафик.
В данном документе описана общая проблема, которая возникает при первом развертывании многоадресного приложения в сети коммутатора Cisco Catalyst, когда происходит сбой в работе многоадресной рассылки. Кроме того, если не настроить коммутаторы соответствующим образом, в работе некоторых серверов/приложений, которые используют многоадресные пакеты для работы в кластере/с высокой доступностью, происходит сбой. В этом документе рассмотрена и эта проблема.
Предварительные условия
Требования
Для данного документа нет особых требований.
Используемые компоненты
Сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения:
Catalyst 6500 с модулем управления Supervisor Engine 720 с ПО Cisco IOS® версии 12.2(18)SXD5
Catalyst 3750 с образом ПО Cisco IOS версии 12.2(25)SEB2
Данные для документа были получены в специально созданных лабораторных условиях. Все устройства, используемые в этом документе, были запущены с чистой (заданной по умолчанию) конфигурацией. Если ваша сеть работает в реальных условиях, убедитесь, что вы понимаете потенциальное воздействие каждой команды.
Соответствующие продукты
Этот документ может также использоваться со следующими версиями оборудования и программного обеспечения:
Любым коммутатором Catalyst с ПО Cisco IOS, поддерживающим отслеживание протокола управления группами Интернет (IGMP)
Условные обозначения
Подробные сведения о применяемых в документе обозначениях см. в разделе Условные обозначения, используемые в технической документации Cisco.
Проблема
Многоадресный трафик не проходит через коммутаторы Catalyst, даже внутри одной VLAN. На Рис.1 изображен типичный сценарий:
Рис. 1. Настройка сети с многоадресным источником и получателями
Многоадресный источник подключается к коммутатору 1, который является коммутатором Catalyst 6500 с модулем управления Supervisor Engine 720 с ПО Cisco IOS. Получатель 1 подключается к коммутатору 1, а получатель 2 подключается к коммутатору 2. Коммутатор 2 – это коммутатор Catalyst 3750. Между коммутатором 1 и коммутатором 2 существует соединение уровня 2, доступ или магистраль.
В данной настройке можно заметить, что получатель 1, который находится на одном коммутаторе с источником, получает многоадресный поток без затруднений. Однако получатель 2 не получает многоадресного трафика. Цель данного документа – устранить данную проблему.
Повторный обзор некоторый ключевых принципов многоадресной рассылки
До получения различных вариантов решения данной проблемы, вы должны четко представлять себе определенные принципы многоадресной рассылки уровня 2. В данном разделе описаны эти принципы.
Примечание. В данном разделе приведено простое и четкое объяснение, касающееся данной конкретной проблемы. Подробное объяснение этих терминов см. в разделе Дополнительные сведения данного документа.
Протокол IGMP
IGMP – это протокол, который обязывает конечные хосты (получатели) сообщить многоадресному маршрутизатору (опросчику IGMP) о намерении конечного хоста получать определенный многоадресный трафик. То есть, это протокол, использующийся между маршрутизатором и конечными хостами и позволяющий:
Маршрутизаторам запрашивать конечные хосты о потребности в определенном многоадресном потоке (запрос IGMP)
Конечным хостам сообщать и отвечать маршрутизатору о потребности в определенном многоадресном потоке (отчеты IGMP)
Функция отслеживания IGMP
Порт Mrouter
Порт mrouter – это порт с точки зрения коммутатора, который подключается к многоадресному маршрутизатору. Необходимо присутствие, по крайней мере, одного порта mrouter для работы коммутаторов по отслеживанию IGMP. Это требование подробно описано в разделе Общие сведения о проблеме и ее решения данного документа.
Многоадресная рассылка на L2
Любой IP-трафик версии 4 (IPv4) с IP-адресом назначения в диапазоне от 224.0.0.0 до 239.255.255.255 является многоадресным потоком. Все многоадресные пакеты IPv4 соответствуют предварительно определенному MAC-адресу IEEE с форматом 01.00.5e.xx.xx.xx.
Примечание. Функция отслеживания IGMP действует в случае, если MAC-адреса многоадресной рассылки соответствуют IEEE-совместимому MAC-диапазону. Согласно разработке данной функции, отслеживание некоторых зарезервированных диапазонов многоадресной рассылки не предполагается. Если не соответствующий критериям многоадресный пакет исходит из коммутируемой сети, он отправляется через эту VLAN, где расценивается как широковещательный трафик.
Общие сведения о проблеме и ее решения
Предположим, что, безо всякой предварительной настройки, получатель 1 и получатель 2 сообщили о своем намерении получать многоадресный поток для 239.239.239.239, который соответствует MAC-адресу многоадресной рассылки на L2 01.00.5e.6f.ef.ef. Коммутатор 1 и коммутатор 2 создают единую запись в таблице отслеживания для данных получателей в ответ на отчеты IGMP, которые генерируют получатели. Коммутатор 1 входит на порт Gigabit Ethernet 2/48 в своей таблице, а коммутатор 2 входит на порт Fast Ethernet 1/0/47 в своей таблице.
Примечание. На данном этапе источник многоадресной рассылки еще не начал передачу, и ни один из коммутаторов не знает о порте mrouter коммутатора.
Если источник на коммутаторе 1 начинает пересылать многоадресный трафик, коммутатор 1 "видит" отчет IGMP от получателя 1. В результате, коммутатор 1 отправляет многоадресную рассылку из порта Gigabit Ethernet 2/48. Так как коммутатор 2 "поглотил" отчет IGMP от получателя 2 в результате процесса отслеживания IGMP, коммутатор 1 не "видит" отчет IGMP (многоадресный запрос) на порте Gigabit Ethernet 2/46. В результате, коммутатор 1 не отправляет трафик многоадресной рассылки на коммутатор 2. Таким образом, получатель 2 никогда не получит трафик многоадресной рассылки, даже если получатель 2 находится в той же сети VLAN, только на другом коммутаторе в отличие от источника многоадресной рассылки.
Причина данной проблемы состоит в том, что функция отслеживания IGMP не поддерживается на платформах Catalyst без mrouter. Механизм "ломается" при отсутствии порта mrouter. Чтобы данное решение заработало, коммутаторам необходимо как-то получить сведения о порте mrouter. В разделе Решения данного документа объясняется эта процедура. Как присутствие порта mrouter на коммутаторах исправит данную ситуацию?
В основном, если данные о порте mrouter внесены в коммутатор, происходит следующее:
Коммутатор направляет отчеты IGMP от получателей к порту mrouter. Это означает, что отчеты IGMP отправляются на многоадресный маршрутизатор. Коммутатор не отправляет все отчеты IGMP. Вместо этого коммутатор отправляет только несколько отчетов на mrouter. Количество отчетов в данном случае неважно. Для многоадресного маршрутизатора только необходимы сведения об одном получателе, для которого необходим многоадресный нисходящий поток. Для определения этого, многоадресный маршрутизатор получает периодические отчеты IGMP в ответ на свои запросы IGMP.
В сценарии, предназначенном только для многоадресного источника, к которому еще не "присоединились" получатели, коммутатор отправляет многоадресный поток только через свой порт mrouter.
Если коммутаторы получают сведения о порте mrouter, коммутатор 2 пересылает отчет IGMP, который он получил от получателя 2, на свой порт mrouter. Это порт Fast Ethernet 1/0/33. Коммутатор 1 получает отчет IGMP на порт коммутатора Gigabit Ethernet 2/46. С позиции коммутатора 1 он просто получил еще один отчет IGMP. Коммутатор добавляет этот порт в таблицу отслеживания IGMP и начинает отправлять многоадресный трафик и на этот порт. На данном этапе оба коммутатора получают запрошенный многоадресный трафик, и приложение работает должным образом.
Решения
Используйте следующие решения, чтобы устранить данную проблемы.
Решение 1: Включить PIM на уровне 3 маршрутизатора/интерфейса VLAN
В данном примере приведен пример конфигурации коммутируемого виртуального интерфейса (SVI) VLAN 1 на коммутаторе Catalyst 6500 с помощью ip pim sparse-dense-mode.
Решение 2: Включить функцию опроса IGMP на коммутаторе Catalyst уровня 2
Опрос IGMP – это относительно новая функция на коммутаторах уровня 2. Если в сети/VLAN нет маршрутизатора, который выступает в роли многоадресного маршрутизатора и позволяет коммутаторам обнаружить порт mrouter, можно включить функцию опроса IGMP. Данная функция позволяет коммутатору уровня 2 работать вместо многоадресного маршрутизатора и рассылать периодические запросы IGMP в сеть. С помощью данного действия коммутатор рассматривает себя как порт mrouter. Оставшиеся коммутаторы в сети определяют свои соответствующие порты mrouter на основание интерфейса, на который они получили данный запрос IGMP.
Сейчас коммутатор 1 "видит" порт Gig 2/46, связанный с коммутатором Switch 2, в качестве порта mrouter.
Если источник на коммутаторе 1 начинает пересылать многоадресный трафик, коммутатор 1 направляет его получателю 1, найденному с помощью функции отслеживания IGMP (напр., из порта Gig 2/48), а также на порт mrouter (напр., из порта Gig 2/46).
Решение 3: Настроить статический порт мrouter на коммутаторе
В этом примере статический порт mrouter необходим только на коммутаторе 2:
Решение 4: Настроить статические многоадресные MAC-записи на всех коммутаторах
Можно сделать статическую запись контекстно-адресуемой памяти (CAM) для MAC-адреса многоадресной рассылки на всех коммутаторах для всех портов получателей и нисходящих портах коммутаторов. Коммутатор подчиняется правилам статической записи CAM и отправляет пакет на все интерфейсы, указанные в таблице CAM. Это наиболее трудоемкое решение для среды с большим количеством многоадресных приложений.
Решение 5: Отключить функцию отслеживания IGMP на всех коммутаторах
Если отключить функцию отслеживания IGMP, все коммутаторы будут рассматривать многоадресный трафик в качестве широковещательного трафика. Это приведет к лавинной пересылке трафика на все порты в данной VLAN вне зависимости от того, есть ли на портах получатели, интересующиеся данным многоадресным потоком.
Читайте также:
