Доброго времени суток!Сразу скажу, что опыта работы с мультикастом у меня практически нет. До этого как-то не было такой необходимости.
Мой апстрим с недавнего времени стал отдавать мне IPTV. Уже неделю бьюсь над тем, чтобы забрать себе multicast и пока результата ноль.
Исходные данные:Схема:
[ источник ] <-> R1 <-> R2 <-> [ клиенты ]R1 - СISCO router апстрима. PIM-SM v2. Как он настроен детально, не имею ни малейшего понятия, и админы не особенно хотят что-то рассказывать и делать. Принцип такой: мы тебе отдали, а забирай как знаешь.
R2 - Linux router. Под моим контролем. Все необходимые опции (MULTICAST MROUTE PIM-SM) в ядре включены.
На R2 ставил pimd и xorp. Результат одинаков: ничего не работает. Если поставить igmpproxy, все работает, но этот вариант не подходит, ибо для достижения конечной цели нужна более сложная схема с каскадированием через несколько роутеров (много клиентских сегментов).
Но если вместо R2 поставить CISCO (у меня 6509) и настроить ее под PIM-SM - все работает. Но у меня нет возможности принять все вланы в эту кошку, поэтому как решение это не подходит.Попробовал сделать схему так:
[ источник ] <-> R1 <-> R2 <-> R3 <-> [ клиенты ]
Где R2 - мой catalyst 6509, а R3 - Linux router, который ранее подключался к апстриму напрямую.
Как все было сделано:
R1: 192.168.248.1/24
Адрес источника вещания: 172.16.2.2 (находится где-то в недрах сети апстрима).R2:
ge5/1: 192.168.248.248/24 (к апстриму)
ge5/2: 192.168.200.200/24 (ко мне)
fa4/1: 192.168.199.1/24 (Для тестового прямого подключения клиента)
ip multicast-routingip pim rp-address 192.168.248.1
На обоих интерфейсах ip pim sparse-mode
R3:
eth0: 192.168.200.1/24 (меж-вланный сегмент)
vl17: 10.128.0.1/14 (влан клиентов)Если включить клиента с адресом 192.168.199.2 в 6509 - все прекрасно работает.
Если включить клиента с адресом 10.128.0.2 - не работает ничего. Что с pimd, что с xorp результат одинаков: роутер видит мой запрос, и включает выбранную группу в список, входящий и исходящий интерфейсы устанавливаются верно. И дальше ничего не происходит.
Что удалось выяснить:
1. Если на R3 настроить RP 192.168.248.1 - он ругается, что next-hop роутер не мультикаст роутер. Группу добавляет, мультикаст не идет. На 6509 при этом абсолютно ничего не происходит, ни сообщений в логах, ничего. Хотя включен debug pim и т.д.
2. Если на R3 настроить RP 192.168.200.200 - сообщений об ошибках нет, группу добавляет, мультикаст не идет. На 6509 выпадает сообщение, что 192.168.200.200 invalid RP, ignored.Если пытаться менять RP на 6509, тогда процесс сдвигается с мертвой точки, но в этом случае 6509 упорно не желает принять 192.168.248.1 как RP-адрес, как я ни пытался это исправить. Она ставит RP-адрес внутреннего сегмента, и соответственно - я ничего не получаю от апстрима.
Такое впечатление, что 6509 может принять join запрос только на том интерфейсе, который напрямую видит клиента. Но если RP установлен на апстрима, то тогда, принимая запрос от Linux, он считает, что RP неверный.
В общем - так я и не понял, каким образом можно организовать получение мультикаст вещания хотя бы через один транзитный роутер, который не имеет прямого линка на реального вещателя, а только выполняет функцию пересылки join/prune запросов и соответственно вещает/не вещает мультикаст в нужном направлении при наличии живых подписчиков. Подскажите, люди добрые, что можно с этим сделать? Интересно, хоть кто-нибудь добивался положительного результата с вещанием мультикаста PIM-SM на связке Linux-Cisco?
Всем спасибо за внимание.
Задача решена. Все оказалось не так уж и сложно, нужно было всего лишь соблюсти некоторые совершенно необходимые условия. К сожалению данная тема освещена в интернетах довольно скудно и в тех документах, которые я читал по pimd в частности и PIM-SM в целом, об одном их этих условий ничего не сказано. А это условие чуть ли не самое главное.После долгих и трудных переговоров с апстримом удалось узнать больше о топологии его мультикаст-сети, и самое главное - адрес rendezvous point. В моем случае это серый адрес, никаким образом не имеющий возможности ходить в мою сеть. Однако, как оказалось, именно этот самый адрес необходимо использовать в качестве rp_address в pimd.
Условия, необходимые для успешного применения pimd:
1. Необходимо точно знать unicast-адрес rendezvous point (адрес маршрутизатора, который прямо видит вещателя). Адрес может быть недоступен по unicast протоколам, но для данной задачи это абсолютно неважно.
2. Если маршрут по умолчанию не идет в мультикаст-апстрим интерфейс, должен быть задан явный маршрут до адреса rendezvous point через мультикаст-апстрим интерфейс, шлюзом должен быть обязательно адрес PIM-SM роутера апстрима.
3. Ни в коем случае не указывать адрес сети rendezvous point как altnet в настройках апстрим-интерфейса, altnet применяется только на интерфейсах, где находятся получатели. (Мда... в igmpproxy все в точности наоборот, и это обстоятельство добавило пару лишних суток в процесс решения).
С помощью pimd прекрасно получается перебрасывать мультикаст-траффик через несколько маршрутизаторов (в моем случае через два, но я не вижу проблем, даже если их будет больше, но в этом случае необходимо учитывать TTL). Самое главное - на всех маршрутизаторах должны быть соблюдены вышеуказанные условия.
В итоге получаем доступность всех вещаемых групп, и при этом в апстрим-интерфейсе, транзитных интерфейсах и интерфейсах получателей присутствует траффик только тех групп, на которые есть подписчик.
Естественно, все это будет работать только в том случае, если апстрим является PIM-SM роутером.