IPTV: broadcast multicast traffic in VRF and the global table

    I was happy to find on Habré a number of articles on a topic very close to me - IPTV.
    I decided to make my small contribution by writing this article.

    Small introduction

    One Internet provider in the central region has IPTV service in several cities for commercial use. One of the foundations, or rather, the most important basis, is filling this service with content, this is obvious. And of course, it’s much more convenient for the operator to aggregate all the content in one place, from where, using their inter-regional data transmission networks, broadcast it to branches.

    Formulation of the problem

    The operator in the place of content aggregation has:
    1. The server farm for the provision of IPTV services;
    2. Joint farm with a regional branch network;
    3. Joint farm with MRTD (interregional data network);
    4. The MRTD is separated from the regional network on the server farm using VRF.
    It is necessary to encrypt the multicast on one of the farm servers and transfer it in this form to the ISMT and the regional network without using any additional video multiplexing devices. Here, the encryption server acts as a streamer, which is subject to certain restrictions:
    1. One TV channel - one license, one multicast group.
    2. Stream server can only from one interface(one multicast source address is the main problem).
    The encryption server OS is RHEL5.4, the farm network equipment is the Cisco 7600 Series.


    First, we need to schematically show what we want to get at the output: A


    logical and elegant solution to the problem is to configure a bridge on the encryption server, which includes two tagged virtual interfaces.

    In VRF and the global table, we configure two vlan in which we organize multicast routing using the PIM protocol.
    Suppose the vlan tag in the global table is 10 and in VRF is 20, then:

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

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

    The next step is to configure the encryption server connection port:

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

    Enable spanning-tree bpdufilter in this case, necessarily , otherwise the linux bridge and cisco does not "agree".
    Now you need to raise the bridge itself. This requires bridge-utils, kernel bridge support, and network interface support for tagged 802.1q traffic.
    In RHEL, the interfaces are configured using the configuration files in / etc / sysconfig / network-scripts / I will give them:
    DEVICE = eth1.10
    VLAN = yes
    HWADDR = 00: 21: 5E: 65: FA: F2
    ONBOOT = yes
    BOOTPROTO = static
    TYPE = Ethernet
    BRIDGE = stream1

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

    Now the bridge config itself ifcfg-stream1:
    DEVICE = stream1
    HWADDR = 00: 21: 5E: 65: FA: F2
    ONBOOT = yes
    BOOTPROTO = static
    TYPE = Bridge
    IPADDR =
    STP = off

    Before raising the interfaces, to prevent loops through the bridge, disable ip forward in the kernel :
    echo 1> / proc / sys / net / ipv4 / ip_forward
    and configure iptables and ebtables to drop packets passing through FORWARD chains.
    Now boldly raise the interfaces, add routes and a second address to the bridge: ifup eth1.10 && ifup eth1.20 && ifup stream1
    ip addr add dev stream1
    ip route add dev stream1

    Voila, now our encrypted multicast poured into the global table, and in VRF.
    There was one detail: in order to route the multicast VRF further from the operator's network, you need to have a VRF on the 7600 route on the source address, namely
    the ip route vrf MSPD

    I hope this The article will be useful to someone.
    And thanks to UFO for inviting me!

    Also popular now: