PIM crash course

By stretch | Thursday, October 16, 2008 at 4:23 a.m. UTC

In multicast forwarding, each packet in a stream is transmitted once by a source and replicated by the infrastructure to efficiently reach an arbitrary number of recipients. This introduces a number of challenges not typically of concern when dealing with strictly unicast traffic. The fundamental difference is that, while unicast routing protocols are designed to forward traffic down the optimal path or paths to a destination, a multicast routing protocol must forward traffic down all paths, often replicating packets out multiple interfaces on the same router.

unicast_vs_multicast.png

Obviously, wherever traffic is replicated across a network containing even a single redundant path, the potential for routing loops is present. While unicast routing protocols are well-suited to detect and avoid loops when routing to a single destination, a multicast routing protocol is needed when paths have multiple end points. There are a number of multicast routing protocols, including DVMRP, MOSPF, and CBT, but this article intends to discuss Protocol Independent Multicast (PIM).

The term "protocol-independent" stems from the fact that PIM does not maintain its own topology database. Instead, it relies on the unicast forwarding table of the router to avoid loops; PIM is considered protocol-independent because it has no direct dependency on the unicast routing protocol(s) used.

Reverse Path Forwarding (RPF) checks are performed on each multicast packet received by a PIM router. RPF verifies that incoming multicast packets arrive on the interface closest to their source, by comparing the source address with the unicast routing table. If a unicast packet destined for that address would be forwarded out a different interface, the packet has reached the router via a non-optimal path, indicating the presence of a potential routing loop. In this event, the RPF check fails, and the incoming multicast packet is discarded.

In addition to monitoring the unicast routing table, PIM maintains its own multicast routing table to track incoming and outgoing interfaces for multicast traffic. Multicast routes are expressed in the format (S, G), where S is the multicast source and G is the group address. The multicast routing table is viewable on IOS with show ip mroute:

Router# 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.0.1.40), 00:07:04/00:02:49, RP 2.2.2.2, flags: SJPL
  Incoming interface: FastEthernet0/0, RPF nbr 10.0.12.2
  Outgoing interface list: Null

PIM Modes

In actuality, PIM refers to a family of very similar routing protocols, but which each operate in a different mode. These are:

PIM-DM

In dense mode operation, routers initially flood multicast traffic for all groups out all multicast-enabled interfaces. Routers which determine they have no clients interested in receiving the traffic then send prune messages up toward the source, requesting that the flow of multicast traffic downstream be stemmed. This process repeats toward the source router until all extraneous branches have been stemmed.

PIM-DM.png

This process of flooding and pruning repeats every three minutes. Because of this and other inefficiencies, PIM-DM isn't often recommended for real-world deployment.

PIM-SM

PIM-SM takes an opposite approach. Initially, multicast traffic from a source isn't forwarded to group members. When a member somewhere in the network decides it wants to receive traffic for a group, it sends a join request to its nearest router. The join request is propagated up the multicast tree toward the source router. Upon receiving the join request, the source router begins forwarding multicast traffic for the group out the appropriate interface(s).

PIM-SM.png

PIM-SM makes use of centralized rendezvous point (RP) routers and purpose-built logical multicast trees (shared and source-based) to achieve end-to-end forwarding.

BIDIR-PIM

Bidirectional PIM is an extension of PIM-SM, where multicast traffic can flow in both directions. All sources are potentially receivers as well.

BIDIR-PIM.png

PIM-SM Configuration

PIM-SM configuration includes three simple steps:

  1. Enable multicast routing
  2. Designate a PIM router to act as the rendezvous point (RP)
  3. Enable PIM-SM interfaces

The first two steps are accomplished with single commands in global configuration on all routers in the multicast domain:

R1(config)# ip multicast-routing
R1(config)# ip pim rp-address 172.16.34.1

Note that there exist other means of configuring RP routers, namely Cisco's proprietary Auto-RP and PIMv2's Bootstrap Router (BSR) methods. In our example, only manual configuration is used.

PIM is enabled per interface:

R1(config)# interface f0/0
R1(config-if)# ip pim sparse-mode

Believe it or not, this is all the configuration necessary to get a bare bones multicast network up and running. After enabling PIM, routers will form adjacencies with other PIM routers and multicast routes will be exchanged:

R1# 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
10.0.12.2         FastEthernet0/0          00:06:39/00:01:30 v2    1 / DR S
10.0.14.4         FastEthernet0/1          00:06:40/00:01:30 v2    1 / DR S

Of course, this article just scratches the surface of PIM operation and configuration. More to come.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Multicast, Routing

Comments


Mark (guest)
October 16, 2008 at 8:38 a.m. UTC

Great as usual, where do you get all this from?


Marius (guest)
October 16, 2008 at 8:47 a.m. UTC

Nice and clear. And although the pictures are not compulsory they really help in remembering easier the differences between all these concepts - I appreciate the time you spent making them. I'll be watching for the "more to come" ;)


Braz (guest)
October 16, 2008 at 9:49 a.m. UTC

Really awesome explanation. cool.. keep up the good work dude..

One suggestion is that whenever you post such articles also place a copy in pdf format of the same for downloads..

Thanks in advance


Kevin (guest)
October 16, 2008 at 1:50 p.m. UTC

Cisco has recently release PSIRTS concerning multicast.

So on the static RP mapping make sure to add override to the end.

ip pim rp-address x.x.x.x multicast override


Abou (guest)
October 16, 2008 at 4:14 p.m. UTC

Can you explain/clarify how you pick which router to be the RP?

also you note that multicast will learn from the unicst forwarding table. is it protocol dependent? ie eigrp but not ripv1 or bgp but not ospf?? does that matter?

thanks


stretch
October 16, 2008 at 4:25 p.m. UTC

@Abou: The RPs are typically routers centrally located in the network. Rest assured I plan to cover PIM-SM and RPs in much greater detail in future posts.

Also, PIM relies on the unicast routing table only for RPF checking; the multicast routing table is built by PIM itself.


Ak (guest)
October 18, 2008 at 4:04 a.m. UTC

Simply Awesome. Right when i needed it. I was fiddling with an Anycast issue yesterday for a client. I don't have good exposure to multicast. Would appreciate a brief overview on anycast....cheers mate...


kerwin (guest)
October 19, 2008 at 5:18 p.m. UTC

All I can say is really appreciate and damn good hoping to c more from u ......


Luís (guest)
May 29, 2009 at 6:57 p.m. UTC

I understand that an initial flood is needed. What I don't understand is why does it repeat it every 3 minutes. Can someone explain? Thanks


Dimas (guest)
December 29, 2009 at 3:06 p.m. UTC

Good explanation, I hope to see more post about IP Multicast... Congratulations


welshydragon
February 25, 2010 at 11:11 a.m. UTC

With later release of IOS PIM-DM has a new optimisation called state-refresh which is enabled by default. This is designed to prevent the flood of multicast every 3 minutes. State-refresh works by sending a control message down the source based tree which resets the prune state in the outgoing interface list. This means that routers who do not have any receivers for a particular group do not have to wait for the flood and prune.


fsohail (guest)
April 29, 2010 at 6:26 p.m. UTC

Simply great lecture


ashmar (guest)
May 9, 2011 at 10:39 a.m. UTC

Supercool explanation. Thank you sir


Sid (guest)
December 12, 2011 at 10:17 a.m. UTC

Excellent..


parthiban
March 11, 2013 at 7:51 a.m. UTC

wonderful


Jazz (guest)
April 23, 2013 at 10:55 p.m. UTC

Tks !!

Comments have closed for this article due to its age.