Saturday, November 19, 2011

Cisco SSM(Source Specific Multicast) configuration example

Cisco SSM(Source Specific Multicast) configuration example
In this blog, We will provide an SSM(Source Specific Multicast) configuration example on Cisco Routers.
SSM works with IGMP version 3.There are no shared tree and there are no need for RP for SSM.
Multicast client subscribes to group (S,G) instead of (*,G).
Here is the topology for this example:


Configuration of R1

interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 ip igmp join-group 232.1.1.1 source 4.4.4.4
 ip igmp version 3

Configuration of R2

ip multicast-routing
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.23.2 255.255.255.0
 ip pim dense-mode
 no ip mroute-cache
!
interface FastEthernet0/1
 ip address 192.168.12.2 255.255.255.0
 ip pim dense-mode
 ip igmp version 3
 no ip mroute-cache

router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0

ip pim ssm range 1
!
access-list 1 permit 232.0.0.0 0.255.255.255

Configuration of R3

ip multicast-routing
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
 ip pim dense-mode
 no ip mroute-cache
!
interface FastEthernet0/1
 ip address 192.168.34.3 255.255.255.0
 ip pim dense-mode
  no ip mroute-cache

router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0

ip pim ssm range 1
!
access-list 1 permit 232.0.0.0 0.255.255.255

Configuration of R4

ip multicast-routing
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.34.4 255.255.255.0
 ip pim dense-mode
 no ip mroute-cache

router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0

ip pim ssm range 1
!
access-list 1 permit 232.0.0.0 0.255.255.255

Lets check R2`s igmp and mroute table outputs:

R2#show ip igmp membership
Flags: A  - aggregate, T - tracked
       L  - Local, S - static, V - virtual, R - Reported through v3
       I - v3lite, U - Urd, M - SSM (S,G) channel
       1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
       / - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
       <mac-or-ip-address> - last reporter if group is not explicitly tracked
       <n>/<m>      - <n> reporter in include mode, <m> reporter in exclude

 Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface
/*,232.1.1.1                    192.168.12.1    00:00:08 stop  3MA    Fa0/1
 4.4.4.4,232.1.1.1                              00:00:08 02:52 RA     Fa0/1
 *,224.0.1.40                   192.168.23.2    00:23:54 02:05 2LA    Fa0/0
R2#show 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

(4.4.4.4, 232.1.1.1), 00:00:22/00:02:59, flags: sTI
  Incoming interface: FastEthernet0/0, RPF nbr 192.168.23.3
  Outgoing interface list:
    FastEthernet0/1, Forward/Dense, 00:00:22/00:00:00

Lets start traffic with source IP address 192.168.34.4

R4#ping
Protocol [ip]:
Target IP address: 232.1.1.1
Repeat count [1]: 1000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yes
Interface [All]:
Time to live [255]:
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 1000, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
.......

We see that pings failed because there is no client that subscribes to group (192.168.34.4,232.1.1.1)
Lets start ping with source IP address of 4.4.4.4
R4#ping
Protocol [ip]:
Target IP address: 232.1.1.1
Repeat count [1]: 1000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yes
Interface [All]: FastEthernet0/0
Time to live [255]:
Source address: 4.4.4.4
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 1000, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4

Reply to request 0 from 192.168.12.1, 256 ms
Reply to request 1 from 192.168.12.1, 204 ms
Reply to request 2 from 192.168.12.1, 248 ms
Reply to request 3 from 192.168.12.1, 240 ms
Reply to request 4 from 192.168.12.1, 268 ms

We see that pings are successful, because client had subscribed to get multicast traffic from source IP address of 4.4.4.4
More outputs from R2:
R2#show ip igmp groups 232.1.1.1 detail
Flags: L - Local, U - User, SG - Static Group, VG - Virtual Group,
       SS - Static Source, VS - Virtual Source,
       Ac - Group accounted towards access control limit
Interface:      FastEthernet0/1
Group:          232.1.1.1
Flags:          SSM
Uptime:         00:16:16
Group mode:     INCLUDE
Last reporter:  192.168.12.1
Group source list: (C - Cisco Src Report, U - URD, R - Remote, S - Static,
                    V - Virtual, M - SSM Mapping, L - Local,
                    Ac - Channel accounted towards access control limit)
  Source Address   Uptime    v3 Exp   CSR Exp   Fwd  Flags
  4.4.4.4          00:16:16  00:02:42  stopped   Yes  R
R2#show ip mroute 232.1.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
(4.4.4.4, 232.1.1.1), 00:15:28/00:02:31, flags: sTI
  Incoming interface: FastEthernet0/0, RPF nbr 192.168.23.3
  Outgoing interface list:
    FastEthernet0/1, Forward/Dense, 00:15:28/00:00:00
R2#show ip mroute 232.1.1.1 count
IP Multicast Statistics
3 routes using 1848 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 232.1.1.1, Source count: 1, Packets forwarded: 5, Packets received: 5
  Source: 4.4.4.4/32, Forwarding: 5/0/100/0, Other: 5/0/0

Cisco PIM Sparse Mode Configuration with Auto-RP

Cisco PIM Sparse Mode Configuration with Auto-RP

Cisco`s Auto RP protocol distributes RP information to across the multicast domain.

There are two multicast groups for auto-rp

224.0.1.39: candidate RPs announce itself to mapping agent.
224.0.1.40: Mapping Agent distributes the RP information to all Multicast Routers.

ip pim autorp listener  command will be used on all routers to cause IP multicast traffic for the two Auto-RP groups 224.0.1.39 and 224.0.1.40 to be Protocol Independent Multicast dense mode flooded across interfaces operating in PIM sparse mode.

Instead of using ip pim autorp listener command we could use ip pim sparse-dense-mode on all interfaces.But we prefer ip pim autorp listener command.

Here is the topology for this example:




R1 is the multicast client for group 224.1.1.1
R2 is RP for all multicast groups:
R3 is the mapping agent.
R4 has the multicast source for group 224.1.1.1


Configuration of R2(RP)
ip multicast-routing

ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 255

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 1 area 0
ip pim sparse-mode
!
interface FastEthernet0/0
 ip address 192.168.23.2 255.255.255.0
 ip pim sparse-mode
 no ip mroute-cache
!
interface FastEthernet0/1
 ip address 192.168.12.2 255.255.255.0
 ip pim dense-mode
 no ip mroute-cache
!
interface FastEthernet1/0
 ip address 192.168.24.2 255.255.255.0
 ip pim sparse-mode
 no ip mroute-cache
!
router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0
!
Configuration of R3(Mapping Agent):

ip multicast-routing
ip pim autorp listener
ip pim send-rp-discovery Loopback0 scope 255

interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip pim sparse-mode
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
 ip pim sparse-mode
 !
interface FastEthernet0/1
 ip address 192.168.34.3 255.255.255.0
 ip pim sparse-mode
!
router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0
!
Configuration R4
ip multicast-routing
ip pim autorp listener

interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.34.4 255.255.255.0
 ip pim sparse-mode
!
interface FastEthernet1/0
 ip address 192.168.24.4 255.255.255.0
 ip pim sparse-mode
!
router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0

Lets debug Auto RP from R3(Mapping Agent)

R3#debug ip pim auto-rp
PIM Auto-RP debugging is on
*Mar  1 01:25:22.339: Auto-RP(0): Received RP-announce packet of length 48, from 2.2.2.2, RP_cnt 1, ht 181
*Mar  1 01:25:22.343: Auto-RP(0): Added with (224.0.0.0/4, RP:2.2.2.2), PIMv2 v1
*Mar  1 01:25:22.371: Auto-RP(0): Build RP-Discovery packet
*Mar  1 01:25:22.371: Auto-RP:  Build mapping (224.0.0.0/4, RP:2.2.2.2), PIMv2 v1,
*Mar  1 01:25:22.375: Auto-RP(0): Send RP-discovery packet of length 48 on FastEthernet0/0 (1 RP entries)
*Mar  1 01:25:22.379: Auto-RP(0): Send RP-discovery packet of length 48 on FastEthernet0/1 (1 RP entries)
*Mar  1 01:25:22.383: Auto-RP(0): Send RP-discovery packet of length 48 on Loopback0(*) (1 RP entries)

Debug from R4

R4#debug ip pim auto-rp
*Mar  1 01:25:17.983: Auto-RP(0): Received RP-discovery packet of length 48, from 3.3.3.3, RP_cnt 1, ht 181
*Mar  1 01:25:17.987: Auto-RP(0): Added with (224.0.0.0/4, RP:2.2.2.2), PIMv2 v1
R4#show ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 2.2.2.2 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:00:21, expires: 00:02:37

Cisco PIM Sparse Mode with Static RP Configuration Example

Cisco PIM Sparse Mode with Static RP Configuration

In PIM Sparse Mode (PIM-SM), multicast traffic is only forwarded to group members which explicitly request it via join requests.Multicast flooding is much less than PIM Dense Mode(PIM-DM).PIM Sparse Mode is the recommended version.

We will provide an example for PIM Sparse Mode with static RP(rendezvous point):

Here is the topology for this example:



R1 is the multicast client for group 224.1.1.1

Configuration of R2

ip multicast-routing

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.23.2 255.255.255.0
 ip pim sparse-mode
 no ip mroute-cache
!
interface FastEthernet0/1
 ip address 192.168.12.2 255.255.255.0
 ip pim dense-mode
 no ip mroute-cache
!
interface FastEthernet1/0
 ip address 192.168.24.2 255.255.255.0
 ip pim sparse-mode
 no ip mroute-cache
!
router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0
!
ip pim rp-address 3.3.3.3

Configuration of R3:

ip multicast-routing

interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip pim sparse-mode
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
 ip pim sparse-mode
 !
interface FastEthernet0/1
 ip address 192.168.34.3 255.255.255.0
 ip pim sparse-mode
!
router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0
!
ip pim rp-address 3.3.3.3

R4 is the source and its configuration is similar to R2

Lets start the traffic from R4:

R4#ping         
Protocol [ip]:
Target IP address: 224.1.1.1     
Repeat count [1]: 10000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yes
Interface [All]: FastEthernet1/0
Time to live [255]:
Source address: 4.4.4.4
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 10000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4

Reply to request 0 from 192.168.12.1, 172 ms
Reply to request 1 from 192.168.12.1, 144 ms
Reply to request 2 from 192.168.12.1, 80 ms
Reply to request 3 from 192.168.12.1, 88 ms

Ping results are OK.Lets show some verifying commands:

R2#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
192.168.23.3      FastEthernet0/0          01:16:17/00:01:36 v2    1 / DR S
192.168.24.4      FastEthernet1/0          01:16:12/00:01:19 v2    1 / DR S


R2# show ip pim rp mapping
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
    RP: 3.3.3.3 (?)

R2#show 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

(*, 224.1.1.1), 00:47:12/stopped, RP 3.3.3.3, flags: SJC
  Incoming interface: FastEthernet0/0, RPF nbr 192.168.23.3
  Outgoing interface list:
    FastEthernet0/1, Forward/Dense, 00:47:12/00:00:00

(4.4.4.4, 224.1.1.1), 00:16:47/00:01:51, flags: JT
  Incoming interface: FastEthernet1/0, RPF nbr 192.168.24.4
  Outgoing interface list:
    FastEthernet0/1, Forward/Dense, 00:16:47/00:00:00

(*, 224.0.1.40), 00:47:14/00:02:10, RP 3.3.3.3, flags: SJPCL
  Incoming interface: FastEthernet0/0, RPF nbr 192.168.23.3
  Outgoing interface list: Null

Multicast Reverse Path Forwarding

Multicast Reverse Path Forwarding(RPF)
The router forwards the multicast packet away from the source along the distribution tree. The router's multicast forwarding state is  based on the reverse path, from the receiver back to the root of the distribution tree. When the router receives a packet, it checks its routing table for the source IP address.If the incoming multicast packet comes from the interface that is same as the outgoing interface for the routing table entry to the source IP address then the router forwards the packet, otherwise drops the paket.This process is known as reverse-path forwarding (RPF).
 We will provide an example for multicast RPF process:
Here is the topology for this example:


We run PIM dense-mode and Ospf between the routers in this example.Ospf costs are same on all routers:
R4 is the multicast source for the group 224.1.1.1 and R1 is the client for the same group.
Lets start the traffic from R4:

R4#ping
Protocol [ip]:
Target IP address: 224.1.1.1
Repeat count [1]: 1000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Interface [All]: FastEthernet1/0
Time to live [255]:
Source address: 4.4.4.4
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 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4

Reply to request 0 from 192.168.12.1, 112 ms
Reply to request 1 from 192.168.12.1, 84 ms
Reply to request 2 from 192.168.12.1, 80 ms

When we check the routing table and RPF from R2:

R2#show ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 192.168.24.4 on FastEthernet1/0, 00:00:01 ago
  Routing Descriptor Blocks:
  * 192.168.24.4, from 4.4.4.4, 00:00:01 ago, via FastEthernet1/0
      Route metric is 2, traffic share count is 1

R2#show ip rpf 4.4.4.4
RPF information for ? (4.4.4.4)
  RPF interface: FastEthernet1/0
  RPF neighbor: ? (192.168.24.4)
  RPF route/mask: 4.4.4.4/32
  RPF type: unicast (ospf 1)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables

We see that packet is coming from FastEthernet1/0 which is same as the rpf interface.

Lets increase the cost of the R2 `s interface that is facing to R4:
R2#show ip ospf interface Fastethernet 1/0 | include Cost
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 1
R2#conf t
R2(config)#interface Fastethernet 1/0
R2(config-if)#ip ospf cost 10000
R2(config-if)#end
R2#show ip ospf interface Fastethernet 1/0 | include Cost
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 10000

Route to 4.4.4.4 is changed:

R2#show ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "ospf 1", distance 110, metric 21, type intra area
  Last update from 192.168.23.3 on FastEthernet0/0, 00:00:11 ago
  Routing Descriptor Blocks:
  * 192.168.23.3, from 4.4.4.4, 00:00:11 ago, via FastEthernet0/0
      Route metric is 21, traffic share count is 1

R2#show ip rpf 4.4.4.4
RPF information for ? (4.4.4.4)
  RPF interface: FastEthernet0/0
  RPF neighbor: ? (192.168.23.3)
  RPF route/mask: 4.4.4.4/32
  RPF type: unicast (ospf 1)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables

Lets start the ICMP and debug the multicast packets at R2:
R2#debug ip mpacket
IP multicast packets debugging is on
R2#
*Mar  1 00:36:12.911: IP(0): s=4.4.4.4 (FastEthernet1/0) d=224.1.1.1 id=139, ttl=254, prot=1, len=114(100), not RPF interface
R2#
*Mar  1 00:36:14.907: IP(0): s=4.4.4.4 (FastEthernet1/0) d=224.1.1.1 id=140, ttl=254, prot=1, len=114(100), not RPF interface
R2#
*Mar  1 00:36:16.891: IP(0): s=4.4.4.4 (FastEthernet1/0) d=224.1.1.1 id=141, ttl=254, prot=1, len=114(100), not RPF interface

We see that multicast packets are not coming from RPF interface and they are dropped by the router:
R2#show ip mroute 224.1.1.1 count
IP Multicast Statistics
3 routes using 2304 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 224.1.1.1, Source count: 1, Packets forwarded: 0, Packets received: 17
  Source: 4.4.4.4/32, Forwarding: 0/0/0/0, Other: 17/17/0

Friday, November 18, 2011

Cisco PIM Dense Mode Configuration Example

PIM Dense Mode

The basic assumption for PIM dense-mode is that the multicast flow has receivers at most locations. Dense mode is ideal for groups where many of the nodes will want to receive the multicast flows.

In dense-mode, the source initially multicasts the flow to every router. Then each router that does not want to receive flows destined for that group will send a prune message to the neighbor which is at the path to the multicast source. After receiving a prune message, the router will modify its state so that it will not forward those packets out that interface. If every interface on a router is pruned, the router will also be pruned.

In this blog we will provide a pim dense mode configuration example on Cisco routers:

Here is the topology for this example:


In this example R4 router`s loopback0 ip address(4.4.4.4) will be the multicast source for group 224.1.1.1, R1 router will be the multicast client for the same group.

Here is the configurations:

R1(Simulates a Client):
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 ip igmp join-group 224.1.1.1
!
router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0

Configuration of R2

ip multicast-routing
!        
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.23.2 255.255.255.0
 ip pim dense-mode
 no ip mroute-cache
!
interface FastEthernet0/1
 ip address 192.168.12.2 255.255.255.0
 ip pim dense-mode
 no ip mroute-cache
!
interface FastEthernet1/0
 ip address 192.168.24.2 255.255.255.0
 ip pim dense-mode
 no ip mroute-cache
!
router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0

Configuration of R3

ip multicast-routing
!     
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
 ip pim dense-mode
!
interface FastEthernet0/1
 ip address 192.168.34.3 255.255.255.0
 ip pim dense-mode
!
router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0

Configuration of R4

ip multicast-routing
!      
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet0/0
 ip address 192.168.34.4 255.255.255.0
 ip pim dense-mode
!
interface FastEthernet1/0
 ip address 192.168.24.4 255.255.255.0
 ip pim dense-mode
!
router ospf 1
 log-adjacency-changes
 network 192.168.0.0 0.0.255.255 area 0

When a multicast client wants to subscribe to a multicast group, it sends igmp join message:
In this example R1 is multicast client.There is "ip igmp join-group 224.1.1.1" command in R1`s F0/0 interface.This command is used for testing purposes to simulate the client.

Lets debug these messages on R2:

R2#debug ip igmp
IGMP debugging is on
R2#
*Mar  1 00:14:55.647: IGMP(0): Received v2 Report on FastEthernet0/1 from 192.168.12.1 for 224.1.1.1
*Mar  1 00:14:55.647: IGMP(0): Received Group record for group 224.1.1.1, mode 2 from 192.168.12.1 for 0 sources
*Mar  1 00:14:55.651: IGMP(0): WAVL Insert group: 224.1.1.1 interface: FastEthernet0/1Successful
*Mar  1 00:14:55.651: IGMP(0): Switching to EXCLUDE mode for 224.1.1.1 on FastEthernet0/1
*Mar  1 00:14:55.651: IGMP(0): Updating EXCLUDE group timer for 224.1.1.1
*Mar  1 00:14:55.651: IGMP(0): MRT Add/Update FastEthernet0/1 for (*,224.1.1.1) by 0

Lets start traffic from R4:

R4# ping
Protocol [ip]:
Target IP address: 224.1.1.1     
Repeat count [1]: 10000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yes
Interface [All]: FastEthernet1/0
Time to live [255]:
Source address: 4.4.4.4
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 10000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
Reply to request 0 from 192.168.12.1, 156 ms
Reply to request 1 from 192.168.12.1, 120 ms
Reply to request 2 from 192.168.12.1, 104 ms
Reply to request 3 from 192.168.12.1, 132 ms
Reply to request 4 from 192.168.12.1, 140 ms

We see that the multicast traffic flows from R4 to R1 through R2.

Lets debug the multicast packets on R2(to debug these packet we have configured no ip mroute-cache command on R2)

R2#
*Mar  1 00:22:39.115: IP(0): s=4.4.4.4 (FastEthernet1/0) d=224.1.1.1 (FastEthernet0/0) id=82, ttl=254, prot=1, len=100(100), mforward
*Mar  1 00:22:39.123: IP(0): s=4.4.4.4 (FastEthernet1/0) d=224.1.1.1 (FastEthernet0/1) id=82, ttl=254, prot=1, len=100(100), mforward

Lets check the mroute table on R2:

R2#show 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
(*, 224.1.1.1), 01:03:42/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Dense, 00:59:31/00:00:00
    FastEthernet0/0, Forward/Dense, 01:03:42/00:00:00
    FastEthernet0/1, Forward/Dense, 00:13:32/00:00:00
(4.4.4.4, 224.1.1.1), 00:06:26/00:02:55, flags: T
  Incoming interface: FastEthernet1/0, RPF nbr 192.168.24.4
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:06:28/00:00:00
    FastEthernet0/1, Forward/Dense, 00:06:28/00:00:00
(*, 224.0.1.40), 01:10:36/00:02:29, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Dense, 00:59:33/00:00:00
    FastEthernet0/0, Forward/Dense, 01:10:36/00:00:00