PIM Sparse-Mode: Register via one link and SPT cutover via another link.

Its not always optimal to use the same link(Shared Tree) in which you register with the RP to take in the multicast data. I will demonstrate how to register via one interface(Shared Tree) but take in the data via another(Source Tree). I'm using static routes in this example but you can also use BGP to take in the same routes and prefer one path over the other. I have done this in other setups with BGP so it works and please note that I am not going to go into great detail but just give you the general idea as PIM is very broad. We will use the diagram in figure1.

Figure 1

Lets enable multicast routing on all the devices, sparse-mode on the interfaces and configure RP details.

R1 - R2 - R3
ip multicast-routing
!
interface range fa0/0 - 1
ip pim sparse-mode
!
ip pim rp-address 1.1.1.1 multicast_groups override
!
ip access-list standard multicast_groups
permit 233.54.1.1

Now lets assign some ip addresses to the interfaces and setup static routes.

R3:
interface FastEthernet0/0
 ip address 192.168.100.1 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex
!
interface FastEthernet0/1
 ip address 192.168.101.1 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex
!
ip route 1.1.1.1 255.255.255.255 FastEthernet0/0 192.168.100.2 name RP
ip route 2.2.2.2 255.255.255.255 FastEthernet0/1 192.168.101.2 name 233_54_1_1_Source

R2:
interface FastEthernet0/0
 ip address 192.168.103.2 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex
!
interface FastEthernet0/1
 ip address 192.168.101.2 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

ip route 1.1.1.1 255.255.255.255 FastEthernet0/0 192.168.103.1 name RP
ip route 2.2.2.2 255.255.255.255 FastEthernet0/0 192.168.103.1 name 233_54_1_1_Source

R1:
interface FastEthernet0/0
 ip address 192.168.103.1 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex
!
interface FastEthernet0/1
 ip address 192.168.100.2 255.255.255.0
 ip pim sparse-mode
 speed 100
 full-duplex

Now we need to configure our loopback interfaces on R1 for the RP  address and Source address. Also enable sparse-mode on the loopback interfaces as well. If not, it wont work.

R1:
interface Loopback1
 ip address 1.1.1.1 255.255.255.255
 ip pim sparse-mode
!
interface Loopback2
 ip address 2.2.2.2 255.255.255.255
 ip pim sparse-mode

Lets setup a dummy loopback interface on R3 and we will statically configure our multicast group to it since I don't have an actual host to use to join the group. This will take the place of that.

R3:

interface Loopback0

 ip address 3.3.3.3 255.255.255.255
 ip pim sparse-mode
 ip igmp static-group 233.54.1.1

Now lets issue this command from R1. "ping 233.54.1.1 source loopback 2 repeat 3"  I am just going to show you how R2 looks after we issue the command.

Currently R2 has no mcast state until the ping command is issued on R1 because R3 is sending a Join only to R1 and not R2 because of how routing is setup by design. When we added the static join to the R3 loopback interface, it let R1 know that it was interested in joinng this group and wanted to also know the source of the group. Since no data was being published from the host at that time, it never sent anything to R2.  Once we issue the above command R3 will learn the source(2.2.2.2) and see that it has to go through R2 to reach that source and in turn tell R2 that it was to Join 233.54.1.1

R2#
*Mar  1 01:42:52.495: PIM(0): Check RP 1.1.1.1 into the (*, 233.54.1.1) entry
*Mar  1 01:42:52.551: PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 192.168.101.1, to us
*Mar  1 01:42:52.551: PIM(0): Join-list: (2.2.2.2/32, 233.54.1.1), S-bit set
*Mar  1 01:42:52.555: PIM(0): Add FastEthernet0/1/192.168.101.1 to (2.2.2.2, 233.54.1.1), Forward state, by PI                                                                   M SG Join
*Mar  1 01:42:52.555: PIM(0): Insert (2.2.2.2,233.54.1.1) join in nbr 192.168.103.1's queue
*Mar  1 01:42:52.559: PIM(0): Building Join/Prune packet for nbr 192.168.103.1
*Mar  1 01:42:52.559: PIM(0): Adding v2 (2.2.2.2/32, 233.54.1.1), S-bit Join
R2#
*Mar  1 01:42:52.559: PIM(0): Send v2 join/prune to 192.168.103.1 (FastEthernet0/0)
R2#

On R3 we can see the *,G and S,G have two different  incoming interfaces. This is by design and expected because of how we have this setup.

R3#show ip mroute 233.54.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 233.54.1.1), 00:51:56/stopped, RP 1.1.1.1, flags: SJC
  Incoming interface: FastEthernet0/0, RPF nbr 192.168.100.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:51:56/00:01:44

(2.2.2.2, 233.54.1.1), 00:00:03/00:02:56, flags: J
  Incoming interface: FastEthernet0/1, RPF nbr 192.168.101.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:03/00:02:56

R3#