Cisco

индекс
113,41

IPTV: вещание мультикаст трафика в VRF и глобальную таблицу

С радостью для себя обнаружил на Хабре некоторое количество статей на тему весьма мне близкую — IPTV.
Решил внести свой небольшой вклад написанием этой статьи.

Небольшое введение


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

Постановка задачи


Оператор в месте агрегации контента имеет:
1. Серверную ферму предоставления услуги IPTV;
2. Стык фермы с региональной сетью филиала;
3. Стык фермы с МСПД (межрегиональная сеть передачи данных);
4. МСПД от региональной сети на серверной ферме отделена с использованием VRF.
Необходимо на одном из серверов фермы шифровать мультикаст и передавать его в таком виде в МСПД и региональную сеть, не используя никаких дополнительных устройств видеомультиплексирования. Сервер шифрования выступает здесь в качестве стримера, на который наложены определенные ограничения:
1. Один телеканал — одна лицензия, одна мультикастовая группа.
2. Стримить сервер может только с одного интерфейса (один адрес источника мультикаста — это основная проблема).
ОС сервера шифрования — RHEL5.4, сетевое оборудование фермы — Cisco серии 7600.


Решение


Сперва необходимо схематично отобразить, что же мы хотим получить на выходе:

image

Логичное и элегантное решение задачи — настройка на сервере шифрования моста, включающего в себя два тегированных виртуальных интерфейса.

В VRF и глобальной таблице настраиваем два vlan, в которых организуем маршрутизацию мультикаста по протоколу PIM.
Предположим, что тег vlan в глобальной таблице — 10, а в VRF — 20, тогда:

interface Vlan10
description # Multicast to Region in GRT #
mac-address 001c.b7a4.3d10
ip address 192.168.10.1 255.255.255.240
ip pim dense-mode
load-interval 30
end

interface Vlan20
description # Multicast to MSPD #
mac-address 001c.b7a4.3d11
ip vrf forwarding MSPD
ip address 192.168.20.1 255.255.255.240
no ip redirects
ip pim dense-mode
load-interval 30
end

Следующим шагом настроим порт подключения сервера шифрования:

interface GigabitEthernet2/20
description # STREAM OUT #
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20
switchport mode trunk
load-interval 30
no mdix auto
no cdp enable
spanning-tree bpdufilter enable
end

Включение spanning-tree bpdufilter в данном случае обязательно, иначе линуксовый мост и cisco не «договорятся».
Теперь необходимо поднять сам мост. Для это требуется bridge-utils, поддержка моста ядром, поддержка сетевым интерфейсом тегированного трафика 802.1q.
В RHEL настройка интерфейсов производится с помощью конфигурационных файлов в /etc/sysconfig/network-scripts/ Их и приведу:
ifcfg-eth1.10:
DEVICE=eth1.10
VLAN=yes
HWADDR=00:21:5E:65:FA:F2
ONBOOT=yes
BOOTPROTO=static
TYPE=Ethernet
BRIDGE=stream1

ifcfg-eth1.20:
DEVICE=eth1.20
VLAN=yes
HWADDR=00:21:5E:65:FA:F2
ONBOOT=yes
BOOTPROTO=static
TYPE=Ethernet
BRIDGE=stream1

Теперь конфиг самого моста ifcfg-stream1:
DEVICE=stream1
HWADDR=00:21:5E:65:FA:F2
ONBOOT=yes
BOOTPROTO=static
TYPE=Bridge
IPADDR=192.168.10.2
NETMASK=255.255.255.240
STP=off

Перед поднятием интерфейсов, во избежание возникновения петель через мост отключаем ip forward в ядре:
echo 1 > /proc/sys/net/ipv4/ip_forward
и настраиваем iptables и ebtables дропать пакеты, проходящие через цепочки FORWARD.
Теперь смело поднимаем интерфейсы, добавляем маршруты и второй адрес на бридж: ifup eth1.10 && ifup eth1.20 && ifup stream1
ip addr add 192.168.20.2/28 dev stream1
ip route add 224.0.0.0/4 dev stream1

Вуаля, теперь наш шифрованный мультикаст полился и в глобальную таблицу, и в VRF.
Осталась одна деталь: для того, чтобы маршрутизировать мультикаст из VRF далее в сеть оператора, нужно в VRF на 7600 иметь маршрут на адрес источника, а именно на 192.168.10.2:
ip route vrf mspd 192.168.10.2 255.255.255.255 192.168.20.2

Надеюсь эта статья окажется кому-то полезной.
И спасибо НЛО за приглашение!
+17
5 марта 2010, 19:09
18

комментарии (11)

НЛО прилетело и опубликовало эту надпись здесь
+2
d_zwei #
Если вы говорите о ферме в целом, то для крупного оператора решение, которое рассчитано на коммерческую эксплуатацию и предполагает извлечение прибыли не может быть дешевым. Это, в первую очередь, обуславливается его расширяемостью и отказоустойчивостью.
Если же речь о том, что описано конкретно здесь, то непонятно, что именно дорого…
0
DLag #
Если не секрет, у какого оператора такая структура?

0
nonoxynol9 #
Ставлю на билайн
0
d_zwei #
Нет, это не билайн.
Раскрывать оператора не буду, но скажу, что услуга предоставляется на adsl.
0
DLag #
Тайны не раскрыли, но круг сильно сузили. :)
Не часто увидишь на aDSL IPTV услугу.
Хотя по большому счету ничего не мешает организовать…
0
Ilya_Smelykh #
у нас в Томске некая фирма уже давно промышляет подобными услугами с adsl2…
0
Pornosloneg #
ADSL здорово проседает под HD ;-(
Вопрос к автору: перезапрос потерянных фреймов есть? Какой видеокодек используется? А то для ADSL часто жмут в MPEG4/AVC с редкими I-frames, и в итоге переключение с канала на канал занимает какое-то время.
0
d_zwei #
Да, перезапрос есть, до 2% восстановления можно получить.
Видео кодируется и в MPEG2, и в MPEG4, GOP от 12 до 33, i-frame поэтому частые. Битрейт одного мультикаст потока примерно 4.5Мбит/сек.
Да, adsl для HD видео не предназначен, хотя, если сильно прижать и линию поднять до 6-7 мбит…
0
Fedia #
А зачем шифровать оба потока?

Я так понял, что через чужие сети передавать платный контент на халяву некомильфо.

А через свою сеть зачем? Все равно от мультикаста то не уходите?
0
d_zwei #
Мультикаст в шифрованном виде идет вплоть до абонентского устройства — таково условие контент-провайдера.
Платный контент через любую сеть в открытом виде передавать не комильфо.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.