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.
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 (*, 184.108.40.206), 00:07:04/00:02:49, RP 220.127.116.11, flags: SJPL Incoming interface: FastEthernet0/0, RPF nbr 10.0.12.2 Outgoing interface list: Null
In actuality, PIM refers to a family of very similar routing protocols, but which each operate in a different mode. These are:
- PIM Dense Mode (PIM-DM) (RFC 3973)
- PIM Sparse Mode (PIM-SM) (RFC 4601)
- Bidirectional PIM (BIDIR-PIM) (RFC 5015)
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.
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 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 makes use of centralized rendezvous point (RP) routers and purpose-built logical multicast trees (shared and source-based) to achieve end-to-end forwarding.
Bidirectional PIM is an extension of PIM-SM, where multicast traffic can flow in both directions. All sources are potentially receivers as well.
PIM-SM configuration includes three simple steps:
- Enable multicast routing
- Designate a PIM router to act as the rendezvous point (RP)
- 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.
October 16, 2008 at 8:38 a.m. UTC
Great as usual, where do you get all this from?
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" ;)
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
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
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?
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.
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...
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 ......
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
December 29, 2009 at 3:06 p.m. UTC
Good explanation, I hope to see more post about IP Multicast... Congratulations
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.
April 29, 2010 at 6:26 p.m. UTC
Simply great lecture
May 9, 2011 at 10:39 a.m. UTC
Supercool explanation. Thank you sir
December 12, 2011 at 10:17 a.m. UTC
March 11, 2013 at 7:51 a.m. UTC
April 23, 2013 at 10:55 p.m. UTC