multicast mac address что это
Multicast в Cisco
Материал из Xgu.ru
 |
| Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной. |
Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.
Содержание
[править] Multicast на коммутаторах
[править] IGMP snooping
[править] Cisco Group Management Protocol (CGMP)
CGMP включается на маршрутизаторе и на коммутаторе.
Маршрутизатор отправляет сообщения CGMP, а коммутатор слушает их. С помощью сообщений маршрутизатор передает коммутатору информацию, которую он получил по IGMP.
MAC-адрес получателя в сообщениях CGMP 0x0100.0cdd.dddd.
Информация в CGMP-сообщениях:
| Тип | 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 |
[править] Формат сообщения CGMP
[править] Cisco Router Port Group Management Protocol (RGMP)
Если RGMP включается на маршрутизаторе или коммутаторе, то CGMP отключается, и наоборот.
Сообщения RGMP отправляются на адрес 224.0.0.25.
Все сообщения RGMP генерирует маршрутизатор:
Информация о протоколе:
[править] Маршрутизация multicast
[править] Настройка PIM
В PIM трафик конкретной мультикаст группы передается в соответствии с правилами режима настроенного для этой группы.
Реализация PIM в Cisco поддерживает четыре режима для мультикаст групп:
[править] Настройка IGMP
[править] Таймеры
Значения таймеров для маршрутизаторов Cisco отличаются от значений RFC 2236:
По умолчанию маршрутизатор отправляет General Query каждые 60 секунд. Изменить это значение можно с помощью команды ip igmp query-interval:
В General Query передается информация о таймере Max Response Time. Это значение указывает максимальное значение времени, в течение которого хост должен ответить на General Query сообщением Host Membership Report. По умолчанию значение таймера 10 секунд.
Изменение значения таймера Max Response Time:
[править] Querier
Один маршрутизатор в сети становится Querier. Другие маршрутизаторы в этой сети слушают сообщения от querier. Если они не видят сообщения в течение Other Querier Present Interval, то они считают, что того маршрутизатора нет и становятся Querier. По умолчанию Other Querier Present Interval равен 120 секунд.
Изменить это значение можно с помощью команды ip igmp querier-timeout:
[править] Присоединение интерфейса маршрутизатора к multicast группе
Есть две команды, которые позволяют интерфейсу маршрутизатора присоединиться к группе:
Настройка принадлежности интерфейса маршрутизатора к группе:
Ping с соседнего маршрутизатора:
[править] Просмотр информации IGMP
Информация об интерфейсах относящаяся к IGMP:
Показать multicast-группы, которые непосредственно присоединены к маршрутизатору и были выучены по IGMP:
Информация о multicast-группах:
Информация о multicast-портах маршрутизатора:
СОДЕРЖАНИЕ
Диапазон адресов разделен на блоки, каждому из которых назначена конкретная цель или поведение.
Известные адреса многоадресной рассылки IPv4
В следующей таблице представлен список известных хорошо известных IPv4-адресов, зарезервированных для многоадресной IP-рассылки и зарегистрированных в Internet Assigned Numbers Authority (IANA).
| Биты | 8 | 4 | 4 | 112 |
|---|---|---|---|---|
| Поле | приставка | флаги | сфера | ID группы |
| Биты | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
|---|---|---|---|---|---|---|---|---|
| Поле | приставка | ff1 | сфера | ff2 | зарезервированный | пленка | префикс сети | ID группы |
Префикс имеет значение и далее для всех адресов многоадресной рассылки.
| Немного | Флаг | 0 | 1 |
|---|---|---|---|
| 0 (MSB) | Зарезервированный | (Зарезервированный) | (Зарезервированный) |
| 1 | R (Свидание) | Точка рандеву не встроена | Точка рандеву встроена |
| 2 | P (префикс) | Без префиксной информации | Адрес на основе префикса сети |
| 3 (младший бит) | T (переходный) | Хорошо известный многоадресный адрес | Динамически назначаемый многоадресный адрес |
Подобно одноадресному адресу, префикс многоадресного IPv6-адреса определяет его область действия, однако набор возможных областей для многоадресного адреса отличается. 4-битное поле sc (или область действия) (биты с 12 по 15) используется для указания, где адрес действителен и уникален.
Известные адреса многоадресной рассылки IPv6
В следующей таблице представлен список известных многоадресных IPv6-адресов, зарегистрированных в IANA.
| Адрес | Описание |
|---|---|
| ff02 :: 1 | Все узлы в сегменте локальной сети |
| ff02 :: 2 | Все роутеры в сегменте локальной сети |
| ff02 :: 5 | OSPFv3 Все маршрутизаторы SPF |
| ff02 :: 6 | OSPFv3 Все маршрутизаторы DR |
| ff02 :: 8 | IS-IS для маршрутизаторов IPv6 |
| ff02 :: 9 | RIP роутеры |
| ff02 :: a | Маршрутизаторы EIGRP |
| ff02 :: d | PIM роутеры |
| ff02 :: 12 | Протокол резервирования виртуального маршрутизатора (VRRP) версии 3 |
| ff02 :: 16 | Отчеты MLDv2 (определены в RFC 3810) |
| ff02 :: 1: 2 | Все серверы DHCPv6 и агенты ретрансляции в сегменте локальной сети (определены в RFC 3315) |
| ff02 :: 1: 3 | Все хосты LLMNR в сегменте локальной сети (определены в RFC 4795) |
| ff05 :: 1: 3 | Все DHCP-серверы на сайте локальной сети (определены в RFC 3315) |
| ff0x :: c | Простой протокол обнаружения сервисов |
| ff0x :: fb | Многоадресный DNS |
| ff0x :: 101 | Сетевой протокол времени |
| ff0x :: 108 | Сетевая информационная служба |
| ff0x :: 181 | Сообщения протокола точного времени (PTP) версии 2 (Sync, Announce и т. Д.), За исключением измерения задержки однорангового узла |
| ff02 :: 6b | Протокол точного времени (PTP) версии 2 сообщения измерения задержки однорангового узла |
| ff0x :: 114 | Используется для экспериментов |
Ethernet
Кадры Ethernet со значением 1 в младшем бите первого октета MAC-адреса назначения обрабатываются как многоадресные кадры и рассылаются по всем точкам сети. Хотя кадры с единицами во всех битах адреса назначения ( FF-FF-FF-FF-FF-FF ) иногда называют широковещательной рассылкой, Ethernet обычно не различает многоадресные и широковещательные кадры. Современные контроллеры Ethernet фильтруют полученные пакеты, чтобы уменьшить нагрузку на ЦП, путем поиска хэша многоадресного адреса назначения в таблице, инициализированной программным обеспечением, которое контролирует, отброшен ли многоадресный пакет или получен полностью.
| Блокировать | Многоадресный адрес Ethernet | Ethertype | использование | ||
|---|---|---|---|---|---|
| Сегмент локальной сети, остановка на коммутаторах с поддержкой STP | |||||
| SNAP (длина) | Протокол связующего дерева (для мостов) IEEE 802.1D | ||||
| 0x88CC | Протокол обнаружения канального уровня (дополнительно) | ||||
| 01-80-C2-00-00-01 | 0x8808 | Управление потоком Ethernet (кадр паузы) IEEE 802.3x | |||
| 01-80-C2-00-00-02 | 0x8809 | «Медленные протоколы», включая протокол Ethernet OAM ( IEEE 802.3ah ) и протокол управления агрегацией каналов (LACP) | |||
| Сегмент локальной сети до следующего многопортового («без TPMR») коммутатора | |||||
| 0x888E | Аутентификация порта ( IEEE 802.1X EAPOL) | ||||
| 0x88CC | Протокол обнаружения канального уровня (дополнительно) | ||||
| 01-80-C2-00-00-08 | SNAP (длина) | Протокол связующего дерева (для мостов провайдера) IEEE 802.1ad | |||
| 01-80-C2-00-00-0D | 0x88F5 | Протокол регистрации нескольких VLAN (для мостов провайдера) IEEE 802.1ad | |||
| 01-80-C2-00-00-0E | Подключение к локальной сети, никогда не пересекает другое устройство | ||||
| 0x88CC | Протокол обнаружения канального уровня (основной) | ||||
| 0x88F7 | Протокол точного времени (PTP) версии 2 через Ethernet (802.1AS) | ||||
| 01-80-C2-00-00-21 | 0x88F5 | Протокол регистрации GARP VLAN (также известный как IEEE 802.1Q GVRP) Протокол регистрации нескольких VLAN (MVRP) | 01-1B-19-00-00-00 | 0x88F7 | Протокол точного времени (PTP) версии 2 через Ethernet (собственный уровень 2) для выбора часов Grandmaster и расширенных приложений, иначе 01-80-C2-00-00-0E |
| С 01-00-5E-00-00-00 по 01-00-5E-7F-FF-FF | 0x0800 | IPv4 Multicast (RFC 1112), вставьте младшие 23 бита многоадресного IPv4-адреса в адрес Ethernet. | |||
| С 01-0C-CD-01-00-00 по 01-0C-CD-01-01-FF | 0x88B8 | МЭК 61850-8-1 GOOSE тип 1 / 1A | |||
| С 01-0C-CD-02-00-00 по 01-0C-CD-02-01-FF | 0x88B9 | GSSE (МЭК 61850 8-1) | |||
| С 01-0C-CD-04-00-00 по 01-0C-CD-04-01-FF | 0x88BA | Значения выборки многоадресной рассылки (IEC 61850 8-1) | |||
| 01-00-0C-CC-CC-CC | SNAP (длина) | Cisco Discovery Protocol (CDP), протокол VLAN Trunking (VTP), Unidirectional_Link_Detection (UDLD) | |||
| 01-00-0C-CC-CC-CD | SNAP (длина) | Адрес протокола общего связующего дерева Cisco | |||
802.11
Беспроводные сети 802.11 используют те же MAC-адреса для многоадресной рассылки, что и Ethernet.
Трафик IP Multicast: как он работает и приложения, которые его используют
Что такое многоадресный трафик?
Наконец, у нас есть IP Multicast-трафик, о чем мы и поговорим сейчас подробно. Многоадресный трафик специально связан с группой «клиентов», заинтересованных в получении этого сетевого трафика. Если он не входит в группу многоадресной рассылки, они не получат информацию, это идеально для того, чтобы не разрушать сети или не отправлять копии всех пакетов всем клиентам. Связь выполняется один раз от исходного IP-адреса одноадресной рассылки к выбранному IP-адресу многоадресной рассылки, независимо от того, сколько клиентов находится на этом адресе многоадресной рассылки, все в группе получат дейтаграммы.
IP-адресация для многоадресной рассылки
Остальная часть диапазона 224.0.0.0/8 была назначена различным приложениям на протяжении многих лет или только что была зарезервирована IANA. Диапазон 223.0.0.0/8 зарезервирован для использования с протоколом SSM. Диапазон 239.0.0.0/8 используется для управления, здесь операторы сети предоставляют услуги IPTV для телевидения через Интернет. Вы можете посетить документ RFC3171 где вы найдете все существующие и зарезервированные диапазоны адресации IP Multicast.
Для чего нужен многоадресный трафик?
Многоадресный трафик широко используется в услугах платного телевидения различных оптоволоконных операторов Испании, например, Movistar. Благодаря многоадресной IP-рассылке оператор может предлагать высококачественную потоковую передачу видео и аудио всем клиентам, которые его нанимают, декодер будет прослушивать IP-адрес специально от Multicast для получения всей информации, а маршрутизатор будет получать каналы, проконсультировавшись Это. через протокол RIPv2. Благодаря платформе Movistar TV все клиенты могут получать телесигнал в своих домах без каких-либо задержек, пикселизации или остановок, когда тысячи подключенных клиентов смотрят футбольный матч.
Как вы видели, многоадресный трафик используется, прежде всего, в услугах IPTV операторов, поэтому для того, чтобы все работало правильно, важно, чтобы и маршрутизатор, и коммутаторы (если они есть) правильно управляли этим многоадресным трафиком. Наиболее важным протоколом для правильного управления многоадресным трафиком является так называемое IGMP Snooping для сетей IPv4 и протокол MLD для сетей IPv6, эти протоколы отвечают только за отправку трафика на компьютеры, которые фактически «слушают» его. трафик, а не на все компьютеры в сети, чтобы избежать его коллапса или замедления.
Multicast routing для IPTV
Один очень близкий мне человек, поклонник Хабра, захотел внести вклад в развитие блога Cisco. Являясь яростным поклонником того, что создает эта корпорация, он захотел поделиться опытом. =) Надеемся росчерк пера удался.
Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.
И вот незадача. Обычно в документации выкладывают все и сразу и для человека, впервые столкнувшегося с этой темой, не понятно с чего начать. Во время чтения pdf’ок я ловила себя на мысли, что было бы неплохо наткнуться где-нибудь на статью, которая могла бы коротким путем провести от теории к практике, чтобы понять с чего стоит начать и где заострить внимание.
Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.
Введение
Это моя самая первая статья (но не последняя! есть еще много зверей), постараюсь изложить все как можно доступнее.
Какой вид трафика использовать для IPTV?
| — | unicast | broadcast | multicast |
| Особенности применительно к IPTV | получаем дублирование трафика, для каждого абонента создается свой поток | клиентское оборудование вынуждено обрабатывать весь поток каналов, который может быть совсем не несколько килобит | абонент получает только тот поток, который запрашивает |
Очевидно, что для вещания каналов наибольшее предпочтение отдается multicast.
Любой TV-канал, который мы хотим вещать в сеть, характеризуется адресом группы, который выбирается из диапазона, зарезервированного для этих целей: 224.0.0.0 – 239.255.255.255.
Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить какому клиенту какой отправлять TV-канал.
Для того чтобы клиент смог зарегистрироваться в одной из этих групп и смотреть TV-канал используется протокол IGMP (Internet Group Management Protocol).
Немного о том, как работает IGMP.
Есть сервер, который включен в роутер MR. Этот сервер вещает несколько TV-мультиков, например:
| 224.12.0.1 | канал 1 | News |
| 224.12.0.2 | канал 2 | History |
| 224.12.0.3 | канал 3 | Animals |
Клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это запрос “JOIN 224.12.0.1”.
Если пользователь переключается на другой канал, то он сначала отправляет уведомление MR, что он отключает канал News или покидает эту группу. Для IGMP это “LEAVE 224.12.0.1”. А затем повторяет аналогичный запрос JOIN для нужного канала.
MR иногда спрашивает всех: “а какой группе кто подключен?”, чтобы отключать тех клиентов, с которыми оборвалась связь и они не успели отправить уведомление LEAVE. Для этого MR использует запрос QUERY.
Ответ абонента на этот запрос это MEMBERSHIP REPORT, который содержит список всех групп, в которых состоит клиент.
Настройка multicast routing.
Предположим, что клиенты одной группы смотрят один и тот же мультик, но находятся они в разных сегментах сети (network A и network B). Для того, чтобы они получили свой мультик и придуман multicast routing.
Пример настройки роутеров MR1 и MR2.
| Network A | 10.1.0.0/24 |
| Network B | 10.2.0.0/24 |
| Network C | 10.3.0.0/24 |
| MR1 | MR2 |
| MR1#sh run ip multicast-routing | MR2#sh run ip multicast-routing |
Команда «ip multicast-routing» включает соответствующий routing, если же он выключен, то роутер не пересылает multicast пакеты, т.е. они не дойдут до недоумевающего зрителя мультиков.
Остановимся чуть поподробнее на команде «ip pim sparse-mode«.
Про режимы протокола PIM и сам протокол.
PIM (Protocol Independent Multicast) — протокол маршрутизации multicast рассылки. Он заполняет свою таблицу multicast маршрутизации на основе обычной таблицы маршрутизации. Эти таблицы можно просмотреть с помощью команд “sh ip mroute” и “sh ip route” соответственно. Целью протокола PIM является построение дерева маршрутов для рассылки multicast сообщений.
У протокола PIM существует два основных режима: разряженный (sparse mode) и плотный (dense mode). Таблица multicast маршрутизации для них выглядит немного по-разному. Иногда эти режимы рассматривают как отдельные протоколы — PIM-SM и PIM-DM.
В нашей конфигурации на интерфейсах мы указали режим «ip pim sparse-mode«.
dense-mode Enable PIM dense-mode operation
sparse-dense-mode Enable PIM sparse-dense-mode operation
sparse-mode Enable PIM sparse-mode operation
………
В чем же разница?
PIM-DM использует механизм лавинной рассылки и отсечения (flood and prune). Другими словами. Роутер MR отправляет всем все multicast потоки, которые на нем зарегистрированы. Если клиенту не нужен какой-то из этих каналов, то он от него отказывается. Если все клиенты, висящие на роутере, отказались от канала, то роутер пересылает “спасибо, не надо” вышестоящему роутеру.
PIM-SM изначально не рассылает зарегистрированные на нем TV-каналы. Рассылка начнется только тогда, когда от клиента придет на нее запрос.
Т.е. в PIM-DM MR отправляет всем, а потом убирает ненужное, а в PIM-SM MR начинает вещание только по запросу.
Если члены группы разбросаны по множеству сегментов сети, что характерно для IPTV, PIM-DM будет использовать большую часть полосы пропускания. А это может привести к снижению производительности. В этом случае лучше использовать PIM-SM.
Между PIM-DM и PIM-SM существуют еще отличия.
PIM-DM строит дерево отдельно для каждого источника определенной multicast группы, т.е. multicast маршрут будет характеризоваться адресом источника и адресом группы. В multicast таблице маршрутизации будут записи вида (S,G), где S — source, G — group.
У PIM-SM есть некоторая особенность. Этому режиму необходима точка рандеву (RP — rendezvous point) на которой будут регистрироваться источники multicast потоков и создавать маршрут от источника S (себя) до группы G: (S,G).
Таким образом, трафик идет с источника до RP по маршруту (S,G), а далее до клиентов уже по общему для источников определенной группы дереву, которое характеризуется маршрутом (*,G) — «*» символизирует «любой источник». Т.е. источники зарегистрировались на RP, и далее клиенты уже получают поток с RP и для них не имеет значения, кто был первоначальным источником. Корнем этого общего дерева будет RP.
Точкой рандеву является один из multicast роутеров, но все остальные роутеры должны знать “кто здесь точка RP”, и иметь возможность до нее достучаться.
Пример статического определения RP (MR1). Объявим всем multicast роутерам, что точкой рандеву является 10.0.0.1 (MR1):
| ip pim rp-address 10.0.0.1 IPTV override | указываем адрес RP и access-list IPTV access-list определяет какие группы |
| ip access-list standard IPTV | регистрироваться на данной точке рандеву |
| permit 224.11.0.0 0.0.0.3 |
Все остальные роутеры должны знать маршрут до RP:
ip route 10.0.0.0 255.255.255.0 10.10.10.1
Существуют так же и другие способы определения RP, это auto-RP и bootstarp router, но это уже тема для отдельной статьи (если кому-нибудь будет интересно – пожалуйста)?
Посмотрим, что будет происходить после настройки роутеров.
Мы по-прежнему рассматриваем схему с роутерами MR1 (RP) и MR2. Как только включаем линк между роутерами MR1 и MR2, то должны увидеть в логах сообщения
Для MR1:
%PIM-5-NBRCHG: neighbor 10.10.10.2 UP on interface Ethernet3
Для MR2:
%PIM-5-NBRCHG: neighbor 10.10.10.1 UP on interface Ethernet0
Это говорит о том, что роутеры установили отношение соседства по протоколу PIM друг с другом. Проверить это также можно с помощью команды:
MR1#sh ip pim neighbor
PIM Neighbor Table
Mode: B — Bidir Capable, DR — Designated Router, N — Default DR Priority, S — State Refresh Capable
| Neighbor Address | Interface | Uptime/Expires | Ver | DR Prio/Mode |
| 10.10.10.2 | Ethernet3 | 00:03:05/00:01:37 | v2 | 1 / DR S |
Не забываем про TTL.
В качестве тестового сервера мне было удобно использовать плеер VLC. Однако, как позже обнаружилось, даже если выставить через GUI достаточный TTL, он все равно (надеюсь только в использованной мной версией) упорно отправлял multicast пакеты с TTL=1. Запускать упрямого пришлось с опцией «vlc.exe –ttl 3» т.к. у нас на пути будет два роутера, каждый из которых уменьшает TTL пакета на единицу.
Как же все таки обнаружить проблему с TTL? Один из способов. Пусть сервер вещает канал 224.12.0.3 с TTL=2, тогда на роутере MR1 пакеты проходят нормально, а за роутером MR2 клиенты уже не смогут смотреть свой мультик.
Обнаруживается это с помощью команды «sh ip traffic» на MR2. Смотрим на поле “bad hop count” – это число пакетов, которые “умерли”, как им и отмеряно, по TTL=0.
MR2#sh ip traffic
IP statistics:
Rcvd: 36788 total, 433 local destination
0 format errors, 0 checksum errors, 2363 bad hop count
……………………………………
Если этот счетчик быстро увеличивается, значит — проблема в TTL.
Show ip mroute
После включения вещания трех каналов на сервере в таблице multicast маршрутизации наблюдаем следующее:
MR1# sh ip mroute
(*, 224.12.0.1), 00:03:51/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.12.0.2), 00:00:45/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.2), 00:00:45/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.12.0.3), 00:00:09/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.3), 00:00:09/00:02:59, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
Видим, что появились маршруты вида (S,G), например (10.0.0.2, 224.12.0.3), т.е. зарегистрировался источник 10.0.0.2, который вещает для группы 224.12.0.3. А так же маршруты с RP до клиента: (*,G), например (*, 224.12.0.3) – которые они будут использовать, так называемое общее для всех дерево.
Как только на интерфейс MR1 (RP) приходит запрос на получение канала 1, в multicast таблице маршрутизации происходят следующие изменения:
MR1#sh ip mroute
…………………
(*, 224.12.0.1), 00:33:16/00:02:54, RP 10.0.0.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53
(10.0.0.2, 224.12.0.1), 00:33:17/00:03:25, flags: T
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53
Стало видно, что приходят запросы на эту группу с порта Ethernet3.
RPF проверка
Возможна ситуация, когда роутер получает multicast поток на двух интерфейсах. Кого из этих двух интерфейсов роутер будет считать источником?
Для этого он выполняет проверку RPF (Reverse Path Forwarding) — проверяет по обычной unicast таблице маршрутизации маршрут до источника и выбирает тот интерфейс, через который идет маршрут до этого источника. Эта проверка необходима для того чтобы избежать образования петель.
Отследить, как источник проходит проверку RPF можно с помощью команды:
MR2#sh ip rpf 10.0.0.2
RPF information for? (10.0.0.2)
RPF interface: Ethernet0
RPF neighbor:? (10.10.10.1)
RPF route/mask: 10.0.0.0/24
RPF type: unicast (static)
RPF recursion count: 0
Doing distance-preferred lookups across tables
Ну, вот и появилась та статейка, которую я бы с удовольствием нашла, на начальном этапе изучения multicast routing’а для IPTV. Я не волшебник, я только учусь… Потому, с радостью выслушаю все пожелания, замечания и советы. А так же, очень надеюсь, что для кого-то она окажется полезной. =)
UPD: Разрешите представить ее. Елена Сахно — lena_sakhno