On Thu, Mar 10, 2011 at 11:34 PM, John Neiberger <[email protected]>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:> _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
