Mistakila Опубликовано 20 марта, 2014 · Жалоба Как будет себя чувствовать multicast IPTV в тунеле VPN? Нет возможности подключиться напрямую к поставщику контента, есть 1Г линк до городской точки обмена через госмонополию). Возможна ли вобще такая схема, и если да то повлияет ли это на качество картинки(артефакты, рассыпание картинки)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 20 марта, 2014 · Жалоба Как будет себя чувствовать multicast IPTV в тунеле VPN? Нет возможности подключиться напрямую к поставщику контента, есть 1Г линк до городской точки обмена через госмонополию). Возможна ли вобще такая схема, и если да то повлияет ли это на качество картинки(артефакты, рассыпание картинки)? Через eoip микротиковский вполне себя хорошо чувствует. Большой траф только не гнал, так - мегабит 50-60. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 20 марта, 2014 · Жалоба Нормальная схема. Обычно L3MTU мультикаст трафика поменьше 1500(видимо это так принято как раз чтоб гонять через тунели). Очень желательно чтоб тунель был udp-шный. Если потерь и реордера не будет, то и сыпаться не будет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mistakila Опубликовано 20 марта, 2014 · Жалоба Поздравляю, 3333 сообщений) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 20 марта, 2014 · Жалоба 188 байтов ts frame, их 7 штук обычно - 1316 байт это сами данные. Плюс заголовки протокола и инкапсуляция. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 марта, 2014 · Жалоба л2 впн или л2 туннелирование на фре нетграфом. Последнее проверял, работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 22 марта, 2014 · Жалоба Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 марта, 2014 · Жалоба Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos. Если говорить про тунели over ip, то gre это не всегда софт решение. На многом оборудовании оно работает аппаратно(потому что это тривальное навешивание хедера) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 марта, 2014 · Жалоба Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos. TCP. На том же нетграфе можно tcp использовать в кач транспорта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 23 марта, 2014 · Жалоба Вопрос не только в инкапсуляции, но и в отсутствии qos в публичном интернете. Мало кто слепо доверяет чужим dscp. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 23 марта, 2014 · Жалоба Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos. TCP. На том же нетграфе можно tcp использовать в кач транспорта. вариант с tcp возможен в случае буферизации и retransmitt потерянных пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 23 марта, 2014 · Жалоба Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos. TCP. На том же нетграфе можно tcp использовать в кач транспорта. вариант с tcp возможен в случае буферизации и retransmitt потерянных пакетов. Если канал интернета не ограничен, можно передавать одновременно 2 или даже 3 потока по разным туннелям, а потом сливать в один. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mistakila Опубликовано 24 марта, 2014 · Жалоба Вопрос не только в инкапсуляции, но и в отсутствии qos в публичном интернете. Мало кто слепо доверяет чужим dscp. Ну если труба свободная, то проблем быть не должно. По этому каналу предпологается гнать только мкаст. Принимать его будет freeBSD на виртуалке ESXi IBM x3650. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 24 марта, 2014 · Жалоба Используя софт решения не будет гарантий отсутствия дронов. А multicast очень чувствителен к ним... Только vlan с прописаны qos. TCP. На том же нетграфе можно tcp использовать в кач транспорта. вариант с tcp возможен в случае буферизации и retransmitt потерянных пакетов. Если канал интернета не ограничен, можно передавать одновременно 2 или даже 3 потока по разным туннелям, а потом сливать в один. Идея вполне очевидная. Но какой софт/оборудование умеет это делать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 24 марта, 2014 · Жалоба Идея вполне очевидная. Но какой софт/оборудование умеет это делать? Mikrotik, у него в бондинге есть режим, когда он поступающие данные передает по всем подключенным портам. Ставите с каждой стороны по железке, которая будет заниматься распределением, и 2-3 помельче для создания EoIP туннелей и готово. С другой стороны так же. Суть кучи железок в том, что бы на каждой можно было сделать линк со своего IP, или по своим каналам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 24 марта, 2014 · Жалоба Если канал интернета не ограничен, можно передавать одновременно 2 или даже 3 потока по разным туннелям, а потом сливать в один. Идея вполне очевидная. Но какой софт/оборудование умеет это делать? FreeBSD + netgraph + bridge. Вот есть статья Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 25 марта, 2014 · Жалоба попробуйте VLC с буферизацией 5-10 секунд и передачей по http. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilili Опубликовано 25 марта, 2014 · Жалоба Через eoip микротиковский вполне себя хорошо чувствует. Большой траф только не гнал, так - мегабит 50-60. +1, работает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shvlad1 Опубликовано 25 марта, 2014 · Жалоба поднял pptp туннель mikrotik-cisco через инет - вполне себе достойное качество картинки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...