IPTV: broadcasting multicast traffic to VRF and global table

With pleasure for myself I discovered a number of articles on Habré on a topic very close to me - IPTV.
I decided to make a small contribution by writing this article.

Small introduction

One Internet provider in the central region has IPTV service commercially available in several cities. One of the bases, more precisely, the most important basis is the filling of this service with content, this is obvious. And of course, it is much more convenient for the operator to aggregate all the content in one place, from where, using its inter-regional data networks, broadcast it to the branches.

Formulation of the problem

The operator at the place of aggregation of content has:
1. Server farm providing IPTV services;
2. Farm joint with regional branch network;
3. Farm trusses with MRTD (interregional data transmission network);
4. The MRTD from the regional network on the server farm is separated using VRF.
It is necessary on one of the farm servers to encrypt a multicast and transmit it in this form to the MRTD and the regional network, without using any additional video multiplexing devices. The encryption server acts here as a tape drive with certain restrictions imposed:
1. One channel - one license, one multicast group.
2. Only one interface can stream the server (one address of the multicast source is the main problem).
Encryption Server OS - RHEL5.4, farm network equipment - Cisco 7600 series.
')

Decision

First you need to schematically display what we want to get at the output:



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

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

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

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

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

The inclusion of the spanning-tree bpdufilter is mandatory in this case, otherwise the Linux bridge and cisco will not “agree”.
Now you need to raise the bridge itself. This requires bridge-utils, support for the bridge by the kernel, support for 802.1q tagged network traffic.
In RHEL, the configuration of interfaces is done using the configuration files in / etc / sysconfig / network-scripts / I will give them:
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

Now the config of the bridge itself 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

Before raising the interfaces, in order to avoid 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 packages that go through FORWARD chains.
Now feel free to raise the interfaces, add the routes and the second address to the bridge: 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

Voila, now our encrypted multicast has been poured into both the global table and the VRF.
One detail remained: in order to route the multicast from the VRF further to the operator’s network, you need to have a route to the source address in the 7600 VRF, namely, at 192.168.10.2:
ip route vrf mspd 192.168.10.2 255.255.255.255 192.168.20.2

I hope this article will be useful to someone.
And thank you UFO for the invitation!