Многоадресная рассылка не функционирует внутри VLAN в коммутаторах Catalyst

Общие сведения о проблеме и ее решения

В коммутаторах Catalyst функция отслеживания IGMP включена по умолчанию. С помощью данной функции коммутатор отслеживает (или слушает) сообщения IGMP на всех портах. В качестве первого сервера в компания малого бизнеса часто используют решение на базе серверов Hewlett-Packard и операционной системы Windows Server Foundation: http://vetriks.ru/perviy-server.html . Такое решение, как правило можно заказать в компаниях, которые оказывают услуги ИТ-аутсорсинга (it outsourcing). В коммутаторе создается таблица отслеживания IGMP, в которой группа многоадресной рассылки сопоставляется всем портам коммутатора, которые ее запросили.

Предположим, что, безо всякой предварительной настройки, получатель 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 и начинает отправлять многоадресный трафик и на этот порт. На данном этапе оба коммутатора получают запрошенный многоадресный трафик, и приложение работает должным образом.

Как же коммутаторы определяют порт mrouter так, чтобы функция отслеживания IGMP работала также, как и в простой среде? В разделе Решения содержится несколько ответов.

Решения

Используйте следующие решения, чтобы устранить данную проблемы.

Решение 1: Включить PIM на уровне 3 маршрутизатора/интерфейса VLAN

На всех платформах Catalyst есть возможность динамически получать сведения о порте mrouter. Коммутаторы слушают либо приветствия не зависящей от протокола многоaдресной рассылки (PIM), либо сообщения с запросами IGMP, которые многоадресный маршрутизатор периодически рассылает.

В данном примере приведен пример конфигурации коммутируемого виртуального интерфейса (SVI) VLAN 1 на коммутаторе Catalyst 6500 с помощью ip pim sparse-dense-mode.

Switch1#show run interface vlan 1
!
interface Vlan1
 ip address 1.1.1.1 255.255.255.0
 ip pim sparse-dense-mode
end

Switch 1 now reflects itself (Actually the internal router port) as an Mrouter port. 

Switch1#show ip igmp snooping mrouter 
vlan            ports
-----+----------------------------------------
   1  Router

Switch 2 receives the same PIM hellos on its Fa 1/0/33 interface. So it assigns that 
port as its Mrouter port.

Switch2#show ip igmp snooping mrouter 
Vlan    ports
----    -----
   1    Fa1/0/33(dynamic)

Sidebar