CCNP Enterprise Core (350-401) Cisco Routing

PIM Sparse Mode

PIM sparse mode was designed for networks where multicast receivers are sparsely located across subnets on the network. PIM spare mode also works quite well in dense multicast receiver environments too.

PIM sparse mode uses the unicast routing table to carry out reverse path forwarding checks, and can utilise any routing protocol that populates the unicast routing table – it is protocol independent.

Sparse mode utilises an explicit join model where the host receivers need to send an IGMP join to their local connected router, known as the last hop router.

This join causes the last hop router to send a PIM join upwards towards the rendezvous point router on the network. If the last hop router knows the rendezvous point of the multicast group, it can send the join request towards that router. If the last hop router does not know the IP address of the rendezvous point, the join request will travel hop by hop, building a branch towards the rendezvous point to discover it

The multicast forwarding state is created through these explicit joins. It works in the opposite way of a flood and join where routers need to explicitly state that they wish to receive a multicast stream.

When a multicast source begins sending traffic, the source needs to send that traffic towards the rendezvous point router. The rendezvous point router sends traffic onwards towards the next router where a receiver is located, working its way down the tree.

CCNP Enterprise Core (350-401) Cisco Revision Topics Routing

PIM Shortest Path Tree Switchover

PIM sparse mode allows the last hop router to switch from the shared tree to a shortest path tree for a specific source.

This is a default behaviour in Cisco routers and happens after the first multicast packet is received from the rendezvous point from the shared tree, even if the shortest path is through the rendezvous point.

When the last hop router receives the first multicast packet from the rendezvous point, it will become aware of the IP address of the multicast source. The last hop router will check its unicast routing table to see where the shortest path is to the source. It will send a (S,G) PIM join hop-by-hop to the first hop router to form a shortest tree path.

If the shortest tree path upstream is out of an interface that is not currently the reverse path forwarding interface, it will send a PIM prune message to the rendezvous point through the existing RPF interface, and change the RPF interface to the interface that is part of the shortest path tree towards the source of the multicast stream. The pruning of the branch helps stop duplicate traffic from reaching the last hop router from multiple directions.

After the pruning, if the rendezvous has no other interfaces that are interested in receiving the multicast traffic, it will send a prune message towards the direction of the first hop router. If there are routers between the rendezvous point and the first hop router, they will travel along their interfaces.

CCNP Enterprise Core (350-401) Cisco Routing

Multicast Source Sparse Mode Registration

When the source for the group sends a packet, the first hop router attached to that source is required to register the source with the rendezvous point. The rendezvous point is also requested to build a tree back towards the first hop router.

The first hop route encapsulates multicast data from the source into a special PIM sparse mode registration message, and that data is unicasted towards the rendezvous point.

When the rendezvous point receives the registration message, it will decapsulate the multicast data from inside the register message. If there are no active shared trees due to there being no interested receivers in that multicast stream, the rendezvous point will send a message to the first hop router requesting that the register messages are stopped directly, without making use of the encapsulation through a PIM tunnel.

If there is an activate shared tree a already for the group, it will forward the multicast packet down the shared tree, and a (S, G) is sent back towards the source to create a (S, G) shortest path tree.

If there are multiple hops along this path between the rendezvous point and the source of the multicast, each router will create a (S, G) state along the branch, including the rendezvous point.

Once a shortest path tree is built, multicast traffic will flow between the source of the multicast and the rendezvous point.

With the flow of data beginning between the source of the multicast and the rendezvous point, a register stop message is sent to the sources first hop router to indicate that the unicast register messages no longer need to be sent to the rendezvous point. Multicast traffic is flowing down the shortest path tree towards the rendezvous point and onwards down the shared tree to the receiver.

The PIM register tunnel from the first hop router to the rendezvous point will always remain in an active up/up state even if there are no multicast streams; it will remain active as long as there is a valid reverse path forward for the rendezvous point

CCNP Enterprise Core (350-401) Cisco Routing

PIM Dense Mode

PIM dense mode constructs the multicast tree by flooding traffic out of every interface from the source to every dense mode router across the network.

PIM dense mode is a suitable configuration where receivers of the multicast group are located across every subnet on the network. It is applicable to small networks, but not recommended for larger production environments.

As each router receives traffic for the multicast group, at which point the router must decide whether to forward the traffic on to any receivers further downstream or to send a prune message towards the source.

When a prune message is sent towards the source, the branch of that tree is cut off so unnecessary multicast traffic is not send towards that router.

The multicast tree grows from the root towards the leaves (routers). Each router receives the multicast traffic from their upstream neighbour through its reverse path forwarding (RPF) interface. That router forwards the multicast traffic to all its PIM dense mode neighbours.

It can mean that multicast traffic arrives on non RPF interfaces and is discarded. Traffic arriving on non RPF interfaces is normal for the initial flooding of multicast traffic, and is gradually corrected with the destination router sending pruning messages back towards the source.

Pruning is sent out via RPF interfaces to indicate upstream that there are no hosts that are interested in receiving the multicast source. Non-RPF interfaces can sent out pruning messages too to indicate that they are interfaces not meant to be receiving multicast traffic.

Pruning expires after three minutes in PIM dense mode. This will cause multicast traffic to be flooded back down the same link, the same as when the initial set-up was established. A new pruning message be sent in response if there are still no interested hosts in receiving the stream.

CCNP Enterprise Core (350-401) Cisco Routing

PIM Operating Modes

There are five operating PIM modes:

  1. PIM Dense Mode (PIM-DM)
  2. PIM Spare Mode (PIM-SM)
  3. PIM Spare Dense Mode
  4. PIM Source Specific Multicast (PIM-SSM)
  5. PIM Bidirectional Mode (Bidir-PIM)

PIM Control messages are sent using IP Protocol 103. Register and register stop messages can be sent using unicast, or multicast with a time-to-live of 1 to all PIM routers at address

IDTypeDestinationPIM Protocol
0Hello224.0.0.13 (all PIM routers)PIM-SM, PIM-DM, Bidir-PIM, SSM
1RegisterRP address (Unicast)PIM-SM
2Register StopFirst-hop router (Unicast)PIM-SM
3Join/prune224.0.0.13PIM-SM, Bidir-PIM, SSM
4Bootstrap224.0.0.13PIM-SM, Bidir-PIM
5Assert224.0.0.13PIM-SM, PIM-DM, Bidir-PIM
8Candidate RP AdvertisementBootstrap router (BSR) address (Unicast)PIM-SM, Bidir-PIM
9State Refresh224.0.0.13PIM-DM
10DF Election224.0.0.13Bidir-PIM
Control Message Types for PIM

Hello messages are sent every 30 seconds out PIM-Enabled interfaces.

Hello messages serve other purposes such as to elect a designated router and to form additional features.

CCNP Enterprise Core (350-401) Cisco Revision Topics Routing

PIM Terminlogy

Reverse Path Forwarding (RPF) Interface

The reverse path forwarding interface is the interface with the lowest cost path to the IP address of the root of the shortest path tree (the source of the multicast stream).

The lowest cost is based on the factors of administrative distance and metric. If there are multiple interfaces with the same cost, a tiebreaker is carried out with the interface of the highest IP address elected as the preferred path.

RPF Neighbour

The RPF neighbour is the PIM neighbour on the RPF interface.


Upstream works towards the source of the tree. This can be towards the source of the multicast traffic in a shortest path tree or towards the router rendezvous point in a shared tree.

Upstream Interface

The upstream interface is the interface towards the source of a tree. It cna be known as the RPF interface or an incoming interface.


Downstream is away from the source of the tree towards the receiving host.

Downstream Interface

A downstream interface is an interface that is used to forward multicast traffic towards the receiving hosts.

Incoming Interface (IIF)

An incoming interface accepts multicast traffic coming from a source of multicast traffic. It is the same as an RPF interface.

Outgoing Interface (OIF)

An outgoing interface is used to forward multicast traffic down the tree towards the receiving hosts.

Outgoing Interface List (OIL)

An outgoing interface list is a collection of outgoing interfaces that are forwarding multicast traffic to the same group.

Last Hop Router (LHR)

The last hop router is the router that is directly attached to receiving hosts. It is also known as the leaf router. It sends PIM joins upstream towards the rendezvous or the source.

First Hop Router (FHR)

The first hop router is directly attached to the multicast source. It is also known as the root router. It sends register messages towards the rendezvous point.

Multicast Routing Information Base (MRIB)

The multicast routing information base is a topology table, also known as the multicast route table, or mroute. The multicast routing information base contains the source S, group G, incoming interfaces, outgoing interfaces, and reverse path forwarding for each multicast router.

Multicast Forwarding Information Base (MFIB)

The multicast forwarding information base contains multicast forwarding information to make forwarding faster through hardware.

Multicast State

The multicast forwarding state is used by a router to forward multicast traffic. It is composed of entries found in the mroute table (S, G, IIF, OIF)

CCNP Enterprise Core (350-401) Cisco Revision Topics Routing

PIM Distribution Trees

A multicast router will create a distribution tree that will define the path multicast traffic follows to reach receiver devices.

There are two types of multicast distribution trees known as source trees. They are also known as shortest path trees, SPTs and shared trees.

Source Tree

A source tree is a multicast distribution tree where the source of the multicast stream is the root of the tree. There are branches that form a tree through the network to the receivers.

When the source tree has been built, it will utilise the shortest path from the source of the multicast traffic to the destination hosts. This is where the source tree gets the definition: shortest path tree.

The shortest path tree uses a forwarding state, known as (Source, Group), or (S, G).

The source is the sender of the multicast packets, or the source of the packet flows. The group is the multicast group address.

Since shortest path trees begin at the source of the multicast stream, every sending source requires to have a shortest path tree.

Shared Tree

A shared tree is a multicast distribution tree where the root is not at the source of the multicast stream. The root of source tree is defined at a router known as a rendezvous point, or RP.

Shared trees can also be known as RP trees (RPT) due to this characteristic.

Multicast traffic are forwarded down the shared tree according to the group address that the packets are addressed too, regardless of the source address.

The forwarding state of a RPT is known as (*, G)

Shared trees require fewer multicast entries. If more sources are introduced utilising the same multicast group, it will not require a separate entry in a shared tree as it would in a shortest path tree.

This advantage also works to the shared trees disadvantage. All receiver hosts in the shared tree will receive traffic sent by any host to the multicast group address. This can generate a lot of unwanted network traffic.

Without the policing of the source address in a shared tree, this can introduce a security issue – as any host can send data to the shared multicast address.

CCNP Enterprise Core (350-401) Cisco Routing

PIM – Protocol Independent Multicast

Hosts utilise IGMP to join a multicast group, this works perfectly fine when the router that the membership join request gets sent to also hosts the subnet that sends out the multicast traffic flows.

If the receiving host and the multicast source router are several hops apart, routing between the routers will need to be accounted for. There are many different multicast routing protocols, but Cisco supports PIM – Protocol Independent Multicast.

PIM is a multicast routing protocol that routes multicast traffic between network networks. PIM can utilise any of the traditional unicast routing protocols to identify a path the destination hosts and the source device.

CCNP Enterprise Core (350-401) Cisco Routing

IGMP Snooping

IGMP snooping is a method that allows switches to only send traffic to interested receivers of multicast packet streams.

IGMP snooping helps switches to optimise forwarding and minimise flooding of multicast streams to all connected ports on their device.

Typically with unicast traffic, switches learn about MAC addresses and where they belong to by inspecting the MAC address source of traffic traveling through the switch. These MAC addresses are then stored in a MAC address table for future reference for more efficient transfer of traffic.

When it comes to multicast traffic, the multicast MAC address is never used as a source MAC address. Typically without IGMP snooping a switch will treat a multicast MAC address as an unknown frame and flood it out of all ports on the switch. It is then up to the connected devices themselves to spend processing time to decide whether to accept or discard the traffic. Cisco switches can utilise two methods to reduce the multicast flooding on a local area network: IGMP snooping and static MAC address entries.

IGMP snooping, as part of RFC 4541, is the most widely used method over the alternative, static MAC address entries. IGMP snooping works by the switch monitoring IGMP joins sent by the hosts and maintaining a list of interfaces to IGMP joins, similar to a MAC address table.

When a switch receives a multicast frame destined for a particular group, the switch can look up its IGMP snooping table and set the traffic destination accordingly.

The alternative, static MAC address entries means programming static multicast entries into the MAC address table. This solution is nowhere near as scalable and dynamic as IGMP snooping.

CCNP Enterprise Core (350-401) Cisco Routing

IGMP Version 3

When a host in IGMPv2 sends a membership report to join a multicast group, it does not specify the source that it would like to receive the multicast traffic from.

IGMPv3 is an extension on top of IGMPv2 that adds support for the multicast source filtering, giving the host a choice to pick the source they wish to accept multicast traffic from.

IGMPv3 can co-exist with both IGMPv2 and IGMPv1

IGMPv3 also supports all of IGMPv2s messages, being backwards compatible with version 2.

There are differences between the versions: New added fields and a new IGMP message type called Version 3 Membership Report. The Version 3 Membership Report is to support source filtering.

In IGMPv3, hosts signal membership reports (join requests) to a multicast group address using one of two modes: Include mode or Exclude mode.

The host, in include mode, will announce membership to a multicast address and provide a list of source addresses it is willing to receive traffic from.

In exclude mode, the host will announce membership to a multicast address but provide a list of source addresses it is not willing to receive multicast traffic from. The host will only receive traffic from addresses that are not on the Exclude list.

In a backwards compatibility mode, the host will send an exclude mode membership report but with an empty list. Indicating that it is willing to accept traffic from any source address.