# Пример II Добавим в схему коммутатор и ещё несколько клиентов: ![](http://img-fotki.yandex.ru/get/9753/83739833.37/0_da2ec_4d18ca94_XXL.png) Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN'а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.\ Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё. > В данной ситуаци трафик будут получать даже те, кто этого в общем-то и не хотел, то есть на нём не запущен ни плеер, ни что бы то ни было другое. Но только, если он в том же VLAN'е. [Позже](https://github.com/eucariot/SDSM/tree/3980ebc949c706312c92a0770d22501121795c27/9.-multicast/0.-obchee-ponatie-multicast/9.-multicast.md#IGMP_Snooping) мы разберёмся, как с этим бороться. Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с \* 30 каналов). Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать.\ Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы. | **Адрес** | **Значение** | | --------------- | ---------------------------------------------------- | | 224.0.0.0 | Не используется | | 224.0.0.1 | Все узлы данного сегмента | | 224.0.0.2 | Все мультикастовые узлы данного сегмента | | 224.0.0.4 | Данный адрес выделялся для покойного протокола DVMRP | | 224.0.0.5 | Все OSPF-маршрутизаторы сегмента | | 224.0.0.6 | Все DR маршрутизаторы сегмента | | 224.0.0.9 | Все RIPv2-маршрутизаторы сегмента | | 224.0.0.10 | Все EIGRP-маршрутизаторы сегмента | | 224.0.0.13 | Все PIM-маршрутизаторы сегмента | | 224.0.0.18 | Все VRRP-маршрутизаторы сегмента | | 224.0.0.19-21 | Все IS-IS-маршрутизаторы сегмента | | 224.0.0.22 | Все IGMP-маршрутизаторы сегмента (v2 и v3) | | 224.0.0.102 | Все HSRPv2/GLBP-маршрутизаторы сегмента | | 224.0.0.107 | PTPv2 — Precision Time Protocol | | 224.0.0.251 | mDNS | | 224.0.0.252 | LLMNR | | 224.0.0.253 | Teredo | | 224.0.1.1 | NTP | | 224.0.1.39 | Cisco Auto-RP-Announce | | 224.0.1.40 | Cisco Auto-RP-Discovery | | 224.0.1.41 | H.323 Gatekeeper | | 224.0.1.129-132 | PTPv1/PTPv2 | | 239.255.255.250 | SSDP | Диапазон 224.0.0.0/24 зарезервирован под [link-local](http://lookmeup.linkmeup.ru/#term42) коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.\ Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы. Вот, собственно, самые базисные вещи касательно мультикаста.\ Мы рассмотрели простую ситуацию, когда источник и получатель находятся в одном сегменте сети. Трафик, полученный коммутатором, просто рассылается им во все порты — никакой магии. Но пока совсем непонятно, как трафик от сервера достигает клиентов, когда между ними огромная провайдерская сеть линкмиап? Да и откуда, собственно, будет известно, кто клиент? Мы же не можем вручную прописать маршруты, просто потому что не знаем, где могут оказаться клиенты. Не ответят на этот вопрос и обычные протоколы маршрутизации. Так мы приходим к пониманию, что доставка мультикаст — это нечто совершенно новое для нас. Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.\ Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.\ С помощью IGMP конечные получатели-клиенты сообщают ближайшим маршрутизаторам о том, что хотят получать трафик. А PIM строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы. ![PIM+IGMP](http://img-fotki.yandex.ru/get/6710/83739833.37/0_da2ed_7bb60de6_XXL.png) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://linkmeup.gitbook.io/sdsm/9.-multicast/0.-obchee-ponatie-multicast/0.-primer-2.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.