white_crow Опубликовано 29 июня, 2012 (изменено) · Жалоба Доброго времени суток. Есть собственная инфраструктура для "генерации" мультика с неба : ) (Антенный пост, "вещалка" (Teleste Luminato), CAS (XCrypt) договоры с правообладателями и прочие "карточные игры и ночные бабочки". Есть филиалы в соседних городах. Не хочется вкладывать кучу бабла в "Головную станцию" и прочую инфраструктуру в каждом городе (а сети там есть наши). Хочу свой весь мультик загнать в соседние городишки. Но вроде как нету возможности L2 - только L3 через пиринг. Как известно - мультик не маршрутизируется через глобальные сети. Так вот что думаю - может тупо в центральной ГС с помощью DNAT заменить мультикаст адреса, на юникаст (линагз + iptables ) - и направить на филиалы, а там обратную операцию совершить? Прокатит? около 200 метров трафика (pps ща не посмотрю...), но там ведь тока заголовки пакетов менять - в payload пакетов не нужно вмешиваться. По идее не особо навороченный серверочек должен справится без проблем? Остается вопрос с задержками, надежностью и прочим джиттером - при передаче этого контента через "региональный пиринг" (в масштабах области) ... Что думаете, господа, по этому поводу? Или какие еще есть нюансы, варианты? Или тунели какие-нить проприетарные городить, которые мультик инкапсулируют, и затем отроутить в эти тунели мультик до филиалов? Изменено 29 июня, 2012 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 29 июня, 2012 · Жалоба А не проще ли сбриджевать двумя линуксами (через что-нить типа openvpn), отфильтровать, чтоб шло только нужное? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 29 июня, 2012 (изменено) · Жалоба Ну, как вариант. Я же так и написал в первом посте "тунели какие-нить ...городить, которые мультик инкапсулируют..." Как раз и спрашиваю - у кого есть реальный опыт - как оптимальней сделать. Неужели никто такую задачу не решал? наверняка от "агрегаторов" кто-нить получает мультикаст трафик, и не всегда же есть возможность сконектиться по L2VPN или тем более "чистый" L2 замутить. И что думаете все таки по поводу DNAT ? Все таки инкапсулировать в любой из впн - это больше операций, чем заменять адрес в заголовках пакетов... И NetFilter - в ядре, а openVPN - это юзерспейс? (и может там нельзя без шифрования трафика?) P.S. надо буит проверить - дойдет мультикаст пакет до DNAT, или на этапе роутинга уже откинеться... или там нужно мутить еще модуль mroute (multicast routing) ? Изменено 29 июня, 2012 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 29 июня, 2012 (изменено) · Жалоба Неужели никто такую задачу не решал? поставьте железку мультеплексор из платформы iplex от тандберга или RGB BNP3 и гоните мультикаст в юникастовый поток. Изменено 29 июня, 2012 пользователем XeonVs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 29 июня, 2012 (изменено) · Жалоба Спасибо, совсем забыл про аппаратные решения : ) Как вариант - будем рассматривать. (хотя стоимость таких железок + аренда каналов - получается, что нет смысла, и можно просто ставить на филиалы давно привычные железки Teleste Luminato и с неба в мультик гнать и все дела (данная штука отличается от приведенных примеров меньшим к-вом модулей и фишек (как раз нет переколбаса в юникаст) ) ) По "софт-решениям" в академическом смысле хотелось бы тоже для сравнения услышать мнения. Изменено 29 июня, 2012 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 29 июня, 2012 · Жалоба Если не юзерспейс хочется - в последних ядрах Linux есть l2tpv3 pseudowire + ethernet over gre Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 29 июня, 2012 (изменено) · Жалоба Варианта без специализированных железок видится два: 1. Linux/vtun (TAP-интерфейсы прекрасно гоняют мультикаст, проверено). Дешево и сердито. 2. Cisco L2TPv3-туннель на двух ~29xx роутерах. Дорого, L2 гоняется, с мультикастом не проверял, но по идее там практически чистый L2, должно пробегать. Если не городить L2-туннели - можно взять те же 19xx/29xx, накромсать на них L3Tunnel-интерфейсы, и зароутить через них multicast. В общем, способы есть. Изменено 29 июня, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 29 июня, 2012 · Жалоба понял, думаю для начала попробовать L2 тунели на линагзе... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 29 июня, 2012 · Жалоба На микротике можно создать туннель SSTP и через EoIP гонять по нему мультикаст. SSTP отрабатывает потери данных и подает пакеты в том виде, в котором они идут через канал. Буфер пакетов на Ethernet интерфейсах нужно поставить по 2000-5000 пакетов. Только что бы передать порядка 200мбит нужно использовать x86, роутерборды не потянут, даже RB1100AHx2. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 29 июня, 2012 (изменено) · Жалоба я слышал, что в принципе даже на мощной машинке EoIP проприетарный тунель "сильно напрягается" на относительно средних объемах трафа. Точные цифры и пруф не скажу. Может это и миф или юзеры не так его готовили. хотя кто мне мешает попробовать...все NASы на микротиках и крутяться (iСore7 + кошерные сетевые чипы = полет нормальный : ) Изменено 29 июня, 2012 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 29 июня, 2012 (изменено) · Жалоба но мне все не дает покоя вроде бы теоретически простое решение - подменить в заголовках пакетов мультикаст адреса на белые юникаст - отроутить куда надо через пиринг и на другой стороне обратное преобразование сделать (для начало тупо с помощью DNAT в iptables. Опять же, кто, как говориться мне мешает попробовать... просто, блин, интересно... Изменено 29 июня, 2012 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 29 июня, 2012 · Жалоба EoIP не особо требовательный. А вот передача данных через SSTP потребляет очень много ресурсов. Например RB751U может прокачать всего около 15мбит через такой туннель. Далее загрузка процессора 100 процентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 29 июня, 2012 · Жалоба ну так SSTP шифрует поток, а EoIP прото gre туннель. Никаких нагрузок EoIP не создает (на х86), гоняет мультикаст без проблем. Нагрузка может быть если фаерволом NCPMSS делать, но в случае мультикаста это не нужно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 30 июня, 2012 · Жалоба По-хорошему, нужно у магистралов VPN заказывать с объявленным QoS. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 30 июня, 2012 · Жалоба а еще лучше, чтобы магистрал предоставил L2VPN. И все, конечно, выльется не только в технические возможности, но и в ценник... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 30 июня, 2012 · Жалоба Как связан VPN с multicast-ом? Если L2 VPN - тогда да, пофиг. Но если L3 - не факт, что пропустят. Базовое решение от Cisco - GRE туннель через провайдера и по GRE - мультикаст. Думаю, для Linux тоже будет работать. Тащить именно эзернет туннель, если есть мультикаст роутинг, смыла не вижу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 30 июня, 2012 · Жалоба Для IPTV приемлемым процентом потерь пакетов можно считать 0.0004167% (оди пакет из 240000). Попробуйте оценть процент потерь через L3 Public Network. Для Юникса простейший тест: # ping -c 240000 -i 0.011 -s 1324 -q 127.0.0.1 где 127.0.0.1 - адрес удалённого хоста, на котором ограничение для ICMP пакетов не менее 100 пакетов в секунду. Если ограничение менее, то можно увеличить интервал отправки опцией -i. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 30 июня, 2012 · Жалоба Если VPN будет L3, то туннели умеет делать mrouted. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 30 июня, 2012 · Жалоба Как связан VPN с multicast-ом? Если L2 VPN - тогда да, пофиг. Но если L3 - не факт, что пропустят. Базовое решение от Cisco - GRE туннель через провайдера и по GRE - мультикаст. Думаю, для Linux тоже будет работать. Тащить именно эзернет туннель, если есть мультикаст роутинг, смыла не вижу. Как связан впн с мультикастом? Вроде разжевали выше... Если стык филиалов по L2 - то все ок - мультик можно живьем гнать. А если чисто L3 - то конечно - мультик никто мой роутить живьем не будет - нужно инкапсулировать его в какой-нить тунель. Очевидно. Вариантов тунелей много - нужно пробовать. Если VPN будет L3, то туннели умеет делать mrouted. вот еще одна идея, спасибо, не знал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 30 июня, 2012 · Жалоба Для IPTV приемлемым процентом потерь пакетов можно считать 0.0004167% (оди пакет из 240000). Попробуйте оценть процент потерь через L3 Public Network. Для Юникса простейший тест: # ping -c 240000 -i 0.011 -s 1324 -q 127.0.0.1 где 127.0.0.1 - адрес удалённого хоста, на котором ограничение для ICMP пакетов не менее 100 пакетов в секунду. Если ограничение менее, то можно увеличить интервал отправки опцией -i. Вот поэтому и надо гнать в туннеле с гарантированной доставкой - тогда потерь не будет вообще. При обработке потерь на канале будет увеличиваться задержка и джиттер, но это не критично, ведь у приемных устройств есть входной буфер и конечный пользователь ничего не заметит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 30 июня, 2012 · Жалоба Для IPTV приемлемым процентом потерь пакетов можно считать 0.0004167% (оди пакет из 240000). Попробуйте оценть процент потерь через L3 Public Network. Для Юникса простейший тест: # ping -c 240000 -i 0.011 -s 1324 -q 127.0.0.1 где 127.0.0.1 - адрес удалённого хоста, на котором ограничение для ICMP пакетов не менее 100 пакетов в секунду. Если ограничение менее, то можно увеличить интервал отправки опцией -i. Да, это ясно, что TVoIP чувствителен к задержкам и потерям. Спасибо за конкретные цифры. Как только будет реальный стык с филиалами -конечно проверим. Возможно - вся затея окажется провальной : ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bel Опубликовано 30 июня, 2012 · Жалоба Как связан впн с мультикастом? Вроде разжевали выше... Прежде чем "городить огород" с L3 Public Network (L3PN), нужно убедиться что L3PN обеспечивает приемлемый для конечной услуги (IPTV) уровень качества (особенно это касается процента потерь пакетов в часы наибольшей нагрузки). Приемлемым уровнем потерь можно считать 1 пакет из 240000 (это приблизительно соответствует одному рассыпанию картинки за 10 минут). Вообще говоря, доставлять трафик через L3PN - это очень плохая идея. Особенно если магистралы используют трафик инженеринг. VPN нужен не простой, а с объявленным уровнем качества. И качество должно быть лучше чем "Best Effort". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
white_crow Опубликовано 30 июня, 2012 (изменено) · Жалоба да мне это ясно с самого начала. Мне нужно "совету директоров" показать и доказать - ибо не верят : ) что это плохая затея. Даже если будет техническая возможность организовать каналы с нужной пропускной способностью, и при этом с четко оговоренными тех.параметрами и QoS - стоит это будет (причем пожизненно каждый месяц) >> чем профит от "100 человек", которые подключаться в маленьких городишках к этому быдлоТВ... И месную собсвенную инфраструкутур тоже с нуля строить - дорого ради ста человек. Цунгцванг? Но "нужно же развиваиься, а не стоять на месте - ибо стоять на месте, значит идти назад, деградировать" : )))) Изменено 30 июня, 2012 пользователем white_crow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 30 июня, 2012 · Жалоба Прежде чем "городить огород" с L3 Public Network (L3PN), нужно убедиться что L3PN обеспечивает приемлемый для конечной услуги (IPTV) уровень качества (особенно это касается процента потерь пакетов в часы наибольшей нагрузки). Приемлемым уровнем потерь можно считать 1 пакет из 240000 (это приблизительно соответствует одному рассыпанию картинки за 10 минут). берём vtund, в кач-ве транспорта выбираем tcp. на удалённом конце добавляем tap-интерфейс в бридж. благо, linux bridge умеет igmp snooping. потери отработает tcp, а задержку компенсирует буфер на клиенте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 1 июля, 2012 · Жалоба ^rage^ +1 - именно так и работает. Для телефонии плохо пригодно из-за задержек, для IPTV - более чем достаточно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...