In this post we will see how to configure PIM-SM (sparse mode) with static RP configurations. Following basic lab setup used for this with a multicast source is connected to a layer 3 switch (CAT2) & a multicast receiver connect to a layer 2 switch (CAT4). EIGRP configured between layer 3 devices (CAT2,WAN, CME) for basic IP routing. Keep in mind, multicast/PIM is running on top of IGP & therefore without proper unicast IP routing, multicast service will not work.

When configuring multicast, First step is enable multicast routing (ip multicast-routing [distributed]) CLI command. “distributed” keyword is required only on switch platforms (3750,3560,etc).

Next step is to enable PIM (ip pim sparse-mode) on required layer 3 interfaces. In our example on “int vlan 200, fa1/0/22 & fa1/0/4 of CAT2, fa0/0, fa2/1 & L0 on CME (as we are planning to configure this as RP), int fa0/0.22, fa0/0.99 & fa0/1 on WAN router.

Final step is to configure RP in order to receivers to find multicast source in the network. In Static-RP configuration, you need to configure “ip pim rp-address x.x.x.x” command on every multicast enable router in your network including RP itself. In this example we will make CME as RP in this network. Usually Loopback address of a device configured as RP as it is  an interface less likely to go down. Once you configure “ip pim rp-address 10.10.205.20” on Cat2, CME & WAN. We can verify RP configuration by using “show ip pim rp mapping” command. “Static” keyword confirms that RP configured using that method.

CAT2#sh ip pim rp mapp
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
    RP: 10.10.205.20
!
WAN#sh ip pim rp mapp
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
    RP: 10.10.205.20

In order to test multicast functionality  in the lab exam, (as no real multicast applications are available) you can use the following verification process.

You can simulate a client join to a multicast group by configuring “ip igmp join-group x.x.x.x” command on a layer 3 interface. In this case will configure this on WAN router int fa0/0.22 as that’s where our multicast receiver going to be. you can use any random group number as you wish.

WAN(config-subif)#ip igmp join-group 239.9.9.9
!
WAN#sh ip igmp groups 
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   Group Accounted
239.9.9.9        FastEthernet0/0.22       00:04:52  00:02:52  10.10.22.129

Now if you go to RP, you should see (*,G) entry for this 239.9.9.9 group address.

CME(config)#do sh ip mroute
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

(*, 239.9.9.9), 00:03:20/00:03:05, RP 10.10.205.20, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/1, Forward/Sparse, 00:03:20/00:03:05

If you could not see, that mean Receiver LHR (Last hop router- WAN) to RP, multicast is broken (either PIM is not properly enable or RPF failures). You can use “mtrace” command to verify proper PIM configurations between LHR to RP.

WAN#mtrace 10.10.205.20
Type escape sequence to abort.
Mtrace from 10.10.205.20 to 172.16.99.10 via RPF
From source (?) to destination (?)
Querying full reverse path... 
 0  172.16.99.10
-1  172.16.99.10 PIM  [10.10.205.0/24]
-2  172.16.99.9 PIM  [10.10.205.0/24]
-3  10.10.205.20

Next is to simulate multicast source traffic to a group by simply ping a multicast group address with the source interface where you need to put your multicast source. In our case vlan 200 in CAT2. You have to use extended ping command, otherwise CAT2 generate multicast traffic from all PIM enabled interfaces to this group address.

CAT2#ping
Protocol [ip]: 
Target IP address: 239.6.6.6
Repeat count [1]: 10
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y
Interface [All]: vlan 200
Time to live [255]: 
Source address: 192.168.200.254
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 192.168.200.254

You can verify this in RP using “show ip mroute 239.6.6.6” command. If you see (S,G) entry for your group address with specific source interface IP you originate ping traffic that proves Source to RP multicast is working. If you could not see this, then it means multicast is broken between source to RP & use “mtrace x.x.x.x ) command to troubleshoot it.

CME#sh ip mroute 239.6.6.6
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

(*, 239.6.6.6), 00:00:07/stopped, RP 10.10.205.20, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(192.168.200.254, 239.6.6.6), 00:00:07/00:02:52, flags: P
  Incoming interface: FastEthernet0/0, RPF nbr 172.16.99.6
  Outgoing interface list: Null

Now we verified both source to RP & receiver to RP multicast in working properly. Final test is to simulate multicast traffic between source to receiver. It is simple & you can do the extended ping to multicast group address where you configure “ip igmp join-group x.x.x.x on receiver LHR. In our case if you do the extended ping to 239.9.9.9 from CAT2 you will see something like this.

CAT2#ping           
Protocol [ip]: 
Target IP address: 239.9.9.9
Repeat count [1]: 10
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y
Interface [All]: vlan 200
Time to live [255]: 
Source address: 192.168.200.254
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.9.9.9, timeout is 2 seconds:
Packet sent with a source address of 192.168.200.254 

Reply to request 0 from 172.16.99.10, 8 ms
Reply to request 1 from 172.16.99.1, 8 ms
Reply to request 2 from 172.16.99.1, 1 ms.......

Here you could noticed replies for first few pings coming from 99.10 & then it switched to 99.1. This mean multicast traffic flow start in shared tree (RPT) & traffic going via RP.  Then it will automatically switched to shortest-path tree (SPT). This is default behaviour (switch to SPT) in Cisco IOS. This is based on shortest path between Source to Receiver and it may not always via RP.(in my example S->D via RP is having multiple hops & shortest path is direct connection from CAT2-WAN).By using “ip pim spt-threshold infinity” command you can force not to switch over to shortest path.

Following INE (Internetwork Expert) free streaming on “Troubleshooting Multicast” is helpful to understand the approach needs to take. Even though target audience is CCIE R&S or SP, it is good for anyone who is learning this topic.

We will see how to configure PIM Auto-RP in order to dynamically learn (oppose to manual static RP configuration) RP information in next post related to this topic.

 Related Posts

1. Test Yourself- Basic Multicast
2. Configuring Multicast on WLC
3. Wireless Multicast is not working – Why ?
4. Understanding “VideoStream” feature
5. IGMP Basics
6. Multicast Address Allocation
7. Multicast Deployment Types
8. PIM-SM Auto-RP configurations