Re: Confused about mVPN and MDT

I think it's also there in later 12.4T. It's there in 12.4(24)T at least.

Also, John - keep in mind that you don't need IPv4 MDT unless you're
running SSM in the core.

--
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior CCIE Instructor - IPexpert
On Wed, Jan 9, 2013 at 5:01 AM, Brian McGahan <bmcgahan_at_ine.com> wrote:
> The BGP IPv4 MDT advertisement is what allows the PEs to learn which endpoints the GRE tunnels should establish between.  The MDT advertisement contains the PE's Loopback address as well as the multicast group used for the default MDT.  You can see this in the details of the advertisement as follows:
>
> R2#show bgp ipv4 mdt all 19.19.19.19
> BGP routing table entry for 100:1:19.19.19.19/32     version 3
> Paths: (1 available, best #1, table IPv4-MDT-BGP-Table)
>   Not advertised to any peer
>   Local
>     19.19.19.19 from 19.19.19.19 (19.19.19.19)
>       Origin IGP, localpref 100, valid, internal, best,
>       MDT group address: 232.0.0.1
>
> In this case there is a PE advertising its loopback 19.19.19.19/32, the VRF has RD 100:1, and the MDT default address is 232.0.0.1.  R2 now knows that it should join the (S,G) tree for (19.19.19.19, 232.0.0.1) in the SP core.  That's all BGP is doing here, just providing the source and group discovery.  The rest of the control plane is signaled with PIM as normal.
>
> BGP IPv4 MDT isn't supported in your version.  It will still work by using the type 2 RD, but the difference is your version has the pre-standard implementation, which means there are interoperability issues.  To get the BGP IPv4 MDT support either go to a 12.2S train or up to 15.x.
>
>
> HTH,
>
> Brian McGahan, CCIE #8593 (R&S/SP/Security)
> bmcgahan_at_INE.com
>
> Internetwork Expert, Inc.
> http://www.INE.com
>
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of David Prall
> Sent: Wednesday, January 09, 2013 5:22 AM
> To: John Neiberger
> Cc: David Prall; ccielab_at_groupstudy.com
> Subject: Re: Confused about mVPN and MDT
>
> MDT address family is a must when using SSM for the data mdt. At least that is what I think I remember.
>
> David
> --
> I'm currently all thumbs so I apologize for the short message.
>
> On Jan 8, 2013, at 11:21 PM, "John Neiberger" <jneiberger_at_gmail.com> wrote:
>
>> I just checked the configuration guide. It looks like this version
>> doesn't
> support the ipv4 mdt address family, which means the mdt information is sent from the VPNv4 AF using a Type 2 RD to differentiate it from the unicast information. So, I guess as long as I'm sending extended communities, I should be okay.
>>
>>
>> On Tue, Jan 8, 2013 at 9:17 PM, John Neiberger <jneiberger_at_gmail.com>
> wrote:
>>> Thanks for the reply! It's starting to make sense now. I'm trying to
>>> lab it
> up in GNS3 on a topology I had previously built with L3VPN. Things seemed to be going well until I went to add the ipv4 mdt address family to BGP. It doesn't seem to be available on this IOS. I'm sure something similar must be available because I was able to set the default mdt address in the vrf config.
> It clearly supports mdt and multicast VPNs, so I'm not sure what to do now if the ipv4 mdt address family isn't available. I'll have to check the configuration guides. Maybe this particular config isn't possible on 12.4(15)T14.
>>>
>>>
>>> On Tue, Jan 8, 2013 at 9:03 PM, David Prall <dcp_at_dcptech.com> wrote:
>>>> The Customer Multicast is encapsulated inside the Provider
>>>> Multicast,
> this
>>>> is the MDT. There is the MDT Default and MDT Data groups. PIM and
>>>> low bandwidth groups are sent to all PE's using the Default. When a
>>>> high bandwidth stream is started, it is moved to a Data MDT and this
>>>> is
> signaled
>>>> so that PE's that have a CE Joined to the inner group, can join the
> specific
>>>> Data Group. Since all PE's for a given VRF are part of the VRF's MDT
> Default
>>>> Group, and the group must be the same on all PE's, BiDir PIM is a
>>>> good choice here. Since specific PE's are joining the MDT Data
>>>> Groups, and to make it so that all PE's can be configured the same
>>>> SSM is a good choice here. If you use ASM, then each PE must have a
>>>> distinct Data group range
> for
>>>> the VRF.
>>>>
>>>> David
>>>>
>>>> --
>>>> http://dcp.dcptech.com
>>>>
>>>> > -----Original Message-----
>>>> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On
>>>> > Behalf Of John Neiberger
>>>> > Sent: Tuesday, January 08, 2013 10:48 PM
>>>> > To: ccielab_at_groupstudy.com
>>>> > Subject: Re: Confused about mVPN and MDT
>>>> >
>>>> > Okay, just after sending that I think I read an explanation that
>>>> > makes sense and corrects some problems I had. It appears that the
>>>> > PE routers participating in the MDT join the MDT group, which is
>>>> > specific to an
> mVPN.
>>>> > That means on the P/PE side of the network, they are signaling to
>>>> > the internal RP that they want to join that *,G. When a multicast
>>>> > packet arrives on a PE from a CE, that packet gets encapsulated in
>>>> > a GRE
> packet
>>>> > with the MDT group as the destination address. That flows toward
>>>> > the provider RP. All of the other participating PEs have joined
>>>> > the MDT
> group,
>>>> > so they receive that multicast packet. Once they receive it, they
>>>> > de-encapsulate it and place it onto the vrf with the associated
>>>> > MDT
> group
>>>> > configured on it.
>>>> >
>>>> > Is that about right? There are still some parts to this that are
>>>> confusing,
>>>> > but I think it's starting to make more sense.
>>>> >
>>>> > John
>>>> >
>>>> >
>>>> > On Tue, Jan 8, 2013 at 8:40 PM, John Neiberger
>>>> > <jneiberger_at_gmail.com>
>>>> > wrote:
>>>> >
>>>> > > I don't know why, but this seems to be a subject that just
>>>> > > doesn't
> make
>>>> > > sense to me. I'm having trouble visualizing the process and I
>>>> > > don't
> yet
>>>> > > understand all of the steps necessary to configure mVPN.
>>>> > >
>>>> > > One thing I'm not entirely sure of is why we would even
>>>> > > configure
> this
>>>> in
>>>> > > the first place. My only thought is that it is a service to
>>>> > > provide
> to
>>>> > > customers and it saves them from having to configure GRE tunnels
>>>> > between
>>>> > > their sites since regular L3VPN wouldn't support multicast. I
>>>> > > don't
> see
>>>> why
>>>> > > they couldn't just configure GRE tunnels between their CE
>>>> > > routers and
>>>> run
>>>> > > PIM on them. I guess it would work, but the idea of being a
>>>> > > service provider is to offload some of that headache, right?
>>>> > >
>>>> > > Okay, to the technical stuff. I'll walk through the process as I
>>>> > > understand it and you'll see where I'm getting lost. Let's
>>>> > > assume
> that
>>>> the
>>>> > > basic L3VPN config is done and working.
>>>> > >
>>>> > > 1. PIM SM is enabled on P/PE routers and an RP is selected.
>>>> > > 2. PIM SM is configured in the customer network and will show as
>>>> > > a
> PIM
>>>> > > neighbor inside their VRF on our PE router.
>>>> > > 3. The MDT address is configured in the VRF.
>>>> > > 4. The ipv4 mdt address family is configured in BGP with the
>>>> > > same
> peers
>>>> as
>>>> > > in the VPNv4 AF.
>>>> > >
>>>> > > Here's where I get confused. At some point in this process, the
>>>> > > PE
>>>> routers
>>>> > > join the MDT group. They also form GRE tunnels between their
> loopbacks.
>>>> > > This seems to be an automatic process. I don't understand the
>>>> > > need
> for
>>>> the
>>>> > > MDT group. If the PE routers already have GRE tunnels between
>>>> > > them,
> PIM
>>>> > > could run across them with no problem as-is. What function does
>>>> > > the
> MDT
>>>> > > perform and what benefit does it provide?
>>>> > >
>>>> > > Another question is this: what actually triggers the building of
> those
>>>> GRE
>>>> > > tunnels? Is that a function of enabling the ipv4 mdt address family?
>>>> > >
>>>> > > Please un-confuse me. If anyone has any helpful pointers or even
>>>> > > old
>>>> blog
>>>> > > posts, please point the way.
>>>> > >
>>>> > > Thanks!
>>>> > > John
>>>> >
>>>> >
>>>> > Blogs and organic groups at http://www.ccie.net
>>>> >
>>>> > __________________________________________________________________
>>>> > _
>>>> > ____
>>>> > Subscription information may be found at:
>>>> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net