Protocol Independent Multicast - Sparse Mode (PIM-SM)

Introduction

Protocol Independent Multicast (PIM) is a family of IP multicast routing protocols. While this family include a number of different variants, this document focus specifically on the Sparse Mode (SM) variant.

Note

The system currently only supports PIM-SM.

The central aspect of PIM, regardless of what mode is being utilized, is the Protocol Independent part and what it entails. The PIM protocol itself contains no method or functionality that allow it to perform any from of topology discovery. Instead, PIM relies on the system’s underlying unicast routing table in order to perform Reverse-Path Forwarding (RPF). It is Independent because it does not matter what unicast routing protocol is used by the device to populate its unicast routing table. The unicast routes could be provided by, for instance, using OSPF or RIP. The routes could even by provided by the means of static routes.

For an introduction and overview to multicast in general, refer to the Static Multicast Routing document provided in the link below.

Related Documentation

Related Examples and Use-Cases

Overview

As mentioned PIM is a family of multicast routing protocols that have a few different variants, but this document considers the Sparse Mode only.

As the name hints at PIM Sparse Mode is suitable for use in network topologies where any interested receivers, of any given multicast group, will be sparsely scattered throughout the network. What this really means is that it is expected that the majority of the subnets in the network have no interest in receiving most of the multicast traffic, at least not at the same time.

PIM-SM generally scales pretty well in larger network topologies, as long as the above mentioned condition holds, that most of the subnets in the network are not interested in all of the relevant multicast groups at the same time.

Tip

In direct opposite, to the scenarios that PIM-SM is suitable for, its sibling PIM Dense Mode (PIM-DM) is instead the method that is preferred if you have a smaller scale network with multicast receivers that are densely populated.

However, the operating system currently does not support PIM-DM.

In Table 1 directly below, a number of terms and concepts that are generally used when talking about PIM-SM are briefly summarized. It is good to quickly glance over these, if the reader is interested and/or new to PIM. However, note that this document is not intended to give a full deep dive description of all the inner workings of PIM-SM. It is intended to provide a high level basic understanding of the general characteristics and concept.

Term Shorthand Description
Rendezvous Point RP The central point for a given multicast group, or group range, within a PIM domain. Any receiver or sender for a given multicast group will essentially meet at the RP.
First-Hop Router FHR The first PIM router that is attached to the source of a specific multicast stream. This device starts the register process for any stream that enters on it.
Last-Hop Router LHR The last PIM router that is connected to any receiver that is interested in a specific multicast group.
Designated Router DR The router responsible for forwarding PIM Join messages towards the RP on any given multi-access network.
Multicast Route mroute An IP multicast route, consisting of a specific group and possible source IP of said group. It also specifies one inbound interface and one, or more, outbound interface(s).
S-G mroute (S,G) mroute This is a source-specific multicast route, where S is the source IP of the sender and G is the IP Multicast group, e.g. (192.168.1.1,225.1.2.3).
Star-G mroute (*,G) mroute This is a source-less multicast route, where * indicates that the source IP of the sender could be any address, i.e. it is a wildcard, e.g. (*,225.1.2.3).
Shared Tree, RP Tree or (*,G) Tree RPT The Shared Tree for a specific multicast group originates from the RP, and it has the receiver DR as its leaf node. Each PIM router part of the RPT has (*,G) mroutes installed for the specific group, with the inbound being the interface towards the RP and the outbound towards the receiver DR.
Shortest-Path Tree or (S,G) Tree SPT The Shortest-Path Tree originates from the router directly connected to the source of a given multicast group. A SPT can be formed between the source and the RP and also all the way to the LHR. Each router along the path of the SPT has (S,G) mroutes installed for the given group. The SPT represent the best path that a stream can take from its source to reach any receivers. It is possible that said path intersects along the RPT, but not necessary.
Reverse-Path Forwarding RPF Reverse-Path Forwarding is performed by consulting the unicast routing table in order to find the expected interface towards a specific source IP address. This is for instance used in order to find the path to the RP or to the source of a specific multicast stream.
Downstream - Direction towards the multicast receiver(s).
Upstream - Direction towards the multicast sender(s).

Table 1: Brief overview and description of some relevant terms and concepts central to PIM-SM.

Control Messages

PIM-SM utilize a number of different control messages in order to function. In Table 2 below the most relevant types of messages are briefly summarized:

Message Destination Description
Hello All PIM Routers (224.0.0.13) Hello messages are transmitted on all the configured PIM interfaces on the device. The messages serve to announce to the other PIM routers on the subnet that the source sender is also a PIM router. The Hello messages are also used to elect which of the routers on the subnet should serve as the DR.
Register Rendezvous Point (Unicast) Message sent towards the RP from a FHR in order to inform it that a specific multicast stream is now present. The register frame contain the entire multicast frame encapsulated within it. If the RP has any receivers that have joined for the specific group, the encapsulated frame will be forwarded towards them.
NULL Register Rendezvous Point (Unicast) A special register frame that is sent from the FHR towards the RP, the purpose of this frame is to inform the RP that a specific multicast stream is still available. A NULL Register frame will not encapsulate the multicast frame.
Register-Stop FHR, source of the Register (Unicast) Sent by the RP back towards the originating FHR router, when it is no longer necessary to continue sending register frames towards the RP.
Join/Prune (J/P) All PIM Routers (224.0.0.13) Sent by a PIM router to indicate if a specific multicast group wants to be received (Joined) downstream or if it should not be received anymore (Pruned). It is normal to refer to simply Join or Prune as individual message types, even though they are in fact a single type of message. A Join/Prune message could be either a (*,G) Join/Prune, for the RPT, or a (S,G) Join/Prune, for the SPT.

Table 2: A list of some relevant PIM control messages.

IGMP messages are also vital for the operation of PIM. The PIM join process will be initiated when a PIM router receives an IGMP Membership Report (IGMP Join). When received, the PIM router will generate a (*,G) Join message and send it along the RPT towards the RP.

When an IGMP Leave is received on a PIM router a (*,G) Prune will be generated instead, and sent on the path towards the RP.

Reverse-Path Forwarding

PIM relies on unicast routing to perform RPF in order to figure out what interface some PIM control messages will be transmitted on and to verify that multicast frames enter on expected interfaces. This can be referred to as a RPF Interface.

In other words, an underlying unicast routing setup is required for PIM to be able to function. As mentioned earlier, the independent part of Protocol Independent Multicast is that any unicast routing protocol can be used, even static routes. As long as the routing table is populated correctly so the RPF can be performed.

Tip

The operating system support both the OSPF and RIP unicast routing protocols.

Warning

A default route cannot be used to perform a RPF lookup. Instead provide a specific static route if this is necessary.

RPF is used in order to handle PIM Join/Prune messages to build Shared Trees (RPT) and Shortest-Path Trees (SPT):

  • The RPT is constructed by means of (*,G) Join/Prune messages. The router will find the outbound interface based on the source address for the RP. The source of the RP will always be known, since each PIM router needs to have it configured. When the outbound interface is determined, the Join will be transmitted on that interface.

  • The SPT is constructed by means of (S,G) Join/Prune messages. For a (S,G) Joins/Prune the location of the source is known. So in this case an RPF lookup is performed for said source in order to determine the outbound interface where the Join will be transmitted.

RPF is also performed in order to ensure that multicast traffic from a given source enter the device on the expected interface, in order to prevent any multicast routing loops. If a multicast frame enter on an unexpected interface the frame is discarded. The check is slightly different depending on the tree state of the router:

  • SPT: If the router has a (S,G) mroute installed for the source of the given multicast frame, the RPF check is performed on the source address of said multicast frame.

  • RPT: If the router only has a (*,G) mroute installed matching the group of the received multicast frame, the RPF check is performed on the IP address of the RP.

Interfaces

Each PIM router in the network must specify all the interfaces that PIM should operate on. All the following interfaces must be known to PIM:

  • Interfaces connected to other PIM routers, so that they can form neighbor relationships with each other.
  • Interfaces connected to any potential multicast receiver.
  • Interfaces connected to any potential multicast sender.
  • The interface where the RP is located (The interface with the IP address corresponding to the configured RP IP address), if the device is intended to serve as a RP.

Note

Interfaces facing receivers must also have IGMP enabled. This is a separate setting from the interface option that exist in the PIM Router configuration. Ensure that it is enabled on relevant interfaces.

Currently the system allows the following interface types to be used as PIM Interfaces:

  • VLAN
  • Loopback (lo)

Neighbor Formation

Each PIM router transmit PIM Hello messages to the link-local multicast address 224.0.0.13 (All PIM Routers), in order to inform other potential PIM routers on the same network that it exist. These messages are transmitted continually on a set interval that is default 30 seconds, but can be adjusted if desired.

Any PIM router that receives a PIM Hello frame will add the source sender of the message as a PIM neighbor. There is no acknowledge process or anything similar. A device will keep a neighbor until it expires or as long as it continues to receive Hello messages. As shown in Figure 2 below, all the PIM routers on the same subnet will consider each other as neighbors, not just the directly adjacent router.

Neighbors in 10.0.0.0/24                                    Neighbors in 10.1.0.0/24
. . . . . . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . .
.                                                 .    .                           .
. .--------.             .--------.             .--------.             .--------.  .
. |        | 10.0.0.0/24 |        | 10.0.0.0/24 |        | 10.0.1.0/24 |        |  .
. |   R1   +-------------+   R2   +-------------+   R3   +-------------+   R4   |  .
. |        | .1       .2 |        | .2       .3 |        | .3       .4 |        |  .
. '--------'             '--------'             '--------'             '--------'  .
.                                                 .    .                           .
. R1 Hello  ------------► -------► ------------►  .    .                           .
. R2 Hello  ◄------------          ------------►  .    .                           .
. R3 Hello  ◄------------ ◄------- ◄------------  .    .  ------------►            .
. R4 Hello                                        .    .  ◄------------            .
. . . . . . . . . . . . . . . . . . . . . . . . . .    . . . . . . . . . . . . . . .

Figure 2: A group of PIM routers and their neighbor relationships. The routers R1, R2 and R3 in subnet 10.0.0.0/24 all form neighbors with each other, not just the directly adjacent routers. Router R3 also form a neighbor relationship with router R4 located in another subnet 10.1.0.0/24.

The neighbors for a subnet elect one of them to serve as the Designated Router (DR) and be the router responsible for the communication with the RP. For instance, if any of the routers have a connected device requesting a multicast stream it is the responsibility of the DR to send a PIM Join for that group towards the RP.

The election process of the DR is based on the priority that is included in the Hello message. By default the value is 1, but can be adjusted if desired. If the best priority value is shared by multiple neighbors the DR is elected based on the router with the highest IP address.

Modes of Operation

PIM-SM also have a few different modes of operation:

  • Any Source Multicast (ASM): Is as the name suggests, a mode where multicast streams originating from any source can be received and handled within the PIM domain. When ASM is used the configuration of Rendezvous Points becomes necessary. In this mode it is also not necessary for the potential receivers to know the source of the senders for interested multicast streams.
  • Source Specific Multicast (SSM): In this mode it is required that all the receivers know beforehand where the sender of a specific multicast group is located. When SSM is used it is not necessary to configure any RPs within the PIM domain. However, IGMPv3 is mandatory on the multicast clients because it includes support for (S,G) IGMP reports (join).

One way to look at the differences between SSM and ASM, is that with SSM the receiver knowns exactly what it wants to receive and from who. But with ASM the receiver only know what it wants to receive, but not necessarily who is the one that will provide it.

Note

As of right now the operating system supports only the ASM mode.

PIM-SM With Any Source Multicast

In PIM-SM ASM the potential receivers does not need to know the sources of any of the multicast that they may want, the receivers can simply join a group and if any traffic for that group is being transmitted, it will be forwarded towards the receiver.

However, as mentioned earlier, in the ASM mode one ore more Rendezvous Points need to be specified. All routers that constitute the PIM domain must be aware of the location of the RP. What this means is that they must be configured in the same manner in this regard.

In Figure 1 below we have an example representation of a simple PIM-SM ASM setup. With R4 acting as the RP for the PIM domain. All the routers will be individually configured to know that the router R4 is the acting RP.

          .----. (Receiver)             .----. (Receiver)
          | H1 |                        | H2 |
          '-+--'                        '--+-'
            |                              |
            |                              |
  (LHR) .---+----.                    .----+---. (LHR)
   (DR) |        |                    |        | (DR)
        |   R1   +--------------------+   R2   |
        |        |                    |        |
        '---+----'                    '----+---'
            |                              |
            |                              |
            |                              |
            |                              |
            |                              |
  (FHR) .---+----.                    .----+---. (RP)
        |        |                    |        |
        |   R3   +--------------------+   R4   |
        |        |                    |        |
        '---+----'                    '--------'
            |
            |
          .-+--. (Sender)
          | S1 |
          '----'

Figure 1: A simple example of a PIM-SM setup using the ASM model.

Various other settings can also be adjusted depending on the specifics of a given setup, but may not be necessary. However, the above mentioned must always be configured for operation to ensue.

Receiver Joins

When a receiver wants to join a given group it will start by sending a IGMP Membership Report indicating that it wants traffic from the specific group. This IGMP Report will find its way to the receiver-side DR for the specific subnet, and it will become the LHR for that specific group.

The now LHR will first add a (*,G) mroute entry to its multicast routing table, where the outbound interface will be the interface the IGMP Membership report was received on, and the incoming interface being the RPF interface for the RP.

The next step is that the LHR will generate a PIM Join message that will be transmitted towards the RP for the given group. This message will be forwarded hop by hop until it reaches the RP. Each router along this path will also install a (*,G) mroute into its multicast routing table. Similar to the LHR, the outbound interface will be the receiving interface of the Join, and the inbound will be the RPF interface towards the RP. A simplistic illustration of this process can be seen in Figure 3 below.

                                                    (DR)
(RP)                      (Intermediate)            (LHR)
.--------.                .--------.                .--------.
|        | vlan1    vlan2 |        | vlan1    vlan2 |        | vlan1          .------.
|   R4   +----------------+   R2   +----------------+   R1   +----------------+  H1  |
|        |                |        |                |        |                '------'
'--------'                '--------'                '--------'
          ◄---------------          ◄---------------          ◄---------------
           PIM Join/Prune            PIM Join/Prune            IGMP Report
           Join: (*,225.1.2.3)       Join: (*,225.1.2.3)       Join: 225.1.2.3


                          Add mroute on R2:         Add mroute on R1:
                           (*,225.1.2.3)             (*,225.1.2.3)
                            in vlan2 out vlan1        in vlan2 out vlan1

Figure 3: A simplified overview what happens when host H1 start to request a specific multicast group 225.1.2.3. From the initial IGMP Report that reaches the receiver side DR, PIM Join messages will be generated and transmitted towards the known RP. Along the way (*,225.1.2.3) mroutes are installed in routing tables of the routers, this forms the RPT.

In the example provided by Figure 3 no mroute is installed on the RP. In this case the multicast stream for 225.1.2.3 is not yet active and known by the RP. If the stream was already active and known by the RP it would install a (S,G) mroute for 225.1.2.3, with the inbound interface being set to the one where the stream is registered, and the outbound interface to vlan1 (Towards the receiver).

All of these installed (*,G) routes on the path from the LHR to the RP together constitute the so called RPT (Shared Tree). As can be seen in Figure 4 the RPT is always rooted at the RP with the DRs, with active receivers, as the leaf nodes. The example setup is similar to the one presented earlier in Figure1.

          .----. (Receiver)             .----. (Receiver)
          | H1 |                        | H2 |
          '-+--'                        '--+-'
            |                              |
            |                              |
  (LHR) .---+----.                    .----+---. (LHR)
   (DR) |        |                    |        | (DR)
        |   R1   +--------------------+   R2   |
        |        |                    |        |
        '---+----' ◄----------------- '----+---'
            |             RPT         ▲    |
            |                         |    |
            |                     RPT |    |
            |                         |    |
            |                              |
  (FHR) .---+----.                    .----+---. (RP)
        |        |                    |        |
        |   R3   +--------------------+   R4   |
        |        |                    |        |
        '---+----'                    '--------'
            |
            |
          .-+--. (Sender)
          | S1 |
          '----'

Figure 4: Example how the RPT looks when the host H1 has requested a specific group. The RPT is always rooted at the RP that is responsible for the given group that the receiver has joined.

Multicast Stream Registration

The goal of the multicast stream registration process is to inform the relevant RP that a specific multicast stream is now present and available on the network for any potential receivers.

The process is started when a FHR receives a multicast frame from a sender on any of its configured PIM interfaces. The FHR encapsulates the multicast data in a PIM Register frame, this frame is subsequently sent towards the RP as a unicast frame, as shown in Figure 5. As any other PIM router the FHR also knowns the IP address of the relevant RP beforehand.

(Source)                (FHR)                     (RP)
                        .--------.                .--------.
.------.                |        |                |        |
|  S1  +----------------+   R3   +----------------+   R4   |
'------'                |        |                |        |
                        '--------'                '--------'
        ---------------►          ---------------►
        Multicast Stream          Register (UC)

Figure 5: Simplified view how the register process is started. The sender S1 starts to transmit a multicast stream. When this stream enters the FHR R3 it will send a PIM Register frame as unicast towards the RP.

When the RP receives a PIM register frame two scenarios are possible. Either a receiver is already requesting the specific multicast group downstream, or it is currently not requested by anyone potential receiver.

Stream Already Requested Downstream

When the RP receives the Register message it will decapsulate the message to obtain the included multicast frame. If the destination group of said frame is already requested downstream the RP will transmit the frame along the RPT towards the intended receiver.

At the same time the RP will add a (S,G) mroute to its routing table. The RP then sends a PIM (S,G) Join towards the source, the FHR, for the multicast stream. Each router along the way to the FHR install a (S,G) mroute in their routing tables. Together this will constitute the SPT, for the specific sender and the group, between the sender and the RP. An example of this is shown in Figure 6.

(Source)                (FHR)                     (RP)
                        .--------.                .--------.
.------.          vlan2 |        | vlan1    vlan2 |        | vlan1   225.1.2.3 joined
|  S1  +----------------+   R3   +----------------+   R4   +-------- Downstream
'------'                |        |                |        |
192.168.1.99            '--------'                '--------'
                                  ◄-----------------
                                   PIM Join/Prune
                                   Join: (192.168.1.99,225.1.2.3)


                        Add mroute on R3:         Add mroute on R4:
                         (192.168.1.99,225.1.2.3)  (192.168.1.99,225.1.2.3)
                         in vlan2 out vlan1        in vlan2 out vlan1

Figure 6: The RP sends a (S,G) Join back towards the source, so that all the routers on that path adds a (S,G) mroute in their routing tables. Doing this creates the SPT between the source and the RP.

When the SPT has been constructed multicast traffic will start to flow and be routed towards the RP. Therefore, the encapsulated multicast frames will no longer be needed. So when the RP receives the multicast stream along the SPT it will send a Regsiter-Stop message towards the FHR, instructing it to stop sending encapsulated register frames.

When the FHR have received a Register Stop frame it will start a Register Stop timer. Before this timer expires the FHR will send a NULL Register towards the RP. If the current state is to be maintained the RP will send another Register-Stop message back. If the timer is allowed to expire, the FHR will again start to encapsulate the multicast traffic in Register messages.

Warning

Currently a problem exist where the encapsulated frames may not be decapsulated and forwarded correctly from the RP. What this means is that the multicast traffic will not start to flow until the RP has sent the (S,G) Join towards the sender, that will allow it to add a (S,G) route towards the RP for the concerned group. Since the RP perform this action as soon as it receives a register for a group that is requested downstream, the traffic should start to flow almost immediately anyway.

Stream Not Currently Requested

When the RP receives the Register frame but there are currently no interested receivers for the encapsulated multicast frame, the RP will drop the frame, since there is no RPT to send it along. At the same time the RP will directly send a Register-Stop frame towards the source FHR, to instruct it that it should not continue to send any encapsulated Register frames.

When the FHR receives the Register-Stop the multicast stream will be dropped at the FHR. If a receiver requests the specific group at this point the RP will send a PIM Join directly towards the FHR so that the SPT can be constructed and the traffic can start to flow.

During this time the FHR will periodically send NULL Register frames towards the RP, in order to inform it that the stream is still active. If the stream disappears the Register will timeout after the Keep alive Time expires.

Switchover to SPT on LHR

Initially when multicast traffic arrive at the LHR it will do so over the RPT. However, this may not be the optimal path for the multicast stream to take through the network. Therefore a so called SPT switchover is performed. An example of this is presented in Figure 7 below.

               .----. (Receiver)             .----. (Receiver)
               | H1 |                        | H2 |
               '-+--'                        '--+-'
                 |      (S,G) Prune             |
                 |      -----------------►      |
             .---+----.                    .----+---.
             |        |                    |        |
             |   R1   +--------------------+   R2   |
             |        |                    |        |
             '---+----' ◄----------------- '----+---'
           |     |    ▲        RPT         ▲    |     |
           |     |    |                    |    |     |
(S,G) Join |     |    | SPT            RPT |    |     | (S,G) Prune
           |     |    |                    |    |     |
           ▼     |                              |     ▼
             .---+----.                    .----+---.
             |        |                    |        |
             |   R3   +--------------------+   R4   |
             |        |                    |        |
             '---+----'                    '--------' (RP)
                 |
                 |
               .-+--. (Sender)
               | S1 |
               '----'

Figure 7: The SPT switchover process initiated from the LHR R1 towards the FHR R3. R1 will send a (S,G) Join towards R3 to create the SPT. It will then also send a (S,G) Prune to stop the transmission of the multicast stream along the RPT

Before the switchover can be completed the SPT needs to be constructed. In order to do this the LHR sends a PIM (S,G) Join message towards the source. The outbound interface for this (S,G) Join is obtained by a Reverse-Path Forwarding lookup. This process is initiated the instant the LHR receives any multicast traffic along the RPT.

The SPT between the source and the LHR is constructed in the same manner as the SPT between the Source and the RP, described earlier. Each router along the path will install a (S,G) mroute in their routing tables, where the incoming interface will be the RPF interface towards the Source, and the outbound the interface the Join was received on.

Subsequently, when multicast traffic starts to flow along the newly established SPT a PIM (S,G) Prune message will be sent along the RPT towards the RP. This should stop the multicast stream from also being transmitted along the RPT, so that it now only uses the SPT instead.

Note

As long as spt-switchover is enabled the SPT will always be created this way, even if it is along the RPT.

At this point the traffic is flowing as efficiently as it can by using the shortest path through the network from the source to the receiver.

Configuration

Configuration of PIM-SM is primarily performed under the router context, containing most of the options. Further, PIM-SM also possess a number of settings related to the individual interface(s) it is set to operate on.

Warning

Due to an existing problem, it is currently not possible to use a configuration that combines any static multicast routes with PIM. If both are configured at the same time, PIM will take precedence.

Enabling Multicast Forwarding

In order for any multicast routing to be useable on the system, including PIM-SM, multicast-forwarding must be enabled. This setting is disabled by default and is enabled in the following manner:

example:/#> configure
example:/config/#> ip
example:/config/ip/#> multicast-forwarding
example:/config/ip/#>

Note

It is still possible to configure PIM-SM, but if multicast-forwarding is not enabled a valid functional PIM-SM configuration will NOT be generated and applied.

Router Configuration

Configuration of PIM-SM is performed within the pim sub-context located under the router section in the global configuration context.

example:/#> configure
example:/config/#> router
example:/config/router/#> pim
example:/config/router/pim/#>

Note

Currently, since only Sparse Mode (SM) is the available mode, no other mode can be selected for PIM. It will therefore always default to be SM.

[no] enable

Enable or disable pim.

Default: Enabled

Example

example:/config/router/pim/#> enable
example:/config/router/pim/#> no enable

no
Use to disable PIM.
[no] rendezvous-point ADDR [GROUP/LEN]

Configure static Rendezvous Point(s) (RP).

A necessity for PIM to be able to operate is that at least one Rendezvous Point (RP) exist, and that its location is specified here. The RP is necessary in order for the PIM routers to know where to send any Join messages and Register messages towards.

Currently the only supported manner in which RPs can be configured is using the static approach.

In order to configure a static RP the IP address where the RP is located must be provided. Further, it is possible to specify a network prefix for specific multicast groups to match on for this RP.

If no network prefix is provided for multicast group matching, any will match, i.e. it would be the same as 224.0.0.0/4.

It is possible to provide up to 128 different RP specifications.

Note

When static RPs are utilized it is important that the configuration is the same for all of the PIM routers that constitute the PIM domain.

Default: None

Alias: rp

Example

example:/config/router/pim/#> rendezvous-point 10.0.1.1 225.1.2.0/24
example:/config/router/pim/#> rendezvous-point 10.0.2.1

no

Remove all configured rendezvous points:

example:/config/router/pim/#> no rendezvous-point

Alternatively, remove a specifically configured rendezvous point, providing either the full value or the numeric ID of the entry.

example:/config/router/pim/#> no rendezvous-point 10.0.1.1 225.1.2.0/24
example:/config/router/pim/#> no rendezvous-point 1

ADDR
IP address in standard quad-dotted notation, e.g. 192.168.1.1.
GROUP/LEN
IP multicast group in standard quad-dotted notation including netmask in CIDR notation, e.g. 225.1.2.0/24.
[no] interface [IFACE [IFACE...]]

Specify the interface(s) on which to enable PIM to operate on.

PIM must be enabled to operate on any interface that faces any multicast sources (senders) or destinations (receivers). The interface on which the Rendezvous Point (RP) is configured must also be specified.

Any intermediate PIM router, that does not directly face a multicast sender or a receiver, must also specify the interfaces where its PIM neighbors will be located.

This setting will NOT enable receiving of IGMP reports, or querying on the provided interfaces. This configuration is handled individually for each specific VLAN, under each individual VLAN context.

More PIM related interface configuration options can be found under the configuration context for each individual interface, under the PIM sub-context.

Note

The selection of at lest one PIM interface is mandatory in order to activate the service.

Default: None

Alias: iface

Example

example:/config/router/pim/#> interface vlan1
example:/config/router/pim/#> interface vlan1 vlan2

no
Remove all or a specifically configured interface.
IFACE
Name of the interface, e.g. vlan1.
[no] passive-interface

Control if PIM should be passive on all interfaces by default.

This setting simply controls what the default, auto mode, will mean for the individual pim interface(s). Each interface can have this value explicitly set under their own PIM configuration sub-context.

If passive-interface is enabled here it means that no PIM control messages should be handled by the interface(s) by default, i.e. no sending or receiving of any PIM control messages.

Default: no passive-interface, i.e. handling of PIM control messages is the default behaviour on all configured interfaces.

Example

example:/config/router/pim/#> passive-interface
example:/config/router/pim/#> no passive-interface

no
Disable passive interface by default for any configured interface that has not explicitly adjusted it.
[no] keepalive-timer [1-65535]

Set the timeout value for a (S,G) multicast stream.

This is the timeout value, in seconds, for how long the knowledge of a detected (S,G) multicast stream will be kept alive, even in the absence of any (S,G) join messages.

When a PIM router receives a specific (S,G) frame this value is the period of time it will be kept alive, even if no more frames are received. As long as the (S,G) stream is active and frames are received the keep alive timeout will be restarted with this value.

Note

If a value below 31 seconds is selected, be aware that some hardware platforms cannot see data flowing in better than 30 seconds chunks.

Default: 210 seconds

Example

example:/config/router/pim/#> keepalive-timer 100

no
Reset the value of the setting back to its default.
[no] rp-keepalive-timer [1-65535]

Set the RP specific timeout value for a (S,G) multicast stream.

Similar to the keepalive-timer, but specific to the RP. Instead of being started when a (S,G) frame is received, it is started when the RP sends a Register-Stop towards the DR that sent a register for a specific (S,G) stream.

It is important to note that the keepalive timer on the RP must be at least the value of the calculated Register-Stop time. If it is not the RP may age out the group before the next NULL-Register arrives.

The keepalive time for the group is set to the maximum value between the keepalive-timer and rp-keepalive-timer, when the RP sends a Register-Stop towards the DR that registered the group.

Note

If a value below 31 seconds is selected, be aware that some hardware platforms cannot see data flowing in better than 30 seconds chunks.

Default: 185 seconds

Example

example:/config/router/pim/#> rp-keepalive-timer 100

no
Reset the value of the setting back to its default.
[no] register-suppression-time [11-65535]

Set the time value for Register Suppression.

This value is used to calculate the time during which a First Hop Router (FHR) will stop transmitting Register frames towards the RP, after it has received a Register-Stop frame from the RP.

The resulting Register-Stop timer will be set to a random value within the following interval:

  • ((0.5*register-suppression-time),(1.5*register-suppression-time))-5

In order to ensure that this timing value is not calculated to be less than zero, we limit the minimum value that can be set to 11 seconds.

Initially the Register frame from the FHR will contain the multicast payload encapsulated in the frame. But after it has received a Register-Stop from the RP, the subsequent Register frame will be a so called Null-Register. This is the same as a Register, but it will not contain any encapsulated multicast payload.

Default: 60 seconds

Example

example:/config/router/pim/#> register-suppression-time 40

no
Reset the value of the setting back to its default.
[no] join-prune-interval [1-65535]

Set the transmission interval of periodic Join/Prune frames.

A PIM router will periodically send Join/Prune messages toward its upstream PIM neighbors, in order to keep each other updated in regard to which groups are requested (Joined) or not (Pruned) by receivers downstream.

Note

The hold time for Join/Prune messages is not possible to configure individually. It will always be based on this value and it will be set to 3.5x this value, i.e. by default it will be 210 seconds.

Default: 60 seconds

Example

example:/config/router/pim/#> join-prune-interval 40

no
Reset the value of the setting back to its default.
[no] spt-switchover

Enable or disable spt-switchover.

This setting can be relevant, if no Shortest-Path Tree (SPT) switchover is wanted on the last hop router. If disabled only the shared tree (RPT) will be used instead. In other words, no (S,G) routes will be installed on any of the routers on the RPT towards the Rendezvous Point (RP).

When SPT switchover is enabled the last hop router will try to find the optimal, i.e. shortest, path towards the multicast source. If a better path exist this will be used instead of the shared tree (RPT).

The SPT switchover will be initiated on the Designated Router (DR) on the receiver side, as soon as the first multicast frame is received. The DR will at this point send a (S,G) join message towards the source of the multicast frame. Any router along the way will install a (S,G) route in their routing tables, together these routers make up the SPT.

During the switchover process, the DR will start to receive frames from both the RPT and SPT. In order to fully switch to the SPT a prune will be sent towards the RP, informing it that it will not need the specific (S,G) traffic from the RPT anymore.

Note

The SPT switchover can only be disabled on a LHR. The RP will still perform the SPT switchover towards the upstream source regardless of this setting.

Default: Enabled

Example

example:/config/router/pim/#> spt-switchover
example:/config/router/pim/#> no spt-switchover

no
Disable SPT switchover.
[no] register-policy [permit|deny ADDR/LEN [,ADDR/LEN ...]]

Specify if a specific source IP is permitted or denied.

When a PIM router receives a register frame it will perform a lookup of the source address for the frame, against this list of permitted or denied source addresses.

If the source address of the register frame matches any permit entry in the list it will be allowed, and normal operation will ensue. On the other hand, if the source address of a register frame matches a deny entry, the register will be denied. Further, a Register-Stop frame will be sent towards DR, from which the register originated from.

Note

If there are no entries defined in the list no lookup can or will be preformed, hence any source will be accepted.

Note

If no prefix len is provided for the address it will be treated as a /32 address.

Default: None

Example

example:/config/router/pim/#> register-policy permit 192.168.1.0/24
example:/config/router/pim/#> register-policy deny 192.168.1.10/32, 192.168.1.20/32

no
Remove all or a specific entry.
ADDR/LEN
IP address in standard quad-dotted notation including netmask in CIDR notation, e.g. 192.168.1.1/24.
[no] ssm-policy [permit|deny GROUP/LEN [,GROUP/LEN ...]]

Specify a range of group addresses where PIM will permit or deny SM over.

One or more Group ranges can be specified, indicating to PIM if SM should be denied or permitted for any groups that fall within the range.

Note

If no prefix len is provided for the group it will be treated as a /32 address.

Default: None

Example

example:/config/router/pim/#> ssm-policy deny 224.1.2.3/30
example:/config/router/pim/#> ssm-policy deny 224.1.2.3/30, 224.3.2.1/32

no
Remove all or a specific entry.
GROUP/LEN
IP multicast group in standard quad-dotted notation including netmask in CIDR notation, e.g. 225.1.2.0/24.

Interface Configuration

Interface settings that concern PIM-SM are found in the pim sub-context located under the configuration context for each individual iface:

example:/#> configure
example:/config/#> iface vlan1
example:/config/iface-vlan1/#> pim
example:/config/iface-vlan1/pim/#>

Note

The interface must still be added as a PIM interface with the interface command in the PIM routing context.

[no] priority <1-65535>

Designated Router (DR) election priority for this interface.

This setting can be useful to specify what device is the preferred DR for a given LAN segment.

The higher the number the higher the priority, i.e. 10 is a higher priority than 1.

Default: 1

Example

example:/config/iface-vlan1/pim/#> priority 10

no
Reset the value of the setting back to its default.
[no] hello-interval <1-65535>

Set the pim hello interval for the iface.

This interval dictates how often PIM hello messages will be transmitted for the specific interface. These hello messages are what PIM uses in order to form PIM neighbors.

Default: 30 Seconds

Example

example:/config/iface-vlan1/pim/#> hello-interval 24

no
Reset the value of the setting back to its default.
[no] hold-interval <1-65535>

Set the PIM hold interval for the iface.

The hold interval specifies the time a neighbor learned from a hello message will be kept, if not more hello messages are received. Each time a new hello message is received this timer is restarted.

It is important that this value is not lower than the hello interval. If it is the neighbor will be aged out before a new hello message will arrive. The default ratio between the hello and hold interval is that the hold time is 3.5x times the hello interval.

Default: 105 Seconds

Example

example:/config/iface-vlan1/pim/#> hold-interval 84

no
Reset the value of the setting back to its default.
[no] passive [auto]

Control passive-interface setting for PIM on this interface.

If this option is enabled the interface will act passively in regard to PIM control messages, i.e. no control messages will be sent or received on the interface.

Default: auto

Example

example:/config/iface-vlan1/pim/#> passive
example:/config/iface-vlan1/pim/#> no passive
example:/config/iface-vlan1/pim/#> passive auto

no
Disable acting as a passive interface.
auto
Follow the global setting passive-interface located in the PIM router context.

Status

A number of status commands are available that can be used to query the status of PIM. They are all accessed in the ip sub-context under the global exec context:

example:/#> ip
example:/ip/#>

All the PIM status commands are always prefixed with show pim. To see all available commands press tab after the prefixed line:

example:/ip/#> show pim
assert                 join                   rpf
assert-internal        jp-agg                 secondary
assert-winner-metric   local-membership       state
bsm-database           mroute                 statistics
bsr                    neighbor               upstream
bsrp-info              nexthop                upstream-join-desired
channel                rendezvous-point       upstream-rpf
interface              rp-info

Examples

Examples of a few different status commands.

Interface

Check the status of all the configured PIM interfaces:

example:/ip/#> show pim interface

PIM Interfaces                                                                
INTERFACE  STATE  ADDRESS       PIM-NBRS  PIM-DR    FHR  IF-CHANNELS          
pimreg     up     0.0.0.0       0         local     0    0
vlan1      up     10.0.1.1      1         10.0.1.2  0    0
vlan2      up     10.0.4.1      1         10.0.4.3  0    0
vlan7      up     192.168.10.1  0         local     0    1
Column Description
INTERFACE The name of the interface.
STATE The oper state of the interface.
ADDRESS The current configured IP address of the interface.
PIM-NBRS The number of PIM neighbors located on the interface.
PIM-DR Who the current DR for the subnet the interface is part of is, where local signifies that the device itself is the DR for the subnet.

Neighbor

List the neighbors that have been established by the router:

example:/ip/#> show pim neighbor

PIM Neighbors                                                                 
INTERFACE  NEIGHBOR  UPTIME    HOLDTIME  DR-PRIO                              
vlan1      10.0.1.2  01:10:16  00:01:28  1
vlan2      10.0.4.3  01:19:30  00:01:44  1
Column Description
INTERFACE The interface that the neighbor was located on, i.e. the interface that received the Hello message from the neighbor.
NEIGHBOR The IP address where the neighbor is located.
UPTIME The amount of time since the neighbor was initially detected.
HOLDTIME The current hold time for the neighbor. If this expires the neighbor will be removed. The timer is reset every time a new Hello message is received from it.
DR-PRIO The DR Priority reported by the neighbor in its hello message.

Rendezvous Point

Show the status of the configured rendezvous point(s):

example:/ip/#> show pim rendezvous-point

PIM Rendezvous Point Info                                                          
RP-ADDRESS  GROUP/PREFIX-LIST  OIF    I-AM-RP  SOURCE  GROUP-TYPE             
10.0.2.4    224.0.0.0/4        vlan1  no       Static  ASM
Column Description
RP-ADDRESS The source IP address for the RPs location.
GROUP/PREFIX-LIST The group or range of groups that the specific RP serves.
OIF The outgoing interface to reach the RP.
I-AM-RP Indicator if the router itself is the RP.
SOURCE How the RP has been assigned. Static indicates that it was statically configured on the device.

Join/Prune

Show the current status of Join/prune for any multicast groups that have some intended receiver that has joined:

example:/ip/#> show pim join

PIM Join                                                                       
INTERFACE  ADDRESS   SOURCE         GROUP      STATE  UPTIME    EXPIRE  PRUNE  
vlan1      10.0.4.3  192.168.30.99  225.2.2.2  JOIN   00:31:57  03:13   --:--
Column Description
INTERFACE Interface that the J/P was received on.
ADDRESS Address of the interface.
SOURCE The source in the J/P message. If it is a (*/G) J/P message the source will be shown as *. If it is a (S/G) J/P message the source S will be displayed.
GROUP The group that has been joined.
STATE The state of the entry, for instance if it is Joined or Pruned.
UPTIME How long since the initial J/P message for the entry was received.
EXPIRE How long until the entry expires, if no J/P messages including it are received.

Upstream

Show the status of current upstreams:

example:/ip/#> show pim upstream

PIM Upstream                                                                           
IIF    SOURCE         GROUP      STATE  UPTIME    JOINTIMER  RSTIMER   KATIMER   REFCNT
vlan1  *              225.2.2.2  J      00:03:55  00:00:58   --:--:--  --:--:--  1
vlan2  192.168.30.99  225.2.2.2  J      00:03:55  00:00:58   --:--:--  00:03:23  2
Column Description
IIF The incoming interface for traffic from the specific upstream source.
SOURCE Source of the upstream.
GROUP The multicast group for the upstream source.
STATE The current state in regards to the upstream.
UPTIME The total uptime of the upstream.
JOINTIMER The timer indicating when a new J/P message will be transmitted, it will be sent when it reaches 0.
RSTIMER The Register suppress timer. indicates when the FHR will send a new register frame to inform the RP that the stream is still active it will be sent when it reaches 0.
KATIMER The Keep Alive timer. Indicating how long the upstream will be kept alive, even if it disappears.
REFCNT The reference counter for the upstream.

List installed mroutes

Show the currently installed mroutes on the router:

example:/ip/#> show pim mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
       R - SGRpt Pruned, F - Register flag, T - SPT-bit set
SOURCE         GROUP      FLAGS  PROTO  INPUT  OUTPUT  TTL  UPTIME    
*              225.2.2.2  SC     IGMP   vlan1  pimreg  1    00:23:16
                                 IGMP          vlan7   1
192.168.30.99  225.2.2.2  ST     STAR   vlan2  vlan7   1    00:23:15
Column Description
SOURCE Displays a source address if the route entry is a (S,G) mroute. Will display a * if the route is a (*,G) mroute.
GROUP The multicast group to route for the mroute.
FLAGS Flags describing additional information for the state of the mroute.
INPUT The incoming interface for the multicast stream.
OUTPUT The outgoing interfaces for the route, any matching multicast to be routed will be sent on these interfaces.
UPTIME The total time that the specific route have been installed in the multicast routing table.

Reverse-Path Forwarding

Show the current status how the RPF would be selected for a (S,G) entry:

example:/ip/#> show pim rpf
RPF Cache Refresh Delay:    50 msecs
RPF Cache Refresh Timer:    0 msecs
RPF Cache Refresh Requests: 6
RPF Cache Refresh Events:   4
RPF Cache Refresh Last:     00:37:39
Nexthop Lookups:            10
Nexthop Lookups Avoided:    0

PIM RPF                                                                       
SOURCE         GROUP      RPFIFACE  RPFADDRESS  RIBNEXTHOP  METRIC  PREF      
*              225.2.2.2  vlan1     10.0.1.2    10.0.1.2    20      110
192.168.30.99  225.2.2.2  vlan2     10.0.4.3    10.0.4.3    20      110
Column Description
SOURCE The specific source address to use when performing the RPF lookup in the unicast routing table. If the source is a * the address of the RP will be used.
GROUP The relevant multicast group.
RPFIFACE The determined interface to use in order to reach the source.
RPFADDRESS The IP address of the RPF.
RIBNEXTHOP The nexthop address determined to use in order to reach the source.

Troubleshooting

Multicast routing can be tricky sometimes and when it comes to PIM-SM there are a number of things that could cause problems getting the setup to work as intended. The following is a list, in no particular order, of common things that could be worth checking if any problems are occurring:

  • Has the underlying unicast routing been configured correctly on all of the routers constituting the PIM domain? If it is not the Reverse-Path Forwarding (RPF) can potentially face some problems.

    • If using OSPF or RIP are the networks for the senders and receivers included? The redistribute connected command could be used for this.

    • Check that the RPF does not try to rely on default routes, since this will not work. In this case use a more specific static route instead.

    • Is the unicast routing consistent throughout the network? If it is not, multicast traffic may be dropped. If multicast traffic enter on the wrong interface, according to the interface determined by the RPF, it will dropped in order to avoid potential routing loops.

  • Have all the required interfaces been specified as PIM interfaces?

  • Is multicast routing enabled on the device? By default this is disabled.

  • Is IGMP enabled on the interfaces facing any receivers? This is not the same as configuring an interface as a PIM interface.

  • Is the Rendezvous Point configuration consistent across all of the PIM routers within the PIM domain, i.e. do they specify the same RPs?

  • Is the multicast traffic that is being transmitted done so with the correct TTL? This is a common issue when trying to route any multicast traffic.