Enigma33 Опубликовано 19 февраля, 2015 · Жалоба Здравствуйте, вопрос есть в разделе ТВ, но тут вопрос скорее с настройкой маршутизирующего оборудования, поэтому напишу и здесь. Есть задача транслировать Multicast от соседнего Интернет-провайдера, у которого есть Multicast в сети. Планируем транслировать через Интернет по VPN через GRE туннель без шифрования, так как прямого стыка нет. Туннель создать на Cisco 3845 планируется. Оборудование агрегации Cisco, доступ в основном Dlink, схема один VLAN на микросектор. Как технически реализовать возможно получение Multicast у нас? Общее представление о PIM, IGMP Snooping есть, практического опыта настройки Мультикаста нет. Каким определить RP и на каком оборудовании, какие интерфейсы поднять. Такие тонкости происходят при настройке, что если на Cisco получателей задать RP как у тех, кто делится (соответственно объявив что IP этого RP доступен через туннель), то телевидение отправителей ложится намертво, пока не отключаешь Cisco 3845, которая для моста. Если идентичная задача траспортировки решалась (и решилась) на форуме, прошу тыкнуть меня в нее носом. Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 19 февраля, 2015 · Жалоба pim-sm + msdp (без bgp). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mightyscv Опубликовано 19 февраля, 2015 · Жалоба Планируем транслировать через Интернет по VPN через GRE туннель без шифрования, так как прямого стыка нет. Туннель создать на Cisco 3845 планируется. Попрощайтесь с качеством телевизора. без bgp А RPF-check как проходить будете? А так да. В туннеле PIM и MSDP. RP - у них свой, у вас свой(лупбек маршрутизатора терминирующего туннель например). MBGP для передачи source маршрутов под RPF. Через интернет/туннель картинка будет сыпаться, так что ваша затея заранее обречена на провал. Но для опыта можете поднять сигнализацию правильно хотя бы. Потом когда будете правильно всё делать опыт пригодится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdntw Опубликовано 19 февраля, 2015 · Жалоба Как технически реализовать возможно получение Multicast у нас? Общее представление о PIM, IGMP Snooping есть, практического опыта настройки Мультикаста нет. Каким определить RP и на каком оборудовании, какие интерфейсы поднять. interdomain multicast routing: practical juniper networks and cisco systems Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 19 февраля, 2015 · Жалоба А RPF-check как проходить будете? http://ccieblog.co.uk/multicast/msdp-rpf-rule-3 Если речь о vpn тунеле, наверняка пляска будет либо от connected либо от static routes, а это позволяет как не использовать идентификатор AS в msdp, так и подставлять fake-AS, и в обоих случаях получать необходимый результат ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Enigma33 Опубликовано 19 февраля, 2015 · Жалоба pim-sm + msdp (без bgp). Наверно то, что надо. Не сочтите за назойливость, но используя MSDP нужно иметь отправляющее оборудование с туннелем в качестве RP сети отправляющей стороны, или не обязательно. Также, поднятие MSDP в такой схеме сильно ли отличается от тривиального "ip msdp peer <ip противоположной стороны туннеля>" А так да. В туннеле PIM и MSDP. RP - у них свой, у вас свой(лупбек маршрутизатора терминирующего туннель например). MBGP для передачи source маршрутов под RPF. Через интернет/туннель картинка будет сыпаться, так что ваша затея заранее обречена на провал. Но для опыта можете поднять сигнализацию правильно хотя бы. Потом когда будете правильно всё делать опыт пригодится. Я полностью открыт к вашим предложениям, как советуете реализовать? Детали следующие: на отправляющей стороне используется RP - один из адресов аплинка, и забирают они мультикаст по IGMP Snooping (не уверен, но как вариант). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Enigma33 Опубликовано 19 февраля, 2015 · Жалоба interdomain multicast routing: practical juniper networks and cisco systems Искренне благодарен. Но есть ли на русском языке серьезное пособие, затрагивающее эту тематику? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 19 февраля, 2015 · Жалоба Расскажу о своем опыте. Буквально пару дней назад прокинул себе в домашнюю сеть (сеть в квартире) через обычный интернет малтикаст влан из удаленной сети, где внедрена услуга iptv. Задача была получить прямой l2 доступ в удаленный iptv влан. Для этого на одном из удаленных серверов, имеющим доступ к iptv влану создал тоннель к домашнему микротик бордеру. Затем на удаленном сервере сбриджевал iptv влан и тоннель интрфейс, и тоже самое проделал на микротике. Тоннель делал по eoip микротиковской технологии, по сути это gre тоннель, с upd транспортом. Все бы хорошо, но HD каналы сыпались. Потестил iperf ом в upd режиме тоннель и обнаружел потери. Затем решил попробовать другие тоннели. Быстренько поднял openvpn сервер в режиме tcp и о чудо, все ок, ничего не сыпется, правда немного нагружен домашний микртотик, т.к. канал шифрованный, и параметры шифрования достаточно стойкие. Что их этой истории на мой взгляд может приодится топикстартеру: 1) через негарантированные инет каналы малтикаст лучше заворачивать в tcp и передавать адресно до нужной точки, где потом разоваричивать обратно чтобы уже раздать на сеть как настоящий малтикаст, используя mvr, снупинги и т.п 2) можете вообще обойтись без малтикаст раутинга 3) если хотите раутинг, то RP необязательно делать свою, можно и чужой обойтись, тоннель ведь есть в удаленную сеть, без которого все равно никак Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Enigma33 Опубликовано 20 февраля, 2015 · Жалоба Что их этой истории на мой взгляд может приодится топикстартеру: 1) через негарантированные инет каналы малтикаст лучше заворачивать в tcp и передавать адресно до нужной точки, где потом разоваричивать обратно чтобы уже раздать на сеть как настоящий малтикаст, используя mvr, снупинги и т.п 2) можете вообще обойтись без малтикаст раутинга 3) если хотите раутинг, то RP необязательно делать свою, можно и чужой обойтись, тоннель ведь есть в удаленную сеть, без которого все равно никак Уточню некоторые моменты: 1. Я так понимаю, нужен туннель на TCP работающий, а GRE на UDP рассчитан. Есть ли TCP варианты на роутере Cisco? 2. Каким образом без мультикаст раутинга можно обойтись? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdntw Опубликовано 20 февраля, 2015 · Жалоба а что думаете о варианте переделать мультикаст в юникаст и передать через тоннель?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Enigma33 Опубликовано 20 февраля, 2015 (изменено) · Жалоба а что думаете о варианте переделать мультикаст в юникаст и передать через тоннель?) Эм, а каким образом такое делается на 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 ограничена гибкая настройка маршутизации Мультикаста. Изменено 20 февраля, 2015 пользователем Enigma33 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdntw Опубликовано 20 февраля, 2015 · Жалоба Эм, а каким образом такое делается на Cisco? И не ограничено ли это принудительно на ней? нее. это нужно делать через какой-нибудь линукс я думаю PS: у самого опыта такого извращения не было, просто предположил) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 20 февраля, 2015 · Жалоба Что их этой истории на мой взгляд может приодится топикстартеру: 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Enigma33 Опубликовано 20 февраля, 2015 · Жалоба телевизионного трафика будет мегабит 200-300, нужно два тазика с openvpn. Стесняюсь спросить, что такое тазик? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Liner's Опубликовано 20 февраля, 2015 · Жалоба прямое попадание в _яндексе_ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 20 февраля, 2015 · Жалоба Прекрасный тред-иллюстрация фразы "использовать не то не для того". Элементарная задача же. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Enigma33 Опубликовано 20 февраля, 2015 · Жалоба Прекрасный тред-иллюстрация фразы "использовать не то не для того". Элементарная задача же. Вот с этого места по подробнее =) Как сделать элементарно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 20 февраля, 2015 · Жалоба я тоже хочу услышать элементарное решение задачи гарантированной доставки малтикаста через интернет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 21 февраля, 2015 · Жалоба Прекрасный тред-иллюстрация фразы "использовать не то не для того". Элементарная задача же. Вот с этого места по подробнее =) Как сделать элементарно? ну какой-нибудь vtun/openvpn или любой другой, позволяющий сделать l2 поверх tcp. можно забрать потоки и сделать из них нечто вроде псевдо-hls. впрочем, я делал на gstreamer вариант, когда на одной стороне трафик разбирался где-то до уровня udp payload и инкапсулировался в gdp. на принимающей стороне все это обратно разворачивалось в мультикаст. у людей спокойно передавало ~ 120 каналов через всю евразию по интернетам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kisa Опубликовано 21 февраля, 2015 · Жалоба Прекрасный тред-иллюстрация фразы "использовать не то не для того". Элементарная задача же. Вот с этого места по подробнее =) Как сделать элементарно? ну какой-нибудь vtun/openvpn или любой другой, позволяющий сделать l2 поверх tcp. можно забрать потоки и сделать из них нечто вроде псевдо-hls. впрочем, я делал на gstreamer вариант, когда на одной стороне трафик разбирался где-то до уровня udp payload и инкапсулировался в gdp. на принимающей стороне все это обратно разворачивалось в мультикаст. у людей спокойно передавало ~ 120 каналов через всю евразию по интернетам. так именно это я и посоветовал - L2 тоннель через tcp и в качестве примера реально работающего решения привел как раз openvpn вопрос в том, а есть ли такое решение для cisco? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
garycat Опубликовано 22 февраля, 2015 · Жалоба В данном случае обойтись без дополнительного преобразования скорее всего не получится. Есть как минимум два проверенных временем варианта: 1. как предлагает ^rage^ использовать gstreamer (можно найти топик на наге с рецептом) 2. Преобразовать сигнал в HLS передать на другой конец планеты, и там сделать обратное преобразование Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Enigma33 Опубликовано 24 февраля, 2015 (изменено) · Жалоба Извините, но я так и не понял как реализовать сабж на оборудовании Cisco. Вообще, я так понял самое надежное и гибкое решение MBGP + MSDN. Может у кого есть опыт с настройкой такой схемы, и мог бы предложить примеры конфигураций для данной задачи? Неужели никто из формумчан не поднимал такую схему? Также вопрос, если провайдер, от которого планируется брать мультикаст, забирает сам по IGMP, не является ли это препятствием серьезным для дальнейшей трансляции? Изменено 24 февраля, 2015 пользователем Enigma33 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Enigma33 Опубликовано 24 февраля, 2015 (изменено) · Жалоба нужно два тазика с openvpn прямое попадание в _яндексе_ Не думаю что мне нужно 2 автомобиля для этого. Думаю речь о чем-то другом) Изменено 24 февраля, 2015 пользователем Enigma33 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Enigma33 Опубликовано 24 февраля, 2015 (изменено) · Жалоба Вот схема для подобной задачи. Из 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 Изменено 24 февраля, 2015 пользователем Enigma33 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 24 февраля, 2015 · Жалоба как именно определить интерфейс до источника? Я так понимаю, ни вы, ни второй оператор, не имеете ни познаний в теории, ни какой-либо практики по развертыванию услуг 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). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...