Re: Problem with Multicast and VRF Lite

Hi Brian,

You have given a detailed and thorough explanation about MDT, however can
you please clarify the following two confusions:

- You mentioned that

> With the default MDT, when one site sends a multicast packet out to the
> MDT, all other sites receive it, even if they don't want it. Data MDT can
> fix this by creating new tunnels depending on which PEs want which groups
> from the CE. It's kind of like 1:1 NAT, but the addresses are still GRE
> encapsulated instead of translated.
>
What I understood is that a PE will forward data only to those PE which are
interested in it but how can we control it? Are you trying to say that every
PE will join "default MDT" but only few will join "data MDT"? How will we
control which traffic should use "default MDT" and which should use "data
MDT", because we can only control the usage of "data MDT" based on the data
rate threshold? Correct me if I am wrong

- Secondly, whenever a PE joins an MDT, should we always be able to see
their MDT peers using "show ip pim mdt bgp"? I have a case in which both PEs
are PIM neighbors over the tunnel, created by MDT, but still I cannot see
them as MDT peers using the mentioned command? How can I troubleshoot it
because the multicast traffic is not flowing between the 2 PEs?

Thanks,
Malik
On Wed, Mar 9, 2011 at 6:24 AM, Brian McGahan <bmcgahan_at_ine.com> wrote:

> Hi John,
>
> I don't think MDT is going to help you in this design. Basically an
> MDT is multipoint GRE tunnel. PE routers that support the same VRF join the
> same "default" MDT. GRE packets are sent from the PE router with a source
> address of the Loopback (typically) and the multicast destination address of
> the default MDT. The PE routers already know each other's Loopback
> addresses, because these are the next-hop values for VPNv4 (MPLS BGP)
> routes. The MDT address is usually in the SSM multicast range. In that
> case each PE sends an (S,G) PIM Join message for the other PE routers, where
> S is their Loopback addresses, and G is the MDT default address. The final
> result is that each PE automatically forms a GRE tunnel to the other PEs
> using that MDT address.
>
> Once the tunnel is up, PIM adjacencies form over them. The MDT
> (GRE) tunnel is treated just like any other PIM enabled interface in the
> incoming or outgoing interface list. The MDT can participate in PIM dense,
> PIM sparse with an RP, PIM sparse with SSM, or bidirectional PIM, just like
> any other PIM enabled link. When multicast traffic is received from a CE
> and it is destined for another VPN site, regardless of the destination
> address, it is GRE encapsulated with the source address of the PE's Loopback
> and the destination address of the MDT. Since all other PEs are listening
> for this (S,G), they all receive it.
>
> If you want to you can also configure a "data" MDT. This is an
> additional range of addresses that can be used for new GRE tunnels between
> specific PEs, in order to optimize the traffic flow. With the default MDT,
> when one site sends a multicast packet out to the MDT, all other sites
> receive it, even if they don't want it. Data MDT can fix this by creating
> new tunnels depending on which PEs want which groups from the CE. It's kind
> of like 1:1 NAT, but the addresses are still GRE encapsulated instead of
> translated.
>
> I believe the problem that you'll have in your case is that VRF-lite
> isn't really designed to leak traffic between different routing tables; the
> whole point of the VRF is to keep the routes and traffic separate. It might
> be possible to hack this up by creating a physical loopback on the router,
> e.g. plugging GigE0/0 into GigE0/1, and then configuring the interfaces into
> different VRFs. This way you'd be able to leak the traffic between tables
> because the router basically wouldn't know that it's peering with itself.
> This solution is probably more trouble than it's worth though.
>
> Also MDT isn't a VRF feature per-se, it's an MPLS L3 VPN feature.
> L3 VPN is made up of two parts, the VRF and the VPNv4 BGP. VRF-lite skips
> over the VPNv4 BGP part, so even if you used multiple routers, they wouldn't
> be able to figure out how to form the GRE tunnels since they don't know each
> other's Loopbacks as VPNv4 BGP next-hops.
>
> What exactly are you trying to solve with your design? Let me know
> more of the specifics of what the end result you want to be, and I'm sure
> there are other feasible solutions we could figure out to do this.
>
>
> 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
> John Neiberger
> Sent: Tuesday, March 08, 2011 7:56 PM
> To: Rich Collins
> Cc: ccielab_at_groupstudy.com
> Subject: Re: Problem with Multicast and VRF Lite
>
> Yeah, the SSM part is throwing me. Besides, I don't really understand
> how a lot of this works yet. I was just trying to fight through it to
> see if I could make it work. I've read the command reference for mdt
> and I still don't understand what it actually is doing. For example, I
> don't understand what the group range I assign to the command is used
> for. Does it convert my actual source groups to the group addresses I
> specify in the mdt data command? If not, what is it actually doing?
>
> Ultimately, I want several VRFs with receivers to pull data from
> another VRF that contains nothing but multicast sources.
>
> -John
>
> On Tue, Mar 8, 2011 at 6:30 PM, Rich Collins <nilsi2002_at_gmail.com> wrote:
> > Hi,
> >
> > I tried an example similar to yours with a static rp-address(one one
> > side only) and no mdt. That seemed to work fine. I have to review
> > SSM to try it again to more closely match your example.
> >
> > I suppose you don't need an mdt GRE tunnel since you are not trying to
> > link two PE's across the core backbone.
> >
> > -Rich
> >
> > On Sat, Mar 5, 2011 at 11:33 PM, John Neiberger <jneiberger_at_gmail.com>
> wrote:
> >> I've never configured VRF Lite or multiprotocol BGP until today. I'll
> >> be up front and say that I really don't know what I'm doing with it.
> >> lol I'm trying to simulate a lab scenario that I want to create in a
> >> real lab at work. I'm using GNS3 at the moment. I have two VRFs for
> >> multicast receivers (Orange and Blue) and a VRF called Shared for my
> >> multicast sources. Here's a simplified network diagram only dealing
> >> with the Orange VRF:
> >>
> >> A -------- B -------- C --------- D
> >>
> >> Simple! :) The Orange VRF extends from A to C, while the Shared VRF
> >> extends from C to D. OSPF is running in each VRF and I'm using MP-BGP
> >> to redistribute the routes so that sources and receivers can reach
> >> each other. Unicast reachability is working.
> >>
> >> I have PIM Spare Mode configured end-to-end. I have an IGMP join
> >> configured on a loopback interface on A, along with IGMPv3 so the SSM
> >> join works. I can see valid mroutes on A, B and C, and from D to C.
> >> I'm sourcing an extended ping from D to C to simulate a source. It is
> >> sending to a 232/8 address. I have pim ssm default configured
> >> everywhere, including on the VRFs on C.
> >>
> >> The problem now appears to be that I can't get PIM to talk across the
> >> VRF boundary. I've been reading up on this and I don't understand how
> >> to solve this problem. When reading about multicast VPNs I see that
> >> MDT is used, but I don't understand how it works. It is pure
> >> conjecture on my part that adding the correct MDT configuration might
> >> create a tunnel between the two VRFs for multicast.
> >>
> >> Am I on the right track? Any thoughts?
> >>
> >> Thanks!
> >> John
> >>
> >> P.S. Here is the config on C (called R4 in the config). I've been
> >> playing around with the mdt commands even though I don't really
> >> understand them yet. I was hoping to get lucky. :)
> >>
> >>
> >> version 12.4
> >> service timestamps debug datetime msec
> >> service timestamps log datetime msec
> >> no service password-encryption
> >> !
> >> hostname R4
> >> !
> >> boot-start-marker
> >> boot-end-marker
> >> !
> >> !
> >> no aaa new-model
> >> memory-size iomem 5
> >> ip cef
> >> !
> >> !
> >> !
> >> !
> >> ip vrf Blue
> >> rd 65000:2
> >> route-target export 65000:2
> >> route-target import 65000:3
> >> !
> >> ip vrf Orange
> >> rd 65000:1
> >> route-target export 65000:1
> >> route-target import 65000:3
> >> mdt default 232.1.1.2
> >> mdt data 232.1.3.0 0.0.0.255
> >> !
> >> ip vrf Shared
> >> rd 65000:3
> >> route-target export 65000:3
> >> route-target import 65000:1
> >> route-target import 65000:2
> >> mdt default 232.1.1.1
> >> mdt data 232.1.2.0 0.0.0.255
> >> !
> >> no ip domain lookup
> >> ip multicast-routing vrf Orange
> >> ip multicast-routing vrf Shared
> >> !
> >> multilink bundle-name authenticated
> >> !
> >> !
> >> interface FastEthernet0/0
> >> no ip address
> >> speed 100
> >> full-duplex
> >> !
> >> interface FastEthernet0/0.1
> >> encapsulation dot1Q 10
> >> ip vrf forwarding Orange
> >> ip address 10.1.34.2 255.255.255.0
> >> ip pim sparse-mode
> >> !
> >> interface FastEthernet0/0.2
> >> encapsulation dot1Q 20
> >> ip vrf forwarding Blue
> >> ip address 10.2.34.2 255.255.255.0
> >> !
> >> interface FastEthernet0/1
> >> ip vrf forwarding Orange
> >> ip address 10.1.45.1 255.255.255.0
> >> duplex auto
> >> speed auto
> >> !
> >> interface FastEthernet1/0
> >> ip vrf forwarding Shared
> >> ip address 10.1.46.1 255.255.255.0
> >> ip pim sparse-mode
> >> ip igmp version 3
> >> duplex auto
> >> speed auto
> >> !
> >> router ospf 1 vrf Orange
> >> log-adjacency-changes
> >> redistribute bgp 65000 subnets
> >> network 10.1.34.0 0.0.0.255 area 0
> >> network 10.1.45.0 0.0.0.255 area 0
> >> !
> >> router ospf 2 vrf Blue
> >> log-adjacency-changes
> >> redistribute bgp 65000 subnets
> >> network 10.2.34.0 0.0.0.255 area 0
> >> !
> >> router ospf 3 vrf Shared
> >> log-adjacency-changes
> >> redistribute bgp 65000 subnets
> >> network 10.1.46.1 0.0.0.0 area 0
> >> !
> >> router bgp 65000
> >> no synchronization
> >> bgp router-id 10.1.45.1
> >> bgp log-neighbor-changes
> >> no auto-summary
> >> !
> >> address-family ipv4 vrf Shared
> >> redistribute connected
> >> redistribute ospf 3 vrf Shared
> >> no synchronization
> >> exit-address-family
> >> !
> >> address-family ipv4 vrf Orange
> >> redistribute connected
> >> redistribute ospf 1 vrf Orange
> >> no synchronization
> >> exit-address-family
> >> !
> >> address-family ipv4 vrf Blue
> >> redistribute connected
> >> redistribute ospf 2 vrf Blue
> >> no synchronization
> >> exit-address-family
> >> !
> >> ip forward-protocol nd
> >> !
> >> !
> >> no ip http server
> >> no ip http secure-server
> >> ip pim ssm default
> >> ip pim vrf Orange ssm default
> >> ip pim vrf Shared ssm default
> >> !
> >> i
> >>
> >>
> >> 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
Received on Wed Mar 09 2011 - 11:56:21 ART