Jump to content
Калькуляторы

Вопрос про мультикаст стример Как парвильно сделать ?

Есть источник мультикаста, который постоянно гонит все свои каналы в мультикаст роутер (cisco 6500), на МР есть PIM и всё работает. Можно ли как-то сделать, чтобы не постоянно гнать все потоки в МР, а по запросу ?

 

Если гнать постоянно, что МР всегда знает, где брать поток -- sh ip mroute <group address> показывает адрес сорса правильно. Если не гнать поток, то через три минуты МР перестаёт знать маршрут и не вещает ничего. Можно ли как-то сделать, чтобы работала подписка со стороны МР на только нужные группы в источнику каналов ?

 

Между источником и МР есть несколько свичей, которые mvr умеют. Типа если сдлеать подписку, то должна такая схема работать. Можно конечно все потоки всегда стримить в ядро сети, но хочется как-то по-умнее сделать.

Share this post


Link to post
Share on other sites

Между источником и МР есть несколько свичей, которые mvr умеют. Типа если сдлеать подписку, то должна такая схема работать. Можно конечно все потоки всегда стримить в ядро сети, но хочется как-то по-умнее сделать.

А где вы подписку собираетесь делать? Типа igmp join-group в ядре на интерфейсе в сторону сегмента с коммутаторами, а те начнут пропускать поток до ядра, и он там зарегистрируется?

 

Лучше делать всё L3, пусть потоки валят на FHR, а тот регистрирует их в ядре на RP, так хотя бы будет способ сказать "постой", если потоки не нужны.

Share this post


Link to post
Share on other sites

Между источником и МР есть несколько свичей, которые mvr умеют. Типа если сдлеать подписку, то должна такая схема работать. Можно конечно все потоки всегда стримить в ядро сети, но хочется как-то по-умнее сделать.

А где вы подписку собираетесь делать? Типа igmp join-group в ядре на интерфейсе в сторону сегмента с коммутаторами, а те начнут пропускать поток до ядра, и он там зарегистрируется?

 

Лучше делать всё L3, пусть потоки валят на FHR, а тот регистрирует их в ядре на RP, так хотя бы будет способ сказать "постой", если потоки не нужны.

 

Ну вот проблема как раз в том, что между источником (сервер на линуксе, который сам с себя берёт rtsp и ffmpeg'ом гонит в мультики) есть несколько свичей, в которых есть клиенты этих потоков. Обычно эти потоки вообще никто не смотрит, но вероятнее всего их будут смотреть эти самые клиенты, менее вероятно их будут смотреть клиенты за Мультикст Роутером. Поэтому хочется сделать красиво: если нет подписчиков на группу, то и не слать её вообще, если появился подписчик в промежуточном свиче, то слать эту группу туда, если появился подписчик за МР, то слать группу в МР. Я не знаю как более правильно объяснить :-).

 

Может быть надо источник мультиков сделать тоже Мультикаст Роутером ? Типа поднять на нём pimd, как-то настроить ... я не понимаю, как это сдлеать и как тогда igmp snooping будет работать или не будет ? Разве МР будет слать igmp-join если кто-то за МР захочет смотреть группу ? По-моему, он пришлёт какое-то pim-сообщение и всё, а свичи между линуксом и МР только igmp умеют и не пропустят поток.

 

Везде на схемах нарисовано примерно так:

 

[MCast sourse]==[MCast Router]==[switch1]==[switch2]... а к свичам подключены клиенты. Нигде нет, чтобы клиенты могли быть где-то межу источником и МР. Наверное я хочу неправильного :-). правильно наверное будет подключить РС непосредственно в МР, собирать в него юникастом потоки по rtsp и фигачить мультики прямо в МР, так ?

 

Просто в этом случае юникаст потоки будут постоянно выжирать полосу, а главное самые вероятные смотрельщики этих потоков будут далеко от имточника мультиков -- красиво не получается сдлеать. Как быть-то ? :-)

Share this post


Link to post
Share on other sites

 

[MCast sourse]==[MCast Router]==[switch1]==[switch2]... а к свичам подключены клиенты. Нигде нет, чтобы клиенты могли быть где-то межу источником и МР. Наверное я хочу неправильного :-).

Нигде нет, потому что хотите неправильного. Разруливать мультикаст на L2 та ещё задача, сейчас как раз абсолютно такую же схему перевожу на L3.

 

Просто в этом случае юникаст потоки будут постоянно выжирать полосу, а главное самые вероятные смотрельщики этих потоков будут далеко от имточника мультиков -- красиво не получается сдлеать. Как быть-то ? :-)

Я так понимаю, юникаст и мультикаст у вас разнонаправленные, соответственно, полоса должна не общая заниматься, а ingress/egress?

Share this post


Link to post
Share on other sites

 

[MCast sourse]==[MCast Router]==[switch1]==[switch2]... а к свичам подключены клиенты. Нигде нет, чтобы клиенты могли быть где-то межу источником и МР. Наверное я хочу неправильного :-).

Нигде нет, потому что хотите неправильного. Разруливать мультикаст на L2 та ещё задача, сейчас как раз абсолютно такую же схему перевожу на L3.

 

Просто в этом случае юникаст потоки будут постоянно выжирать полосу, а главное самые вероятные смотрельщики этих потоков будут далеко от имточника мультиков -- красиво не получается сдлеать. Как быть-то ? :-)

Я так понимаю, юникаст и мультикаст у вас разнонаправленные, соответственно, полоса должна не общая заниматься, а ingress/egress?

 

Да, но зачем её постоянно занимать, если бОльшую часть времени эти камеры никто не смотрит ?

Уже переделали. Воткнули в DES-3028, у него мультикаст более правильно работает, чем в DES-3526 было. Гоним всё в отдельном влане в шеститонник, он уже разливает по требованию (pim'ом в другие роутеры, в mvr vlan по igmp запросу). Т.е. получается, что в ядро льём постоянно, а когда смотрим, то оно нам обратно по тем же каналам связи летит в мультике :-). Полоса позволяет, но здравый смысл - нет :-).

Edited by wtyd

Share this post


Link to post
Share on other sites

Ну если это действительно причиняет духовную, а может и физическую боль, то можно убить МР и l3-routing мультикаста. Заливать с сервера трафик мультикастом на коммутаторы с igmp snooping, а на сервере дополнительно, как тут советовали, поднять какой-нибудь стриминг в unicast, в тот же hls, например. У вас же за МР мало подписчиков, юникаста много не будет по-идее.

Share this post


Link to post
Share on other sites

Ну если это действительно причиняет духовную, а может и физическую боль, то можно убить МР и l3-routing мультикаста. Заливать с сервера трафик мультикастом на коммутаторы с igmp snooping, а на сервере дополнительно, как тут советовали, поднять какой-нибудь стриминг в unicast, в тот же hls, например. У вас же за МР мало подписчиков, юникаста много не будет по-идее.

 

А нельзя, надо именно мультиком доставлять контент -- так же понтов больше :-). Да всё уже, решили литьём через центр :-). Здравый смысл отдыхает, а вместе с ним, как вы выразились, духовная боль :-)

Edited by wtyd

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.