[c-nsp] IOS XR BGP error: parent address family not initialized

[John Neiberger]

On Sun, Mar 13, 2011 at 1:21 AM, Oliver Boehmer (oboehmer)
<oboehmer at cisco.com> wrote:
>
>> It turns out that this may all be for nought anyway. I think we're
>> close to getting it working, but I just saw that this feature may only
>> really be supported on the 12000, not the ASR9K. I just looked at an
>> ASR9K-specific multicast conifguration guide for IOS XR 4.0 and it
>> makes no mention of mVPN Extranet Routing. And even if we could get it
>> to work, it sounds like only one receiver VRF can join the source, so
>> the other receiver VRFs that I want to create would not be able to
>> join.
>
> are you using 4.0.1? mVPN extranet on ASR9k definitly works across PEs
> (i.e. you have a MDT between the PEs), but not sure about if source and
> dest VRF are on the same PE. Can you please work with TAC and/or your
> Cisco team on this?
>
> tx!
>        oli
>

We are using 4.0.1. We almost had it working, but for some reason IGMP
would not work inside a VRF. It was so strange. I could specifically
enable IGMP on an interface in a VRF, yet "show igmp vrf <whatever>
interface" would say that IGMP was disabled.

Our goal is to have the source and destination VRF on the same PE. But
if the ASR9K has the same limitation as the one mentioned in the other
documentation, only one encapsulted tunnel is allowed in the OIL, so
only one receiver VRF would be able to join the source VRF. The others
would be out of luck. If only there were a way to get multicast
sources from one VRF to another on the same PE without using an MDT
tunnel. I'm not sure if there is any way to do that. If there were, we
still may be able to do this.

Our second option is going to be to split the router up into bridge
groups and have one BVI per virtual "lab" area. Then we'll use ACLs to
stop any sort of unicast routing between BVIs and only allow PIM from
the receiver bridge groups to the source bridge group. That still
basically gets us our goal, which was to split the router up into lab
groups that have no awareness of each other, yet can still get
multicast sources from the same source. That limits the number of
replications we have to do, and dramatically reduces the bandwidth
needed back to the actual multicast sources.

It's kind of complicated and hard for me to explain via text. I think
my explainer is broken today.  :)  I was going to get our Cisco team
involved tomorrow, and possibly open a TAC case, but we're under some
tight time constraints to get this new lab up and running, so we may
just have to do whatever works first.

Thanks!
John