[c-nsp] Multicast VPN Extranet Routing in IOS XR

[Tim Durack]

On Thu, Mar 10, 2011 at 11:34 PM, John Neiberger <jneiberger at gmail.com>wrote:

> I'm *really* new to this and I honestly do not know what I'm doing. My
> goal is to have two (or more) VRFs on a single router that don't
> necessarily communicate from a unicast perspective, but I do want to
> have a bunch of multicast sources in one VRF and receivers in other
> VRFs. It appears that Multicast VPN Extranet Routing is the feature
> I'm looking for. According to CCO:
>
> "Multicast VPN (MVPN) extranet routing lets service providers
> distribute IP multicast content from one enterprise site to another
> across a multicast VRF. In other words, this feature provides
> capability to seamlessly hop VRF boundaries to distribute multicast
> content end to end."
>
> Has anyone here configured this before? I think my config is going to
> be pretty simple. I only need BGP on a single router. There will not
> be any BGP peers. I just need BGP to handle routing between the VRFs
> on one router. Then, on that same router, I need incoming joins to be
> able to hop the VRF boundary and reach the sources.
>
> Have any of you actually done this before?
>

Attempted to do something like this on an IOS platform. Could not get it to
work. Multicast between VRFs on the same PE was not supported.

TAC case said:

"MVPN Extranet support means to build a mdt tunnel between PEs for source vrf
and receiver vrf. MVPN extranet will work in PIM sparse-mode as long as you
have source located on one PE and receiver located on other PE. This is
outlined in below document. Option 1 and Option 2 are Cisco supported and
recommend design.

http://www.cisco.com/en/US/docs/ios/12_2sb/feature/guide/extvpnsb.html#wp1054493

For single PE scenario, PE cannot build tunnel to itself. From your
output, it seems single PE scenario works in dense mode, as you can see
no RP shown in mroute entry. However, this is not a supported feature.
As dense mode works in flood and prune fashion, so, when vrf v203
interface receiving traffic, it has no way to flood interface on vrf 204
as they belongs to different VRF. ( no pim join mechanism like 2 PEs
scenario, that pim join can come from mdt tunnel).     So, if you
configure source and receiver in different vrf from fresh, it would not
work as dense mode cannot flood different vrf interface. However, it may
work if you configure receiver interface in same vrf first to make
packet start to flood, now even after you rename the VRF, the receiver
is not going to prune itself.     But, this is not a support feature."


We tried all kinds of tricks, including connecting VRF across a back-to-back
jumper. Ended up putting source/receiver in the same VRF.

-- 
Tim:>