Wireless multicast forwarding что это

Внедрение Multicast VPN на Cisco IOS (часть 1 — знакомство с Default MDT)

Разбираясь с современными методами организации multicast VPN я заметил, что в сети не так много материала, описывающего принципы и детали работы технологий. На сайте вендора представлена достаточная конфигурация для внедрения, но не описан смысл всех производимых деяний.

В этом цикле статей я постараюсь немного приоткрыть завесу тайны того как всё работает под капотом.

Прим. Автор подразумевает, что читатель хорошо знаком со следующими технологиями: OSPF, BGP, PIM, MPLS.

Заинтересовавшимся — добро пожаловать под кат.

Основной задачей является туннелирование мультикаст-пакетов между РЕ маршрутизаторами (от Ingress PE к одному или более Egress PE). Для этого необходимо построить наложенную (overlay) сеть поверх опорной (underlay) инфраструктуры.

Если мы обратимся к RFC6513, то найдем там одно довольно пространственное пояснение по поводу, как необходимо передавать трафик между РЕ-маршрутизаторами: «P-tunnels must be used – a P-tunnel is a transport mechanism inside the network of the Service Provider that instantiates a Provider Multicast Service Interface (PMSI). A PMSI is a conceptual “overlay” on the P-network with the following property: a PE in a given MVPN can give a packet to the PMSI, and the packet will be delivered to some or all of the other PEs in the MVPN, such that any PE receiving the packet will be able to determine the MVPN to which the packet belongs.»

Т.е. если просто следовать сказанному, то вся multicast VPN инфраструктура будет выглядеть приблизительно вот так:

Осталась самая малость – разобраться с тем, как строить этот PMSI и как РЕ устройствам узнавать друг о друге.

На текущий момент мне известно четыре способа создания Р-туннелей:

Прим. В статьях основное внимание будет уделено созданию PMSI с помощью PIM и mLDP.

После поднятия Р-туннелей, РЕ должны произвести сигнализацию о наличии Источников и/или Получателей трафика в сети. Делается это одним из двух вариантов:

Ключевыми блоками mVPN являются следующие компоненты:

Мультикастные деревья

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

В зависимости от того, как может передаваться многоадресный трафик, все деревья можно разделить по группам:

Функционально деревья делятся на три категории:

О каждом из этих деревьев мы подробно поговорим в следующих разделах (в следующих выпусках). Сейчас же остановимся на дереве, которое является обязательным аттрибутом любой имплементации mVPN и носит название «Default MDT».

Default MDT

Default MDT представляет собой древовидную структуру для соединения всех PE-маршрутизаторов в рамках одного VPN (VRF) с включенной многоадресной рассылкой. Преимущество наличия Default MDT заключается в том, что оно облегчает передачу сигнализации PIM в наложенной сети.

Default MDT всегда включено и из-за этого все маршрутизаторы PE становятся PIM соседями в рамках VRF, что позволяет передавать PIM сигнализацию (Join/Prune, RPT Switchover) поверх Default MDT также, как если бы все РЕ маршрутизаторы находились в одном LAN сегменте.

mVPN Profile 0

Одним из наиболее простых способов реализации mVPN является вариант настройки который известен под кодовым именем «Profile 0», именуемый в народе как «Draft Rosen».

Основные компоненты реализации профиля:

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

Шаблон для настройки базовых ингридиентов:

После проведение указанных настроек, Вы можете увидеть, что на каждом из устройств появился как минимум один туннель (а на Provider RP (P-RP) – целых два). При этом эти туннели не видны в конфигурации, но присутствуют в выводе show ip int brief. В чем же их назначение? Ответ: Tunnel необходим для передачи (encap) сообщений PIM-Register в сторону P-RP. На стороне P-RP дополнительный Tunnel необходим для обработки (decap) всех прибывающих Register сообщений.

Прим. Номера туннельных интерфейсов у меня и у Вас в лаборатории могут отличаться

В Profile 0 подразумевается передача C-multicast трафика с помощью mGRE инкапсуляции. В новом (внешнем) IP заголовке выставляется адрес многоадресной рассылки. Данный адрес должен быть маршрутизируем в рамках опорной сети (внутри GRT). Именно для этого нам необходим PIM внутри GRT. Задается данная группа с помощью следующей конструкции:

Таким образом, если ingress PE получает мультикаст-пакет в рамках клиентского VRF, то этот ingress РЕ инкапсулирует его внутрь mGRE, в качестве destination IP выставляет адрес 239.1.1.1 и пакет отправляется в опорную сеть.

Очевидно, что все egress PE должны быть подписаны на ту же самую многоадресную группу. В противном случае трафик до них не дойдет. Дополнительной настройки для подписки на группу не требуется.

Из вывода видно, что РЕ2 подписался на группу (*, 239.1.1.1) со своего интерфейса Loopback0. Это, в свою очередь, ведет к генерации PIM Join в сторону RP и формированию многоадресного дерева в опорной сети.

В выводе ниже видно, что на Р2 появляется запись в mRIB. Наличие двух маршрутов обусловлено работой PIM ASM (shared tree и source-based tree):

После того, как настройка MDT для vrf C-ONE растиражирована на все РЕ, на Р устройствах появляются соответствующие маршруты:

На данном этапе опорная сеть готова к передаче многоадресного трафика в рамках GRT. Но зачем нам это? — ведь пользовательский трафик живет внутри C-VRF! Постараемся ответить на данный вопрос ниже.

Следующим шагом необходимо поднять интерфейс PMSI. На Cisco IOS (в рамках Profile 0) за это отвечает адресное семейство MDT процесса BGP. Как только на РЕ появляется сконфигурированный MDT сосед, операционная система автоматически создает PMSI интерфейс.

Все MDT сессии будем строить также через Route Reflector (R8).

На РЕ сразу же появляется дополнительный интерфейс Tunnel:

Интерфейс Tunnel0 — ничто иное, как PMSI относящийся к C-VRF.

Через данный интерфейс РЕ начинает рассылку сообщений PIM Hello (на адрес 224.0.0.13) и устанавливает отношения соседства со всеми другими РЕ, на которых настроена VRF с таким же адресом для Default MDT.

На рисунке ниже представлен дамп одного из PIM Hello, отправленного со стороны РЕ1. Как видно, доставка клиентского (в рамках VRF) пакета до всех заинтересованных РЕ достигается за счет инкапсуляции внутрь многоадресного IP-пакета, который может маршрутизироваться в рамках опорной сети.

Из всего вышесказанного следует, что дерево Default MDT имеет тип Multipoint-to-Multipoint т.к. любой РЕ имеет право передавать данные в рамках дерева (напр. сообщения PIM Hello) и пакеты будут доставлены до любого другого РЕ, являющегося частью указанного дерева.

Внимательный читатель мог справедливо задаться вопросом: «а в чем тайный смысл адресного семейства MDT? Ведь маршрутизация осуществляется благодарю наличию PIM ASM в опорной сети».

Все дело в том, что реализация Cisco IOS подразумевает, что PMSI поднимется только после настройки хотя бы одного BGP соседа в рамках указанного адресного семейства. Технически, соседство может быть даже не установлено (Tunnel0 переходит в состояние UP как только Вы введете команду neighbor activate).

Соседство в рамках MDT строго требуется, если внутри опорной сети работает PIM SSM. Дело в том, что если в сети отсутствует RP, то РЕ маршрутизаторам как-то необходимо узнать друг о друге. В рамках MDT они обмениваются маршрутами следующего вида:

Из указанных апдейтов РЕ выбирает поля Originator и MDT group address, что позволяет просигнализировать (S,G) дерево.

Прим. Согласно документации от вендора: The Address Family (AF) IPv4 Multicast Distribution Tree (MDT) must be used for all types of PIM signaling in the core (not only for PIM Source Specific Multicast (SSM)).
Т.е. без sAFI MDT всё будет работать, но официально такая конструкция не поддерживается.

Осталось проверить прохождение клиентского трафика.

Для этого, на CE3 и CE4 пропишем конструкцию:

Убедимся, что на РЕ3 и РЕ4 появились маршруты:

На РЕ2 OIL пустой (поскольку нет активных получателей). Однако, IIL состоит из интерфейса Tunnel (default MDT). Т.е. РЕ2 будет получать пакеты на группу 230.0.0.1 и отбрасывать их.

Из дампа наглядно видно, что передача трафика осуществляется абсолютно также, как и передача сигнальных сообщений PIM (посредством инкапсуляции в mGRE):

Таким образом: даже при наличии MPLS внутри опорной сети, метки для передачи многоадресного трафика (в рамках Profile 0) не используются.

При этом ответный трафик (ICMP reply) подчиняется законам одноадресной маршрутизации и его передача осуществляется по классическим правилам MPLS L3 VPN:

К сожалению, Default MDT не всегда эффективно. Все дело в том, что оно доставляет весь многоадресный трафик на все PE-маршрутизаторы, независимо от того, есть ли C-Receiver или же нет. Это означает, что ядро ​​сети может передавать многоадресный трафик к тем маршрутизаторам PE, которые затем отбрасывают трафик. Это видно из дампа трафика (обратите внимание на поле VLAN которое символизирует линк между R2 (PE2) и R6 (P2)).

Чтобы обойти ограничения Default MDT вводится понятие Data MDT, которое позволяет переключить пользовательский трафик C-(S,G) из Default MDT в Data MDT, в котором участвуют только те РЕ, где есть активные источники или получатели трафика. Об этом мы поговорим с Вами в следующем выпуске.

Источник

Настройка IP-TV на роутерах

Для просмотра IP-TV на Вашем компьютере, требуется настроить для этого Ваш wi-fi роутер. Рассмотрим настройки различных моделей беспроводных роутеров на примерах распространенных моделей.

Настройка IP-TV для роутеров Asus

Настройка IP-TV для Asus Ver. 1.0.x (на примере Asus RT-G32)

Есть два варианта настройки.

Вариант 1.

Теперь необходимо выбрать порт маршрутизатора через который будем смотреть IP-TV. Переходим в раздел WAN-> Интернет соединение (Internet Connection) и указываем номер порта.

Преимущества:

Недостатки:

Вариант 2.

Преимущества:

Недостатки:

Необходимо изменение плейлиста для мультимедиа плеера. Изменения, которые необходимо провести c VLC плей-листом при использовании функции IPTV UDP Multicast to HTTP Proxy:

Инструкция на настройке IP-TV для Asus ver. 3.0.0.x (на примере Asus RT-N66U)

Для настройки IPTV, выберите меню Локальная сеть и вкладку IPTV

Для просмотра IPTV через wi-fi, перейдите в меню Беспроводная сеть, вкладка Профессионально

Настройка IP-TV для D-Link

Настройка IP-TV на D-Link DIR-615 ver. E

Настройка IP-TV на D-Link DIR-615 ver. 1.3.x

Вариант 1. Настройка без тегирования траффика

В данном случае смысл настройки сводится к отделению одного из четырех LAN-портов и объединению его с WAN-портом. С помощью такой настройки приставка смотрит напрямую в сеть провайдера, как бы сквозь роутер, т.е. так, как будто кабель провайдера включили напрямую в приставку.

Заходим в Настройка IP-TV.

В данном случае подключаем stb или смотрим IP-TV на компьютере с 4-го порта вашего wi-fi роутера.

Вариант 2. Настройка с тегированием траффика.

Теперь добавляем Port 5, но уже выбираем ему тип Tagget. Фактически мы объединяем порт 5 (Wan-порт) и порт 1 (с которого будем смотреть IP-TV).

Если Вы все правильно сделали, должно получиться как на картинке ниже (смотрим строчку IP-TV)

Настройка IP-TV на D-Link DIR-615 ver. 1.4.x

Вариант 1. Настройка без тегирования траффика

В данном случае смысл настройки сводится к отделению одного из четырех LAN-портов и объединению его с WAN-портом. С помощью такой настройки приставка смотрит напрямую в сеть провайдера, как бы сквозь роутер, т.е. так, как будто кабель провайдера включили напрямую в приставку.

Нажимаем вкладку IP телевидение.

В данном случае подключаем stb или смотрим IP-TV на компьютере с 4-го порта вашего wi-fi роутера.

Вариант 2. Настройка с тегированием траффика.

Здесь выбираем любой LAN-порт, например порт 4, кликаем на нем мышью и нажимаем кнопку Удалить порт а затем Сохранить изменения. Должно получится вот так:

Все, настройка IPTV на DIR-615 K1(DIR-300 NRU B5) завершена. Не забудьте сохранить настройки роутера.

Настройка IP-TV на D-Link DIR-320 NRU B5

Обязательно при создании подключения к инернету в разделе Разное проставьте галочки на пунктах Включить IGMP и NAT.

Попадаем в окошко настройки WAN, в самом низу есть 2 кнопки (Сохранить, Удалить). Нажимаем кнопку Удалить;

В результате получим, что в списке соединений нет WAN;

Выбираем один из портов lan, в нашем случае port 4 и жмем Удалить порт;

В результате получаем следующее (в VLAN объявлены только port 1, 2 и 3 соответствующие разъемам LAN на задней панели устройства):

Жмем Сохранить изменения; В подменю VLAN наблюдаем следующую картину:

Сохраняем изменения (кнопка Сохранить; в правом верхнем углу) и ждем перезагрузки устройства.

В появившемся окошке в разделе Порты;, в выпадающем списке выбираем port4, добавив его к VLAN wan:

Жмем Сохранить изменения;

Внимание: Можно снова добавить port 5 Сохраняем настройки устройства с перезагрузкой устройства. Ниже видно, что port4 и port5 принадлежат VLAN wan

4. Создать соединение WAN; Далее идем в меню Сеть; подменю Соединения;, для создания соединение WAN жмем Добавить;

Настройка IP-TV на роутерах NetGear

Настройка IP-TV для Netgear WNR2200

Настройка IP-TV для Netgear WNDR4300

Настройка IP-TV на роутерах TP-Link

Настройка IP-TV для TP-Link TP-Link TL-WR741ND и TL-WR841ND

Примечания:

Настройка IP-TV для TrendNet

Для Wi-Fi роутеров TrendNet на стандартных прошивках дополнительно настраивать ничего не надо. Опция Multicast Routing; по умолчанию включена, выключить ее нельзя. Если у Вас все же не работаем IPTV, проверьте настройки файервола и брэндмауэра и обращайтесь к поставщику услуг.

Настройка IP-TV для Upvel

Настройка IP-TV для Upvel UR-315BN

Настройки IP-TV для данного роутера делаются при создании подключения к Интернету и одинаковы для всех типов подключения. Требуется проставить галочки как на картинке:

Настройка IP-TV для Upvel UR-326N4G

Настройка IP-TV для роутеров ZyXEL

Настройка IP-TV для ZyXEL Keenetic Lite

Для того, чтобы включить IPTV и смотреть его на компьютере выбираемАвтоматический режим для TVport в раздел Домашняя сеть подраздел IP-телевидение.

Для просмотра на телевизоре через IPTV-ресивер (STB приставка) Режим TVport. Выбираем Назначить разъем LAN. Указываем порт, через который подключен ресивер (stb приставка).

Настройка IP-TV на ZyXEL Keenetic V1

Настройка с тегированием траффика.

Для настройки требуется узнать Vlan-ы для IP-TV и Интернета у Вашего провайдера. Это связано с тем, что Zyxel Keenetic V1 при настройках IP-TV требует тегирование и Vlan для Интернета.

Режим TVport выбираем На базе 802.1Q VLAN, разъём для ресивера IPTV ставим тот портпорты, с которого будем смотреть ip-tv (в нашем примере это 3 и 4 порты). Прописываем Vlan для Интернета и для IP-Телевидения (у нас это 1225 и 1000). Нажимаем Применить.

Настройка IP-TV на ZyXEL Keenetic V2 (На примере ZyXEL Keenetic Giga)

1. Включите в интернет-центре функцию IGMP Proxy. Для этого в веб-конфигураторе устройства надо перейти на закладку Домашняя сеть > IGMP Proxy и установить галочку в поле Включить функцию IGMP proxy. Примечание. Если в веб-интерфейсе отсутствует закладка IGMP Proxy, то это означает, что в микропрограмме не установлен компонент IGMP proxy. Для его включения зайдите в меню Система > Компоненты, поставьте галочку в поле IGMP proxy и нажмите Применить. Дождитесь обновления компонентов и затем приступайте к настройке.

3. Если вы планируете просмотр IPTV через приставку, определите специальный ТВ-порт, к которому она будет подключена и на который будет приходить цифровое телевидение. Зайдите в меню Интернет и щелкните по строке сетевого интерфейса ISP (базовый WAN-интерфейс) для дополнительной настройки этого интерфейса.

В списке портов/разъемов установите в поле Использовать разъем только галочку на порту, к которому будет подключена приставка IPTV (в нашем примере указан порт 4). Нажмите кнопку Применить для сохранения настроек.

Источник

Multicast routing для IPTV

Один очень близкий мне человек, поклонник Хабра, захотел внести вклад в развитие блога Cisco. Являясь яростным поклонником того, что создает эта корпорация, он захотел поделиться опытом. =) Надеемся росчерк пера удался.

Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.

И вот незадача. Обычно в документации выкладывают все и сразу и для человека, впервые столкнувшегося с этой темой, не понятно с чего начать. Во время чтения pdf’ок я ловила себя на мысли, что было бы неплохо наткнуться где-нибудь на статью, которая могла бы коротким путем провести от теории к практике, чтобы понять с чего стоит начать и где заострить внимание.

Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.

Введение

Это моя самая первая статья (но не последняя! есть еще много зверей), постараюсь изложить все как можно доступнее.

Какой вид трафика использовать для IPTV?

Очевидно, что для вещания каналов наибольшее предпочтение отдается multicast.
Любой TV-канал, который мы хотим вещать в сеть, характеризуется адресом группы, который выбирается из диапазона, зарезервированного для этих целей: 224.0.0.0 – 239.255.255.255.

Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить какому клиенту какой отправлять TV-канал.

Для того чтобы клиент смог зарегистрироваться в одной из этих групп и смотреть TV-канал используется протокол IGMP (Internet Group Management Protocol).

Немного о том, как работает IGMP.

Есть сервер, который включен в роутер MR. Этот сервер вещает несколько TV-мультиков, например:

Клиент включает канал 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.

Команда «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):

Все остальные роутеры должны знать маршрут до 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

Не забываем про 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

Источник