PIM sparse mode (PIM SM) the traffic from sources to the RP initially flows encapsulated in Register messages.
This activity is very intensive because of encapsulation/de-encapsulation mechanisms, also an SPT is built between the RP and the source (initiated by the RP), which results in (*, G) and (S, G) entries created between the RP and the source.
For the moment lets have this scenario
There are two commands that you need for simple PIM sparse mode (PIM SM) deployment (assuming that the rendezvous point [RP] is learned automatically via Auto-RP or bootstrap router [BSR] mechanisms; if not, the RP address has to be manually configured (using the ip pim rp-address).
- Global command ip multicast-routing enables support for IP multicast on a router.
- Interface command ip pim sparse-mode enables PIM SM operation on the selected interface.
An additional command is the SPT threshold, the default value (0) results in switching to the shortest-path tree (SPT) soon after receipt of the first multicast packet for the group.
If this switching is not desired for some or all groups, we can use the ip pim spt-threshold (in kbps) command, and optional standard access list defining the affected groups; if the infinity keyword is used, no switchover is allowed for those groups, and only shared trees will be used.
The RP address for sparse mode groups may be defined manually, or one of the mechanisms for automatic distribution of RP information (Auto-RP or BSR) may be used. To manually define the IP address of an RP for multicast groups, use the ip pim rp-address command.
we should do the same configuration on R3, R6, and on the RP (R4).
in Resume, only 3 steps are necessary to configure basic PIM SM:
- Add the ip multicast-routing global command to the configuration.
- Add the ip pim sparse-mode interface command to each interface in the router configuration to enable IP multicasting using PIMSM.
- Configure the IP address of the rendezvous point (RP) using the ip pim rp-address address global command.
If there are any problems (no multicast flow, entries missing in multicast forwarding table, PIM Neighbors not seen, and so on) use the following two debugging commands to show information:
- debug ip mrouting―Shows the activity in creating, maintaining, or deleting entries in the multicast forwarding table
- debug ip pim―Shows PIM control messages and associated activity
The debug output of PIM messages for group 22.214.171.124, a Join/Prune message for active group (126.96.36.199) is composed and sent periodically (every 60 s) to the RP, and routers by which the Join (Join-list) is received they propagated this to the upstream PIM Neighbor, until it hits the RP.
The RP (rendezvous point), WC (wildcard), and S (sparse) bits are set – meaning that the message travels upstream toward the RP, that the message relates to (*, G), and that G is sparse mode group.
On the RP, the Join is received on the serial interface, which is added to an Outgoing Interface List (OIL), or, if already there, the interface timers are “refreshed.”
The RP periodically send the RP-reachability message and propagates it down the shared tree to inform the nodes that RP is still reachable.
now if a source is present on the network:
on the RP (R4),
Upon receiving the first multicast packet from the source, the first-hop router consults the RP mapping cache and finds the RP address for the group (188.8.131.52).
The first-hop router then encapsulates the data in a Register message and sends it in unicast manner directly to the RP.
The RP already has a shared tree state for the group and immediately reacts with the (S, G) Join message toward the source. It also de-encapsulates the data from the Register and forwards it down the shared tree.
When (S, G) Join reaches the first-hop router, the shortest-path tree (SPT) is built between the RP and the first-hop router, and the traffic is now forwarded natively (down the already built tree) toward the RP (in addition to registering it).
When the first multicast packet arrives natively at the RP, the RP sends a Register-Stop message to instruct the first-hop router to stop registering. The Registering flag is cleared.
The router where the SPT and shared trees diverge was inspected. (S, G) Join was received, entry created (interface was added to the OIL) and Join propagated toward the source. At the same time, (S, G) Prune with RPT-bit was forwarded toward the RP to stop it from sending (S, G) traffic down the shared tree. (S, G) traffic will flow directly via the SPT from the source to the receiver segments.
On the RP, the periodic (*, G) Join was received, and the timer was refreshed. Additionally, (S, G) Prune with the RPT-bit arrived on a serial interface that was deleted from the OIL for (S, G) entry (if already existed; otherwise the entry is created first and the interface deleted immediately).