Pim-SM router types

Within a PIM-SM domain, PIM-SM routers can be configured to fill one or more of the roles described in this section.

DR:	A router performing this function forwards multicast traffic from a unicast source to the appropriate distribution (rendezvous) point.
BSR:	A router elected to this function keeps all routers in a PIM-SM domain informed of the currently assigned RP for each multicast group currently known in the domain.
RP:	A router elected as a RP for a multicast group receives requested multicast traffic from a DR and forwards it toward the multicast receiver(s) requesting the traffic. See RP.
Static RP (static RP):	This option forwards traffic in the same way as an RP, but requires manual configuration on all routers in the domain to be effective.

All of the above functions can be enabled on each of several routers in a PIMSM domain.

DR

In a VLAN populated by one or more routers running PIM-SM, one such router is elected the DR for that VLAN. When the DR receives a Join request from a multicast receiver on that VLAN, it forwards the join toward the router operating as the RP for the requested multicast group.

Where multiple PIM-SM routers exist in a VLAN, the following criteria is used to elect a DR:

The router configured with the highest DR priority in the VLAN is elected.
If multiple routers in the VLAN are configured with the highest DR priority, the router having the highest IP address is elected.

In a given domain, each VLAN capable of receiving multicast traffic from a unicast source should have at least one DR. (Enabling PIM-SM on a VLAN automatically enables the router as a DR for that VLAN.) Because there is an election process for DR on each VLAN, all routers on a VLAN need to be enabled for DR. Where it is important to ensure that a particular router is elected as the DR for a given VLAN, you can increase the DR priority on that VLAN configuration for that router.

If it is necessary to prevent a router from operating as a DR on a given VLAN, disable DR operation by configuring the DR priority as zero (0.)

BSR

Before a DR can forward encapsulated packets for a specific multicast group to an RP, it must know which router in the domain is the elected RP for that multicast group. The BSR function enables this operation by doing the following:

Learns the group-to-RP mappings on the C-RPs in the domain by reading the periodic advertisements each one sends to the BSR.
Distributes the aggregate C-RP information as an RP-set to the PIM-SM routers in the domain. This is followed by an election to assign a specific multicast group or range of groups to the C-RPs in the domain. (The software supports assignment of up to four multicast addresses and/or ranges of multicast addresses to a C-RP.)

The BSR periodically sends bootstrap messages to the other PIM-SM routers in the domain to maintain and update the RP-set data throughout the domain, and to maintain its status as the elected BSR.


	NOTE: Where static RPs are configured in the domain to support the same multicast group(s) as one or more (dynamic) C-RPs, then the RP-set data has the precedence for assigning RPs for these groups unless the static RPs have been configured with the `override` option and if the multicast group mask for the static RP equals or exceeds the same mask for the applicable C-RP(s.)

BSR configuration and election

There should be multiple BSR candidates configured in a PIM-SM domain so that if the elected BSR becomes unavailable, another router will take its place. In the BSR election process, the BSR candidate configured with the highest priority number is selected. Where the highest priority setting is shared by multiple candidates, the candidate having the highest IP address is selected. In the event that the selected BSR subsequently fails, another election takes place among the remaining BSR candidates. To facilitate a predictable BSR election, configure a higher priority on the router you want elected as the BSR for the domain.


	NOTE: A router serving as the BSR for a domain should be central to the network topology. This helps to ensure optimal performance and also reduce the possibility of a network problem isolating the BSR.

BSR role in fault recovery

If the hold-time maintained in the BSR for a given C-RP's latest advertisement expires before being refreshed by a new advertisement from the C-RP, the non-reporting C-RP is removed from the domain. In this case, the removed C-RP's multicast groups are re-assigned to other C-RPs. (If no other C-RPs or static RPs in the domain are configured to support a multicast group from the non-reporting C-RP, that group becomes unavailable in the domain.)

RP

Instead of flooding multicast traffic as is done with PIM-DM, PIM-SM uses a set of multiple routers to operate as RPs. Each RP controls multicast traffic forwarding for one or more multicast groups as follows:

Receives traffic from multicast sources (S) via a DR.
Receives multicast joins from routers requesting multicast traffic.
Forwards the requested multicast traffic to the requesting routers.

Note that the routers requesting multicast traffic are either edge routers or intermediate routers. Edge routers are directly connected to specific multicast receivers using ICMP to request traffic. Intermediate routers are on the path between edge routers and the RP. This is known as a RP Tree (RPT) where only the multicast address appears in the routing table. For example:

( *, G ), where:

* = a variable (wildcard) representing the IP address of any multicast source

G = a particular multicast group address.


	NOTE: The software supports up to 100 RPs in a given PIM-SM domain.

Defining supported multicast groups

An RP in the default candidate configuration supports the entire range of possible multicast groups. This range is expressed as a multicast address and mask, where the mask defines whether the address is for a single address or a range of contiguous addresses:

Multicast address	Mask	Address range
224.0.0.0	240.0.0.0	224.0.0.0 - 239.255.255.255

An alternate way to express the above (default) address and mask is:

224.0.0.0/4

In non-default candidate configurations, an RP allows up to four ranges of contiguous multicast groups, and/or individual multicast groups, or both. For example:

RP candidate configuration	Supported range of multicast groups
235.0.240.0/12	235.0.240.1 — 235.0.255.255
235.0.0.1/28	235.0.0.1 — 235.0.0.15
235.0.0.128/32	235.0.0.128 only
235.0.0.77/32	235.0.0.77 only


	NOTE: If a given multicast group is excluded from all RPs in a given domain, then that group will not be available to the multicast receivers connected in the domain.

For more on this topic, see Configuring C-RPs on PIM-SM routers.

C-RP election

Within a PIM-SM domain, different RPs support different multicast addresses or ranges of multicast addresses. (That is, a given PIM-SM multicast group or range of groups is supported by only one active RP, although other C-RPs can also be configured with overlapping or identical support.)

A C-RP's group-prefix configuration identifies the multicast groups the RP is enabled to support.

If multiple C-RPs have group-prefixes configured so that any of these RPs can support a given multicast group, then the following criteria are used to select the RP to support the group:

The C-RP configured with the longest group-prefix mask applicable to the multicast group is selected to support the group. Step 2 of this procedure applies if multiple RP candidates meet this criterion.
The C-RP configured with the highest priority is selected. Step 3 of this procedure applies if multiple RP candidates meet this criterion.
A hash function (using the configured bsr-candidate hash-mask-length value) generates a series of mask length values that are individually assigned to the set of eligible C-RPs. If the hash function matches a single RP candidate to a longer mask length than the other candidates, that candidate is selected to support the group. Apply step 4 of this procedure if the hash function matches the longest mask length to multiple RP candidates.
The C-RP having the highest IP address is selected to support the group.

NOTE: In a PIM-SM domain where there are overlapping ranges of multicast groups configured on the C-RPs, discrete ranges of these groups are assigned to the domain's C-RPs in blocks of sequential group numbers. The number of multicast groups in the blocks assigned within a given domain is determined by the bsr-candidate hash-mask-length value (range=1 to 32) configured on the elected BSR for the domain. A higher value means fewer sequential group numbers in each block of sequential group numbers, which results in a wider dispersal of multicast groups across the C-RPs in the domain.

As indicated above, multiple C-RPs can be configured to support the same multicast group(s.) This is the generally recommended practice and results in redundancy that helps to prevent loss of support for desired multicast groups in the event that a router in the domain becomes unavailable.

Configuring a C-RP to support a given multicast group does not ensure election of the C-RP to support that group unless the group is excluded from all other RPs in the domain.

Also, within a PIM-SM domain, a router can be configured as a C-RP available for a given multicast group or range of groups and as the static RP for a given multicast group or range of groups. The recommended practice is to use C-RPs for all multicast groups unless there is a need to ensure that a specific group or range of groups is always supported by the same routing switch. See Static RP (static RP).

Redundant Group Coverage Provides Fault-Tolerance

If a C-RP elected to support a particular multicast group or range of groups becomes unavailable, the router is excluded from the RP-set. If the multicast group configuration of one or more other C-RPs overlaps the configuration in the failed RP, then another C-RP is elected to support the multicast group(s) formerly relying on the failed RP.

Static RP (static RP)

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

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

Supporting a static RP as primary

A static RP can be configured to operate as either a secondary or primary RP. With the primary option, a dynamic (C-RP) backup is recommended. The precedence of a static RP over a dynamic RP is determined by the following static RP configuration options:

override enabled on the static RP.
A group mask on the static RP that equals or exceeds the group mask on the C-RP for the same multicast group(s.)

For override configuration information, see Statically configuring an RP to accept multicast traffic.

Operating rules for static RPs

Static RPs can be configured on the same routers as C-RPs.
Where a C-RP and a static RP are configured to support the same multicast group(s), the C-RP takes precedence over the static RP unless the static RP is configured to override the C-RP. (See Supporting a static RP as primary.)
Any static RP in a domain must be configured identically on all routers in the domain. Otherwise, some DRs will not know of the static RP and will not forward the appropriate multicast traffic, and some routers will not know where to send Joins for the groups supported by static RP.
Up to four static RP entries can be configured on a router. Each entry can be for either a single multicast group or a range of contiguous groups.
Only one interface can be configured as the static RP for a given multicast group or range of groups. For example, a properly configured PIM-SM domain does not support configuring 10.10.10.1 and 10.20.10.1 to both support a multicast group identified as 239.255.255.10.
Static RPs are not included in the RP-set messages generated by the BSR, and do not generate advertisements.
If a static RP becomes unavailable, it is necessary to remove and/or replace the configuration for this RP in all routers in the domain.

Configuration

See Statically configuring an RP to accept multicast traffic.

prev	up	next
PIM-SM DT	home	Operating rules and recommendations