cancel
Showing results for 
Search instead for 
Did you mean: 

Routing video multicasts between vlans

Routing video multicasts between vlans

Justin_Beaman
New Contributor
Hello,

I am stumped on how to approach my situation and haven't had any luck with the previously posted solutions.

Current setup:
vlan446 contains ~100 IPTV video multicasts.
I want to split specific channels/multicasts into 4 other vlans, e.g., 10 channels to vlan610, 20 channels to vlan620, etc. in order to balance traffic around our ring. So instead of flooding all 100 channels via layer 2 to our ring on vlan446, I would like to have a more targeted approach and split some channels from vlan446 --> vlan610 North feed, vlan446 --> vlan620 South feed

In order to single out specific channels/multicasts, is this an ACL that needs to be configured? Do I have to run PIM in order to split the specific multicasts to new vlans?

Thank you in advance!

7 REPLIES 7

Justin_Beaman
New Contributor
I apologize for the delay! So I was able to successfully route a multicast from vlan442 on switch 1 and receive the multicast in vlan610 on switch 2 using the suggested MVR.

Is it possible to then add an igmp snooping statement for vlan610 and send out another port in vlan610? I tried 'conf igmp snoop vlan610 add static group ' but it is not sending the multicast to another switch through the configured port.

Thank you in advance!
-Justin

Justin_Beaman
New Contributor
That reads just like what I'm looking for Henrique! I'll give it a shot tomorrow in my lab and see what I can do with it. Thanks again!

Henrique
Extreme Employee
Hi Justin, I was wondering about MVR feature.

Please see a brief explanation I got from User Guide:
"Multicast VLAN Registration (MVR) is designed to support distributing multicast streams for IPTV to subscribers over a Layer 2 network. In a standard Layer 2 network, a multicast stream received on a VLAN is not forwarded to another VLAN. The streams are confined to the Layer 2 broadcast domain. In an IGMP snooping environment, streams are forwarded only to interested hosts on a VLAN. For inter- VLAN forwarding (routing) a multicast routing protocol, such as PIM/DVMRP must be deployed.

MVR breaks this basic rule, so that a stream received over Layer 2 VLANs is forwarded to another VLAN, eliminating the need for a Layer 3 routing protocol. It simplifies the multicast stream distribution and is a better solution for IPTV-like services. With MVR, a multicast stream is forwarded to all VLANs containing interested hosts. "

Please take a look in the article below:

How to configure “Static” MVR regardless of IGMP join

Justin_Beaman
New Contributor
Thank you for the fast responses Roberto and Henrique.

Some background:
We are a headend/transport provider and as things are currently configured, we only do layer 2 to our dmarcs that reside at our customer locations. The customers then have their own PIM routers to provide IPTV to their own video subscribers. We block all ingress PIM requests coming back through to our network. Instead, we flood our source multicasts to these companies and control flows around our transport ring via igmp snooping on the vlans (conf igmp snooping 'vlan' 'port' add static group 'multicast')

What I have been tasked to do is to try to split one of our distribution vlans into 4 zones. Each zone will contain a subset of traffic that was previously all flowing out on the vlan446 that I was describing in my first post. We will keep vlan446 internally and branch the 4 vlans around the ring. The goal is to still flood all traffic out on these new vlan zones by routing the multicasts from vlan446 to the new zones without the need for PIM requests/joins downstream from us. I'm hoping something like a static route like so:

multicast 224.0.104.108 on internal vlan446 is now going to be heading out of our headend/transported on vlan610 - just flood it out and have it always present downstream to our dmarc switch at customer premise to cutover to their PIMs.

Our network consists of a mix of Summit 450, 460, 460G2 running a mix of EOS versioning from 11.0-16.0.

Does this provide a better picture on what I hope to accomplish?
GTM-P2G8KFN