Русские Блоги
Basic IP Multicast (2) Принцип работы и базовая конфигурация каждой версии протокола IGMP, принцип работы IGMP Snooping
Каталог статей
Предисловие
В предыдущей статье мы объяснили основы технологии многоадресной IP-рассылки, а затем решили первый из трех вопросов технологии многоадресной рассылки.
В этой статье мы решим вторую проблему.
Потребности получателя многоадресной рассылки
В процессе многоадресной передачи отправитель отправляет данные многоадресной рассылки на определенный адрес многоадресной рассылки. Но, в конце концов, нам нужно решить еще две проблемы:
Источник многоадресной рассылки не обращает внимания на информацию о местоположении получателя, но для маршрутизатора, соединяющего членов группы, он должен собирать и поддерживать информацию о членах группы. Многоадресная рассылка не указывает четкого получателя и не отправляет данные всем хостам в сети. Если хост хочет получать данные, отправленные на определенный адрес многоадресной рассылки, ему необходимо присоединиться к этой группе и стать членом группы многоадресной рассылки.
Конечно, мы можем использовать ручную настройку для решения этих проблем, но ручная настройка имеет следующие недостатки:
Итак, существует ли протокол, который может быстро обмениваться данными между хостом и маршрутизатором и решить вышеуказанные проблемы?
Конечно, есть, то есть протокол IGMP. Протокол IGMP действует между хостом и многоадресным маршрутизатором.
Далее мы подходим к пониманию механизма работы и различий трех версий IGMP.
IGMPv1
Рабочий механизм
Групповой запрос, ответ и механизм подавления ответа
Как показано на рисунке ниже, когда протокол IGMPv1 работает, маршрутизатор будет периодически (60 с) отправлять информацию запроса членства (сообщения общего запроса группы) на все хосты в подсети. В это время все хосты в сегменте сети будут принимать его. В этом сообщении, после получения этого сообщения, каждый хост запускает таймер (таймер случайным образом выбирает время отсчета времени от 0 до 10 с).
Предполагая, что клиент A и клиент C хотят присоединиться к группе G1, таймеры A и C рандомизируются на 3 и 9 соответственно, поэтому клиент A заканчивает отсчет времени первым. Когда таймер обратный отсчет, A отправит сообщение с отчетом о членстве, указывая, что он хочет присоединиться к группе многоадресной рассылки G1. Это сообщение также будет получено другими устройствами в сегменте сети. Когда клиент C получает это сообщение и проверяет его, он обнаруживает, что он находится в той же группе, что и клиент A, поэтому он больше не отправляет сообщения с отчетом о членстве (механизм подавления ответа) ); Когда клиент B получает и просматривает сообщение и обнаруживает, что группа A, к которой хочет присоединиться, отличается от себя, он ждет, пока не истечет время таймера, и отправляет собственное сообщение с отчетом о членстве.
После того, как RTA получит сообщение с отчетом об участниках, он знает, что в этом сегменте сети есть члены групп многоадресной рассылки G1 и G2. Как только RTA получит данные многоадресной рассылки от G1 и G2, он будет Переадресация сетевого сегмента. 
GMPv1 поддерживает два типа сообщений:
Сообщение общего запроса (General Query):
Маршрутизатор периодически отправляет общие сообщения запроса на адрес 224.0.0.1 (представляющий все хосты и маршрутизаторы в одном сегменте сети). Период запроса по умолчанию составляет 60 секунд, и период отправки можно настроить с помощью команд.
Отчет о членстве (Отчет о членстве):
Используется для хостов для присоединения к группе многоадресной рассылки.
Механизм подавления ответа:
Может уменьшить трафик протокола в сегменте сети
Члены присоединяются
Если новый участник, то активно подайте заявку на вступление в группу.
Если новый узел доступа хочет присоединиться к группе многоадресной рассылки, чтобы быстро получать данные многоадресной рассылки, не ждите, пока маршрутизатор отправит сообщения общего запроса группы.Вместо этого немедленно отправьте отчет для участников, которые хотят присоединиться к группе.. После того, как RTA получил отчетное сообщение участника, он узнал, что в этом сегменте сети появились члены многоадресной группы G3. Как только данные групповой адресации G3 поступают в RTA, они будут перенаправлены в этот сегмент сети.
Члены группы уходят
Уйти молча и уйти без всякого приветствия.
Как показано на рисунке ниже, когда клиент покидает группу многоадресной рассылки, он больше не будет отвечать на сообщения общего запроса группы. Предполагая, что все клиенты выходят из группы многоадресной рассылки, клиенты больше не будут отвечать на сообщения общего запроса группы. Поскольку в сегменте сети нет других членов группы многоадресной рассылки, RTA не будет получать сообщения с отчетами об участниках.Затем в течение определенного периода времени (130 секунд = 60 * 2 + 10, то есть время ожидания членства в группе = интервал отправки сообщения общего запроса IGMP × коэффициент устойчивости + максимальное время ответа на запрос) (то есть время для отправки общих сообщений запроса дважды + максимальное время 10 секунд По истечении времени устройства) удалите соответствующую запись многоадресной пересылки. 
Выбор запросчика
Если несколько маршрутизаторов одновременно подключены к одной принимающей конечной сети, для запроса IGMP требуется только один маршрутизатор.
Но IGMPv1 не имеет механизма выбора маршрутизатора запросов и полагается на протокол многоадресной маршрутизации для выбора запрашивающего в конечной сети.
Поскольку разные протоколы многоадресной маршрутизации используют разные механизмы выбора, в IGMPv1 может быть несколько запросчиков в одной конечной сети.
У IGMP проблемы
IGMPv2
Принцип работы IGMPv2 и IGMPv1 очень похож, но были улучшены две проблемы версии 1. В настоящее время в сетях чаще используется протокол ICMPv2.
Улучшение 1: участники группы уходят
Как показано на рисунке, в IGMPv2 процесс выхода клиента B из группы многоадресной рассылки G2 следующий:
Клиент B отправляет сообщение о выходе для группы G2 всем многоадресным маршрутизаторам в сегменте локальной сети.
Когда запрашивающий получает сообщение о разрешении, он отправляет G2Сообщение с запросом конкретной группы, ** Запуск таймера членства в группе Timer-Membership = интервал отправки x количество одновременных отправлений (2 с). По умолчанию отправляется один раз в 1 секунду, всего два раза, интервал отправки и время отправки можно настроить. ** По сравнению с 130S v1 он намного короче.
Если в сегменте сети нет других членов группы G2, маршрутизатор не получит сообщение с отчетом о членстве группы G2. По истечении времени таймера-членства удалите соответствующий нисходящий интерфейс в записи многоадресной пересылки. Маршрутизатор больше не будет пересылать многоадресные данные G2 в этот сегмент сети. Если в сетевом сегменте есть другие члены G2, эти участники будут отправлять сообщения с отчетом об участнике G2 в течение максимального времени ответа после получения сообщения с запросом конкретной группы. Маршрутизатор продолжает пересылать многоадресные данные G2 в этот сегмент сети. 
Улучшение 2: Выбор запросов
По сравнению с IGMPv1, IGMPv2 использует независимый механизм выбора запрашивающего.
Все маршрутизаторы IGMPv2 в исходном состоянии считают себя запрашивающими и отправляют общие сообщения запроса всем хостам и маршрутизаторам в сегменте локальной сети. После получения сообщения другие маршрутизаторы сравнивают исходный IP-адрес сообщения с адресом собственного интерфейса.Маршрутизатор с наименьшим IP-адресом станет запрашивающим., Остальные маршрутизаторы становятся не запрашивающими.
Все пользователи, не выполняющие запросы, запустят таймер. Если сообщение запроса от запрашивающего получено до истечения таймера, таймер сбрасывается; в противном случае исходный запросчик считается недействительным и инициируется выбор нового запрашивающего.
нота:
| рабочие места | Запросчик | Не запрашивающий |
|---|---|---|
| Отправить общий запрос | да | нет |
| Обработка сообщений отчета о членстве | да | да |
| Отправить конкретное сообщение-запрос | да | нет |
| Обработка отпускных сообщений | да | нет |
Сравнение сообщений IGMPv1 и IGMPv2
Сообщение IGMPv1:
Сообщение IGMPv2: сообщение IGMPv2 немного отличается от сообщения IGMPv1. Оно отменяет поле версии и добавляет поле максимального времени ответа.
IGMPv3
Новые требования в модели SSM
Получайте только многоадресные данные, отправленные определенным источником (сериал, iQiyi имеет bilibili, я смотрю только bilibili и не хочу смотреть iQiyi.)
Клиенты, использующие протоколы IGMPv1 и IGMPv2, не могут выбрать источник многоадресной рассылки. Независимо от того, нужно ли им это или нет, они будут получать данные от источников многоадресной рассылки Источник A и B одновременно.
Чтобы соответствовать новым требованиям модели SSM, появился IGMPv3.
v3 рабочий механизм
По сравнению с IGMPv2, сообщения IGMPv3 изменены следующим образом:
Сообщения IGMPv3 включают две основные категории: сообщения запроса и сообщения отчета о членстве. IGMPv3 не определяет специального сообщения о выходе из члена. Сообщение о выходе из члена передается через отчет определенного типа.
Сообщение запроса включает в себя не только сообщения общего запроса группы и сообщения запроса конкретной группы, но также новое сообщение запроса, специфичное для группы и источника (запрос, специфичный для группы и источника). Сообщение отправляется запрашивающим определенному члену группы многоадресной рассылки в совместно используемом сегменте сети, чтобы запросить, желает ли член группы получать данные из определенного источника. Конкретный запрос исходной группы достигает этой цели, неся в сообщении один или несколько групповых адресов источника.
Сообщение с отчетом о членстве содержит не только группу многоадресной рассылки, к которой узел хочет присоединиться, но также источник многоадресной рассылки, от которого узел хочет получать данные.
IGMPv3 добавляет режим фильтрации для источников многоадресной рассылки (INCLUDE / EXCLUDE):
Отчетное сообщение IGMPv3 сохранит изменение отношения в поле групповой записи (Group Record) и отправит его запросчику IGMP.
p В IGMPv3 сообщение с отчетом о членстве может нести информацию о нескольких группах многоадресной рассылки, тогда как в предыдущей версии отчет о членстве мог нести только одну группу многоадресной рассылки.Таким образом, хотя теперь каждый хост должен отправлять сообщения (механизм подавления отменяется, поскольку хосты могут быть одной и той же группы, но требования могут быть разными), количество сообщений в IGMPv3 все же значительно сокращается.
Различия между версиями IGMP
| механизм | IGMPv1 | IGMPv2 | IGMPv3 |
|---|---|---|---|
| Выбор запросчика | Положитесь на другие соглашения | Собственные выборы | Собственные выборы |
| Как участники уходят | Уйти тихо | Активно отправить оставить сообщение | Активно отправить оставить сообщение |
| Конкретный групповой запрос | не поддерживается | ожидать | ожидать |
| Укажите источник, группу | не поддерживается | не поддерживается | ожидать |
IGMP Snooping
Проблема пересылки многоадресных данных на втором уровне
Чтобы присоединиться к группе многоадресной рассылки, хост должен отправить отчет о членстве IGMP на вышестоящее устройство, чтобы вышестоящее устройство могло отправлять многоадресные пакеты на хост. Поскольку сообщения IGMP инкапсулируются в IP-сообщения и относятся к сообщениям протокола уровня 3, а устройства уровня 2 не обрабатывают информацию уровня 3 сообщений, устройство уровня 2 не знает процесс добавления хоста в группу и через канал передачи данных. MAC-адрес источника кадра данных на уровне дороги не может узнать MAC-адрес многоадресной рассылки (MAC-адрес источника кадра данных не будет MAC-адресом многоадресной рассылки).
Таким образом, когда устройство уровня 2 получает фрейм данных, MAC-адрес назначения которого является MAC-адресом многоадресной рассылки, оно не найдет соответствующую запись в таблице MAC-адресов. В это время он будет отправлять многоадресные сообщения широковещательной рассылкой, так что данные многоадресной рассылки будут получены, даже если это не класс-член многоадресной рассылки.
Как работает IGMP Snooping
IGMP Snooping настроен на нашем коммутаторе. 
IGMP Snooping может реализовывать пересылку и управление кадрами многоадресных данных на уровне канала данных.
Процесс IGMP Snooping, устанавливающий и поддерживающий таблицу многоадресной пересылки уровня 2:
Простая настройка IGMP
Конфигурация IGMP в основном выполняется на стороне маршрутизатора, и принимающему узлу необходимо только загрузить соответствующее программное обеспечение многоадресной рассылки.
Конфигурация маршрутизатора:
Точно так же мы можем передать команду [AR1]dis igmp group Информация о группе запросов.
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
