Перейти к содержимому
Калькуляторы

Multicast via VPN

Как будет себя чувствовать multicast IPTV в тунеле VPN? Нет возможности подключиться напрямую к поставщику контента, есть 1Г линк до городской точки обмена через госмонополию). Возможна ли вобще такая схема, и если да то повлияет ли это на качество картинки(артефакты, рассыпание картинки)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как будет себя чувствовать multicast IPTV в тунеле VPN? Нет возможности подключиться напрямую к поставщику контента, есть 1Г линк до городской точки обмена через госмонополию). Возможна ли вобще такая схема, и если да то повлияет ли это на качество картинки(артефакты, рассыпание картинки)?

 

Через eoip микротиковский вполне себя хорошо чувствует. Большой траф только не гнал, так - мегабит 50-60.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нормальная схема. Обычно L3MTU мультикаст трафика поменьше 1500(видимо это так принято как раз чтоб гонять через тунели). Очень желательно чтоб тунель был udp-шный. Если потерь и реордера не будет, то и сыпаться не будет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

188 байтов ts frame, их 7 штук обычно - 1316 байт это сами данные. Плюс заголовки протокола и инкапсуляция.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

л2 впн или л2 туннелирование на фре нетграфом. Последнее проверял, работает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos.

 

Если говорить про тунели over ip, то gre это не всегда софт решение. На многом оборудовании оно работает аппаратно(потому что это тривальное навешивание хедера)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos.

TCP.

На том же нетграфе можно tcp использовать в кач транспорта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вопрос не только в инкапсуляции, но и в отсутствии qos в публичном интернете. Мало кто слепо доверяет чужим dscp.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos.

TCP.

На том же нетграфе можно tcp использовать в кач транспорта.

вариант с tcp возможен в случае буферизации и retransmitt потерянных пакетов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos.

TCP.

На том же нетграфе можно tcp использовать в кач транспорта.

вариант с tcp возможен в случае буферизации и retransmitt потерянных пакетов.

 

Если канал интернета не ограничен, можно передавать одновременно 2 или даже 3 потока по разным туннелям, а потом сливать в один.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вопрос не только в инкапсуляции, но и в отсутствии qos в публичном интернете. Мало кто слепо доверяет чужим dscp.

 

Ну если труба свободная, то проблем быть не должно. По этому каналу предпологается гнать только мкаст.

Принимать его будет freeBSD на виртуалке ESXi IBM x3650.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos.

TCP.

На том же нетграфе можно tcp использовать в кач транспорта.

вариант с tcp возможен в случае буферизации и retransmitt потерянных пакетов.

 

Если канал интернета не ограничен, можно передавать одновременно 2 или даже 3 потока по разным туннелям, а потом сливать в один.

 

Идея вполне очевидная. Но какой софт/оборудование умеет это делать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Идея вполне очевидная. Но какой софт/оборудование умеет это делать?

 

Mikrotik, у него в бондинге есть режим, когда он поступающие данные передает по всем подключенным портам. Ставите с каждой стороны по железке, которая будет заниматься распределением, и 2-3 помельче для создания EoIP туннелей и готово. С другой стороны так же. Суть кучи железок в том, что бы на каждой можно было сделать линк со своего IP, или по своим каналам.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Если канал интернета не ограничен, можно передавать одновременно 2 или даже 3 потока по разным туннелям, а потом сливать в один.

 

Идея вполне очевидная. Но какой софт/оборудование умеет это делать?

 

FreeBSD + netgraph + bridge. Вот есть статья

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

попробуйте VLC с буферизацией 5-10 секунд и передачей по http.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Через eoip микротиковский вполне себя хорошо чувствует. Большой траф только не гнал, так - мегабит 50-60.

+1, работает

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

поднял pptp туннель mikrotik-cisco через инет - вполне себе достойное качество картинки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.