Protocol Independent Multicast (PIM) provides IP multicast forwarding by leveraging unicast routing tables generated by any unicast routing protocol, such as routing information protocol (RIP), open shortest path first (OSPF), intermediate system to intermediate system (IS-IS), or border gateway protocol (BGP). Independent of the unicast routing protocols running on the device, multicast routing can be implemented as long as the corresponding multicast routing entries are created through unicast routes. PIM uses the reverse path forwarding (RPF) mechanism to implement multicast forwarding. When a multicast packet arrives on an interface of the device, it is subject to an RPF check. If the RPF check succeeds, the device creates the corresponding routing entry and forwards the packet; if the RPF check fails, the device discards the packet. For more information about RPF, refer to Multicast Routing and Forwarding Configuration in the IP Multicast Volume.

Based on the forwarding mechanism, PIM falls into two modes:

l Protocol Independent Multicast–Dense Mode (PIM-DM), and

l Protocol Independent Multicast–Sparse Mode (PIM-SM).

Presently, the any-source multicast (ASM) model implementations include the PIM-DM and PIM-SM modes, while the source-specific multicast (SSM) model can be implemented by leveraging part of the PIM-SM technique.

& Note:

To simplify description, a network comprising PIM-capable routers is referred to as a “PIM domain” in this document.

1.1.1 Introduction to PIM-DM

PIM-DM is a type of dense mode multicast protocol. It uses the “push mode” for multicast forwarding, and is suitable for small-sized networks with densely distributed multicast members.

The basic implementation of PIM-DM is as follows:

l PIM-DM assumes that at least one multicast group member exists on each subnet of a network, and therefore multicast data is flooded to all nodes on the network. Then, branches without multicast forwarding are pruned from the forwarding tree, leaving only those branches that contain receivers. This “flood and prune” process takes place periodically, that is, pruned branches resume multicast forwarding when the pruned state times out and then data is re-flooded down these branches, and then are pruned again.

l When a new receiver on a previously pruned branch joins a multicast group, to reduce the join latency, PIM-DM uses a graft mechanism to resume data forwarding to that branch.

Generally speaking, the multicast forwarding path is a source tree, namely a forwarding tree with the multicast source as its “root” and multicast group members as its “leaves”. Because the source tree is the shortest path from the multicast source to the receivers, it is also called shortest path tree (SPT).

1.1.2 How PIM-DM Works

The working mechanism of PIM-DM is summarized as follows:

l Neighbor discovery

l SPT building

l Graft

l Assert

I. Neighbor discovery

In a PIM domain, a PIM router discovers PIM neighbors, maintains PIM neighboring relationships with other routers, and builds and maintains SPTs by periodically multicasting hello messages to all other PIM routers (224.0.0.13).

& Note:

Every PIM-enabled interface on a router sends hello messages periodically, and thus learns the PIM neighboring information pertinent to the interface.

II. SPT building

The process of building an SPT is the process of “flood and prune”.

1) In a PIM-DM domain, when a multicast source S sends multicast data to a multicast group G, the multicast packet is first flooded throughout the domain: The router first performs RPF check on the multicast packet. If the packet passes the RPF check, the router creates an (S, G) entry and forwards the data to all downstream nodes in the network. In the flooding process, an (S, G) entry is created on all the routers in the PIM-DM domain.

2) Then, nodes without receivers downstream are pruned: A router having no receivers downstream sends a prune message to the upstream node to notify the upstream node to delete the corresponding interface from the outgoing interface list in the (S, G) entry and stop forwarding subsequent packets addressed to that multicast group down to this node.

& Note:

l An (S, G) entry contains the multicast source address S, multicast group address G, outgoing interface list, and incoming interface.

l For a given multicast stream, the interface that receives the multicast stream is referred to as “upstream”, and the interfaces that forward the multicast stream are referred to as “downstream”.

A prune process is first initiated by a leaf router. As shown in Figure 1-1, a router without any receiver attached to it (the router connected with Host A, for example) sends a prune message, and this prune process goes on until only necessary branches are left in the PIM-DM domain. These branches constitute the SPT.

Figure 1-1 SPT building

The “flood and prune” process takes place periodically. A pruned state timeout mechanism is provided. A pruned branch restarts multicast forwarding when the pruned state times out and then is pruned again when it no longer has any multicast receiver.

III. Graft

When a host attached to a pruned node joins a multicast group, to reduce the join latency, PIM-DM uses a graft mechanism to resume data forwarding to that branch. The process is as follows:

1) The node that needs to receive multicast data sends a graft message to its upstream node, as a request to join the SPT again.

2) Upon receiving this graft message, the upstream node puts the interface on which the graft was received into the forwarding state and responds with a graft-ack message to the graft sender.

3) If the node that sent a graft message does not receive a graft-ack message from its upstream node, it will keep sending graft messages at a configurable interval until it receives an acknowledgment from its upstream node.

IV. Assert

If multiple multicast routers exist on a multi-access subnet, duplicate packets may flow to the same subnet. To shutoff duplicate flows, the assert mechanism is used for election of a single multicast forwarder on a multi-access network.

Figure 1-2 Assert mechanism

As shown in Figure 1-2, after Router A and Router B receive an (S, G) packet from the upstream node, they both forward the packet to the local subnet. As a result, the downstream node Router C receives two identical multicast packets, and both Router A and Router B, on their own local interface, receive a duplicate packet forwarded by the other. Upon detecting this condition, both routers send an assert message to all PIM routers (224.0.0.13) through the interface on which the packet was received. The assert message contains the following information: the multicast source address (S), the multicast group address (G), and the preference and metric of the unicast route to the source. By comparing these parameters, either Router A or Router B becomes the unique forwarder of the subsequent (S, G) packets on the multi-access subnet. The comparison process is as follows:

1) The router with a higher unicast route preference to the source wins;

2) If both routers have the same unicast route preference to the source, the router with a smaller metric to the source wins;

3) If there is a tie in route metric to the source, the router with a higher IP address of the local interface wins.

& Note:

Currently, S9500 series routing switches do not support the assert mechanism.

1.1.3 Introduction to PIM-SM

PIM-DM uses the “flood and prune” principle to build SPTs for multicast data distribution. Although an SPT has the shortest path, it is built with a low efficiency. Therefore the PIM-DM mod is not suitable for large- and medium-sized networks.

PIM-SM is a type of sparse mode multicast protocol. It uses the “pull mode” for multicast forwarding, and is suitable for larger networks with sparsely and widely distributed multicast group members.

The basic implementation of PIM-SM is as follows:

l PIM-SM assumes that no hosts need to receive multicast data. In the PIM-SM mode, routers must specifically request a particular multicast stream before the data is forwarded to them. The core task for PIM-SM to implement multicast forwarding is to build and maintain rendezvous point trees (RPTs). An RPT is rooted at a router in the PIM domain as the common node, or rendezvous point (RP), through which the multicast data travels along the RPT and reaches the receivers.

l When a receiver is interested in the multicast data addressed to a specific multicast group, the router connected to this receiver sends a join message to the RP corresponding to that multicast group. The path along which the message goes hop by hop to the RP forms a branch of the RPT.

l When a multicast source sends a multicast packet to a multicast group, the source-side designated router (DR) first registers the multicast source with the RP by sending a register message to the RP by unicast. The arrival of this message at the RP triggers the establishment of an SPT. Then, the multicast source sends subsequent multicast packets along the SPT to the RP. Upon reaching the RP, the multicast packet is duplicated and delivered to the receivers along the RPT.

& Note:

Multicast traffic is duplicated only where the distribution tree branches. This process automatically repeats until the multicast traffic reaches the receivers.

1.1.4 How PIM-SM Works

The working mechanism of PIM-SM is summarized as follows:

l Neighbor discovery

l DR election

l RP discovery

l RPT formation

l Multicast source registration

l Switchover from RPT to SPT

l Assert

I. Neighbor discovery

PIM-SM uses the same neighbor discovery mechanism as PIM-DM does. Refer to Neighbor discovery described above.

II. DR election

PIM-SM also uses hello messages to elect a DR for a multi-access network (such as an LAN). The elected DR will be the only multicast forwarder on this multi-access network.

A DR must be elected in a multi-access network, no matter this network connects to multicast sources or to receivers. The DR at the receiver side sends join messages to the RP; the DR at the multicast source side sends register messages to the RP.

& Note:

l A DR is elected on a multi-access subnet by means of comparison of the priorities and IP addresses carried in hello messages. An elected DR is substantially meaningful to PIM-SM. PIM-DM itself does not require a DR. However, if any IGMPv1 router exists in a PIM-DM domain, a DR must be elected to act as the IGMPv1 querier.

l IGMP must be enabled on a device that acts as a DR before receivers attached to this device can join multicast groups through this DR.

For details about IGMP, refer to IGMP Configuration in the IP Multicast Volume.

Figure 1-3 DR election

As shown in Figure 1-3, the DR election process is as follows:

1) Routers on the multi-access network send hello messages to one another. The hello messages contain the router priority for DR election. The router with the highest DR priority will become the DR.

2) In the case of a tie in the router priority, or if any router in the network does not support carrying the DR-election priority in hello messages, the router with the highest IP address will win the DR election.

When the DR fails, a timeout in receiving hello message triggers a new DR election process among the other routers.

III. RP discovery

The RP is the core of a PIM-SM domain. For a small-sized, simple network, one RP is enough for forwarding information throughout the network, and the position of the RP can be statically specified on each router in the PIM-SM domain. In most cases, however, a PIM-SM network covers a wide area and a huge amount of multicast traffic needs to be forwarded through the RP. To lessen the RP burden and optimize the topological structure of the RPT, multiple candidate RPs (C-RPs) can be configured in a PIM-SM domain, among which an RP is dynamically elected through the bootstrap mechanism. Each elected RP serves a different multicast group range. For this purpose, a bootstrap router (BSR) must be configured. The BSR serves as the administrative core of the PIM-SM domain. A PIM-SM domain can have only one BSR, but can have multiple candidate-BSRs (C-BSRs). Once the BSR fails, a new BSR is automatically elected from the C-BSRs to avoid service interruption.

As shown in Figure 1-4, each C-RP periodically unicasts its advertisement messages (C-RP-Adv messages) to the BSR. A C-RP-Adv message contains the address of the advertising C-RP and the multicast group range it serves. The BSR collects these advertisement messages and chooses the appropriate C-RP information for each multicast group to form an RP-set, which is a database of mappings between multicast groups and RPs. The BSR then encapsulates the RP-set in the bootstrap messages it periodically originates and floods the bootstrap messages to the entire PIM-SM domain.

Figure 1-4 BSR and C-RPs

Based on the information in the RP-sets, all routers in the network can calculate the location of the corresponding RPs based on the following rules:

1) The C-RP with the highest priority wins.

2) If all the C-RPs have the same priority, their hash values are calculated through the hashing algorithm. The C-RP with the largest hash value wins.

3) If all the C-RPs have the same priority and hash value, the C-RP has the highest IP address wins.

The hashing algorithm used for RP calculation is: Value (G, M, C_i) = (1103515245 * ( (1103515245 * (G & M) + 12345) XOR C_i) + 12345) mod 2³¹. The table below gives the meanings of the values in this algorithm.

Table 1-1 Values in the hashing algorithm

Item	Meaning
Value	Hash value
G	IP address of the multicast group
M	Hash mask length
C_i	IP address of the C-RP
&	Logical operator of “and”
XOR	Logical operator of “exclusive or”
mod	Modulo operator, which gives the remainder of an integer division

IV. RPT formation

Figure 1-5 Build an RPT in PIM-SM

As shown in Figure 1-5, host B and host C are receivers of multicast data. The process of building an RPT is as follows:

1) When a receiver joins a multicast group G, it uses an IGMP message to inform the directly connected DR.

2) Upon getting the receiver information, the DR sends a join message, which is hop by hop forwarded to the RP corresponding to the multicast group.

3) The routers along the path from the DR to the RP form an RPT branch. Each router on this branch generates a (*, G) entry in its forwarding table. The * means any multicast source. The RP is the root, while the DRs are the leaves, of the RPT.

The multicast data addressed to the multicast group G flows through the RP, reaches the corresponding DR along the established RPT, and finally is delivered to the receiver.

When a receiver is no longer interested in the multicast data addressed to a multicast group G, the directly connected DR sends a prune message, which goes hop by hop along the RPT to the RP. Upon receiving the prune message, the upstream node deletes its interface connecting to this downstream node from the outgoing interface list and checks whether it itself has receivers for that multicast group. If not, the router continues to forward the prune message to its upstream router.

V. Multicast source registration

The purpose of multicast source registration is to inform the RP about the existence of the multicast source.

Figure 1-6 Multicast registration

As shown in Figure 1-6, the multicast source registers with the RP as follows:

1) When the multicast source S sends the first multicast packet to a multicast group G, the DR directly connected with the multicast source, upon receiving the multicast packet, encapsulates the packet in a PIM register message, and sends the message to the corresponding RP by unicast.

2) When the RP receives the register message, on one hand, it extracts the multicast packet from the register message and forwards the multicast packet down the RPT, and, on the other hand, it sends an (S, G) join message hop by hop toward the multicast source. Thus, the routers along the path from the RP to the multicast source constitute an SPT branch. Each router on this branch generates a (S, G) entry in its forwarding table. The multicast source is the root, while the RP is the leaf, of the SPT.

3) The subsequent multicast data from the multicast source travels along the established SPT to the RP, and then the RP forwards the data along the RPT to the receivers. When the multicast traffic arrives at the RP along the SPT, the RP sends a register-stop message to the source-side DR by unicast to stop the source registration process.

VI. Switchover from RPT to SPT

Initially, multicast traffic flows along an RPT from the RP to the receivers. Because the RPT is not necessarily the tree that has the shortest path, the receiver-side DR initiates an RPT-to-SPT switchover process upon receiving the first multicast packet along the RPT by default.

1) First, the receiver-side DR sends an (S, G) join message hop by hop to the multicast source. When the join message reaches the source-side DR, all the routers on the path have installed the (S, G) entry in their forwarding table, and thus an SPT branch is established.

2) Subsequently, the receiver-side DR sends a prune message hop by hop to the RP. Upon receiving this prune message, the RP forwards the message toward the multicast source if it determines no other receivers have joined the group on the interface that received the prune message, thus to implement RPT-to-SPT switchover.

After the RPT-to-SPT switchover, multicast data can be directly sent from the source to the receivers. PIM-SM builds SPTs through RPT-to-SPT switchover more economically than PIM-DM does through the “flood and prune” mechanism.

VII. Assert

PIM-SM uses the same assert mechanism as PIM-DM does. Refer to Assert described above.

1.1.5 Introduction to Administrative Scoping in PIM-SM

I. Division of PIM-SM domains

Typically, a PIM-SM domain contains only one BSR, which is responsible for advertising RP-set information within the entire PIM-SM domain. The information for all multicast groups is forwarded within the network scope administered by the BSR. We call this non-scoped BSR mechanism.

To implement refined management, a PIM-SM domain can be divided into one global scope zone and multiple administratively scoped zones (admin-scope zones). We call this administrative scoping mechanism.

The administrative scoping mechanism effectively releases stress on the management in a single-BSR domain and enables provision of zone-specific services using private group addresses.

Admin-scope zones are divided specific to multicast groups. The boundary of the admin-scope zone is formed by zone border routers (ZBRs). Each admin-scope zone maintains one BSR, which serves multicast groups within a specific range. Multicast protocol packets, such as assert messages and bootstrap messages, for a specific group range cannot cross the admin-scope zone boundary. Multicast group ranges served by different admin-scope zones can be overlapped. A multicast group is valid only within its local admin-scope zone, functioning as a private group address.

The global scope zone maintains a BSR, which serves the multicast groups that do not belong to any admin-scope zone.

II. Relationship between admin-scope regions and the global scope zone

The global scope zone and each admin-scope zone have their own C-RPs and BSRs. These devices are effective only in their respective admin-scope zones. Namely, BSR election and RP election are implemented independently within each admin-scope zone. Each admin-scope zone has its own boundary. The multicast information cannot cross this border in either direction. A better understanding of the global scope zone and admin-scope zones should be based on two aspects: geographical space and group address range.

1) Geographical space

Admin-scope regions are logical regions specific to particular multicast groups, and each admin-scope region must be geographically independent of another, as shown in Figure 1-7.

Figure 1-7 Relationship between admin-scope regions and the global scope zone in geographic space

Admin-scope regions are geographically segregated from one another. Namely, a router must not serve different admin-scope regions. In other words, different admin-scope regions contain different routers, whereas the global scope zone covers all routers in the PIM-SM domain.

2) In terms of multicast group address ranges

Each admin-scope region serves specific multicast groups. Usually, these addresses have no intersections; however, they may overlap one another.

Figure 1-8 Relationship between admin-scope regions and the global scope zone in group address ranges

l In Figure 1-8, the group address ranges of admin-scope 1 and 2 have no intersection, whereas the group address range of admin-scope 3 is a subset of the address range of admin-scope 1. The group address range of the global scope zone covers all the group addresses other than those of all the admin-scope zones. That is, the group address range of the global scope zone is G-G1-G2. In other words, there is a supplementary relationship between the global scope zone and all the admin-scope zones in terms of group address ranges.

1.1.6 SSM Model Implementation in PIM

The source-specific multicast (SSM) model and the any-source multicast (ASM) model are two opposite models. Presently, the ASM model includes the PIM-DM and PIM-SM modes. The SSM model can be implemented by leveraging part of the PIM-SM technique.

The SSM model provides a solution for source-specific multicast. It maintains the relationships between hosts and routers through IGMPv3.

In actual application, part of the PIM-SM technique is adopted to implement the SSM model. In the SSM model, receivers know exactly where a multicast source is located by means of advertisements, consultancy and so on. Therefore, no RP is needed, no RPT is required, there is no source registration process, and there is no need of using the multicast source discovery protocol (MSDP) for discovering sources in other PIM domains.

Compared with the ASM model, the SSM model only needs the support of IGMPv3 and some subsets of PIM-SM. The operation mechanism of PIM-SSM can be summarized as follows:

l Neighbor discovery

l DR election

l SPT building

I. Neighbor discovery

PIM-SSM uses the same neighbor discovery mechanism as in PIM-DM and PIM-SM. Refer to Neighbor discovery described above.

II. DR election

PIM-SSM uses the same DR election mechanism as in PIM-SM. Refer to DR election described above.

III. Construction of SPT

Whether to build an RPT for PIM-SM or an SPT for PIM-SSM depends on whether the multicast group the receiver is to join falls in the SSM group address range (the default SSM group address range is 232.0.0.0/8).

Figure 1-9 SPT establishment in PIM-SSM

As shown in Figure 1-9, Host B and Host C are multicast information receivers. They send IGMPv3 report messages denoted as (Include S, G) to the respective DRs to express their interest in the information of the specific multicast source S. The position of multicast source S is explicitly specified for receivers.

The DR that has received the report first checks whether the group address in this message falls in the SSM group address range:

l If so, the DR sends a subscribe message for channel subscription hop by hop toward the multicast source S. An (Include S, G) is created on all routers on the path from the DR to the source. Thus, an SPT is built in the network, with the source S as its root and receivers as its leaves. This SPT is the transmission channel in PIM-SSM.

l If not, the PIM-SM process is followed: the DR needs to send a (*, G) join message to the RP, and a multicast source registration process is needed.

& Note:

In PIM-SSM, the “channel” concept is used to refer to a multicast group, and the “channel subscription” concept is used to refer to a join message.

1.1.7 Protocols and Standards

PIM-related specifications are as follows:

l RFC 4601: Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised)

l RFC 3973: Protocol Independent Multicast-Dense Mode (PIM-DM): Protocol Specification (Revised)

l RFC 4607: Source-Specific Multicast for IP

l Draft-ietf-pim-sm-bsr-09: Bootstrap Router (BSR) Mechanism for PIM

l Draft-ietf-ssm-overview-05: An Overview of Source-Specific Multicast (SSM)

1.2 Configuring PIM-DM

1.2.1 PIM-DM Configuration Task List

Complete these tasks to configure PIM-DM:

Task	Remarks
Enabling PIM-DM	Required
Enabling State Refresh	Optional
Configuring State Refresh Parameters	Optional
Configuring PIM-DM Graft Retry Period	Optional
Configuring PIM Common Features	Optional

1.2.2 Configuration Prerequisites

Before configuring PIM-DM, complete the following task:

l Configure any unicast routing protocol so that all devices in the domain are interoperable at the network layer.

Before configuring PIM-DM, prepare the following data:

l The interval between state refresh messages

l Minimum time to wait before receiving a new refresh message

l TTL value of state refresh messages

l Graft retry period

1.2.3 Enabling PIM-DM

With PIM-DM enabled, a device sends hello messages periodically to discover PIM neighbors and processes messages from PIM neighbors. When deploying a PIM-DM domain, you are recommended to enable PIM-DM on all non-border interfaces of the routers.

Follow these steps to enable PIM-DM:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enable IP multicast routing	multicast routing-enable	Required Disable by default
Enter VLAN/POS interface view	interface interface-type interface-number	—
Enable PIM-DM	pim dm	Required Disabled by default

Caution:

l All the interfaces of the same router must work in the same PIM mode.

l After PIM-DM is enabled on a VLAN interface, IGMP snooping cannot be enabled in the VLAN corresponding to the VLAN interface, and vice versa.

l PIM-DM does not work with multicast groups in the SSM group grange.

1.2.4 Enabling State Refresh

A multi-access subnet can have the state-refresh capability only if the state-refresh capability is enabled on all PIM routers on the subnet.

It is recommended to keep the state-refresh capability enabled on all routers in the PIM-DM domain.

Follow these steps to enable the state refresh capability:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter VLAN/POS interface view	interface interface-type interface-number	—
Enable state refresh	pim state-refresh-capable	Optional Enabled by default

1.2.5 Configuring State Refresh Parameters

To avoid the resource-consuming reflooding of unwanted traffic caused by timeout of pruned interfaces, the device directly connected with the multicast source periodically sends an (S, G) state refresh message, which is forwarded hop by hop along the initial multicast flooding path of the PIM-DM domain, to refresh the prune timer state of all the devices on the path.

A device may receive multiple state refresh messages within a short time, of which some may be duplicated messages. To keep a device from receiving such duplicated messages, you can configure the time the device must wait before receiving the next state refresh message. If a new state refresh message is received within the waiting time, the device will discard it; if this timer times out, the device will accept a new state refresh message, refresh its own PIM state, and reset the waiting timer.

The TTL value of a state refresh message decrements by 1 whenever it passes a device before it is forwarded to the downstream node until the TTL value comes down to 0. In a small network, a state refresh message may cycle in the network. To effectively control the propagation scope of state refresh messages, you need to configure an appropriate TTL value based on the network size.

It is recommended to perform the following configurations on all routers in the PIM-DM domain.

Follow these steps to configure state refresh parameters:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure the interval between state refresh messages	state-refresh-interval interval	Optional 60 seconds by default
Configure the time to wait before receiving a new state refresh message	state-refresh-rate-limit interval	Optional 30 seconds by default
Configure the TTL value of state refresh messages	state-refresh-ttl ttl-value	Optional 255 by default

1.2.6 Configuring PIM-DM Graft Retry Period

In PIM-DM, graft is the only type of message that uses the acknowledgment mechanism. In a PIM-DM domain, if a device does not receive a graft-ack message from the upstream device within the specified time after it sends a graft message, the device keeps sending new graft messages at a configurable interval, namely graft retry period, until it receives a graft-ack from the upstream router.

Follow these steps to configure graft retry period:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter VLAN/POS interface view	interface interface-type interface-number	—
Configure graft retry period	pim timer graft-retry interval	Optional 3 seconds by default

& Note:

For the configuration of other timers in PIM-DM, refer to Configuring PIM Common Timers.

1.3 Configuring PIM-SM

& Note:

A device can serve as a C-RP and a C-BSR at the same time.

1.3.1 PIM-SM Configuration Task List

Complete these tasks to configure PIM-SM:

Task		Remarks
Enabling PIM-SM		Required
Configuring an RP	Configuring a static RP	Optional
	Configuring a C-RP	Required
	Enabling auto-RP	Optional
	Configuring C-RP timers globally	Optional
Configuring a BSR	Configuring C-BSRs	Required
	Configuring a PIM-SM domain border	Optional
	Configuring global C-BSR parameters	Optional
	Configuring C-BSR timers	Optional
Configuring Administrative Scoping	Enabling administrative scoping	Required
Configuring Administrative Scoping	Configuring a C-BSR for each region	Optional
Configuring Multicast Source Registration		Optional
Disabling RPT-to-SPT Switchover		Optional
Configuring PIM Common Features		Optional

1.3.2 Configuration Prerequisites

Before configuring PIM-SM, complete the following task:

l Configure any unicast routing protocol so that all devices in the domain are interoperable at the network layer.

Before configuring PIM-SM, prepare the following data:

l The IP address of a static RP and an ACL rule defining the range of multicast groups to be served by the static RP

l C-RP priority and an ACL rule defining the range of multicast groups to be served by each C-RP

l A legal C-RP address range and an ACL rule defining the range of multicast groups to be served

l C-RP-Adv interval

l C-RP timeout

l C-BSR priority

l Hash mask length

l An ACL rule defining a legal BSR address range

l BS period

l BS timeout

l An ACL rule for register message filtering

l Register suppression time

l Register probe time

l Whether to disable RPT-to-SPT switchover

1.3.3 Enabling PIM-SM

With PIM-SM enabled, a device sends hello messages periodically to discover PIM neighbors and processes messages from PIM neighbors. When deploying a PIM-SM domain, you are recommended to enable PIM-SM on all non-border interfaces of the routers.

Follow these steps to enable PIM-SM:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enable IP multicast routing	multicast routing-enable	Required Disable by default
Enter VLAN/POS interface view	interface interface-type interface-number	—
Enable PIM-SM	pim sm	Required Disabled by default

Caution:

l All the interfaces of the same device must work in the same PIM mode.

l After PIM-SM is enabled on a VLAN interface, IGMP snooping cannot be enabled in the VLAN corresponding to the VLAN interface, and vice versa.

1.3.4 Configuring an RP

An RP can be manually configured or dynamically elected through the BSR mechanism. For a large PIM-SM network, static RP configuration is a tedious job. Generally, static RP configuration is just a backup means for the dynamic RP election mechanism to enhance the robustness and operation manageability of a multicast network.

I. Configuring a static RP

If there is only one dynamic RP in a network, manually configuring a static RP can avoid communication interruption due to single-point failures and avoid frequent message exchange between C-RPs and the BSR. To enable a static RP to work normally, you need to perform this configuration on all the routers in the PIM-SM domain and specify the same RP address.

Follow these steps to configure a static RP:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure a static RP	static-rp rp-address [ acl-number ] [ preferred ]	Required No static RP by default

II. Configuring a C-RP

In a PIM-SM domain, you can configure routers that intend to become the RP as C-RPs. The BSR collects the C-RP information by receiving the C-RP-Adv messages from C-RPs or auto-RP announcements from other routers and organizes the information into an RP-set, which is flooded throughout the entire network. Then, the other routers in the network calculate the mappings between specific group ranges and the corresponding RPs based on the RP-set. We recommend that you configure C-RPs on backbone routers.

To guard against C-RP spoofing, you need to configure a legal C-RP address range and the range of multicast groups to be served on the BSR. In addition, because every C-BSR has a chance to become the BSR, you need to configure the same filtering policy on all C-BSRs in the PIM-SM domain.

Follow these steps to configure a C-RP:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure an interface to be a C-RP	c-rp interface-type interface-number [ group-policy acl-number \| priority priority \| holdtime hold-interval \| advertisement-interval adv-interval ] *	Required No C-RPs are configured by default
Configure a legal C-RP address range and the range of multicast groups to be served	crp-policy acl-number	Optional No restrictions by default

& Note:

l When configuring a C-RP, ensure a relatively large bandwidth between this C-RP and the other devices in the PIM-SM domain.

l An RP can serve multiple multicast groups or all multicast groups. Only one RP can forward multicast traffic for a multicast group at a moment.

III. Enabling auto-RP

Auto-RP announcement and discovery messages are addressed to the multicast group addresses 224.0.1.39 and 224.0.1.40 respectively. With auto-RP enabled on a device, the device can receive these two types of messages and record the RP information carried in such messages.

Follow these steps to enable auto-RP:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Enable auto-RP	auto-rp enable	Required Disabled by default

IV. Configuring C-RP timers globally

To enable the BSR to distribute the RP-set information within the PIM-SM domain, C-RPs must periodically send C-RP-Adv messages to the BSR. The BSR learns the RP-set information from the received messages, and encapsulates its own IP address together with the RP-set information in its bootstrap messages. The BSR then floods the bootstrap messages to all PIM routers (224.0.0.13) in the network.

Each C-RP encapsulates a timeout value in its C-RP-Adv messages. Upon receiving a C-RP-Adv message, the BSR obtains this timeout value and starts a C-RP timeout timer. If the BSR fails to hear a subsequent C-RP-Adv message from the C-RP when the timer times out, the BSR assumes the C-RP to have expired or become unreachable.

The C-RP timers need to be configured on C-RP routers.

Follow these steps to configure C-RP timers globally:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure the C-RP-Adv interval	c-rp advertisement-interval interval	Optional 60 seconds by default
Configure C-RP timeout time	c-rp holdtime interval	Optional 150 seconds by default

& Note:

For the configuration of other timers in PIM-SM, refer to Configuring PIM Common Timers.

1.3.5 Configuring a BSR

A PIM-SM domain can have only one BSR, but must have at least one C-BSR. Any device can be configured as C-BSR. Elected from C-BSRs, a BSR is responsible for collecting and advertising RP information in the PIM-SM.

I. Configuring C-BSRs

C-BSRs should be configured on devices in the backbone network. When configuring a router as a C-BSR, be sure to specify a PIM-SM-enabled interface. The BSR election process is as follows:

l Initially, every C-BSR assumes itself to be the BSR of this PIM-SM domain, and uses its interface IP address as the BSR address to send bootstrap messages.

l When a C-BSR receives the bootstrap message of another C-BSR, it first compares its own priority with the other C-BSR’s priority carried in the message. The C-BSR with a higher priority wins. If there is a tie in the priority, the C-BSR with a higher IP address wins. The loser uses the winner’s BSR address to replace its own BSR address and no longer assumes itself to be the BSR, while the winner keeps its own BSR address and continues assuming itself to be the BSR.

Configuring a legal range of BSR addresses enables filtering of BSR messages based on the address range, thus to prevent malicious hosts from initiating attacks by disguising themselves as legitimate BSRs. To protect legitimate BSRs from being maliciously replaced, preventive measures are taken specific to the following two situations:

1) Some malicious hosts intend to fool routers by forging BSR messages and change the RP mapping relationship. Such attacks often occur on border devices. Because a BSR is inside the network whereas hosts are outside the network, you can protect a BSR against attacks from external hosts by enabling border devices to perform neighbor check and RPF check on BSR messages and discard unwanted messages.

2) When a device in the network is controlled by an attacker or when an illegal device is present in the network, the attacker can configure such a device to be a C-BSR and make it win BSR election so as to gain the right of advertising RP information in the network. After being configured as a C-BSR, a device automatically floods the network with BSR messages. As a BSR message has a TTL value of 1, the whole network will not be affected as long as the neighbor device discards these BSR messages. Therefore, if a legal BSR address range is configured on all devices in the entire network, all devices will discard BSR messages from out of the legal address range, and thus this kind of attacks can be prevented.

The above-mentioned preventive measures can partially protect the security of BSRs in a network. However, if a legal BSR is controlled by an attacker, the above-mentioned problem will also occur.

Follow these steps to complete C-BSR configuration:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure an interface as a C-BSR	c-bsr interface-type interface-number [ hash-length [ priority ] ]	Required No C-BSR is configured by default
Configure a legal BSR address range	bsr-policy acl-number	Optional No restrictions on BSR address range by default

& Note:

Since a large amount of information needs to be exchanged between a BSR and the other devices in the PIM-SM domain, a relatively large bandwidth should be provided between the C-BSR and the other devices in the PIM-SM domain.

II. Configuring a PIM-SM domain border

As the administrative core of a PIM-SM domain, the BSR sends the collected RP-Set information in the form of bootstrap messages to all routers in the PIM-SM domain.

A PIM domain border is a bootstrap message boundary. Each BSR has its specific service scope. A number of PIM-SM domain border interfaces partition a network into different PIM-SM domains. Bootstrap messages cannot cross a domain border in either direction.

Follow these steps to configure a PIM-SM domain border:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter VLAN/POS interface view	interface interface-type interface-number	—
Configure a PIM-SM domain border	pim bsr-boundary	Required No PIM-SM domain border is configured by default.

III. Configuring global C-BSR parameters

In each PIM-SM domain, a unique BSR is elected from C-BSRs. The C-RPs in the PIM-SM domain send advertisement messages to the BSR. The BSR summarizes the advertisement messages to form an RP-set and advertises it to all routers in the PIM-SM domain. All the routers use the same Hash algorithm to get the RP address corresponding to specific multicast groups.

Perform the following configuration on C-BSR routers.

Follow these steps to configure global C-BSR parameters:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure the Hash mask length	c-bsr hash-length hash-length	Optional 30 by default
Configure the C-BSR priority	c-bsr priority priority	Optional 0 by default

& Note:

About the Hash mask length and C-BSR priority:

l You can configure these parameters at three levels: global configuration level, global scope zone level, and admin-scope region level.

l The value of these parameters configured at the global scope zone level or admin-scope region level have preference over the global values.

l If you do not configure these parameters at the global scope zone level or admin-scope region level, the corresponding global values will be used.

IV. Configuring C-BSR timers

The BSR election winner advertises its own IP address and RP-Set information via multicast throughout the region that it serves through bootstrap messages. The BSR floods bootstrap messages throughout the network at the interval of BSR state (BS) period. Any C-BSR that receives a bootstrap message retains the RP-set for the length of BS timeout, during which no BSR election takes place. If the BSR state times out and no bootstrap message is received from the BSR, a new BSR election process is triggered among the C-BSRs.

Perform the following configuration on C-BSR routers.

Follow these steps to configure C-BSR timers:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure the BS period	c-bsr interval interval	Optional 60 by default
Configure the BS timeout	c-bsr holdtime interval	Optional 130 by default

Caution:

In configuration, make sure that the bootstrap interval is smaller than the bootstrap timeout time.

1.3.6 Configuring Administrative Scoping

Without administrative scoping, a PIM-SM domain has only one BSR. The BSR manages the whole network. To manage your network more effectively and specifically, you can partition the PIM-SM domain into multiple admin-scope zones. Each admin-scope zone maintains a BSR, which serves a specific multicast group range; while the global scope zone also maintains a BSR, which serves all the rest multicast groups.

I. Enabling administrative scoping

Before configuring an admin-scope zone, you must enable administrative scoping first.

Perform the following configuration on all routers in the PIM-SM domain.

Follow these steps to enable administrative scoping:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Enable administrative scoping	c-bsr admin-scope	Required Disabled by default

& Note:

Administrative scoping is effective only for the multicast groups in the range of 239.0.0.0 to 239.255.255.255.

II. Configuring an admin-scope zone boundary

The boundary of each admin-scope zone is formed by ZBRs. Each admin-scope zone maintains a BSR, which serves a specific multicast group range. Multicast protocol packets (such as assert messages and bootstrap messages) that belong to this range cannot cross the admin-scope zone boundary.

Perform the following configuration on routers that can become a ZBR.

Follow these steps to configure an admin-scope zone boundary:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure a multicast forwarding boundary	multicast boundary group-address { mask \| mask-length }	Required By default, no multicast forwarding boundary is configured.

& Note:

For details about the multicast boundary command, see Multicast Routing and Forwarding Commands in the IP Multicast Volume.

III. Configuring a C-BSR for each region

In an administratively scoped network, group-range-specific BSRs are elected from C-BSRs. C-RPs in the network send advertisement messages to the specific BSR. The BSR summarizes the advertisement messages to form an RP-set and advertises it to all routers in the specific admin-scope region. All the routers use the same Hash algorithm to get the RP address corresponding to the specific multicast group.

Perform the following configuration on the routers that may become C-BSRs in each admin-scope zone or the global scope zone.

Follow these steps to configure a C-BSR for each region:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Configuring a C-BSR for an admin-scope region	c-bsr group group-address { mask \| mask-length } [ hash-length hash-length \| priority priority ] *	Required No C-BSRs are configured for a admin-scope region by default
Configure a C-BSR for the global-scope zone	c-bsr global [ hash-length hash-length \| priority priority ] *	Required No C-BSRs are configured for the global-scope zone by default

& Note:

About the Hash mask length and C-BSR priority:

l You can configure these parameters at three levels: global configuration level, global scope zone level, and admin-scope region level.

l The value of these parameters configured at the global scope zone level or admin-scope region level have preference over the global values.

l If you do not configure these parameters at the global scope zone level or admin-scope region level, the corresponding global values will be used.

1.3.7 Configuring Multicast Source Registration

Within a PIM-SM domain, the source-side DR sends register messages to the RP, and these register messages have different multicast source or group addresses. You can configure a filtering rule to filter register messages so that the RP can serve specific multicast groups. If an (S, G) entry is denied by the filtering rule, or the action for this entry is not defined in the filtering rule, the RP will send a register-stop message to the DR to stop the registration process for the multicast data.

In view of information integrity of register messages in the transmission process, you can configure the device to calculate the checksum based on the entire register messages. However, to reduce the workload of encapsulating data in register messages and for the sake of interoperability, this method of checksum calculation is not recommended.

When receivers stop receiving multicast data addressed to a certain multicast group through the RP (that is, the RP stops serving the receivers of a specific multicast group), or when the RP formally starts receiving multicast data from the multicast source, the RP sends a register-stop message to the source-side DR. Upon receiving this message, the DR stops sending register messages encapsulated with multicast data and enters the register suppression state.

In a probe suppression cycle, the DR can send a null register message (a register message without multicast data encapsulated), a certain length of time defined by the probe time before the register suppression timer expires, to the RP to indicate that the multicast source is active. When the register suppression expires, the DR starts sending register messages again. A smaller register suppression timeout setting will cause the RP to receive bursting multicast data more frequently, while a larger timeout setting will result in a larger delay for new receivers to join the multicast group they are interested in.

Configure a filtering rule for register messages on all C-RP routers and configure them to calculate the checksum based on the entire register messages. Configure the register suppression time and the register probe time on all routers that may become source-side DRs.

Follow these steps to configure PIM-SM register-related parameters:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure a filtering rule for register messages	register-policy acl-number	Optional No register filtering rule by default
Configure the device to calculate the checksum based on the entire register messages	register-header-checksum	Optional By default, the checksum is calculated based on the header of register messages
Configure the register suppression time	register-suppression-timeout interval	Optional 60 seconds by default
Configure the probe time	probe-interval interval	Optional 5 seconds by default

& Note:

After a filtering rule for register messages is configured, the RP accepts only the register messages that match the permit statement of the filtering rule. If you specify an undefined advanced ACL number, the RP will reject all the register messages.

1.3.8 Disabling RPT-to-SPT Switchover

When an S9500 series routing switch serves as a receiver-side DR, by default, it initiates an RPT-to-SPT switchover process immediately after receiving the first multicast packet along the RPT. You can disable the RPT-to-SPT switchover function with the following commands.

Perform the following configuration on routers that may become receiver-side DRs and on C-RP routers.

Follow these steps to disable RPT-to-SPT switchover:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Disable RPT-to-SPT switchover	spt-switch-threshold infinity [ group-policy acl-number [ order order-value ] ]	Optional By default, the device switches to the SPT immediately after it receives the first multicast packet along the RPT.

& Note:

To avoid forwarding failure, do not disable RPT-to-SPT switchover on a switch that may become an RP (namely, a static RP or a C-RP).

1.4 Configuring PIM-SSM

& Note:

The SSM module needs the support of IGMPv3. Therefore, be sure to enable IGMPv3 on PIM devices with attached multicast receivers.

1.4.1 PIM-SSM Configuration Task List

Complete these tasks to configure PIM-SSM:

Task	Remarks
Enabling PIM-SM	Required
Configuring the SSM Group Range	Optional
Configuring PIM Common Features	Optional

1.4.2 Configuration Prerequisites

Before configuring PIM-SSM, complete the following task:

l Configure any unicast routing protocol so that all devices in the domain are interoperable at the network layer.

Before configuring PIM-SSM, prepare the following data:

l The SSM group range

1.4.3 Enabling PIM-SM

The SSM model is implemented based on some subsets of PIM-SM. Therefore, a device is PIM-SSM-capable after you enable PIM-SM on it.

When deploying a PIM-SM domain, you are recommended to enable PIM-SM on non-border interfaces of the multicast devices.

Follow these steps to enable PIM-SM:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enable IP Multicast Routing	multicast routing-enable	Required Disable by default
Enter VLAN/POS interface view	interface interface-type interface-number	—
Enable PIM-SM	pim sm	Required Disabled by default

Caution:

l All the interfaces of the same router must work in the same PIM mode.

l After PIM-SM is enabled on a VLAN interface, IGMP snooping cannot be enabled in the VLAN corresponding to the VLAN interface, and vice versa.

1.4.4 Configuring the SSM Group Range

As for whether the information from a multicast source is delivered to the receivers based on the PIM-SSM model or the PIM-SM model, this depends on whether the group address in the (S, G) channel subscribed by the receivers falls in the SSM group range. All PIM-SM-enabled interfaces assume that multicast groups within this address range are working in the SSM model.

It is recommended to perform this configuration on all routers in the PIM-SM domain.

Follow these steps to configure the SSM group range:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure the SSM group range	ssm-policy acl-number	Optional 232.0.0.0/8 by default

Caution:

l Make sure that the same SSM group range is configured on all devices in the entire PIM-SM domain. Otherwise, multicast information cannot be delivered through the SSM model.

l If a multicast group falls in the PIM-SSM range but members of this group send IGMPv1 or IGMPv2 joins, the device that receives these join messages will not trigger (*, G) joins.

1.5 Configuring PIM Common Features

& Note:

For the configuration tasks described in this section:

l Configurations performed in PIM view are effective to all interfaces, while configurations performed in interface view are effective to the current interface only.

l If the same function or parameter is configured in both PIM view and interface view, the configuration performed in interface view is given priority, regardless of the configuration sequence.

1.5.1 PIM Common Information Configuration Task List

Complete these tasks to configure PIM common information:

Task	Remarks
Configuring a Multicast Data Filter	Optional
Configuring PIM Hello Options	Optional
Configuring PIM Common Timers	Optional
Configuring Join/Prune Message Sizes	Optional

1.5.2 Configuration Prerequisites

Before configuring PIM common information, complete the following tasks:

l Configure any unicast routing protocol so that all devices in the domain are interoperable at the network layer.

l Configure PIM-DM, or PIM-SM

Before configuring PIM common information, prepare the following data:

l An ACL rule for filtering multicast data

l Priority for DR election (global value/interface level value)

l PIM neighbor timeout time (global value/interface value)

l Prune delay (global value/interface level value)

l Prune override interval (global value/interface level value)

l Hello interval (global value/interface level value)

l Maximum delay between hello message (interface level value)

l Join/prune interval (global value/interface level value)

l Join/prune timeout (global value/interface value)

l Multicast source lifetime

l Maximum size of join/prune messages

l Maximum number of (S, G) entries in a join/prune message

1.5.3 Configuring a Multicast Data Filter

No matter in a PIM-DM domain or a PIM-SM domain, devices can check passing-by multicast data based on the configured filtering rules and determine whether to continue forwarding the multicast data. In other words, PIM devices can act as multicast data filters. These filters can help implement traffic control on one hand, and control the information available to receivers downstream to enhance data security on the other hand.

Follow these steps to configure a multicast data filter:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure a multicast data filter	source-policy acl-number	Required No multicast data filter by default

& Note:

Generally, a smaller distance from the filter to the multicast source results in a more remarkable filtering effect.

1.5.4 Configuring PIM Hello Options

No matter in a PIM-DM domain or a PIM-SM domain, the hello messages sent among devices contain many configurable options, including:

l DR_Priority (for PIM-SM only): priority for DR election. The device with the highest priority wins the DR election. You can configure this parameter on all the devices in a multi-access network directly connected to multicast sources or receivers.

l Holdtime: the timeout time of PIM neighbor reachability state. When this timer times out, if the router has received no hello message from a neighbor, it assumes that this neighbor has expired or become unreachable.

l LAN_Prune_Delay: the delay of prune messages on a multi-access network. This option consists of LAN-delay (namely, prune delay), override-interval, and neighbor tracking flag. If the LAN-delay or override-interval values of different PIM routers on a multi-access subnet are different, the largest value will take effect. If you want to enable neighbor tracking, the neighbor tracking feature should be enabled on all PIM routers on a multi-access subnet.

The LAN-delay setting will cause the upstream devices to delay processing received prune messages. If the LAN-delay setting is too small, it may cause the upstream device to stop forwarding multicast packets before a downstream device sends a prune override message. Therefore, be cautious when configuring this parameter.

The override-interval sets the length of time a downstream router is allowed to wait before sending a prune override message. When a router receives a prune message from a downstream router, it does not perform the prune action immediately; instead, it maintains the current forwarding state for a period of LAN-delay plus override-interval. If the downstream router needs to continue receiving multicast data, it must send a prune override message within the prune override interval; otherwise, the upstream route will perform the prune action when the period of LAN-delay plus override-interval time out.

A hello message sent from a PIM device contains a generation ID option. The generation ID is a random value for the interface on which the hello message is sent. Normally, the generation ID of a PIM device does not change unless the status of the device changes (for example, when PIM is just enabled on the interface or the device is restarted). When the device starts or restarts sending hello messages, it generates a new generation ID. If a PIM device finds that the generation ID in a hello message from the upstream device has changed, it assumes that the status of the upstream neighbor is lost or the upstream neighbor has changed. In this case, it triggers a join message for state update.

If you disable join suppression (namely, enable neighbor tracking), the join suppression feature should be disabled on all PIM routers on a multi-access subnet; otherwise, the upstream router will fail to explicitly track which downstream routers are joined to it.

I. Configuring hello options globally

Follow these steps to configure hello options globally:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure the priority for DR election	hello-option dr-priority priority	Optional 1 by default
Configure PIM neighbor timeout time	hello-option holdtime interval	Optional 105 seconds by default
Configure the prune delay time (LAN-delay)	hello-option lan-delay interval	Optional 500 milliseconds by default
Configure the prune override interval	hello-option override-interval interval	Optional 2,500 milliseconds by default
Disable join suppression	hello-option neighbor-tracking	Optional Enabled by default

II. Configuring hello options on an interface

Follow these steps to configure hello options on an interface:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter VLAN/POS interface view	interface interface-type interface-number	—
Configure the priority for DR election	pim hello-option dr-priority priority	Optional 1 by default
Configure PIM neighbor timeout time	pim hello-option holdtime interval	Optional 105 seconds by default
Configure the prune delay time (LAN-delay)	pim hello-option lan-delay interval	Optional 500 milliseconds by default
Configure the prune override interval	pim hello-option override-interval interval	Optional 2,500 milliseconds by default
Disable join suppression	pim hello-option neighbor-tracking	Optional Enabled by default
Configure the interface to reject hello messages without a generation ID	pim require-genid	Optional By default, hello messages without Generation_ID are accepted.

1.5.5 Configuring PIM Common Timers

PIM devices discover PIM neighbors and maintain PIM neighboring relationships with other devices by periodically sending out hello messages.

Upon receiving a hello message, a PIM device waits a random period, which is equal to or smaller than the maximum delay between hello messages, before sending out a hello message. This avoids collisions that occur when multiple PIM devices send hello messages simultaneously.

A PIM device periodically sends join/prune messages to its upstream for state update. A join/prune message contains the join/prune timeout time. The upstream device sets a join/prune timeout timer for each pruned downstream interface, and resumes the forwarding state of the pruned interface when this timer times out.

When a device fails to receive subsequent multicast data from the multicast source S, the device does not immediately delete the corresponding (S, G) entries; instead, it maintains the (S, G) entry for a period of time, namely the multicast source lifetime, before deleting the (S, G) entry.

I. Configuring PIM common timers globally

Follow these steps to configure PIM common timers globally:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure the hello interval	timer hello interval	Optional 30 seconds by default
Configure the join/prune interval	timer join-prune interval	Optional 60 seconds by default
Configure the join/prune timeout time	holdtime join-prune interval	Optional 210 seconds by default
Configure the multicast source lifetime	source-lifetime interval	Optional 210 seconds by default

II. Configuring PIM common timers on an interface

Follow these steps to configure PIM common timers on an interface:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter VLAN/POS interface view	interface interface-type interface-number	—
Configure the hello interval	pim timer hello interval	Optional 30 seconds by default
Configure the maximum delay between hello messages	pim triggered-hello-delay interval	Optional 5 seconds by default
Configure the join/prune interval	pim timer join-prune interval	Optional 60 seconds by default
Configure the join/prune timeout time	pim holdtime join-prune interval	Optional 210 seconds by default

& Note:

If there are no special networking requirements, we recommend that you use the default settings.

1.5.6 Configuring Join/Prune Message Sizes

A larger join/prune message size will result in loss of a larger amount of information when a message is lost; with a reduced join/message size, the loss of a single message will bring relatively minor impact.

By controlling the maximum number of (S, G) entries in a join/prune message, you can effectively reduce the number of (S, G) entries sent per unit of time.

Follow these steps to configure join/prune message sizes:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter PIM view	pim	—
Configure the maximum size of a join/prune message	jp-pkt-size packet-size	Optional 8,100 bytes by default
Configure the maximum number of (S, G) entries in a join/prune message	jp-queue-size queue-size	Optional 1,020 by default

1.6 Displaying and Maintaining PIM

To do...	Use the command...	Remarks
View the BSR information in the PIM-SM domain and locally configured C-RP information in effect	display pim bsr-info	Available in any view
View the information of unicast routes used by PIM	display pim claimed-route [ source-address ]	Available in any view
View the number of PIM control messages	display pim control-message counters [ message-type { probe \| register \| register-stop } \| [ interface interface-type interface-number \| message-type { assert \| bsr \| crp \| graft \| graft-ack \| hello \| join-prune \| state-refresh } ] * ]	Available in any view
View the information about unacknowledged graft messages	display pim grafts	Available in any view
View the PIM information on the specified interface or all interfaces	display pim interface [ interface-type interface-number ] [ verbose ]	Available in any view
View PIM neighboring information	display pim neighbor [ interface interface-type interface-number \| neighbor-address \| verbose ] *	Available in any view
View the content of the PIM routing table	display pim routing-table [ group-address [ mask { mask-length \| mask } ] \| source-address [ mask { mask-length \| mask } ] \| incoming-interface [ interface-type interface-number \| register ] \| outgoing-interface { include \| exclude \| match } { interface-type interface-number \| register } \| mode mode-type \| flags flag-value \| fsm ] *	Available in any view
View the RP information	display pim rp-info [ group-address ]	Available in any view
Reset PIM control message counters	reset pim control-message counters [ interface interface-type interface-number ]	Available in user view

1.7 PIM Configuration Examples

1.7.1 PIM-DM Configuration Example

I. Network requirements

l Receivers receive VOD information through multicast. The receiver groups of different organizations form stub networks, and one or more receiver hosts exist in each stub network. The entire PIM domain operates in the dense mode.

l As shown in Figure 1-10, Host A and Host C are multicast receivers in two stub networks.

l Switch D connects to the network that comprises the multicast source (Source) through VLAN-interface 300.

l Switch A connects to stub network N1 through VLAN-interface 100, and to Switch D through VLAN-interface 103.

l Switch B and Switch C connect to stub network N2 through their respective VLAN-interface 200, and to Switch D through VLAN-interface 101 and VLAN-interface 102 respectively.

l IGMPv3 is required on Switch A, Switch B, Switch C, and hosts in N1 and N2.

II. Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int100	10.110.1.1/24	Switch D	Vlan-int300	10.110.5.1/24
	Vlan-int103	192.168.1.1/24		Vlan-int103	192.168.1.2/24
Switch B	Vlan-int200	10.110.2.1/24		Vlan-int101	192.168.2.2/24
	Vlan-int101	192.168.2.1/24		Vlan-int102	192.168.3.2/24
Switch C	Vlan-int200	10.110.2.2/24
	Vlan-int102	192.168.3.1/24

Figure 1-10 Network diagram for PIM-DM configuration

III. Configuration procedure

& Note:

Only the commands related to the PIM-DM configuration are listed below.

1) Configure IP addresses and unicast routing

Configure the IP address and subnet mask for each interface as per Figure 1-10. Detailed configuration steps are omitted here.

Configure the OSPF protocol for interoperation among the switches in the PIM-DM domain. Ensure the network-layer interoperation among Switch A, Switch B, Switch C and Switch D in the PIM-DM domain and enable dynamic update of routing information among the switches through a unicast routing protocol. Detailed configuration steps are omitted here.

2) Enable IP multicast routing, and enable PIM-DM and IGMP

# Enable IP multicast routing on Switch A, enable PIM-DM on each interface, and enable IGMPv3 on VLAN-interface 100, which connects Switch A to the stub network.

<SwitchA> system-view

[SwitchA] multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[SwitchA-Vlan-interface100] igmp version 3

[SwitchA-Vlan-interface100] pim dm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 103

[SwitchA-Vlan-interface103] pim dm

[SwitchA-Vlan-interface103] return

The configuration on Switch B and Switch C is similar to the configuration on Switch A.

# Enable IP multicast routing on Switch D, and enable PIM-DM on each interface.

<SwitchD> system-view

[SwitchD] multicast routing-enable

[SwitchD] interface vlan-interface 300

[SwitchD-Vlan-interface300] pim dm

[SwitchD-Vlan-interface300] quit

[SwitchD] interface vlan-interface 103

[SwitchD-Vlan-interface103] pim dm

[SwitchD-Vlan-interface103] quit

[SwitchD] interface vlan-interface 101

[SwitchD-Vlan-interface101] pim dm

[SwitchD-Vlan-interface101] quit

[SwitchD] interface vlan-interface 102

[SwitchD-Vlan-interface102] pim dm

[SwitchD-Vlan-interface102] return

3) Verify the configuration

Use the display pim interface command to view the PIM configuration and running status on each interface. For example:

# View the PIM configuration information on Switch D.

<SwitchD> display pim interface

Interface NbrCnt HelloInt DR-Pri DR-Address

Vlan300 0 30 1 10.110.5.1 (local)

Vlan103 1 30 1 192.168.1.2 (local)

Vlan101 1 30 1 192.168.2.2 (local)

Vlan102 1 30 1 192.168.3.2 (local)

Carry out the display pim neighbor command to view the PIM neighboring relationships among the switches. For example:

# View the PIM neighboring relationships on Switch D.

<SwitchD> display pim neighbor

Total Number of Neighbors = 3

Neighbor Interface Uptime Expires Dr-Priority

192.168.1.1 Vlan103 00:02:22 00:01:27 1

192.168.2.1 Vlan101 00:00:22 00:01:29 3

192.168.3.1 Vlan102 00:00:23 00:01:31 5

Assume that Host A needs to receive the information addressed to a multicast group G (225.1.1.1). After multicast source S (10.110.5.100/24) sends multicast packets to the multicast group G, an SPT is established through traffic flooding. Switches on the SPT path (Switch A and Switch D) have their (S, G) entries. Host A sends an IGMP report to Switch A to join multicast group G, and a (*, G) entry is generated on Switch A. You can use the display pim routing-table command to view the PIM routing table information on each switch. For example:

# View the PIM routing table information on Switch A.

<SwitchA> display pim routing-table

Total 1 (*, G) entry; 1 (S, G) entry

(*, 225.1.1.1)

Protocol: pim-dm, Flag: WC

UpTime: 00:04:25

Upstream interface: NULL

Upstream neighbor: NULL

RPF prime neighbor: NULL

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface100

Protocol: igmp, UpTime: 00:04:25, Expires: never

(10.110.5.100, 225.1.1.1)

Protocol: pim-dm, Flag: ACT

UpTime: 00:06:14

Upstream interface: Vlan-interface103

Upstream neighbor: 192.168.1.2

RPF prime neighbor: 192.168.1.2

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface100

Protocol: pim-dm, UpTime: 00:04:25, Expires: never

The information on Switch B and Switch C is similar to that on Switch A.

# View the PIM routing table information on Switch D.

<SwitchD> display pim routing-table

Total 0 (*, G) entry; 1 (S, G) entry

(10.110.5.100, 225.1.1.1)

Protocol: pim-dm, Flag: LOC ACT

UpTime: 00:03:27

Upstream interface: Vlan-interface300

Upstream neighbor: NULL

RPF prime neighbor: NULL

Downstream interface(s) information:

Total number of downstreams: 3

1: Vlan-interface101

Protocol: pim-dm, UpTime: 00:03:27, Expires: never

2: Vlan-interface102

Protocol: pim-dm, UpTime: 00:03:27, Expires: never

3: Vlan-interface103

Protocol: pim-dm, UpTime: 00:03:27, Expires: never

1.7.2 PIM-SM Configuration Example

I. Network requirements

l Host A and Host C are multicast receivers in two stub networks.

l Switch D connects to the network that comprises the multicast source (Source) through VLAN-interface 300.

l Switch A connects to stub network N1 through VLAN-interface 100, and to Switch D and Switch E through VLAN-interface 101 and VLAN-interface 102 respectively.

l Switch B and Switch C connect to stub network N2 through their respective VLAN-interface 200, and to Switch E through VLAN-interface 103 and VLAN-interface 104 respectively.

l Switch E connects to Switch A, Switch B, Switch C and Switch D, and its VLAN-interface 102 interface acts a C-BSR and a C-RP, with the range of multicast groups served by the C-RP being 225.1.1.0/24.

l IGMPv3 needs to run between Switch A and N1, and between Switch B plus Switch C and N2.

II. Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int100	10.110.1.1/24	Switch D	Vlan-int300	10.110.5.1/24
	Vlan-int101	192.168.1.1/24		Vlan-int101	192.168.1.2/24
	Vlan-int102	192.168.9.1/24		Vlan-int105	192.168.4.2/24
Switch B	Vlan-int200	10.110.2.1/24	Switch E	Vlan-int104	192.168.3.2/24
	Vlan-int103	192.168.2.1/24		Vlan-int103	192.168.2.2/24
Switch C	Vlan-int200	10.110.2.2/24		Vlan-int102	192.168.9.2/24
	Vlan-int104	192.168.3.1/24		Vlan-int105	192.168.4.1/24

Figure 1-11 Network diagram for PIM-SM domain configuration

III. Configuration procedure

& Note:

Only the commands related to the PIM-SM configuration are listed below

1) Configure IP addresses and unicast routing

Configure the IP address and subnet mask for each interface as per Figure 1-11. Detailed configuration steps are omitted here.

Configure the OSPF protocol for interoperation among the switches in the PIM-SM domain. Ensure the network-layer interoperation among Switch A, Switch B, Switch C, Switch D and Switch E in the PIM-DM domain and enable dynamic update of routing information among the switches through a unicast routing protocol. Detailed configuration steps are omitted here.

2) Enable IP multicast routing, and enable PIM-SM and IGMP

# Enable IP multicast routing on Switch A, enable PIM-SM on each interface, and enable IGMPv3 on VLAN-interface 100, which connects Switch A to the stub network.

<SwitchA> system-view

[SwitchA] multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[SwitchA-Vlan-interface100] igmp version 3

[SwitchA-Vlan-interface100] pim sm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] pim sm

[SwitchA-Vlan-interface101] quit

[SwitchA] interface vlan-interface 102

[SwitchA-Vlan-interface102] pim sm

[SwitchA-Vlan-interface102] return

The configuration on Switch B and Switch C is similar to that on Switch A. The configuration on Switch D and Switch E is also similar to that on Switch A except that it is not necessary to enable IGMP on the corresponding interfaces on these two switches.

3) Configure a C-BSR and a C-RP

# Configure the service scope of RP advertisements and the positions of the C-BSR and C-RP on Switch E.

<SwitchE> system-view

[SwitchE] acl number 2005

[SwitchE-acl-basic-2005] rule permit source 225.1.1.0 0.0.0.255

[SwitchE-acl-basic-2005] quit

[SwitchE] pim

[SwitchE-pim] c-bsr vlan-interface 102

[SwitchE-pim] c-rp vlan-interface 102 group-policy 2005

[SwitchE-pim] return

4) Verify the configuration

Carry out the display pim interface command to view the PIM configuration and running status on each interface. For example:

# View the PIM configuration information on Switch A.

<SwitchA> display pim interface

Interface NbrCnt HelloInt DR-Pri DR-Address

Vlan100 0 30 1 10.110.1.1 (local)

Vlan101 1 30 1 192.168.1.2

Vlan102 1 30 1 192.168.9.2

To view the BSR election information and the locally configured C-RP information in effect on a switch, use the display pim bsr-info command. For example:

# View the BSR information and the locally configured C-RP information in effect on Switch A.

<SwitchA> display pim bsr-info

Elected BSR Address: 192.168.9.2

Priority: 0

Hash mask length: 30

State: Accept Preferred

Scope: Not scoped

Uptime: 00:40:40

Next BSR message scheduled at: 00:01:42

# View the BSR information and the locally configured C-RP information in effect on Switch E.

<SwitchE> display pim bsr-info

Elected BSR Address: 192.168.9.2

Priority: 0

Hash mask length: 30

State: Elected

Scope: Not scoped

Uptime: 00:00:18

Next BSR message scheduled at: 00:01:52

Candidate BSR Address: 192.168.9.2

Priority: 0

Hash mask length: 30

State: Pending

Scope: Not scoped

Candidate RP: 192.168.9.2(Vlan-interface102)

Priority: 0

HoldTime: 150

Advertisement Interval: 60

Next advertisement scheduled at: 00:00:48

To view the RP information discovered on a switch, use the display pim rp-info command. For example:

# View the RP information on Switch A.

<SwitchA> display pim rp-info

PIM-SM BSR RP information:

Group/MaskLen: 225.1.1.0/24

RP: 192.168.9.2

Priority: 0

HoldTime: 150

Uptime: 00:51:45

Expires: 00:02:22

Assume that Host A needs to receive information addressed to the multicast group G (225.1.1.1). An RPT will be built between Switch A and Switch E. When the multicast source S (10.110.5.100/24) registers with RP, an SPT will be built between Switch D and Switch E. Upon receiving multicast data, Switch A immediately switches from the RPT to the SPT. Switches on the RPT path, (Switch A and Switch E for example) contain (*, G) and (S, G) entries, while routers on the SPT path (Switch A and Switch D for example) contain an (S, G) entry. You can use the display pim routing-table command to view the PIM routing table information on the switches. For example:

# View the PIM routing table information on Switch A.

<SwitchA> display pim routing-table

Total 1 (*, G) entry; 1 (S, G) entry

(*, 225.1.1.1), RP: 192.168.9.2

Protocol: pim-sm, Flag: WC

UpTime: 00:13:46

Upstream interface: Vlan-interface102

Upstream neighbor: 192.168.9.2

RPF prime neighbor: 192.168.9.2

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface100

Protocol: igmp, UpTime: 00:13:46, Expires: 00:03:06

(10.110.5.100, 225.1.1.1), RP: 192.168.9.2

Protocol: pim-sm, Flag: SPT ACT

UpTime: 00:00:42

Upstream interface: Vlan-interface101

Upstream neighbor: 192.168.9.2

RPF prime neighbor: 192.168.9.2

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface100

Protocol: pim-sm, UpTime: 00:00:42, Expires: 00:03:06

The information on Switch B and Switch C is similar to that on Switch A.

# View the PIM routing table information on Switch D.

<SwitchD> display pim routing-table

Total 0 (*, G) entry; 1 (S, G) entry

(10.110.5.100, 225.1.1.1), RP: 192.168.9.2

Protocol: pim-sm, Flag: SPT LOC ACT

UpTime: 00:00:42

Upstream interface: Vlan-interface300

Upstream neighbor: NULL

RPF prime neighbor: NULL

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface105

Protocol: pim-sm, UpTime: 00:00:42, Expires: 00:02:06

# View the PIM routing table information on Switch E.

<SwitchE> display pim routing-table

Total 1 (*, G) entry; 0 (S, G) entry

(*, 225.1.1.1), RP: 192.168.9.2 (local)

Protocol: pim-sm, Flag: WC

UpTime: 00:13:16

Upstream interface: Register

Upstream neighbor: 192.168.4.2

RPF prime neighbor: 192.168.4.2

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface102

Protocol: pim-sm, UpTime: 00:13:16, Expires: 00:03:22

1.7.3 PIM-SSM Configuration Example

I. Network requirements

l Host A and Host C are multicast receivers in two stub networks.

l Switch D connects to the network that comprises the multicast source (Source) through VLAN-interface 300.

l Switch A connects to stub network N1 through VLAN-interface 100, and to Switch D and Switch E through VLAN-interface 101 and VLAN-interface 102 respectively.

l Switch B and Switch C connect to stub network N2 through their respective VLAN-interface 200, and to Switch E through VLAN-interface 103 and VLAN-interface 104 respectively.

l Switch E connects to Switch A, Switch B, Switch C and Switch D.

l The range of SSM multicast group addresses is 232.1.1.0/24.

l IGMPv3 is required on Switch A, Switch B, Switch C, and hosts in N1 and N2.

II. Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlanint100	10.110.1.1/24	Switch D	Vlanint300	10.110.5.1/24
	Vlanint101	192.168.1.1/24		Vlanint101	192.168.1.2/24
	Vlanint102	192.168.9.1/24		Vlanint105	192.168.4.2/24
Switch B	Vlanint200	10.110.2.1/24	Switch E	Vlanint104	192.168.3.2/24
	Vlanint103	192.168.2.1/24		Vlanint103	192.168.2.2/24
Switch C	Vlanint200	10.110.2.2/24		Vlanint102	192.168.9.2/24
	Vlanint104	192.168.3.1/24		Vlanint105	192.168.4.1/24

Figure 1-12 Network diagram for PIM-SSM configuration (on switches)

III. Configuration procedure

& Note:

Only the commands related to the PIM-SMM configuration are listed below.

1) Configure IP addresses and unicast routing

Configure the IP address and subnet mask for each interface as per Figure 1-12. Detailed configuration steps are omitted here.

Configure the OSPF protocol for interoperation among the switches in the PIM-SM domain. Ensure the network-layer interoperation among Switch A, Switch B, Switch C, Switch D and Switch E in the PIM-SM domain and enable dynamic update of routing information among the switches through a unicast routing protocol. Detailed configuration steps are omitted here.

2) Enable IP multicast routing, and enabling PIM-SM and IGMP

# Enable IP multicast routing on Switch A, enable PIM-SM on each interface, and enable IGMPv3 on VLAN-interface 100, which connects Switch A to the stub network.

<SwitchA> system-view

[SwitchA] multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[SwitchA-Vlan-interface100] igmp version 3

[SwitchA-Vlan-interface100] pim sm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] pim sm

[SwitchA-Vlan-interface101] quit

[SwitchA] interface vlan-interface 102

[SwitchA-Vlan-interface102] pim sm

[SwitchA-Vlan-interface102] quit

3) Configure the range of PIM-SSM multicast group addresses

# Configure the range of PIM-SSM multicast group addresses to be 232.1.1.0/24 one Switch A.

[SwitchA] acl number 2000

[SwitchA-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255

[SwitchA-acl-basic-2000] quit

[SwitchA] pim

[SwitchA-pim] ssm-policy 2000

[SwitchA-pim] return

The configuration on Switch B, Switch C, Switch D and Switch E is similar to the configuration on Switch A.

4) Verify the configuration

Carry out the display pim interface command to view the PIM configuration and running status on each interface. For example:

# View the PIM configuration information on Switch A.

<SwitchA> display pim interface

Interface NbrCnt HelloInt DR-Pri DR-Address

Vlan100 0 30 1 10.110.1.1 (local)

Vlan101 1 30 1 192.168.1.2

Vlan102 1 30 1 192.168.9.2

Assume that Host A needs to receive the information a specific multicast source S (10.110.5.100/24) sends to multicast group G (232.1.1.1). Switch A builds an SPT towards the multicast source. Switches on the SPT path (Switch A and Switch D for example) generates (S, G) entries, while Switch E, which is not on the SPT path does not have multicast routing entries. You can use the display pim routing-table command to view the PIM routing table information on each switch. For example:

# View the PIM routing table information on Switch A.

<SwitchA> display pim routing-table

Total 0 (*, G) entry; 1 (S, G) entry

(10.110.5.100, 232.1.1.1)

Protocol: pim-ssm, Flag:

UpTime: 00:13:25

Upstream interface: Vlan-interface101

Upstream neighbor: 192.168.1.2

RPF prime neighbor: 192.168.1.2

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface100

Protocol: igmp, UpTime: 00:13:25, Expires: 00:03:25

The information on Switch B and Switch C is similar to that on Switch A.

# View the PIM routing table information on Switch D.

<SwitchD> display pim routing-table

Total 0 (*, G) entry; 1 (S, G) entry

(10.110.5.100, 232.1.1.1)

Protocol: pim-ssm, Flag: LOC

UpTime: 00:12:05

Upstream interface: Vlan-interface300

Upstream neighbor: NULL

RPF prime neighbor: NULL

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface105

Protocol: pim-ssm, UpTime: 00:12:05, Expires: 00:03:25

1.8 Troubleshooting PIM Configuration

1.8.1 Failure of Building a Multicast Distribution Tree Correctly

I. Symptom

None of the devices in the network (including devices directly connected with multicast sources and receivers) has multicast forwarding entries. That is, a multicast distribution tree cannot be built correctly and clients cannot receive multicast data.

II. Analysis

l When PIM-DM runs on the entire network, multicast data is flooded from the first hop device connected with the multicast source to the last hop device connected with the clients along the SPT. When the multicast data is flooded to a device, no matter which device is, it creates (S, G) entries only if it has a route to the multicast source. If the device does not have a route to the multicast source, or if PIM-DM is not enabled on the device’s RPF interface to the multicast source, the device cannot create (S, G) entries.

l When PIM-SM runs on the entire network, and when a device is to join the SPT, the device creates (S, G) entries only if it has a route to the multicast source. If the device does not have a route to the multicast source, or if PIM-DM is not enabled on the device’s RPF interface to the multicast source, the device cannot create (S, G) entries.

l When a multicast device receives a multicast packet, it searches the existing unicast routing table for the optimal route to the RPF check object. The outgoing interface of this route will act as the RPF interface and the next hop will be taken as the RPF neighbor. The RPF interface completely relies on the existing unicast route, and is independent of PIM. The RPF interface must be PIM-enabled, and the RPF neighbor must also be a PIM neighbor. If PIM is not enabled on the device where the RPF interface or the RPF neighbor resides, the establishment of a multicast distribution tree will surely fail, causing abnormal multicast forwarding.

l Because a hello message does not carry the PIM mode information, a device running PIM is unable to know what PIM mode its PIM neighbor is running. If different PIM modes are enabled on the RPF interface and on the corresponding interface of the RPF neighbor device, the establishment of a multicast distribution tree will surely fail, causing abnormal multicast forwarding.

l The same PIM mode must run on the entire network. Otherwise, the establishment of a multicast distribution tree will surely fail, causing abnormal multicast forwarding.

III. Solution

1) Check unicast routes. Use the display ip routing-table command to check whether a unicast route exist from the receiver host to the multicast source.

2) Check that PIM is enabled on the interfaces, especially on the RPF interface. Use the display pim interface command to view the PIM information on each interface. If PIM is not enabled on the interface, use the pim dm or pim sm command to enable PIM-DM or PIM-SM.

3) Check that the RPF neighbor is a PIM neighbor. Use the display pim neighbor command to view the PIM neighbor information.

4) Check that PIM and IGMP are enabled on the interfaces directly connecting to the multicast source and to the receivers.

5) Check that the same PIM mode is enabled on related interfaces. Use the display pim interface verbose command to check whether the same PIM mode is enabled on the RPF interface and the corresponding interface of the RPF neighbor device.

6) Check that the same PIM mode is enabled on all the devices in the entire network. Make sure that the same PIM mode is enabled on all the devices: PIM-SM on all devices, or PIM-DM on all devices. In the case of PIM-SM, also check that the BSR and RP configurations are correct.

1.8.2 Multicast Data Abnormally Terminated on an Intermediate Device

I. Symptom

An intermediate device can receive multicast data successfully, but the data cannot reach the last hop device. An interface on the intermediate device receives data but no corresponding (S, G) entry is created in the PIM routing table.

II. Analysis

l If a multicast forwarding boundary has been configured through the multicast boundary command, any multicast packet will be kept from crossing the boundary, and therefore no routing entry can be created in the PIM routing table.

l In addition, the source-policy command is used to filter received multicast packets. If the multicast data fails to pass the ACL rule defined in this command, PIM cannot create the route entry, either.

III. Solution

1) Check the multicast forwarding boundary configuration. Use the display current-configuration command to check the multicast forwarding boundary settings. Use the multicast boundary command to change the multicast forwarding boundary settings.

2) Check the multicast filter configuration. Use the display current-configuration command to check the multicast filter configuration. Change the ACL rule defined in the source-policy command so that the source/group address of the multicast data can pass ACL filtering.

1.8.3 RPs Unable to Join SPT in PIM-SM

I. Symptom

An RPT cannot be established correctly, or the RPs cannot join the SPT to the multicast source.

II. Analysis

l As the core of a PIM-SM domain, the RPs serve specific multicast groups. Multiple RPs can coexist in a network. Make sure that the RP information on all devices is exactly the same, and a specific group is mapped to the same RP. Otherwise, multicast forwarding will fail.

l If the static RP mechanism is used, the same static RP command must be executed on all the devices in the entire network. Otherwise, multicast forwarding will fail.

III. Solution

1) Check that a route is available to the RP. Carry out the display ip routing-table command to check whether a route is available on each device to the RP.

2) Check the dynamic RP information. Use the display pim rp-info command to check whether the RP information is consistent on all devices.

3) Check the configuration of static RPs. Use the display pim rp-info command to check whether the same static RP address has been configured on all the devices in the entire network.

1.8.4 RPT Establishment Failure or Source Registration Failure in PIM-SM

I. Symptom

C-RPs cannot unicast advertise messages to the BSR. The BSR does not advertise bootstrap messages containing C-RP information and has no unicast route to any C-RP. An RPT cannot be established correctly, or the DR cannot perform source register with the RP.

II. Analysis

l The C-RPs periodically send C-RP-Adv messages to the BSR by unicast. If a C-RP has no unicast route to the BSR, the BSR cannot receive C-RP-Adv messages from that C-RP and the bootstrap message of the BSR will not contain the information of that C-RP.

l In addition, if the BSR does not have a unicast device to a C-RP, it will discard the C-RP-Adv messages from that C-RP, and therefore the bootstrap messages of the BSR will not contain the information of that C-RP.

l The RP is the core of a PIM-SM domain. Make sure that the RP information on all devices is exactly the same, a specific group G is mapped to the same RP, and unicast routes are available to the RP.

III. Solution

1) Check whether routes to the RP and the BSR are available. Carry out the display ip routing-table command to check whether routes are available on each device to the RP and the BSR, and whether a route is available between the RP and the BSR. Make sure the C-RP has a unicast route to the BSR, the BSR has a unicast route to the RP, and all the devices in the entire network have a unicast route to the RP.

2) Check the RP and BSR information. PIM-SM needs the support of the RP and BSR. Use the display pim bsr-info command to check whether the BSR information is available on each device, and then use the display pim rp-info command to check whether the RP information is correct.

3) View PIM neighboring relationships. Use the display pim neighbor command to check whether the normal PIM neighboring relationships have been established among the devices.

H3C S9500 Operation Manual-Release2132[V2.03]-04 IP Multicast Volume

1.1 PIM Overview

I. Neighbor discovery

II. SPT building

III. Graft

IV. Assert

I. Neighbor discovery

II. DR election

III. RP discovery

IV. RPT formation

V. Multicast source registration

VI. Switchover from RPT to SPT

VII. Assert

I. Division of PIM-SM domains

II. Relationship between admin-scope regions and the global scope zone

I. Neighbor discovery

II. DR election

III. Construction of SPT

1.2 Configuring PIM-DM

1.2.3 Enabling PIM-DM

1.2.4 Enabling State Refresh

1.2.5 Configuring State Refresh Parameters

1.2.6 Configuring PIM-DM Graft Retry Period

1.3 Configuring PIM-SM

1.3.4 Configuring an RP

IV. Configuring C-RP timers globally

II. Configuring a PIM-SM domain border

III. Configuring global C-BSR parameters

1.3.6 Configuring Administrative Scoping

1.3.7 Configuring Multicast Source Registration

1.3.8 Disabling RPT-to-SPT Switchover

1.4 Configuring PIM-SSM

1.4.3 Enabling PIM-SM

1.4.4 Configuring the SSM Group Range

1.5 Configuring PIM Common Features

1.5.3 Configuring a Multicast Data Filter

1.5.4 Configuring PIM Hello Options

I. Configuring hello options globally

1.5.5 Configuring PIM Common Timers

I. Configuring PIM common timers globally

1.5.6 Configuring Join/Prune Message Sizes

1.6 Displaying and Maintaining PIM

1.7 PIM Configuration Examples

I. Network requirements

II. Network diagram

III. Configuration procedure

1.7.2 PIM-SM Configuration Example

I. Network requirements

II. Network diagram

III. Configuration procedure

1.7.3 PIM-SSM Configuration Example

I. Network requirements

II. Network diagram

III. Configuration procedure

1.8 Troubleshooting PIM Configuration

I. Symptom

II. Analysis

III. Solution

I. Symptom

II. Analysis

III. Solution

1.8.3 RPs Unable to Join SPT in PIM-SM

I. Symptom

II. Analysis

III. Solution

1.8.4 RPT Establishment Failure or Source Registration Failure in PIM-SM

I. Symptom

II. Analysis

III. Solution

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business