MVPN Extranet Support - (S,G) MVRF's behind same PE pair...

Unanswered Question
Jan 19th, 2009

I've read the one document 'Configuring Multicast VPN Extranet Support'. But it only talks about remote MVRF M-cast, not MVRF sharing with S, G exist behind the same PE (pair).

After doing a practical implementation last Friday where the source MVRF was to be joined to by receivers in another User (M)VRF, it was required to point the MVRFs to the same RP (PE)...using a static command, ip pim...rp-address OVERride...predictably, each MVRF was pointing to its own RP, (running autoRP in this environment with pairs of PE's at each distribution point around the campus). I understand why the OVERride would work here, but it's not ideal.


What is the best method for creating this "pointing to same RP" solution in a more dynamic fashion so that it will support M-Cast VPN Extranet MVPN/MVRF's behind the same PE(s)?

We'll need high availability aspects for this to be scalable/reliable.

Can it be made to work with AutoRP, or, are pointing all MVPN/MVRFs to the same pair of weighted static RP's the solution? Or, is the OVERride the only solution for Extranet MVPN?

(Note that the documentations says the source and RP must be behind the same PE - I get that, just not how to improve M-cast HA aspects since now we're pinning up a single point of failure RP - that can't be a good thing.)

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Laurent Aubert Mon, 01/19/2009 - 18:13


This is a requirement for MVPN extranet support to have the RP associated to your shared group to be on the same site as your source. You can achieve RP HA with anycast RP.

In your Receiver VPN, if you already have a RP, you should apply filters to be sure your internal RP is not chosen for the shared group. Such Filters can be applied either with static or auto-rp implementation.

Also you could try an MSDP session between both RPs but it's just an idea and I didn't test it...

Hope this helps



mprescher Tue, 01/20/2009 - 09:22


Well, we tried the MSDP session and crashed both 6500's (PE pair). We actually had both 6500's acting as RP's for the same VLAN's.

This is info and the crash dumps are going in to a TAC case today. We didn't have time in the maint. window to try other scenarios...we're pretty sure this solution didn't invision what we tried so to some degree, the crash was a complete surprise.

Laurent Aubert Tue, 01/20/2009 - 13:12


I'm really sorry to read that. You should try such complex configuration first in your lab if it's possible. You could also go with dedicated boxes acting as RP as well.




This Discussion