отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel
Объявления
Community Live

1432
Просмотры
55
Полезный материал
20
Ответы
Chingiz
Beginner

Основной принцип работы мультикаста (протокол PIM)

Добрый день! Не смог найти однозначного и внятного ответа на сей вопрос - в сети, в которой реализован мультикаст, то есть вещание многих источников на многих клиентов, каждый из данных источников получает свой уникальный мультикаст IP адресс из сетки 224.0.0.0/4? Один такой мультикаст адрес называется группой, что несколько запутывает, - непонятно , под группой подразумевается что в этой группе ОДИН источник и много получаетелей или то, что в эту группу могут вещать много источников ( подразумеваю что источники разные, то есть вещают совершенно разный траффик). Мультикаст траффик реплицируется на коммутатрое, на котором идет разделение по разным веткам клиентов, и если со стороны источников находится несколько разных по траффику источников, то если они будут иметь одинаковй мультикаст адрес, то коммутатор не будет знать от какого из них пришел пакет. Вдобавок не ясно, к какому из адресов идет обращение со стороны маршрутизатора клиента - если он знает юникаст IP адрес источника, то для чего ему мульткаст адрес? Все эти вопросы возникают при рассмотрении более сложного варианта сети, чем те, которые показываются в многочисленных статьях в интернете, то есть в варианте, когда несколько источников подсоединены к одному коммутатору и маршрутизатору и он должен как-то различать траффик от некольких источников. То есть допустим несколько камер подсоединены к однмоу коммутатору и каждая вещает мультикаст траффик. 

1 УТВЕРЖДЕННОЕ РЕШЕНИЕ

Утвержденные решения

Логика в следующем:

До версии IGMP 3.0, было невозможным "подписаться" на получение трафика для определённого источника, то есть если Ваш сервер объявляет, что он "слушает" группу 239.3.3.3, то он получает трафик ото всех источников, вещающих для этой группы. Поэтому, чтобы ограничивать ненужный трафик, разделяли по группам. Сейчас же этой проблемы нет, но по-прежнему можно разделять, например - телеканалы. Представьте, что у Вас в сети "бегает" трафик для 5 телеканалов. Каждый канал ещё вещает на 2-3 языках. Можно разделить трафик так: одна группа для каждого канала и разделение по источникам для языков. 

 

Есть каналы - BBC, ITV, Netflix, Disney и CNN. И есть 10 серверов: 5 транслируют по одному каналу на английском, 5 на русском. Можно использовать одну группу для каждого канала, а ПО будет при выборе языка преключаться на поток от соответствующего сервера. А можно использовать 10 групп, каждый сервер вещает свой поток на отдельную группу. В первом случае, если у Вас в сети не поддерживается IGMP v3, то клиент подписывающийся на одну группу получает два потока - оба языка. Но так как смотреть одновременно два канала не совсем удобно, то ПО на клиенте выберет один канал, а трафик для второго будет просто отброшен. Но в этом случае Вы просто теряете пропускную способность в сети на невостребованный поток.

Если же Вы просто пустите все серверы в одной группе, то каждый клиент будет получать по 10 потоков, из которых использоваться будет только один.

Просмотреть решение в исходном сообщении

20 ОТВЕТ 20
Leonid Voronkin
VIP Collaborator

Судя по тому как вы задаёте вопрос, про мультикаст понимание околонулевое.

Статья специально для вас https://linkmeup.ru/blog/1205/

А ещё здесь в сообществе был вебинар на тему мультикаста https://community.cisco.com/t5/архив-маршрутизация-и-коммутация/сообщество-live-основы-multicast-routing/ba-p/4014508

 

 

________________________________________________________
Если ответ понравился, ставь звёздочку. Если ответ помог решить твою проблему, утверди его в качестве решения

   Вопросы возникли как раз после прочтения этой статьи) Все остальное, что удалось найти - вырезки или полная ее копия. В конце вскользь упоминается метод SSM, который меня больше всего интересует и вызывает больше всего вопросов. 

   Спасибо за ссылку на вебинар, сейчас посмотрю

Sergey Lisitsin
Collaborator

Добрый день,

 

1. Мультикастовые адреса используются только в качестве адресов получателя. Адрес источника - это всегда обычный юникастовый адрес. А группой адрес получателя называется потому, что множество получателей могут получать трафик адресованный группе. Передача мультикаста происходит по принципу радио. Радиостанция ведёт вещание на определённой частоте, а все, кто заинтересован в получении просто на эту частоту настраивают приёмники. Примерно так же происходит с сетевым вещанием. Источник вещает свой поток для определённого адреса группы, а заинтересованные получатели информируют свои сегменты сети, что они хотят получать трафик для этой группы.

 

2. Репликация мультикастовых пакетов происходит не только на коммутаторах, но и на маршрутизаторах. Есть два варианта мультикастовых маршрутов - *,G и S,G произносится по-английски star comma G и S comma G. Первый - это маршрут для адреса группы от любого источника. Второй - это маршрут для адреса группы от конкретного источника. И да, два или более источников могут посылать пакеты для одной и той же группы. В рамках одного поста полностью покрыть эту тему невозможно, поэтому я рекомендую Вам почитать книгу Beau Williamson'a Developing IP Multicast Networks

Developing IP Multicast Networks, Volume I (paperback): 1: 1: Amazon.co.uk: Williamson, Beau Williamson: 0619472142899: Books

Книга старая, но даёт хорошее понимание принципов работы мультикаста. Ну и конечно же - практикуйте. Соберите стенд на GNS3 или EVE-NG и вперёд!

 

 "Мультикастовые адреса используются только в качестве адресов получателя. Адрес источника - это всегда обычный юникастовый адрес..." - этот момент можете поподробнее раскрыть? Принцип мультикаста сам по себе мне ясен - источник - своего рода корень дерева, отправляет один экземпляр пакета, а дальше оборудование отправляет его по веткам  клиентам, туда где они есть. Меня  путает взаимосвязь юникаст и мультикаст адресов источника. Особенно похо стало, когда дочел до SSM, где клиент знает, юникаст адрес источника. Зачем ему его знать и отправлять запись типа (S,G), если ему нужен траффик этой группы, а ей соответствует определенный один источник? А если источник не один, как вы написали, то как в случае ASM клиент различает траффик двух разных источников, вещающих совершенно разный траффик в однку группу? 

    Приведу пример - 3 IР камеры на одном коммутаторе и несколько клиентов, желающих получать от них изображение. Если каждой камере дать отдельный мультикаст адрес, то надобность знать ее юникаст адрес клиентам отпадет. При этом в SSM клиент должен знать юникаст адрес клиента - зачем, если в данном примере каждой отдельной камере отдан свой мультикаст адрес. Если же все 3 камеры вещают в одну группу - на один мультикаст адрес - в таком случае клиентам нужно знать юникаст адрес камеры, чтобы различать траффик общей группы. Но тогда как ближайший к камере коммутатор различает траффик 3-ех разных камер, если он не рабоатает с юникаст адресами, а просто свич уровня 2? 

 "Мультикастовые адреса используются только в качестве адресов получателя. Адрес источника - это всегда обычный юникастовый адрес..."
- этот момент можете поподробнее раскрыть?

Конечно могу. Мультикастовые адреса на назначаются на интерфейсы. В нормальном IP-пакете Вы никогда не встретите мультикастовый адрес в поле source. Хосты, генерирующие мультикастовый трафик создают пакеты с мультикастовым адресом группы в поле destination.

 

ринцип мультикаста сам по себе мне ясен - источник - своего рода корень дерева, отправляет один экземпляр пакета, а дальше оборудование отправляет его по веткам  клиентам, туда где они есть.

Совершенно правильно.

Меня  путает взаимосвязь юникаст и мультикаст адресов источника. 

Возвращаясь в начало, повторюсь, что мультикаст адреса источника не существует. Источник имеет только адрес юникаст.

Особенно похо стало, когда дочел до SSM, где клиент знает, юникаст адрес источника. Зачем ему его знать и отправлять запись типа (S,G), если ему нужен траффик этой группы, а ей соответствует определенный один источник?

Клиент может знать адрес источника и использовать его в своих запросах чтобы решить следующую проблему, которую Вы описали. 

А если источник не один, как вы написали, то как в случае ASM клиент различает траффик двух разных источников, вещающих совершенно разный траффик в однку группу? 

Клиент может подписаться на трафик для определённой группы и от определённого источника. То есть если у Вас есть источники А и Б, вещающие для группы 239.3.3.3, то клиент может подписаться на один из них и не получать весь трафик для группы 239.3.3.3.

 

Необходимость знать адрес источника существует в тех режимах, где не существует вспомогательных средств для построения дерева распределения мультикаста, как например RP.

 

Тогда у меня вопрос - по какому правилу с точки зрения источников выдается адрес мультикаст группы? Какие источники он объединяет? Если выбор источника из группы идет по его юникаст адресу, то в чем смысл группы? Понятно,что к юникаст адрес не будет работать как мультикаст, но почему вводят несколько групп, если обращение к определенному источнику идет по юникаст адресу? Если так, то просто можно сделать одну группу на всю сеть, просто чтобы мультикаст работал. Или группа выбирается исходя из локальных соображений - то есть множество источников в одном широковвещательном домене? Могут ли источники одной группы находиться в разных сегментах сети? 

  Сумбурные вопросы, но один порождает другой) По сути вопрос один - по какой логике выдаются группы с точки зрения источников, по какому общему признаку они в нее группируются? Опять же можно рассмотреть на примере камер - каждая показывает что-то свое, не правильнее ли для каждой создать свою группу?

Тогда у меня вопрос - по какому правилу с точки зрения источников выдается адрес мультикаст группы?

Этот параметр произвольный. Можно сконфигурировать источник мультикастового трафика использовать определённый адрес группы для своего потока. 

Если выбор источника из группы идет по его юникаст адресу, то в чем смысл группы?

Смысл группы в том, что все получатели группы могут получать трафик для адреса группы. Чтобы было понятнее, действительно лучше показать на примере камер.

Камера снимает видео и генерирует видеопоток. Этот видеопоток может передаваться по протоколу IP. Если камере необходимо чтобы поток мог был принят более, чем одним получателем (например двумя или более записывающими серверами), то камера может транслировать поток для мультикастовой группы. Скажем если есть 3 камеры: К1, К2 и К3 и два сервера записи: С1 и С2.

Камера 1 транслирует для группы 239.0.0.1, камера 2 для группы 239.0.0.2 и камера 3 для группы 239.0.0.3. Оба сервера подписываются на все три группы. Каждая группа - это один видеопоток, который получают оба сервера.

Итого: 3 потока.

Если бы камеры могли использовать только юникаст, то потребовалось бы 6 потоков: 3 для сервера С1 и 3 для сервера С2. 

 

И да, источники для одной и той же группы могут быть в разных сегментах.

Спасибо за подробные ответы. Со стороны клиентов картина мне ясна. Изначально так себе и представлял - в примере с камерами - для каждой камеры свой адрес группы. Каждая из них будет иметь свой адрес, даже если они находятся на одном коммутаторе и имеют общий gateway? Я к тому, что даже находясь на одном коммутаторе в одном широковещательном домене и имея общий шлюз, они не могут находиться в одной группе?

Я к тому, что даже находясь на одном коммутаторе в одном широковещательном домене и имея общий шлюз, они не могут находиться в одной группе?

Могут. Главное, что нужно помнить - нет жёсткой связи между адресами юникаст и мультикастовыми группами. Источники для разных групп могут находиться в одной подсети, или наобором источники для одной группы могут находиться в разных. Мультикаст - это отдельная топология в рамках физической сети. Главное, что необходимо помнить - мультикаст - это о том, как от одного источника доставить копию пакета ко многим получателям. При этом локация получателей источник никак не заботит. Всё, что ему надо знать - адрес группы, для которой предназначен пакет. Остальное - забота инфраструктурных узлов сети: маршрутизаторов и коммутаторов.

 

Все-таки давайте на примере) Я нарисовал схему небольшой сети с 6ю камерами, на которых нужно реализовать мультикаст. На юникаст адреса не обращайте внимания, допустим они не маршрутизируемы, это не важно. Важно что каждая камера показывает что-то свое. Напишите и объясните, пожалуйста, сколько и какие здесь будут адреса групп. Это простая схема, поэтому хочется получить универсальный ответ, а не только под этот рисунок, имейте ввиду что размеры это сети с камерами могут быть в десятки раз больше. Файл приложил

Давайте на примере. Сколько и каких адресов там будет зависит от того, что решит администратор, а также от того, какое ПО будет отвечать за приём мультикаста. Например если ПО написано кривыми ручками и умеет различать потоки только по адресам групп, то понадобится 6 групповых адресов - по одному на камеру. Если ПО нормальное, то можно обойтись одной группой для всех камер. Каждый клиент будет получать 6 видео потоков и ПО будет сортировать пакеты по адресам отправителя. Так что универсальной схемы тут нет и к сожалению быть не может. В конечном итоге, каждый поток мультикастового трафика может быть уникально идентифицирован по связке - адрес отправителя (юникаст) плюс адрес группы (мультикаст).

Если у Вас есть GNS3 или EVE-NG, то я Вам советую построить тестовую топологию. В качестве камер можете воткнуть Docker контейнеры с линуксом. И мы с Вами по шагам настроим мультикаст.

 

Извините, никак не могу понять логику разных групп - зачем их столько создавать? То есть в идеале число групп должно быть минимальным? Должно же быть какое-то правило, по которому создаются эти группы. Для чего тогда создавался такой большой диапазон мультикаст адресов? Если, как вы написали, нет никакой связи между юникаст и мультикаст адресами источников и их можно произвольно заставлять вещать в одну группу, то зачем вообще нужно понятие группы? 

Логика в следующем:

До версии IGMP 3.0, было невозможным "подписаться" на получение трафика для определённого источника, то есть если Ваш сервер объявляет, что он "слушает" группу 239.3.3.3, то он получает трафик ото всех источников, вещающих для этой группы. Поэтому, чтобы ограничивать ненужный трафик, разделяли по группам. Сейчас же этой проблемы нет, но по-прежнему можно разделять, например - телеканалы. Представьте, что у Вас в сети "бегает" трафик для 5 телеканалов. Каждый канал ещё вещает на 2-3 языках. Можно разделить трафик так: одна группа для каждого канала и разделение по источникам для языков. 

 

Есть каналы - BBC, ITV, Netflix, Disney и CNN. И есть 10 серверов: 5 транслируют по одному каналу на английском, 5 на русском. Можно использовать одну группу для каждого канала, а ПО будет при выборе языка преключаться на поток от соответствующего сервера. А можно использовать 10 групп, каждый сервер вещает свой поток на отдельную группу. В первом случае, если у Вас в сети не поддерживается IGMP v3, то клиент подписывающийся на одну группу получает два потока - оба языка. Но так как смотреть одновременно два канала не совсем удобно, то ПО на клиенте выберет один канал, а трафик для второго будет просто отброшен. Но в этом случае Вы просто теряете пропускную способность в сети на невостребованный поток.

Если же Вы просто пустите все серверы в одной группе, то каждый клиент будет получать по 10 потоков, из которых использоваться будет только один.

Вот сейчас понятно стало) Сейчас уже можно читать дальше теорию и пробовать на эмуляторе. Спасибо большое!

Создать
Выразить признание своим коллегам
Content for Community-Ad

Сообщество Cisco

Помощь по сообществу