wtyd Posted May 17, 2016 Есть источник мультикаста, который постоянно гонит все свои каналы в мультикаст роутер (cisco 6500), на МР есть PIM и всё работает. Можно ли как-то сделать, чтобы не постоянно гнать все потоки в МР, а по запросу ? Если гнать постоянно, что МР всегда знает, где брать поток -- sh ip mroute <group address> показывает адрес сорса правильно. Если не гнать поток, то через три минуты МР перестаёт знать маршрут и не вещает ничего. Можно ли как-то сделать, чтобы работала подписка со стороны МР на только нужные группы в источнику каналов ? Между источником и МР есть несколько свичей, которые mvr умеют. Типа если сдлеать подписку, то должна такая схема работать. Можно конечно все потоки всегда стримить в ядро сети, но хочется как-то по-умнее сделать. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted May 17, 2016 Раздавай юникастом, софт в подписи. Или читай про IGMP Snooping. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tehmeh Posted May 17, 2016 Между источником и МР есть несколько свичей, которые mvr умеют. Типа если сдлеать подписку, то должна такая схема работать. Можно конечно все потоки всегда стримить в ядро сети, но хочется как-то по-умнее сделать. А где вы подписку собираетесь делать? Типа igmp join-group в ядре на интерфейсе в сторону сегмента с коммутаторами, а те начнут пропускать поток до ядра, и он там зарегистрируется? Лучше делать всё L3, пусть потоки валят на FHR, а тот регистрирует их в ядре на RP, так хотя бы будет способ сказать "постой", если потоки не нужны. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
wtyd Posted May 18, 2016 Между источником и МР есть несколько свичей, которые mvr умеют. Типа если сдлеать подписку, то должна такая схема работать. Можно конечно все потоки всегда стримить в ядро сети, но хочется как-то по-умнее сделать. А где вы подписку собираетесь делать? Типа igmp join-group в ядре на интерфейсе в сторону сегмента с коммутаторами, а те начнут пропускать поток до ядра, и он там зарегистрируется? Лучше делать всё L3, пусть потоки валят на FHR, а тот регистрирует их в ядре на RP, так хотя бы будет способ сказать "постой", если потоки не нужны. Ну вот проблема как раз в том, что между источником (сервер на линуксе, который сам с себя берёт rtsp и ffmpeg'ом гонит в мультики) есть несколько свичей, в которых есть клиенты этих потоков. Обычно эти потоки вообще никто не смотрит, но вероятнее всего их будут смотреть эти самые клиенты, менее вероятно их будут смотреть клиенты за Мультикст Роутером. Поэтому хочется сделать красиво: если нет подписчиков на группу, то и не слать её вообще, если появился подписчик в промежуточном свиче, то слать эту группу туда, если появился подписчик за МР, то слать группу в МР. Я не знаю как более правильно объяснить :-). Может быть надо источник мультиков сделать тоже Мультикаст Роутером ? Типа поднять на нём pimd, как-то настроить ... я не понимаю, как это сдлеать и как тогда igmp snooping будет работать или не будет ? Разве МР будет слать igmp-join если кто-то за МР захочет смотреть группу ? По-моему, он пришлёт какое-то pim-сообщение и всё, а свичи между линуксом и МР только igmp умеют и не пропустят поток. Везде на схемах нарисовано примерно так: [MCast sourse]==[MCast Router]==[switch1]==[switch2]... а к свичам подключены клиенты. Нигде нет, чтобы клиенты могли быть где-то межу источником и МР. Наверное я хочу неправильного :-). правильно наверное будет подключить РС непосредственно в МР, собирать в него юникастом потоки по rtsp и фигачить мультики прямо в МР, так ? Просто в этом случае юникаст потоки будут постоянно выжирать полосу, а главное самые вероятные смотрельщики этих потоков будут далеко от имточника мультиков -- красиво не получается сдлеать. Как быть-то ? :-) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tehmeh Posted May 18, 2016 [MCast sourse]==[MCast Router]==[switch1]==[switch2]... а к свичам подключены клиенты. Нигде нет, чтобы клиенты могли быть где-то межу источником и МР. Наверное я хочу неправильного :-). Нигде нет, потому что хотите неправильного. Разруливать мультикаст на L2 та ещё задача, сейчас как раз абсолютно такую же схему перевожу на L3. Просто в этом случае юникаст потоки будут постоянно выжирать полосу, а главное самые вероятные смотрельщики этих потоков будут далеко от имточника мультиков -- красиво не получается сдлеать. Как быть-то ? :-) Я так понимаю, юникаст и мультикаст у вас разнонаправленные, соответственно, полоса должна не общая заниматься, а ingress/egress? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
wtyd Posted May 18, 2016 (edited) [MCast sourse]==[MCast Router]==[switch1]==[switch2]... а к свичам подключены клиенты. Нигде нет, чтобы клиенты могли быть где-то межу источником и МР. Наверное я хочу неправильного :-). Нигде нет, потому что хотите неправильного. Разруливать мультикаст на L2 та ещё задача, сейчас как раз абсолютно такую же схему перевожу на L3. Просто в этом случае юникаст потоки будут постоянно выжирать полосу, а главное самые вероятные смотрельщики этих потоков будут далеко от имточника мультиков -- красиво не получается сдлеать. Как быть-то ? :-) Я так понимаю, юникаст и мультикаст у вас разнонаправленные, соответственно, полоса должна не общая заниматься, а ingress/egress? Да, но зачем её постоянно занимать, если бОльшую часть времени эти камеры никто не смотрит ? Уже переделали. Воткнули в DES-3028, у него мультикаст более правильно работает, чем в DES-3526 было. Гоним всё в отдельном влане в шеститонник, он уже разливает по требованию (pim'ом в другие роутеры, в mvr vlan по igmp запросу). Т.е. получается, что в ядро льём постоянно, а когда смотрим, то оно нам обратно по тем же каналам связи летит в мультике :-). Полоса позволяет, но здравый смысл - нет :-). Edited May 18, 2016 by wtyd Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tehmeh Posted May 18, 2016 Ну если это действительно причиняет духовную, а может и физическую боль, то можно убить МР и l3-routing мультикаста. Заливать с сервера трафик мультикастом на коммутаторы с igmp snooping, а на сервере дополнительно, как тут советовали, поднять какой-нибудь стриминг в unicast, в тот же hls, например. У вас же за МР мало подписчиков, юникаста много не будет по-идее. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
wtyd Posted May 18, 2016 (edited) Ну если это действительно причиняет духовную, а может и физическую боль, то можно убить МР и l3-routing мультикаста. Заливать с сервера трафик мультикастом на коммутаторы с igmp snooping, а на сервере дополнительно, как тут советовали, поднять какой-нибудь стриминг в unicast, в тот же hls, например. У вас же за МР мало подписчиков, юникаста много не будет по-идее. А нельзя, надо именно мультиком доставлять контент -- так же понтов больше :-). Да всё уже, решили литьём через центр :-). Здравый смысл отдыхает, а вместе с ним, как вы выразились, духовная боль :-) Edited May 18, 2016 by wtyd Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...