Multicast routing between VRF's

  • 0
  • 1
  • Question
  • Updated 3 years ago
  • Answered
Hi!

I wondering if it's possible to route incoming multicast from one VR to another VR in the same machine?

The reason is that I want to isolate a PIM domain for our IPTV customers from our core network. A simple solution would be to do a loop in the switch and push all traffic over that link, but that's cheating ;-)

Would be thankful for some insight and maybe configuration samples.

With regards
Mattias
Photo of mael

mael

  • 200 Points 100 badge 2x thumb

Posted 3 years ago

  • 0
  • 1
Photo of Stephen Williams

Stephen Williams, Employee

  • 9,040 Points 5k badge 2x thumb
Currently we can only do Inter-VR Routing for IPv4 Unicast by using Static Routes.
Photo of mael

mael

  • 200 Points 100 badge 2x thumb
So there's no way you can route multicast from one VR to another VR or Sub VR internally? (RD, BGP, OSPF)
Feels very 2001 using a loop or an extra link to get multicast into another VR :-P
Photo of Stephen Williams

Stephen Williams, Employee

  • 9,040 Points 5k badge 2x thumb
What type of isolation are you trying to get?  PIM passive VLANs would prevent user vlans from seeing PIM messages.
Photo of mael

mael

  • 200 Points 100 badge 2x thumb
We run PIM-SM passive today and push everything to our providers. But now many off them doesn't want that, they want us to have a ordinary PIM-SM with MSDP (I've gotten everything working except multicast). So to isolate them from our core, I want a separate VRF.
A solution would be to add a new "droppoing" switch and it would only deliver to them, but it's just wrong ;-)
Photo of Henrique

Henrique, Employee

  • 10,342 Points 10k badge 2x thumb
Hi Mattias,

You can find more details about the information provided by Stephen in the article below:

Routing configuration between VRs
Photo of mael

mael

  • 200 Points 100 badge 2x thumb
Thanks Henrique!
Though I already read it ;-) and it's not unicast that's the problem....We are an IPTV distributor so multicast is kind of our thing :-D
Photo of Mike D

Mike D, Alum

  • 3,852 Points 3k badge 2x thumb
Hey Mattias

I understand the business requirement but even unicast route leaking is a non-trivial task.  Inter-vrf routing has always confused me.  Take 

 My rule of thumb for multicast: the simplest solution that solves the problem is generally the right solution.  PIM troubleshooting causes heartburn for many a network admin.   

I am glad there's a workaround in this case - that always makes the conversation easier.  And I'm always happy to see folks coming to the HUB community with these sorts of questions.  It's a time saver and maybe saves you a call to support.  And of course we welcome the discussion.  Ultimately its customer requirements that decide direction - so we need to hear it.      

I'm not saying its hip or elegant, but life is much easier with a five inch cat5 cable handling the tricky business. 

Best regards,

Mike
Photo of mael

mael

  • 200 Points 100 badge 2x thumb
Hi Mike!

That's so true...simpliest solution is always best. :-)
But we also has to acknowledge our providers request.
So please develop inter-vrf multicast support ;-)

With regards
Mattias
Photo of Michael Suggs

Michael Suggs

  • 412 Points 250 badge 2x thumb
Not trying to high jack this post, but have a similar issue. i have a 460 with pim sparse to a external RP off my network. i pull 324 multicast via this sparse vlan.  the rest  of my network is currently dense, working as it is , i want to convert my entire network from dense to all sparse. which will cause me to have a different RP on my own network. could i use this same inter-VR solution to pass multicast from my current sparse VR to a new separate VR sparse ring? i was kind of thinking of using MSDP. thanks in advance,
Photo of Julian Eble

Julian Eble

  • 1,394 Points 1k badge 2x thumb
Well I would like to have same thing with our network.
The main core runs with MPLS but the PIM are doing the same work in the same OSPF area..
I would like to create VR`s and run the multicast separately.