Мультикаст между одноуровевыми провайдерами

[Enigma33]

Здравствуйте, вопрос есть в разделе ТВ, но тут вопрос скорее с настройкой маршутизирующего оборудования, поэтому напишу и здесь.

Есть задача транслировать Multicast от соседнего Интернет-провайдера, у которого есть Multicast в сети. Планируем транслировать через Интернет по VPN через GRE туннель без шифрования, так как прямого стыка нет. Туннель создать на Cisco 3845 планируется. Оборудование агрегации Cisco, доступ в основном Dlink, схема один VLAN на микросектор.

Как технически реализовать возможно получение Multicast у нас? Общее представление о PIM, IGMP Snooping есть, практического опыта настройки Мультикаста нет. Каким определить RP и на каком оборудовании, какие интерфейсы поднять.

Такие тонкости происходят при настройке, что если на Cisco получателей задать RP как у тех, кто делится (соответственно объявив что IP этого RP доступен через туннель), то телевидение отправителей ложится намертво, пока не отключаешь Cisco 3845, которая для моста.

Если идентичная задача траспортировки решалась (и решилась) на форуме, прошу тыкнуть меня в нее носом.

Спасибо.

[darkagent]

pim-sm + msdp (без bgp).

[mightyscv]

Планируем транслировать через Интернет по VPN через GRE туннель без шифрования, так как прямого стыка нет. Туннель создать на Cisco 3845 планируется.

Попрощайтесь с качеством телевизора.

 

без bgp

А RPF-check как проходить будете?

 

А так да. В туннеле PIM и MSDP. RP - у них свой, у вас свой(лупбек маршрутизатора терминирующего туннель например). MBGP для передачи source маршрутов под RPF.

Через интернет/туннель картинка будет сыпаться, так что ваша затея заранее обречена на провал. Но для опыта можете поднять сигнализацию правильно хотя бы. Потом когда будете правильно всё делать опыт пригодится.

[rdntw]

Как технически реализовать возможно получение Multicast у нас? Общее представление о PIM, IGMP Snooping есть, практического опыта настройки Мультикаста нет. Каким определить RP и на каком оборудовании, какие интерфейсы поднять.

interdomain multicast routing: practical juniper networks and cisco systems

[darkagent]

А RPF-check как проходить будете?

http://ccieblog.co.uk/multicast/msdp-rpf-rule-3

Если речь о vpn тунеле, наверняка пляска будет либо от connected либо от static routes, а это позволяет как не использовать идентификатор AS в msdp, так и подставлять fake-AS, и в обоих случаях получать необходимый результат ;)

[Enigma33]

pim-sm + msdp (без bgp).

Наверно то, что надо.

Не сочтите за назойливость, но используя MSDP нужно иметь отправляющее оборудование с туннелем в качестве RP сети отправляющей стороны, или не обязательно.

Также, поднятие MSDP в такой схеме сильно ли отличается от тривиального "ip msdp peer <ip противоположной стороны туннеля>"

 

А так да. В туннеле PIM и MSDP. RP - у них свой, у вас свой(лупбек маршрутизатора терминирующего туннель например). MBGP для передачи source маршрутов под RPF.

Через интернет/туннель картинка будет сыпаться, так что ваша затея заранее обречена на провал. Но для опыта можете поднять сигнализацию правильно хотя бы. Потом когда будете правильно всё делать опыт пригодится.

Я полностью открыт к вашим предложениям, как советуете реализовать? Детали следующие: на отправляющей стороне используется RP - один из адресов аплинка, и забирают они мультикаст по IGMP Snooping (не уверен, но как вариант).

[Enigma33]

interdomain multicast routing: practical juniper networks and cisco systems

Искренне благодарен. Но есть ли на русском языке серьезное пособие, затрагивающее эту тематику?

[kisa]

Расскажу о своем опыте. Буквально пару дней назад прокинул себе в домашнюю сеть (сеть в квартире) через обычный интернет малтикаст влан из удаленной сети, где внедрена услуга iptv.

Задача была получить прямой l2 доступ в удаленный iptv влан. Для этого на одном из удаленных серверов, имеющим доступ к iptv влану создал тоннель к домашнему микротик бордеру.

Затем на удаленном сервере сбриджевал iptv влан и тоннель интрфейс, и тоже самое проделал на микротике. Тоннель делал по eoip микротиковской технологии, по сути это gre тоннель,

с upd транспортом. Все бы хорошо, но HD каналы сыпались. Потестил iperf ом в upd режиме тоннель и обнаружел потери. Затем решил попробовать другие тоннели. Быстренько поднял openvpn сервер в режиме tcp и о чудо, все ок, ничего не сыпется, правда немного нагружен домашний микртотик, т.к. канал шифрованный, и параметры шифрования достаточно стойкие.

 

Что их этой истории на мой взгляд может приодится топикстартеру:

1) через негарантированные инет каналы малтикаст лучше заворачивать в tcp и передавать адресно до нужной точки, где потом разоваричивать обратно

чтобы уже раздать на сеть как настоящий малтикаст, используя mvr, снупинги и т.п

 

2) можете вообще обойтись без малтикаст раутинга

 

3) если хотите раутинг, то RP необязательно делать свою, можно и чужой обойтись, тоннель ведь есть в удаленную сеть, без которого все равно никак

[Enigma33]

Что их этой истории на мой взгляд может приодится топикстартеру:

1) через негарантированные инет каналы малтикаст лучше заворачивать в tcp и передавать адресно до нужной точки, где потом разоваричивать обратно

чтобы уже раздать на сеть как настоящий малтикаст, используя mvr, снупинги и т.п

2) можете вообще обойтись без малтикаст раутинга

3) если хотите раутинг, то RP необязательно делать свою, можно и чужой обойтись, тоннель ведь есть в удаленную сеть, без которого все равно никак

Уточню некоторые моменты:

1. Я так понимаю, нужен туннель на TCP работающий, а GRE на UDP рассчитан. Есть ли TCP варианты на роутере Cisco?

2. Каким образом без мультикаст раутинга можно обойтись?

[rdntw]

а что думаете о варианте переделать мультикаст в юникаст и передать через тоннель?)

[Enigma33]

а что думаете о варианте переделать мультикаст в юникаст и передать через тоннель?)

Эм, а каким образом такое делается на Cisco? И не ограничено ли это принудительно на ней?

Верно ли понимаю:

На отправителе: ip route <псевдо-ip-канала> 255.255.255.255 <ip-канала-мультикаст>

На применике: ip route <ip-канала-мультикаст> 255.255.255.255 <псевдо-ip-канала>; ip route <псевдо-ip-канала> 255.255.255.0 <ip-тунеля-отправителя>

 

Если только так, но на это Cisco ругается, то на Cisco ограничена гибкая настройка маршутизации Мультикаста.

Edited February 20, 2015 by Enigma33

[rdntw]

Эм, а каким образом такое делается на Cisco? И не ограничено ли это принудительно на ней?

нее. это нужно делать через какой-нибудь линукс я думаю

 

PS: у самого опыта такого извращения не было, просто предположил)

[kisa]

Что их этой истории на мой взгляд может приодится топикстартеру:

1) через негарантированные инет каналы малтикаст лучше заворачивать в tcp и передавать адресно до нужной точки, где потом разоваричивать обратно

чтобы уже раздать на сеть как настоящий малтикаст, используя mvr, снупинги и т.п

2) можете вообще обойтись без малтикаст раутинга

3) если хотите раутинг, то RP необязательно делать свою, можно и чужой обойтись, тоннель ведь есть в удаленную сеть, без которого все равно никак

Уточню некоторые моменты:

1. Я так понимаю, нужен туннель на TCP работающий, а GRE на UDP рассчитан. Есть ли TCP варианты на роутере Cisco?

да, про циско не скажу, я делал на openvpn.

 

2. Каким образом без мультикаст раутинга можно обойтись?

 

раутинг нужун когда на пути пакетов есть раутеры ;) поэтому надо сделать так чтобы их не было или они были прозрачными для l2 трафика.

ключевой момент l2 связность за счет того, что концы тоннеля - это tun интерфейсы в терминологии linux, которые можно добавлять в bridge.

то есть приставка, подключенная у меня дома, отправляет igmp пакеты и они попадают прямиков в удаленный iptv влан, в котором есть igmp querier на источнике

малтикаста, в ответ он шлет малтикаст трафик нужной группы, трафик то частный случай широковещательного, поэтому он проходит через мои бриджи и тоннель и попадет

в домашнюю сеть.

 

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

но функций не будет. здесь нужна золотая середина. телевизионного трафика будет мегабит 200-300, нужно два тазика с openvpn.

[Enigma33]

телевизионного трафика будет мегабит 200-300, нужно два тазика с openvpn.

Стесняюсь спросить, что такое тазик?

[Liner's]

прямое попадание в _яндексе_

[^rage^]

Прекрасный тред-иллюстрация фразы "использовать не то не для того". Элементарная задача же.

[Enigma33]

Прекрасный тред-иллюстрация фразы "использовать не то не для того". Элементарная задача же.

Вот с этого места по подробнее =) Как сделать элементарно?

[kisa]

я тоже хочу услышать элементарное решение задачи гарантированной доставки малтикаста через интернет

[^rage^]

Прекрасный тред-иллюстрация фразы "использовать не то не для того". Элементарная задача же.

Вот с этого места по подробнее =) Как сделать элементарно?

ну какой-нибудь vtun/openvpn или любой другой, позволяющий сделать l2 поверх tcp.

можно забрать потоки и сделать из них нечто вроде псевдо-hls.

впрочем, я делал на gstreamer вариант, когда на одной стороне трафик разбирался где-то до уровня udp payload и инкапсулировался в gdp. на принимающей стороне все это обратно разворачивалось в мультикаст.

у людей спокойно передавало ~ 120 каналов через всю евразию по интернетам.

[kisa]

Прекрасный тред-иллюстрация фразы "использовать не то не для того". Элементарная задача же.

Вот с этого места по подробнее =) Как сделать элементарно?

ну какой-нибудь vtun/openvpn или любой другой, позволяющий сделать l2 поверх tcp.

можно забрать потоки и сделать из них нечто вроде псевдо-hls.

впрочем, я делал на gstreamer вариант, когда на одной стороне трафик разбирался где-то до уровня udp payload и инкапсулировался в gdp. на принимающей стороне все это обратно разворачивалось в мультикаст.

у людей спокойно передавало ~ 120 каналов через всю евразию по интернетам.

 

так именно это я и посоветовал - L2 тоннель через tcp и в качестве примера реально работающего решения привел как раз openvpn

 

вопрос в том, а есть ли такое решение для cisco?

[garycat]

В данном случае обойтись без дополнительного преобразования скорее всего не получится.

Есть как минимум два проверенных временем варианта:

1. как предлагает ^rage^ использовать gstreamer (можно найти топик на наге с рецептом)

2. Преобразовать сигнал в HLS передать на другой конец планеты, и там сделать обратное преобразование

[Enigma33]

Извините, но я так и не понял как реализовать сабж на оборудовании Cisco. Вообще, я так понял самое надежное и гибкое решение MBGP + MSDN. Может у кого есть опыт с настройкой такой схемы, и мог бы предложить примеры конфигураций для данной задачи? Неужели никто из формумчан не поднимал такую схему?

Также вопрос, если провайдер, от которого планируется брать мультикаст, забирает сам по IGMP, не является ли это препятствием серьезным для дальнейшей трансляции?

Edited February 24, 2015 by Enigma33

[Enigma33]

нужно два тазика с openvpn

прямое попадание в _яндексе_

Не думаю что мне нужно 2 автомобиля для этого. Думаю речь о чем-то другом)

Edited February 24, 2015 by Enigma33

[Enigma33]

Вот схема для подобной задачи. Из R1 в R2. Кто такие NW1 NW2 NW3, что такое SAFI, и как именно определить интерфейс до источника?

 

! On Cisco IOS, IOS-XE
! R1-R2

R1#
! On Cisco IOS, IOS-XE
! Configuration
router bgp $MY_AS
neighbor $R2 remote-as $REMOTE_AS
network $NW1 mask $MASK1
network $NW2 mask $MASK2
!
address-family ipv4 multicast
 neighbor $R2 activate		! Sets up a new BGP session
 network $NW1 mask $MASK1	! Advertises RPF route
 network $NW3 mask $MASK3
!
interface lo0
 ip $NW1 $MASK1
 ip pim sparse-mode		! Required for MBGP to advertise
!
! Note: $NW1 will have SAFI=3 (unicast and multicast), 
! 		$NW2's SAFI=1 (unicast only)
! 		$NW3's SAFI=2 (multicast only)

R2#
router bgp $MY_AS
neighbor $R1 remote-as $REMOTE_AS
!
address-family ipv4 multicast
 neighbor $R1 activate
!

! Verification
show ip mbgp == show ip bgp ipv4 multicast ! Shows mcast RPF prefixes
R1# show ip bgp ipv4 multicast summary ! Session should be up
R1# show ip bgp ipv4 multicast advertised-routes
R2# show ip bgp ipv4 unicast
! shows $NW1 and $NW2
R2# show ip bgp ipv4 multicast
! shows $NW1 and $NW3
R2# show ip rpf $NW3 | include multicast
! RPF check works

Edited February 24, 2015 by Enigma33

[darkagent]

как именно определить интерфейс до источника?

Я так понимаю, ни вы, ни второй оператор, не имеете ни познаний в теории, ни какой-либо практики по развертыванию услуг IPTV.

Если судить по содержимому приведенного примера - это для случая внедрения mdt для ibgp, т.е. развертывание мультикаста в рамках одного оператора.

Для завязки меж.операторского обмена, на R2 так же нужен int loopback со sparse-mode на нем, и дополнить все это дело встречными msdp сессиями:

ip msdp peer $NW1 connect-source loopback0

ip msdp cache-sa-state

ip msdp redistribute list ABC (на стороне оператора, отдающего вам мультикаст)

где ABC - ацесс-лист,разрешающий анонсирование S,G пар, примерно в таком формате:

ip access-list ext 101

permit ip host source_ip 234.5.6.0 0.0.0.255

 

При этом необходимо убедиться, что адреса лупбеков с обеих сторон анонсируются и видят друг друга (ping $NW1 source loopback0).