General application

Like C-RPs, static RPs control multicast forwarding of specific multicast groups or ranges of contiguous groups. However, static RPs are not dynamically learned, and increase the configuration and monitoring effort needed to maintain them. As a result, static RPs are not generally recommended for use except where one of the following conditions applies:
  • It is desirable to designate a specific router interface as a backup RP for specific group(s.)

  • Specific multicast groups are expected, and a static RP would help to avoid overloading a given RP with a high volume of multicast traffic.

  • A C-RP for the same group(s) is less reliable than another RP that would not normally be elected to support the group(s.)

  • Tighter traffic control or a higher priority is desired for specific multicast groups


While the use of C-RPs and a BSR enable a dynamic selection of RPs for the multicast group traffic in a network, using static RPs involves manually configuring all routers in the domain to be aware of each static RP. This can increase the possibility of multicast traffic failure from to misconfigurations within the PIM-SM domain. Also, because a BSR does not administer static RPs, troubleshooting PIM-SM traffic problems can become more complex. For these reasons, use of static RPs should be limited to applications where no viable alternatives exist, or where the network is stable and requires configuring and maintaining only a few routers.

If a static RP operating as the primary RP for a multicast group fails, and the PIM-SM configuration in the domain does not include a (secondary) dynamic RP (C-RP) backup to the static RP, then new multicast groups assigned to the static RP will not be available to multicast receivers in the domain. Also, if a static RP fails, support for existing groups routed through SPTs that exclude the failed router will continue, but any existing flows routed through the RPT will fail.