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
Received on Tue Mar 08 2011 - 18:56:05 ART