PIM crash course

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

(*, 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 Dense Mode (PIM-DM) (RFC 3973)
• PIM Sparse Mode (PIM-SM) (RFC 4601)
• Bidirectional PIM (BIDIR-PIM) (RFC 5015)

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.

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 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.

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.