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

Насыпать свой мультикаст в свои филиалы через L3 Public Network

Доброго времени суток.

Есть собственная инфраструктура для "генерации" мультика с неба : )

(Антенный пост, "вещалка" (Teleste Luminato), CAS (XCrypt) договоры с правообладателями и прочие "карточные игры и ночные бабочки".

Есть филиалы в соседних городах.

Не хочется вкладывать кучу бабла в "Головную станцию" и прочую инфраструктуру в каждом городе (а сети там есть наши).

Хочу свой весь мультик загнать в соседние городишки.

Но вроде как нету возможности L2 - только L3 через пиринг.

Как известно - мультик не маршрутизируется через глобальные сети.

 

Так вот что думаю - может тупо в центральной ГС с помощью DNAT заменить мультикаст адреса, на юникаст (линагз + iptables ) - и направить на филиалы, а там обратную операцию совершить?

Прокатит? около 200 метров трафика (pps ща не посмотрю...), но там ведь тока заголовки пакетов менять - в payload пакетов не нужно вмешиваться. По идее не особо навороченный серверочек должен справится без проблем?

 

Остается вопрос с задержками, надежностью и прочим джиттером - при передаче этого контента через "региональный пиринг" (в масштабах области) ...

Что думаете, господа, по этому поводу?

Или какие еще есть нюансы, варианты?

Или тунели какие-нить проприетарные городить, которые мультик инкапсулируют, и затем отроутить в эти тунели мультик до филиалов?

Изменено пользователем white_crow

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


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

А не проще ли сбриджевать двумя линуксами (через что-нить типа openvpn), отфильтровать, чтоб шло только нужное?

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


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

Ну, как вариант. Я же так и написал в первом посте "тунели какие-нить ...городить, которые мультик инкапсулируют..."

 

Как раз и спрашиваю - у кого есть реальный опыт - как оптимальней сделать.

 

Неужели никто такую задачу не решал?

наверняка от "агрегаторов" кто-нить получает мультикаст трафик, и не всегда же есть возможность сконектиться по L2VPN или тем более "чистый" L2 замутить.

 

И что думаете все таки по поводу DNAT ? Все таки инкапсулировать в любой из впн - это больше операций, чем заменять адрес в заголовках пакетов... И NetFilter - в ядре, а openVPN - это юзерспейс? (и может там нельзя без шифрования трафика?)

 

P.S. надо буит проверить - дойдет мультикаст пакет до DNAT, или на этапе роутинга уже откинеться...

или там нужно мутить еще модуль mroute (multicast routing) ?

Изменено пользователем white_crow

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


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

Неужели никто такую задачу не решал?

поставьте железку мультеплексор из платформы iplex от тандберга или RGB BNP3 и гоните мультикаст в юникастовый поток.

Изменено пользователем XeonVs

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


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

Спасибо, совсем забыл про аппаратные решения : )

Как вариант - будем рассматривать.

(хотя стоимость таких железок + аренда каналов - получается, что нет смысла, и можно просто ставить на филиалы давно привычные железки Teleste Luminato и с неба в мультик гнать и все дела (данная штука отличается от приведенных примеров меньшим к-вом модулей и фишек (как раз нет переколбаса в юникаст) ) )

 

По "софт-решениям" в академическом смысле хотелось бы тоже для сравнения услышать мнения.

Изменено пользователем white_crow

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


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

Если не юзерспейс хочется - в последних ядрах Linux есть l2tpv3 pseudowire + ethernet over gre

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


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

Варианта без специализированных железок видится два:

1. Linux/vtun (TAP-интерфейсы прекрасно гоняют мультикаст, проверено). Дешево и сердито.

2. Cisco L2TPv3-туннель на двух ~29xx роутерах. Дорого, L2 гоняется, с мультикастом не проверял, но по идее там практически чистый L2, должно пробегать.

Если не городить L2-туннели - можно взять те же 19xx/29xx, накромсать на них L3Tunnel-интерфейсы, и зароутить через них multicast. В общем, способы есть.

Изменено пользователем Alex/AT

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


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

понял, думаю для начала попробовать L2 тунели на линагзе...

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


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

На микротике можно создать туннель SSTP и через EoIP гонять по нему мультикаст. SSTP отрабатывает потери данных и подает пакеты в том виде, в котором они идут через канал. Буфер пакетов на Ethernet интерфейсах нужно поставить по 2000-5000 пакетов.

 

Только что бы передать порядка 200мбит нужно использовать x86, роутерборды не потянут, даже RB1100AHx2.

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


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

я слышал, что в принципе даже на мощной машинке EoIP проприетарный тунель "сильно напрягается" на относительно средних объемах трафа. Точные цифры и пруф не скажу. Может это и миф или юзеры не так его готовили.

хотя кто мне мешает попробовать...все NASы на микротиках и крутяться (iСore7 + кошерные сетевые чипы = полет нормальный : )

Изменено пользователем white_crow

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


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

но мне все не дает покоя вроде бы теоретически простое решение - подменить в заголовках пакетов мультикаст адреса на белые юникаст - отроутить куда надо через пиринг и на другой стороне обратное преобразование сделать

(для начало тупо с помощью DNAT в iptables.

Опять же, кто, как говориться мне мешает попробовать...

просто, блин, интересно...

Изменено пользователем white_crow

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


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

EoIP не особо требовательный. А вот передача данных через SSTP потребляет очень много ресурсов. Например RB751U может прокачать всего около 15мбит через такой туннель. Далее загрузка процессора 100 процентов.

 

 

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


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

ну так SSTP шифрует поток, а EoIP прото gre туннель. Никаких нагрузок EoIP не создает (на х86), гоняет мультикаст без проблем. Нагрузка может быть если фаерволом NCPMSS делать, но в случае мультикаста это не нужно

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


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

По-хорошему, нужно у магистралов VPN заказывать с объявленным QoS.

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


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

а еще лучше, чтобы магистрал предоставил L2VPN.

И все, конечно, выльется не только в технические возможности, но и в ценник...

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


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

Как связан VPN с multicast-ом? Если L2 VPN - тогда да, пофиг. Но если L3 - не факт, что пропустят.

Базовое решение от Cisco - GRE туннель через провайдера и по GRE - мультикаст. Думаю, для Linux тоже будет работать.

Тащить именно эзернет туннель, если есть мультикаст роутинг, смыла не вижу.

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


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

Для 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.

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


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

Если VPN будет L3, то туннели умеет делать mrouted.

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


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

Как связан VPN с multicast-ом? Если L2 VPN - тогда да, пофиг. Но если L3 - не факт, что пропустят.

Базовое решение от Cisco - GRE туннель через провайдера и по GRE - мультикаст. Думаю, для Linux тоже будет работать.

Тащить именно эзернет туннель, если есть мультикаст роутинг, смыла не вижу.

Как связан впн с мультикастом? Вроде разжевали выше...

Если стык филиалов по L2 - то все ок - мультик можно живьем гнать.

А если чисто L3 - то конечно - мультик никто мой роутить живьем не будет - нужно инкапсулировать его в какой-нить тунель. Очевидно.

Вариантов тунелей много - нужно пробовать.

 

Если VPN будет L3, то туннели умеет делать mrouted.

вот еще одна идея, спасибо, не знал.

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


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

Для 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.

 

Вот поэтому и надо гнать в туннеле с гарантированной доставкой - тогда потерь не будет вообще. При обработке потерь на канале будет увеличиваться задержка и джиттер, но это не критично, ведь у приемных устройств есть входной буфер и конечный пользователь ничего не заметит.

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


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

Для 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 чувствителен к задержкам и потерям. Спасибо за конкретные цифры. Как только будет реальный стык с филиалами -конечно проверим. Возможно - вся затея окажется провальной : )

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


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

Как связан впн с мультикастом? Вроде разжевали выше...

Прежде чем "городить огород" с L3 Public Network (L3PN), нужно убедиться что L3PN обеспечивает приемлемый для конечной услуги (IPTV) уровень качества (особенно это касается процента потерь пакетов в часы наибольшей нагрузки).

Приемлемым уровнем потерь можно считать 1 пакет из 240000 (это приблизительно соответствует одному рассыпанию картинки за 10 минут).

 

Вообще говоря, доставлять трафик через L3PN - это очень плохая идея. Особенно если магистралы используют трафик инженеринг.

 

VPN нужен не простой, а с объявленным уровнем качества. И качество должно быть лучше чем "Best Effort".

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


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

да мне это ясно с самого начала. Мне нужно "совету директоров" показать и доказать - ибо не верят : )

что это плохая затея. Даже если будет техническая возможность организовать каналы с нужной пропускной способностью, и при этом с четко оговоренными тех.параметрами и QoS - стоит это будет (причем пожизненно каждый месяц) >> чем профит от "100 человек", которые подключаться в маленьких городишках к этому быдлоТВ...

И месную собсвенную инфраструкутур тоже с нуля строить - дорого ради ста человек. Цунгцванг?

Но "нужно же развиваиься, а не стоять на месте - ибо стоять на месте, значит идти назад, деградировать" : ))))

Изменено пользователем white_crow

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


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

Прежде чем "городить огород" с L3 Public Network (L3PN), нужно убедиться что L3PN обеспечивает приемлемый для конечной услуги (IPTV) уровень качества (особенно это касается процента потерь пакетов в часы наибольшей нагрузки).

Приемлемым уровнем потерь можно считать 1 пакет из 240000 (это приблизительно соответствует одному рассыпанию картинки за 10 минут).

 

берём vtund, в кач-ве транспорта выбираем tcp. на удалённом конце добавляем tap-интерфейс в бридж. благо, linux bridge умеет igmp snooping. потери отработает tcp, а задержку компенсирует буфер на клиенте.

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


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

^rage^ +1 - именно так и работает. Для телефонии плохо пригодно из-за задержек, для IPTV - более чем достаточно.

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


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

Join the conversation

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

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

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

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

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

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

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