С радостью для себя обнаружил на Хабре некоторое количество статей на тему весьма мне близкую — IPTV.
Решил внести свой небольшой вклад написанием этой статьи.
Один интернет провайдер центрального региона имеет в коммерческой эксплуатации в нескольких городах услугу IPTV. Одной из основ, точнее, самой главной основой является наполнение этой услуги контентом, это очевидно. И разумеется, оператору гораздо удобнее агрегировать весь контент в одном месте, откуда, используя свои межрегиональные сети передачи данных, вещать его в филиалы.
Оператор в месте агрегации контента имеет:
1. Серверную ферму предоставления услуги IPTV;
2. Стык фермы с региональной сетью филиала;
3. Стык фермы с МСПД (межрегиональная сеть передачи данных);
4. МСПД от региональной сети на серверной ферме отделена с использованием VRF.
Необходимо на одном из серверов фермы шифровать мультикаст и передавать его в таком виде в МСПД и региональную сеть, не используя никаких дополнительных устройств видеомультиплексирования. Сервер шифрования выступает здесь в качестве стримера, на который наложены определенные ограничения:
1. Один телеканал — одна лицензия, одна мультикастовая группа.
2. Стримить сервер может только с одного интерфейса (один адрес источника мультикаста — это основная проблема).
ОС сервера шифрования — RHEL5.4, сетевое оборудование фермы — Cisco серии 7600.
Сперва необходимо схематично отобразить, что же мы хотим получить на выходе:
Логичное и элегантное решение задачи — настройка на сервере шифрования моста, включающего в себя два тегированных виртуальных интерфейса.
В 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
Надеюсь эта статья окажется кому-то полезной.
И спасибо НЛО за приглашение!
Решил внести свой небольшой вклад написанием этой статьи.
Небольшое введение
Один интернет провайдер центрального региона имеет в коммерческой эксплуатации в нескольких городах услугу IPTV. Одной из основ, точнее, самой главной основой является наполнение этой услуги контентом, это очевидно. И разумеется, оператору гораздо удобнее агрегировать весь контент в одном месте, откуда, используя свои межрегиональные сети передачи данных, вещать его в филиалы.
Постановка задачи
Оператор в месте агрегации контента имеет:
1. Серверную ферму предоставления услуги IPTV;
2. Стык фермы с региональной сетью филиала;
3. Стык фермы с МСПД (межрегиональная сеть передачи данных);
4. МСПД от региональной сети на серверной ферме отделена с использованием VRF.
Необходимо на одном из серверов фермы шифровать мультикаст и передавать его в таком виде в МСПД и региональную сеть, не используя никаких дополнительных устройств видеомультиплексирования. Сервер шифрования выступает здесь в качестве стримера, на который наложены определенные ограничения:
1. Один телеканал — одна лицензия, одна мультикастовая группа.
2. Стримить сервер может только с одного интерфейса (один адрес источника мультикаста — это основная проблема).
ОС сервера шифрования — RHEL5.4, сетевое оборудование фермы — Cisco серии 7600.
Решение
Сперва необходимо схематично отобразить, что же мы хотим получить на выходе:
Логичное и элегантное решение задачи — настройка на сервере шифрования моста, включающего в себя два тегированных виртуальных интерфейса.
В 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
Надеюсь эта статья окажется кому-то полезной.
И спасибо НЛО за приглашение!