Protocol Independent Multicast (PIM) provides IP multicast forwarding by leveraging unicast static routes or unicast routing tables generated by any unicast routing protocol, such as RIP, OSPF, IS-IS, or BGP. PIM is not dependent on any particular unicast routing protocol, and it uses the underlying unicast routing to generate a routing table with routes.

PIM uses the RPF mechanism to implement multicast forwarding. When a multicast packet arrives on an interface of the device, it undergoes an RPF check. If the RPF check succeeds, the device creates a multicast routing entry and forwards the packet. If the RPF check fails, the device discards the packet. For more information about RPF, see "Configuring multicast routing and forwarding."

Based on the implementation mechanism, PIM falls into the following categories:

· Protocol Independent Multicast–Dense Mode (PIM-DM)

· Protocol Independent Multicast–Sparse Mode (PIM-SM)

· Bidirectional Protocol Independent Multicast (BIDIR-PIM)

· Protocol Independent Multicast Source-Specific Multicast (PIM-SSM)

Currently, the switch does not support PIM-DM, BIDIR-PIM, or PIM-SSM.

In this document, a PIM domain refers to a network composed of PIM routers.

PIM-DM overview

PIM-DM uses the push mode for multicast forwarding, and is suitable for small-sized networks with densely distributed multicast members.

The following describes the basic implementation of PIM-DM:

· PIM-DM assumes that all downstream nodes want to receive multicast data when a source starts sending, so multicast data is flooded to all downstream nodes on the network.

· Branches without downstream receivers are pruned from the forwarding trees, leaving only those branches that contain receivers.

· The pruned state of a branch has a finite holdtime timer. When the timer expires, multicast data is again forwarded to the pruned branch. This flood-and-prune cycle takes place periodically to maintain the forwarding branches.

· To reduce join latency when a new receiver on a previously pruned branch joins a multicast group, PIM-DM uses a graft mechanism to turn the pruned branch into a forwarding branch.

In PIM-DM, the multicast forwarding paths for a multicast group constitutes a source tree, which is rooted at the multicast source and has multicast group members as its "leaves." Because the source tree consists of the shortest paths from the multicast source to the receivers, it is also called a "shortest path tree (SPT)."

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

· Neighbor discovery

· SPT building

· Graft

· Assert

Neighbor discovery

In a PIM domain, each interface that runs PIM on a router periodically multicasts PIM hello messages to all other PIM routers (identified by the address 224.0.0.13) on the local subnet to discover PIM neighbors, maintain PIM neighboring relationship with other routers, and build and maintain SPTs.

SPT building

The process of building an SPT is the flood-and-prune process:

1. In a PIM-DM domain, when the multicast source S sends multicast data to the multicast group G, the multicast data is flooded throughout the domain. A router performs an RPF check for the multicast data. If the RPF check succeeds, the router creates an (S, G) entry and forwards the data to all downstream nodes in the network. In the flooding process, all the routers in the PIM-DM domain create the (S, G) entry.

2. The nodes without downstream receivers are pruned. A router that has no downstream receivers sends a prune message to the upstream node to remove the interface that receives the prune message from the (S, G) entry. In this way, the upstream stream node stops forwarding subsequent packets addressed to that multicast group down to this node.

NOTE:

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

A prune process is initiated by a leaf router. As shown in Figure 1, the router interface that does not have any downstream receivers initiates a prune process by sending a prune message toward the multicast source. This prune process goes on until only necessary branches are left in the PIM-DM domain, and these necessary branches constitute an SPT.

Figure 1 SPT building

The pruned state of a branch has a finite holdtime timer. When the timer expires, multicast data is again forwarded to the pruned branch. The flood-and-prune cycle takes place periodically to maintain the forwarding branches.

Graft

To reduce the join latency when a new receiver on a previously pruned branch joins a multicast group, PIM-DM uses a graft mechanism to turn the pruned branch into a forwarding branch, as follows:

1. The node that needs to receive the multicast data sends a graft message to its upstream node, telling it to rejoin the SPT.

2. After receiving this graft message, the upstream node adds the interface that received the graft message into the outgoing interface list of the (S, G) entry for the multicast group, and then sends 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 continues to send graft messages at a configurable interval until it receives an acknowledgment from its upstream node.

Assert

On a subnet with more than one multicast router, the assert mechanism shuts off duplicate multicast flows to the network. It does this by electing a unique multicast forwarder for the subnet.

Figure 2 Assert mechanism

As shown in Figure 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 downstream interfaces, receive a duplicate packet forwarded by the other. After detecting this condition, both routers send an assert message to all PIM routers (224.0.0.13) on the local subnet through the interface that received the packet. The assert message contains the multicast source address (S), the multicast group address (G), and the preference and metric of the unicast route/MBGP route/static multicast route to the multicast source. By comparing these parameters, either Router A or Router B becomes the unique forwarder of the subsequent (S, G) packets on the shared-media LAN. The comparison process is as follows:

1. The router with a higher preference to the multicast source wins.

2. If both routers have the same preference to the source, the router with a smaller metric to the multicast source wins.

3. If a tie exists in route metric to the multicast source, the router with a higher IP address on the downstream interface wins.

PIM-SM overview

PIM-DM uses the flood-and-prune cycles to build SPTs for multicast data forwarding. Although an SPT has the shortest paths from the multicast source to the receivers, it is built with a low efficiency and is not suitable for large- and medium-sized networks.

PIM-SM uses the pull mode for multicast forwarding, and it is suitable for large- and medium-sized networks with sparsely and widely distributed multicast group members.

The basic implementation of PIM-SM is as follows:

· PIM-SM assumes that no hosts need multicast data. In the PIM-SM mode, a host must express its interest in the multicast data for a multicast group before the data is forwarded to it. PIM-SM implements multicast forwarding by building and maintaining rendezvous point trees (RPTs). An RPT is rooted at a router that has been configured as the rendezvous point (RP) for a multicast group, and the multicast data to the group is forwarded by the RP to the receivers along the RPT.

· When a receiver expresses it interest in the multicast data addressed to a specific multicast group, the receiver-side designated router (DR) sends a join message to the RP for the multicast group. The path along which the message goes hop by hop to the RP forms a branch of the RPT.

· When a multicast source sends multicast data to a multicast group, the source-side DR must register the multicast source with the RP by unicasting register messages to the RP. The multicast source stops sending until it receives a register-stop message from the RP. When the RP receives the register message, it triggers the establishment of an SPT. Then, the multicast source sends subsequent multicast packets along the SPT to the RP. After reaching the RP, the multicast packet is duplicated and delivered to the receivers along the RPT.

Multicast data is replicated wherever the RPT branches, and this process automatically repeats until the multicast data reaches the receivers.

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

· Neighbor discovery

· DR election

· RP discovery

· RPT building

· Multicast source registration

· Switchover to SPT

· Assert

Neighbor discovery

PIM-SM uses a similar neighbor discovery mechanism as PIM-DM does. For more information, see "Neighbor discovery."

DR election

On a shared-media LAN like Ethernet, only a DR forwards the multicast data. A DR is required in both the source-side network and receiver-side network. A source-side DR acts on behalf of the multicast source to send register messages to the RP, and the receiver-side DR acts on behalf of the receiver hosts to send join messages to the RP.

PIM-DM does not require a DR. However, if IGMPv1 runs on any shared-media LAN in a PIM-DM domain, a DR must be elected to act as the IGMPv1 querier for the LAN. For more information about IGMP, see "Configuring IGMP."

IMPORTANT:

IGMP must be enabled on the device that acts as the receiver-side DR. Otherwise, the receiver hosts attached to the DR cannot join any multicast groups.

Figure 3 DR election

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

1. The routers on the shared-media LAN send hello messages to one another. The hello messages contain the priority for DR election. The router with the highest DR priority is elected as the DR.

2. In the case of a tie in the 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 wins the DR election.

If the DR fails, its PIM neighbor lifetime expires and the other routers will initiate to elect a new DR.

RP discovery

An RP is the core of a PIM-SM domain. For a small-sized, simple network, one RP is enough for multicast forwarding throughout the network. In this case, you can specify a static RP on each router in the PIM-SM domain. However, in a PIM-SM network that covers a wide area, a huge amount of multicast data is forwarded by the RP. To lessen the RP burden and optimize the topological structure of the RPT, you can configure multiple candidate-RPs (C-RPs) in a PIM-SM domain, and use the bootstrap mechanism to dynamically elect RPs. An elected RP serves a different multicast group. For this purpose, you must configure a bootstrap router (BSR). A BSR serves as the administrative core of a PIM-SM domain. A PIM-SM domain has only one BSR, but can have multiple candidate-BSRs (C-BSRs) so that, if the BSR fails, a new BSR can be automatically elected from the C-BSRs and avoid service interruption.

NOTE:

· An RP can serve multiple multicast groups, but a multicast group has only one RP to serve the group.

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

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

Figure 4 Information exchange between C-RPs and BSR

Based on the information in the RP-set, all routers in the network can select the proper RP for a specific multicast group based on the following rules:

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

2. If all the C-RPs have the same priority, the C-RP with the largest hash value (calculated through the hash algorithm) wins.

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

RPT building

Figure 5 RPT building in a PIM-SM domain

As shown in Figure 5, the process of building an RPT is as follows:

1. When a receiver wants to join the multicast group G, it uses an IGMP message to inform the receiver-side DR.

2. After getting the receiver information, the DR sends a join message, which is forwarded hop by hop to the RP that serves the multicast group.

3. The routers along the path from the DR to the RP form an RPT branch. Each router on this branch adds to its forwarding table a (*, G) entry, where the asterisk (*) means any multicast source. The RP is the root of the RPT, and the DR is a leaf of the RPT.

When the multicast data addressed to the multicast group G reaches the RP, the RP forwards the data to the DR along the established RPT, and finally to the receiver.

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

Multicast source registration

The multicast source uses the registration process to inform an RP of its presence.

Figure 6 Multicast source registration

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

1. The multicast source S sends the first multicast packet to the multicast group G. When receiving the multicast packet, the source-side DR encapsulates the packet in a PIM register message and unicasts the message to the RP.

2. After the RP receives the register message, it decapsulates the register message and forwards the register message down to the RPT. Meanwhile, it sends an (S, G) source-specific join message hop by hop toward the multicast source. The routers along the path from the RP to the multicast source constitute an SPT branch, and each router on this branch creates an (S, G) entry in its forwarding table. The source-side DR is the root of the SPT, and the RP is the leaf of the SPT.

3. The subsequent multicast data from the multicast source are forwarded to the RP along the established branch, and the RP forwards the data to the receivers along the RPT. When the multicast data reaches the RP along the SPT, the RP unicasts a register-stop message to the source-side DR to prevent the DR from unnecessarily encapsulating the data.

Switchover to SPT

CAUTION:

If the switch is an RP, disabling switchover to SPT might cause multicast traffic forwarding failures on the source-side DR. When disabling switchover to SPT, be sure you fully understand its impact on your network.

In a PIM-SM domain, only one RP and one RPT serve a specific multicast group. Before the switchover to SPT occurs, the source-side DR encapsulates all multicast data addressed to the multicast group in register messages and sends them to the RP. After receiving these register messages, the RP decapsulates them and forwards them to the receivers-side DR along the RPT.

Switchover to STP includes the following issues:

· The source-side DR and the RP might perform complicated encapsulation and de-encapsulation operations.

· Multicast packets are delivered along a path that might not be the shortest one.

· An increase in multicast traffic adds a great burden on the RP, increasing the risk of failure.

To solve these issues, PIM-SM allows an RP or the receiver-side DR to initiate a switchover to SPT.

· The RP initiates a switchover to SPT:

When the RP receives the first multicast packet, it sends an (S, G) source-specific join message hop by hop toward the multicast source. The routers along the path from the RP to the multicast source constitute an SPT branch. The subsequent multicast data for the multicast group can be forwarded to the RP along the branch without being encapsulated.

For more information about the switchover to SPT initiated by the RP, see "Multicast source registration."

· The receiver-side DR initiates a switchover to SPT:

When the receiver-side DR receives the first multicast packet, it initiates a switchover to SPT as follows:

a. The receiver-side DR sends an (S, G) source-specific join message hop by hop toward the multicast source. The routers along the path from the RP to the source-side DR create an (S, G) entry in their forwarding table to constitute an SPT branch.

b. When the multicast packets for the multicast group are forwarded to the router where the RPT and the SPT branches, the router drops the multicast packets that reach it along the RPT and sends a prune message with the RP bit hop by hop to the RP. After receiving the prune message, the RP forwards it toward the multicast source (supposed only one receiver exists). Thus, the switchover to SPT is completed.

c. Finally, the multicast source sends the multicast packets for the multicast group to the receiver along the SPT.

With the switchover to SPT, PIM-SM builds SPTs more economically than PIM-DM does.

Assert

PIM-SM uses a similar assert mechanism as PIM-DM does. For more information, see "Assert."

BIDIR-PIM overview

In some many-to-many applications, such as a multi-side video conference, multiple receivers might be interested in the multicast data from multiple multicast sources. With PIM-DM or PIM-SM, each router along the SPT must create an (S, G) entry for each multicast source, consuming a lot of system resources.

BIDIR-PIM addresses the problem. Derived from PIM-SM, BIDIR-PIM builds and maintains a bidirectional RPT, which is rooted at the RP and connects the multicast sources and the receivers. Along the bidirectional RPT, the multicast sources send multicast data to the RP, and the RP forwards the data to the receivers. Each router along the bidirectional RPT needs to maintain only one (*, G) entry, saving system resources.

BIDIR-PIM is suitable for a network with dense multicast sources and receivers.

The operating mechanism of BIDIR-PIM is summarized as follows:

· Neighbor discovery

· RP discovery

· DF election

· Bidirectional RPT building

Neighbor discovery

BIDIR-PIM uses the same neighbor discovery mechanism as PIM-SM does. For more information, see "Neighbor discovery."

RP discovery

BIDIR-PIM uses the same RP discovery mechanism as PIM-SM does. For more information, see "RP discovery." In BIDIR-PIM, an RPF interface is the interface toward an RP, and an RPF neighbor is the address of the next hop to the RP.

In PIM-SM, an RP must be specified with a real IP address. In BIDIR-PIM, an RP can be specified with a virtual IP address, which is called the "rendezvous point address (RPA)." The link corresponding to the RPA's subnet is called the "rendezvous point link (RPL)." All interfaces connected to the RPL can act as the RPs, and they back up one another.

DF election

On a subnet with multiple multicast routers, the same multicast packets might be forwarded to the RP repeatedly. To address this issue, BIDIR-PIM uses a designated forwarder (DF) election mechanism to elect a unique DF for each RP on each subnet in the BIDIR-PIM domain, and allows only the DF to forward multicast data to the RP.

DF election is not necessary for an RPL.

Figure 7 DF election

As shown in Figure 7, without the DF election mechanism, both Router B and Router C can receive multicast packets from Route A, and both can forward the packets to downstream routers on the local subnet. As a result, the RP (Router E) receives duplicate multicast packets. With the DF election mechanism, once receiving the RP information, Router B and Router C initiate a DF election process for the RP:

1. Router B and Router C multicast a DF election message to all PIM routers (224.0.0.13). The election message carries the RP's address, and the priority and metric of the unicast route, MBGP route, or static multicast route to the RP.

2. The router with a route of the highest priority becomes the DF.

3. In the case of a tie in the priority, the router with the route with the lowest metric wins the DF election.

4. In the case of a tie in the metric, the router with the highest IP address wins.

Bidirectional RPT building

A bidirectional RPT comprises a receiver-side RPT and a source-side RPT. The receiver-side RPT is rooted at the RP and takes the routers that directly connect to the receivers as leaves. The source-side RPT is also rooted at the RP but takes the routers that directly connect to the sources as leaves. The processes for building these two RPTs are different.

Figure 8 RPT building at the receiver side

As shown in Figure 8, the process for building a receiver-side RPT is similar to that for building an RPT in PIM-SM:

1. When a receiver wants to join the multicast group G, it uses an IGMP message to inform the directly connected router.

2. After receiving the message, the router sends a join message, which is forwarded hop by hop to the RP for the multicast group.

3. The routers along the path from the receiver's directly connected router to the RP form an RPT branch, and each router on this branch adds to its forwarding table a (*, G) entry, where the asterisk (*) means any multicast source.

When a receiver wants to leave the multicast group G, the directly connected router sends a prune message, which goes hop by hop along the reverse direction of the RPT to the RP. After receiving the prune message, an upstream node removes the interface that connects to the downstream node from the outgoing interface list and checks whether it has receivers for that multicast group. If not, the router continues to forward the prune message to its upstream router.

Figure 9 RPT building at the multicast source side

As shown in Figure 9, the process for building a source-side RPT is relatively simple:

1. When a multicast source sends multicast packets to the multicast group G, the DF in each subnet unconditionally forwards the packets to the RP.

2. The routers along the path from the source's directly connected router to the RP constitute an RPT branch. Each router on this branch adds to its forwarding table a (*, G) entry, where the asterisk (*) means any multicast source.

After a bidirectional RPT is built, the multicast sources send multicast traffic to the RP along the source-side RPT, and the RP forwards the traffic to the receivers along the receiver-side RPT.

IMPORTANT:

If a receiver and a multicast source are at the same side of the RP, the source-side RPT and the receiver-side RPT might meet at a node before reaching the RP. In this case, the multicast packets from the multicast source to the receiver are directly forwarded by the node, instead of by the RP.

Administrative scoping overview

Typically, a PIM-SM domain or a BIDIR-PIM domain contains only one BSR, which is responsible for advertising RP-set information within the entire PIM-SM domain or BIDIR-PIM domain. The information about all multicast groups is forwarded within the network that the BSR administers. This is called the "non-scoped BSR mechanism."

To implement refined management, you can divide a PIM-SM domain or BIDIR-PIM domain into a global-scoped zone and multiple administratively-scoped zones (admin-scoped zones). This is called the "administrative scoping mechanism."

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 through private group addresses.

Admin-scoped zones are divided for multicast groups. Zone border routers (ZBRs) form the boundary of an admin-scoped zone. Each admin-scoped zone maintains one BSR, which serves multicast groups within a specific range. Multicast protocol packets, such as assert messages and BSMs, for a specific group range cannot cross the boundary of the admin-scoped zone that serves the group range. Multicast group ranges that different admin-scoped zones serve can have intersections. However, the multicast groups in an admin-scoped zone are valid only within the local zone, and theses multicast groups are regarded as private group addresses.

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

Relationship between admin-scope zones and the global scope zone

The global-scoped zone and each admin-scoped zone have their own C-RPs and BSRs. These devices are effective only on their respective zones, and the BSR election and the RP election are implemented independently. Each admin-scoped zone has its own boundary. The multicast information within a zone cannot cross this boundary in either direction. You can have a better understanding of the global-scoped zone and admin-scoped zones based on geographical locations and multicast group address ranges.

· In view of geographical locations:

An admin-scope zone is a logical zone for particular multicast groups. The multicast packets for such multicast groups are confined within the local admin-scope zone and cannot cross the boundary of the zone.

Figure 10 Relationship in view of geographical locations

As shown in Figure 10, for the multicast groups in a specific group address range, the admin-scope zones must be geographically separated and isolated. A router cannot belong to multiple admin-scope zones. In other words, different admin-scope zones contain different routers. However, the global-scoped zone includes all routers in the PIM-SM domain or BIDIR-PIM domain. Multicast packets that do not belong to any admin-scope zones are forwarded in the entire PIM-SM domain or BIDIR-PIM domain.

· In view of multicast group address ranges:

Each admin-scope zone serves specific multicast groups, of which the multicast group addresses are valid only within the local zone. The multicast groups of different admin-scoped zones might have intersections. All the multicast groups other than those of the admin-scoped zones are served by the global-scoped zone.

Figure 11 Relationship in view of multicast group address ranges

As shown in Figure 11, the admin-scoped zones 1 and 2 have no intersection, but the admin-scoped zone 3 is a subset of the admin-scoped zone 1. The global-scoped zone serves all the multicast groups that are not covered by the admin-scoped zones 1 and 2, G−G1−G2 in this case.

PIM-SSM overview

The ASM model includes PIM-DM and PIM-SM. The SSM model can be implemented by leveraging part of the PIM-SM technique. It is also called "PIM-SSM."

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

In actual applications, part of IGMPv3 and PIM-SM techniques are adopted to implement the SSM model. In the SSM model, because receivers have located a multicast source, no RP or RPT is required, multicast sources do not register, and the MSDP is not needed for discovering multicast sources in other PIM domains.

The operating mechanism of PIM-SSM is summarized as follows:

· Neighbor discovery

· DR election

· SPT building

Neighbor discovery

PIM-SSM uses the same neighbor discovery mechanism as PIM-SM. For more information, see "Neighbor discovery."

DR election

PIM-SSM uses the same DR election mechanism as PIM-SM. For more information, see "DR election."

SPT building

The decision to build an RPT for PIM-SM or an SPT for PIM-SSM depends on whether the multicast group that the receiver wants to join falls into the SSM group range (232.0.0.0/8 reserved by IANA).

Figure 12 SPT building in PIM-SSM

As shown in Figure 12, Host B and Host C are receivers. They send IGMPv3 report messages to their DRs to express their interest in the multicast information that the multicast source S sends to the multicast group G.

After receiving a report message, the DR first checks whether the group address in this message falls into the SSM group range and does the following:

· If the group address falls into the SSM group range, the DR sends a subscribe message hop by hop toward the multicast source S. All routers along the path from the DR to the source create an (S, G) entry so as to build an SPT, which is rooted at the multicast source S and has the receivers as its leaves. This SPT is the transmission channel in PIM-SSM.

· If the group address does not fall into the SSM group range, the receiver-side DR sends a (*, G) join message to the RP, and the multicast source registers with the source-side DR.

In PIM-SSM, the term "channel" refers to a multicast group, and the term "subscribe message" refers to a join message.

Relationship among PIM protocols

In a PIM network, PIM-DM cannot run together with PIM-SM, BIDIR-PIM, or PIM-SSM. However, PIM-SM, BIDIR-PIM, and PIM-SSM can run together. Figure 13 shows how the device selects one protocol from among them for a receiver trying to join a group.

For more information about IGMP SSM mapping, see "Configuring IGMP."

Figure 13 Relationship among PIM protocols

Protocols and standards

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

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

· RFC 5015, Bidirectional Protocol Independent Multicast (BIDIR-PIM)

· RFC 5059, Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)

· RFC 4607, Source-Specific Multicast for IP

· Draft-ietf-ssm-overview-05, An Overview of Source-Specific Multicast (SSM)

Configuring PIM-DM

PIM-DM configuration task list

Task at a glance
(Required.) Enabling PIM-DM
(Optional.) Enabling the state refresh feature
(Optional.) Configuring state refresh parameters
(Optional.) Configuring PIM-DM graft retry timer
(Optional.) Configuring common PIM features

Configuration prerequisites

Before you configure PIM-DM, configure any unicast routing protocol so that all devices in the domain are interoperable at the network layer

Enabling PIM-DM

Enable IP multicast routing before you configure PIM.

With PIM-DM enabled on interfaces, routers can establish PIM neighbor relationship and process PIM messages from their PIM neighbors. When you deploy a PIM-DM domain, enable PIM-DM on all non-border interfaces of the routers.

IMPORTANT:

All the interfaces on a device must operate in the same PIM mode.

To enable PIM-DM:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable IP multicast routing.	multicast routing-enable	By default, IP multicast routing is disabled.
3. Enter interface view.	interface interface-type interface-number	N/A
4. Enable PIM-DM.	pim dm	By default, PIM-DM is disabled.

Enabling the state refresh feature

Pruned interfaces resume multicast forwarding when the pruned state times out. To prevent this, the router with the multicast source attached 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 routers on the path. A shared-media subnet can have the state refresh feature only if the state refresh feature is enabled on all PIM routers on the subnet.

To enable the state refresh feature on all routers in PIM-DM domain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Enable the state refresh feature.	pim state-refresh-capable	By default, the state refresh feature is enabled.

Configuring state refresh parameters

The router directly connected with the multicast source periodically sends state refresh messages. You can configure the interval for sending such messages on that router.

A router might receive duplicate state refresh messages within a short time. To prevent this situation, you can configure the amount of time that the router must wait before it receives next state refresh message. If the router receives a new state refresh message within the specified waiting time, it discards the message. If this timer times out, the router accepts a new state refresh message, refreshes its own PIM-DM state, and resets the waiting timer.

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

To configure state refresh parameters:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A
3. Configure the interval to send state refresh messages.	state-refresh-interval interval	By default, the interval to send state refresh messages is 60 seconds.
4. Configure the time to wait before receiving a new state refresh message.	state-refresh-rate-limit time	By default, the waiting time is 30 seconds.
5. Configure the TTL value of state refresh messages.	state-refresh-ttl ttl-value	By default, the TTL value of state refresh messages is 255.

Configuring PIM-DM graft retry timer

In PIM-DM, graft is the only type of message that uses the acknowledgment mechanism. In a PIM-DM domain, if a router does not receive a graft-ack message from the upstream router within the specified time after it sends a graft message, the router keeps sending new graft messages at a configurable interval known as graft retry timer, until it receives a graft-ack message from the upstream router. For more information about the configuration of other timers in PIM-DM, see "Configuring common PIM timers."

To configure the graft retry timer:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure the graft retry timer.	pim timer graft-retry interval	By default, the graft retry timer is 3 seconds.

Configuring PIM-SM

PIM-SM configuration task list

Task at a glance
(Required.) Enabling PIM-SM
(Required.) Configuring an RP · Configuring a static RP · Configuring a C-RP NOTE: Perform at least one of the above tasks. In a network with a static RP, skip the task of configuring a BSR.
Configure a BSR: · (Required.) Configuring a C-BSR · (Optional.) Configuring a PIM domain border · (Optional.) Disabling the BSM semantic fragmentation function

(Optional.) Configuring multicast source registration
(Optional.) Configuring switchover to SPT
(Optional.) Configuring common PIM features

Configuration prerequisites

Before you configure PIM-SM, configure a unicast routing protocol so that all devices in the domain are interoperable at the network layer.

Enabling PIM-SM

Enable IP multicast routing before you configure PIM.

With PIM-SM enabled on interfaces, routers can establish PIM neighbor relationship and process PIM messages from their PIM neighbors. When you deploy a PIM-SM domain, H3C recommends that you enable PIM-SM on all non-border interfaces.

IMPORTANT:

All the interfaces on the same router must operate in the same PIM mode.

To enable PIM-SM:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable IP multicast routing.	multicast routing-enable	By default, IP multicast routing is disabled.
3. Enter interface view.	interface interface-type interface-number	N/A
4. Enable PIM-SM.	pim sm	By default, PIM-SM is disabled. If you execute this command or the igmp enable command on the VLAN interface, IGMP snooping does not take effect in the VLAN.

Configuring an RP

An RP can serve multiple multicast groups or all multicast groups. However, only one RP can forward multicast traffic for a multicast group at a moment.

An RP can be manually configured or dynamically elected through the BSR mechanism. For a large-scaled PIM network, configuring static RPs is a tedious job. Generally, static RPs are backups for dynamic RPs to enhance the robustness and operational manageability on a multicast network.

Configuring a static RP

If only one dynamic RP exists on a network, you can configure a static RP to avoid communication interruption caused by single-point failures. It can also avoid waste of bandwidth due to frequent message exchange between C-RPs and the BSR. To make the static RP properly operate, configure the same static RP on all routers in the PIM-SM domain.

To configure a static RP:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A
3. Configure a static RP for PIM-SM.	static-rp rp-address [ acl-number \| bidir \| preferred ] *	By default, no static RP is configured.

Configuring a C-RP

IMPORTANT:

When you configure a C-RP, reserve a relatively large bandwidth between the C-RP and the other devices in the PIM-SM domain.

In a PIM-SM domain, if you want a router to become the RP, you can configure the router as a C-RP. The BSR collects the C-RP information according to the received advertisement messages from C-RPs or the auto-RP announcements from other routers. Then, it organizes the C-RP information into the RP-set information, which is flooded throughout the entire network. Then, the other routers in the network can determine the RPs for different multicast group ranges based on the RP-set information. H3C recommends configuring C-RPs on backbone routers.

To enable the BSR to distribute the RP-set information in the PIM-SM domain, the C-RPs must periodically send advertisement messages to the BSR. The BSR learns the C-RP information, encapsulates the C-RP information and its own IP address in a BSM, and floods the BSM to all PIM routers in the domain.

An advertisement message contains a holdtime option, which defines the C-RP lifetime for the advertising C-RP. After the BSR receives an advertisement message from a C-RP, it starts a timer for the C-RP. If the BSR does not receive any advertisement message when the timer expires, it regards the C-RP failed or unreachable.

To guard against C-RP spoofing, you must configure a legal C-RP address range and the multicast group range to serve on the BSR. In addition, because every C-BSR might become the BSR, you must configure the same filtering policy on all C-BSRs in the PIM-SM domain.

To configure a C-RP:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A
3. Configure a C-RP.	c-rp ip-address [ advertisement-interval adv-interval \| group-policy acl-number \| holdtime hold-time \| priority priority ] *	By default, no C-RP is configured.
4. (Optional.) Configure a legal C-RP address range and the multicast group range to serve.	crp-policy acl-number	By default, no restrictions are defined.

Configuring a BSR

You must configure a BSR if C-RPs are configured to dynamically select the RP. In a network with a static RP, this configuration task is unnecessary.

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

Configuring a C-BSR

C-BSRs should be configured on routers on the backbone network. The BSR election process is summarized as follows:

· Initially, each C-BSR regards itself as the BSR of the PIM-SM domain and sends BSMs to other routers in the domain.

· When a C-BSR receives the BSM from another C-BSR, it compares its own priority with the priority carried in the message. The C-BSR with a higher priority wins the BSR election. If a tie exists 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 regards itself as the BSR, and the winner retains its own BSR address and continues to regard itself as the BSR.

In a PIM-SM domain, the BSR collects C-RP information from the received advertisement messages from the C-RPs, encapsulates the C-RP information in the RP-set information, and distributes the RP-set information to all routers in the PIM-SM domain. All routers use the same hash algorithm to get an RP for a specific multicast group.

Configuring a legal BSR address range enables filtering of BSMs based on the address range, thereby preventing a maliciously configured host from masquerading as a BSR. The same configuration must be made on all routers in the PIM-SM domain. The following describes the typical BSR spoofing cases and the corresponding preventive measures:

· Some maliciously configured hosts can forge BSMs to fool routers and change RP mappings. Such attacks often occur on border routers. 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 the border routers to perform neighbor checks and RPF checks on BSMs and to discard unwanted messages.

· When an attacker controls a router in the network or when an illegal router is present in the network, the attacker can configure the router as a C-BSR and make it win the BSR election to advertise RP information in the network. After a router is configured as a C-BSR, it automatically floods the network with BSMs. Because a BSM has a TTL value of 1, the whole network will not be affected as long as the neighbor router discards these BSMs. Therefore, with a legal BSR address range configured on all routers in the network, all these routers can discard BSMs from out of the legal address range.

These preventive measures can partially protect the BSR in a network. However, if an attacker controls a legal BSR, the problem still exists.

When you configure a C-BSR, reserve a relatively large bandwidth between the C-BSR and the other devices in the PIM-SM domain.

When C-BSRs connect to other PIM routers through tunnels, static multicast routes must be configured to make sure the next hop to a C-BSR is a tunnel interface. Otherwise, RPF check is affected. For more information about static multicast routes, see "Configuring multicast routing and forwarding."

To configure a C-BSR:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A
3. Configure a C-BSR.	c-bsr ip-address [ scope group-address { mask-length \| mask } ] [ hash-length hash-length \| priority priority ] *	By default, no C-BSR is configured.
4. (Optional.) Configure a legal BSR address range.	bsr-policy acl-number	By default, no restrictions are defined.

Configuring a PIM 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 domain border interfaces partition a network into different PIM-SM domains. Bootstrap messages cannot cross a domain border in either direction.

Perform the following configuration on routers that you want to configure as a PIM domain border.

To configure a PIM domain border:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure a PIM domain border.	pim bsr-boundary	By default, no PIM domain border is configured.

Disabling the BSM semantic fragmentation function

Generally, a BSR periodically advertises the RP-set information in BSMs within the PIM-SM domain. It encapsulates a BSM in an IP datagram and might fragment the datagram if the message exceeds the MTU. In this case, loss of a single IP fragment leads to unavailability of the entire message.

Semantic fragmentation of BSMs can solve this issue. When a BSM exceeds the MTU, it is split to multiple BSM fragments (BSMFs).

· If the RP-set information for a multicast group range is carried in one BSMF, a non-BSR router directly updates the RP-set information for the group range after receiving the BSMF.

· If the RP-set information for a multicast group range is carried in multiple BSMFs, a non-BSR router updates the RP-set information for the group range after receiving all these BSMFs. Because the RP-set information contained in each segment is different, loss of some IP fragments does not result in dropping of the entire BSM.

The BSM semantic fragmentation function is enabled by default. A device that does not support this function might regard a fragment as a BSM and thus learns only part of the RP-set information. Therefore, if such devices exist in the PIM-SM domain, you must disable the BSM semantic fragmentation function on the C-BSRs.

To disable the BSM semantic fragmentation function:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A
3. Disable the BSM semantic fragmentation function.	undo bsm-fragment enable	By default, BSM semantic fragmentation is enabled.

NOTE:

Generally, a BSR performs BSM semantic fragmentation according to the MTU of its BSR interface. However, for BSMs originated due to learning of a new PIM neighbor, semantic fragmentation is performed according to the MTU of the interface that sends the BSMs.

Configuring multicast source registration

In 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 the filtering rule denies an (S, G) entry, or if the filtering rule does not define the action for this entry, the RP sends a register-stop message to the DR to stop the registration process for the multicast data.

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

To configure multicast source registration:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A
3. Configure a filtering rule for register messages.	register-policy acl-number	By default, no register filtering rule exists.
4. Configure the device to calculate the checksum based on the entire register message.	register-whole-checksum	By default, the device calculates the checksum based on the header of a register message.

Configuring switchover to SPT

CAUTION:

If the device is an RP, disabling switchover to SPT might cause multicast traffic forwarding failures on the source-side DR. When disabling switchover to SPT, be sure you fully understand its impact on your network.

To configure the switchover to SPT:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A
3. Configure the criteria for triggering a switchover to SPT.	spt-switch-threshold { immediacy \| infinity } [ group-policy acl-number ]	By default, both the RP and the receiver-side DR immediately trigger the switchover to SPT after receiving the first multicast packet.

Configuring common PIM features

Configuration task list

Task at a glance
(Optional.) Configuring a multicast data filter
(Optional.) Configuring a hello message filter
(Optional.) Configuring PIM hello message options
(Optional.) Configuring common PIM timers
(Optional.) Setting the maximum size of each join or prune message

Configuration prerequisites

Before you configure common PIM features, complete the following tasks:

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

· Configure PIM-DM, or PIM-SM.

Configuring a multicast data filter

In either a PIM-DM domain or a PIM-SM domain, routers can check passing-by multicast data and determine whether to continue forwarding the multicast data based on the configured filtering rules. In other words, a PIM router can act as a multicast data filter, which can help implement traffic control and also control the information available to downstream receivers.

A filter can filter not only independent multicast data but also multicast data encapsulated in register messages. Generally, a filter nearer to the multicast source has a better filtering effect.

To configure a multicast data filter:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A
3. Configure a multicast data filter.	source-policy acl-number	By default, no multicast data filter is configured.

Configuring a hello message filter

Along with the wide applications of PIM, the security requirement for the protocol is becoming increasingly demanding. The establishment of correct PIM neighboring relationships is the prerequisite for secure application of PIM.

To guard against PIM message attacks, you can configure a legal source address range for hello messages on interfaces of routers to ensure the correct PIM neighboring relationships.

To configure a hello message filter:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure a hello message filter.	pim neighbor-policy acl-number	By default, no hello message filter exists. If a PIM neighbor's hello messages cannot pass the filter, the neighbor is automatically removed when its maximum number of hello attempts is reached.

Configuring PIM hello message options

In either a PIM-DM domain or a PIM-SM domain, hello messages exchanged among routers contain the following configurable options:

· DR_Priority (for PIM-SM only)—Priority for DR election. The device with the highest priority wins the DR election. You can configure this option for all the routers in a shared-media LAN that directly connects to the multicast source or the receivers.

· Holdtime—PIM neighbor lifetime. If a router does not receive a hello message from a neighbor when the neighbor lifetime expires, it regards the neighbor failed or unreachable.

· LAN_Prune_Delay—Delay of forwarding prune messages on a shared-media LAN. This option consists of LAN delay (namely, prune message delay), override interval, and neighbor tracking support (namely, the capability to disable join message suppression).

The prune message delay defines the delay time for a router to forward a received prune message to the upstream routers. The override interval defines a period for a downstream router to override a prune message. If the prune message delay or override interval on different PIM routers on a shared-media LAN are different, the largest value takes effect.

A router does not immediately prune an interface after it receives a prune message from the interface. Instead, it starts a timer (the prune message delay plus the override interval). If interface receives a join message before the override interval expires, the router does not prune the interface. Otherwise, the router prunes the interface when the timer (the prune message delay plus the override interval) expires.

You can enable the neighbor tracking function (or disable the join message suppression function) on an upstream router to track the states of the downstream nodes that have sent the join message and the joined state holdtime timer has not expired. If you want to enable the neighbor tracking function, you must enable it on all PIM routers on a shared-media LAN. Otherwise, the upstream router cannot track join messages from every downstream routers.

· Generation ID—A router generates a generation ID for hello messages when an interface is enabled with PIM. The generation ID is a random value, but only changes when the status of the router changes. If a PIM router finds that the generation ID in a hello message from the upstream router has changed, it assumes that the status of the upstream router has changed. In this case, it sends a join message to the upstream router for status update. You can configure an interface to drop hello messages without the generation ID options to promptly know the status of an upstream router.

You can configure hello message options in PIM view or interface view. The configurations made in PIM view are effective on all interfaces and the configurations made in interface view are effective on only the current interface. If you configure hello message options in both PIM view and interface view, the configuration in interface view always takes precedence.

Configuring hello message options globally

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A
3. Set the DR priority.	hello-option dr-priority priority	By default, the DR priority is 1.
4. Set the neighbor lifetime.	hello-option holdtime time	By default, the neighbor lifetime is 105 seconds.
5. Set the prune message delay.	hello-option lan-delay delay	By default, the prune message delay is 500 milliseconds.
6. Set the override interval.	hello-option override-interval interval	By default, the override interval is 2500 milliseconds.
7. Enable the neighbor tracking function.	hello-option neighbor-tracking	By default, the neighbor tracking function is disabled.

Configuring hello message options on an interface

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Set the DR priority.	pim hello-option dr-priority priority	By default, the DR priority is 1.
4. Set the neighbor lifetime.	pim hello-option holdtime time	By default, the neighbor lifetime is 105 seconds.
5. Set the prune delay.	pim hello-option lan-delay delay	By default, the prune delay is 500 milliseconds.
6. Set the override interval.	pim hello-option override-interval interval	By default, the override interval is 2500 milliseconds.
7. Enable the neighbor tracking function.	pim hello-option neighbor-tracking	By default, the neighbor tracking function is disabled.
8. Enable dropping hello messages without the Generation ID option.	pim require-genid	By default, an interface accepts hello messages without the Generation ID option.

Configuring common PIM timers

PIM routers periodically send hello messages to discover PIM neighbors, and maintain PIM neighbor relationship.

After receiving a hello message, a PIM router waits for a random time period before sending a hello message. This random time period is smaller than the maximum delay for sending hello messages, and it can avoid collisions that might occur when multiple PIM routers send hello messages simultaneously.

A PIM router periodically sends join/prune messages to its upstream routers for state update. A join/prune message contains the joined/pruned state holdtime value, and an upstream router uses this value to set a holdtime timer for the joined state or pruned state of the downstream interfaces.

When a router fails to receive subsequent multicast data from the multicast source S, the router does not immediately remove the corresponding (S, G) entry. Instead, it maintains the (S, G) entry for a period of time (known as, the multicast source lifetime) before deleting the (S, G) entry.

You can configure common PIM timers in PIM view or interface view. The configurations made in PIM view are effective on all interfaces. The configurations made in interface view are effective on only the current interface. If you configure common PIM timers in both PIM view and interface view, the configuration in interface view always takes precedence.

TIP:

For a network without special requirements, H3C recommends using the defaults.

Configuring common PIM timers globally

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A
3. Set the interval to send hello messages.	timer hello interval	By default, the interval to send hello messages is 30 seconds.
4. Set the interval to send join/prune messages.	timer join-prune interval	By default, the interval to send join/prune messages is 60 seconds.
5. Set the joined/pruned state holdtime timer.	holdtime join-prune time	By default, the joined/pruned state holdtime timer is 210 seconds.
6. Set the multicast source lifetime.	source-lifetime time	By default, the multicast source lifetime is 210 seconds.

Configuring common PIM timers on an interface

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Set the interval to send hello messages.	pim timer hello interval	By default, the interval to send hello messages is 30 seconds.
4. Set the maximum delay for sending hello messages.	pim triggered-hello-delay delay	By default, the maximum delay for sending hello messages is 5 seconds.
5. Set the interval to send join/prune messages.	pim timer join-prune interval	By default, the interval to send join/prune messages is 60 seconds.
6. Set the joined/pruned state holdtime timer.	pim holdtime join-prune time	By default, the joined/pruned state holdtime timer is 210 seconds.

Setting the maximum size of each join or prune message

The loss of an oversized join or prune message might result in loss of massive information. You can set a small value for the size of each join or prune message to reduce the impact.

To set the maximum size of each join or prune message:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter PIM view.	pim	N/A

Displaying and maintaining PIM

Execute display commands in any view and reset commands in user view.

Task	Command
Display BSR information in the PIM-SM domain.	display pim bsr-info
Display information about the routes used by PIM.	display pim claimed-route [ source-address ]
Display C-RP information in the PIM-SM domain.	display pim c-rp [ local ]
Display PIM information on an interface.	display pim interface [ interface-type interface-number ] [ verbose ]
Display PIM neighbor information.	display pim neighbor [ neighbor-address \| interface interface-type interface-number \| verbose ] *
Display PIM routing table information.	display pim routing-table [ group-address [ mask { mask-length \| mask } ] \| source-address [ mask { mask-length \| mask } ] \| flags flag-value \| fsm \| incoming-interface interface-type interface-number \| mode mode-type \| outgoing-interface { exclude \| include \| match } interface-type interface-number ] *
Display RP information in the PIM-SM domain.	display pim rp-info [ group-address ]

PIM configuration examples

IMPORTANT:

By default, Ethernet interfaces, VLAN interfaces, and aggregate interfaces are in the state of DOWN. To configure such an interface, use the undo shutdown command to bring it up first.

PIM-DM configuration example

Network requirements

As shown in Figure 14, receiver hosts 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.

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

IGMPv2 runs between Switch A and N1 and between Switch B, Switch C, and N2.

Figure 14 Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch A	VLAN-interface 100	10.110.1.1/24	Switch D	VLAN-interface 300	10.110.5.1/24
	VLAN-interface 103	192.168.1.1/24		VLAN-interface 103	192.168.1.2/24
Switch B	VLAN-interface 200	10.110.2.1/24		VLAN-interface 101	192.168.2.2/24
	VLAN-interface 101	192.168.2.1/24		VLAN-interface 102	192.168.3.2/24
Switch C	VLAN-interface 200	10.110.2.2/24
	VLAN-interface 102	192.168.3.1/24

Configuration procedure

1. Configure the IP address and subnet mask for each interface as per Figure 14. (Details not shown.)

2. Configure OSPF on the switches in the PIM-DM domain to make sure they are interoperable at the network layer and routing information among the switches can be dynamically updated. (Details not shown.)

3. Enable IP multicast routing, IGMP, and PIM-DM:

# On Switch A, enable IP multicast routing, enable IGMP on VLAN-interface 100, and enable PIM-DM on each interface.

<SwitchA> system-view

[SwitchA] multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[SwitchA-Vlan-interface100] pim dm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 103

[SwitchA-Vlan-interface103] pim dm

[SwitchA-Vlan-interface103] quit

# Enable IP multicast routing, IGMP, and PIM-DM on Switch B and Switch C in the same way. (Details not shown.)

# On Switch D, enable IP multicast routing, 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] quit

Verifying the configuration

# Display PIM 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)

# Display 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 multicast group 225.1.1.1. After multicast source 10.110.5.100/24 sends multicast packets to the multicast group, 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 the multicast group G, and a (*, G) entry is generated on Switch A. You can use the display pim routing-table command to display the PIM routing table information on each switch. For example:

# Display 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

# Display 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: 2

1: Vlan-interface103

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

2: Vlan-interface102

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

PIM-SM non-scoped zone configuration example

Network requirements

As shown in Figure 15, the receiver hosts receive VOD information through multicast. The receivers of different subnets form stub networks, and at least one receiver host exist in each stub network. The entire PIM-SM domain contains only one BSR.

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

Both VLAN-interface 105 on Switch D and VLAN-interface 102 on Switch E act as C-BSRs and C-RPs. The C-BSR on Switch E has a higher priority. The C-RPs server the multicast group range 225.1.1.0/24. Modify the hash mask length to map the multicast group range to the two C-RPs.

IGMPv2 runs between Switch A and N1, and between Switch B, Switch C, and N2.

Figure 15 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

Configuration procedure

1. Assign an IP address and subnet mask to each interface according to Figure 15. (Details not shown.)

2. Enable OSPF on all switches on the PIM-SM network to make sure the network-layer on the PIM-SM network is interoperable and the routing information among the switches can be dynamically updated. (Details not shown.)

3. Enable IP multicast routing, and enable IGMP and PIM-SM:

# On Switch A, enable IP multicast routing globally, enable IGMP on VLAN-interface 100, and enable PIM-SM on each interface.

<SwitchA> system-view

[SwitchA] multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[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

The configuration on Switch B, Switch C, Switch D, and Switch E is similar to that on Switch A. IGMP is not enabled on Switch D and Switch E. (Details not shown.)

4. Configure C-BSRs and C-RPs:

# On Switch D, configure the service scope of RP advertisements, configure VLAN-interface 105 as a C-BSR and a C-RP, and set the hash mask length to 32 and the priority of the C-BSR to 10.

<SwitchD> system-view

[SwitchD] acl number 2005

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

[SwitchD-acl-basic-2005] quit

[SwitchD] pim

[SwitchD-pim] c-bsr 192.168.4.2 hash-length 32 priority 10

[SwitchD-pim] c-rp 192.168.4.2 group-policy 2005

[SwitchD-pim] quit

# On Switch E, configure the service scope of RP advertisements, configure VLAN-interface 102 as a C-BSR and a C-RP, and set the hash mask length to 32 and the priority of the C-BSR to 20.

<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 192.168.9.2 hash-length 32 priority 20

[SwitchE-pim] c-rp 192.168.9.2 group-policy 2005

[SwitchE-pim] quit

Verifying the configuration

# Display PIM 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

# Display BSR information on Switch A.

[SwitchA] display pim bsr-info

Scope: non-scoped

State: Accept Preferred

Bootstrap timer: 00:01:44

Elected BSR address: 192.168.9.2

Priority: 20

Hash mask length: 32

Uptime: 00:40:40

# Display BSR information on Switch D.

[SwitchD] display pim bsr-info

Scope: non-scoped

State: Candidate

Bootstrap timer: 00:01:44

Elected BSR address: 192.168.9.2

Priority: 20

Hash mask length: 32

Uptime: 00:05:26

Candidate BSR address: 192.168.4.2

Priority: 10

Hash mask length: 32

# Display BSR information on Switch E.

[SwitchE] display pim bsr-info

Scope: non-scoped

State: Elected

Bootstrap timer: 00:01:44

Elected BSR address: 192.168.9.2

Priority: 20

Hash mask length: 32

Uptime: 00:01:18

Candidate BSR address: 192.168.9.2

Priority: 20

Hash mask length: 32

# Display RP information on Switch A.

[SwitchA] display pim rp-info

BSR RP information:

Scope: non-scoped

Group/MaskLen: 225.1.1.0/24

RP address Priority HoldTime Uptime Expires

192.168.4.2 192 150 00:51:45 00:02:22

192.168.9.2 192 150 00:51:45 00:02:22

PIM-SM admin-scoped zone configuration example

Network requirements

As shown in Figure 16, receiver hosts receive VOD information through multicast. The entire PIM-SM domain is divided into admin-scoped zone 1, admin-scoped zone 2, and the global-scoped zone. Switch B, Switch C, and Switch D are ZBRs of the three zones, respectively.

The source 1 and the source 2 send different multicast data to the multicast group 239.1.1.1. Host A receives the multicast data only from the source 1, and Host B receives the multicast data only from the source 2. The source 3 sends multicast data to the multicast group 224.1.1.1. Host C is a multicast receiver for the multicast group 224.1.1.1.

VLAN-interface 101 of Switch B acts as a C-BSR and a C-RP for admin-scoped zone 1, and VLAN-interface 105 of Switch D acts as a C-BSR and a C-RP for admin-scoped zone 2, and both of the two interfaces serve the multicast group range 239.0.0.0/8. VLAN-interface 109 of Switch F acts as a C-BSR and a C-RP for the global-scoped zone, and it serves all the multicast groups that are not in the range 239.0.0.0/8.

IGMPv2 runs between Switch A, Switch E, Switch I, and the receivers that directly connect to them, respectively.

Figure 16 Network diagram

Device	Interface	IP address	Device	Interface	IP address
Switch A	Vlan-int100	192.168.1.1/24	Switch D	Vlan-int105	10.110.5.2/24
	Vlan-int101	10.110.1.1/24		Vlan-int108	10.110.7.1/24
Switch B	Vlan-int200	192.168.2.1/24		Vlan-int107	10.110.8.1/24
	Vlan-int101	10.110.1.2/24	Switch E	Vlan-int400	192.168.4.1/24
	Vlan-int103	10.110.2.1/24		Vlan-int104	10.110.4.2/24
	Vlan-int102	10.110.3.1/24		Vlan-int108	10.110.7.2/24
Switch C	Vlan-int300	192.168.3.1/24	Switch F	Vlan-int109	10.110.9.1/24
	Vlan-int104	10.110.4.1/24		Vlan-int107	10.110.8.2/24
	Vlan-int105	10.110.5.1/24		Vlan-int102	10.110.3.2/24
	Vlan-int103	10.110.2.2/24	Switch G	Vlan-int500	192.168.5.1/24
	Vlan-int106	10.110.6.1/24		Vlan-int109	10.110.9.2/24
Switch H	Vlan-int110	10.110.10.1/24	Source 1	-	192.168.2.10/24
	Vlan-int106	10.110.6.2/24	Source 2	-	192.168.3.10/24
Switch I	Vlan-int600	192.168.6.1/24	Source 3	-	192.168.5.10/24
	Vlan-int110	10.110.10.2/24

Configuration procedure

1. Assign an IP address and subnet mask to each interface according to Figure 16. (Details not shown.)

3. Enable IP multicast routing, and enable IGMP and PIM-SM:

# On Switch A, enable IP multicast routing globally, enable IGMP on VLAN-interface 100, and enable PIM-SM on each interface.

<SwitchA> system-view

[SwitchA] multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[SwitchA-Vlan-interface100] pim sm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] pim sm

[SwitchA-Vlan-interface101] quit

The configuration on Switch E and Switch I is similar to that on Switch A. (Details not shown.)

# On Switch B, enable IP multicast routing globally, and enable PIM-SM on each interface.

<SwitchB> system-view

[SwitchB] multicast routing-enable

[SwitchB] interface vlan-interface 200

[SwitchB-Vlan-interface200] pim sm

[SwitchB-Vlan-interface200] quit

[SwitchB] interface vlan-interface 101

[SwitchB-Vlan-interface101] pim sm

[SwitchB-Vlan-interface101] quit

[SwitchB] interface vlan-interface 102

[SwitchB-Vlan-interface102] pim sm

[SwitchB-Vlan-interface102] quit

[SwitchB] interface vlan-interface 103

[SwitchB-Vlan-interface103] pim sm

[SwitchB-Vlan-interface103] quit

The configuration on Switch C, Switch D, Switch F, Switch G, and Switch H is similar to that on Switch B. (Details not shown.)

4. Configure admin-scoped zone boundaries:

# On Switch B, configure VLAN-interface 102 and VLAN-interface 103 as the boundaries of admin-scoped zone 1.

[SwitchB] interface vlan-interface 102

[SwitchB-Vlan-interface102] multicast boundary 239.0.0.0 8

[SwitchB-Vlan-interface102] quit

[SwitchB] interface vlan-interface 103

[SwitchB-Vlan-interface103] multicast boundary 239.0.0.0 8

[SwitchB-Vlan-interface103] quit

# On Switch C, configure VLAN-interface 103 and VLAN-interface 106 as the boundaries of admin-scoped zone 2.

<SwitchC> system-view

[SwitchC] interface vlan-interface 103

[SwitchC-Vlan-interface103] multicast boundary 239.0.0.0 8

[SwitchC-Vlan-interface103] quit

[SwitchC] interface vlan-interface 106

[SwitchC-Vlan-interface106] multicast boundary 239.0.0.0 8

[SwitchC-Vlan-interface106] quit

# On Switch D, configure VLAN-interface 107 as the boundary of admin-scoped zone 2.

<SwitchD> system-view

[SwitchD] interface vlan-interface 107

[SwitchD-Vlan-interface107] multicast boundary 239.0.0.0 8

[SwitchD-Vlan-interface107] quit

5. Configure C-BSRs and C-RPs:

# On Switch B, configure the service scope of RP advertisements and configure VLAN-interface 101 as a C-BSR and a C-RP for admin-scoped zone 1.

[SwitchB] acl number 2001

[SwitchB-acl-basic-2001] rule permit source 239.0.0.0 0.255.255.255

[SwitchB-acl-basic-2001] quit

[SwitchB] pim

[SwitchB-pim] c-bsr 10.110.1.2 scope 239.0.0.0 8

[SwitchB-pim] c-rp 10.110.1.2 group-policy 2001

[SwitchB-pim] quit

# On Switch D, configure the service scope of RP advertisements and configure VLAN-interface 105 as a C-BSR and a C-RP for admin-scoped zone 2.

[SwitchD] acl number 2001

[SwitchD-acl-basic-2001] rule permit source 239.0.0.0 0.255.255.255

[SwitchD-acl-basic-2001] quit

[SwitchD] pim

[SwitchD-pim] c-bsr 10.110.5.2 scope 239.0.0.0 8

[SwitchD-pim] c-rp 10.110.5.2 group-policy 2001

[SwitchD-pim] quit

# On Switch F, configure VLAN-interface 109 as a C-BSR and a C-RP for the global-scoped zone.

<SwitchF> system-view

[SwitchF] pim

[SwitchF-pim] c-bsr 10.110.9.1

[SwitchF-pim] c-rp 10.110.9.1

[SwitchF-pim] quit

Verifying the configuration

# Display BSR information on Switch B.

[SwitchB] display pim bsr-info

Scope: non-scoped

State: Accept Preferred

Bootstrap timer: 00:01:44

Elected BSR address: 10.110.9.1

Priority: 64

Hash mask length: 30

Uptime: 00:01:45

Scope: 239.0.0.0/8

State: Elected

Bootstrap timer: 00:00:06

Elected BSR address: 10.110.1.2

Priority: 64

Hash mask length: 30

Uptime: 00:04:54

Candidate BSR address: 10.110.1.2

Priority: 64

Hash mask length: 30

# Display BSR information on Switch D.

[SwitchD] display pim bsr-info

Scope: non-scoped

State: Accept Preferred

Bootstrap timer: 00:01:44

Elected BSR address: 10.110.9.1

Priority: 64

Hash mask length: 30

Uptime: 00:01:45

Scope: 239.0.0.0/8

State: Elected

Bootstrap timer: 00:01:12

Elected BSR address: 10.110.5.2

Priority: 64

Hash mask length: 30

Uptime: 00:03:48

Candidate BSR address: 10.110.5.2

Priority: 64

Hash mask length: 30

# Display BSR information on Switch F.

[SwitchF] display pim bsr-info

Scope: non-scoped

State: Elected

Bootstrap timer: 00:00:49

Elected BSR address: 10.110.9.1

Priority: 64

Hash mask length: 30

Uptime: 00:11:11

Candidate BSR address: 10.110.9.1

Priority: 64

Hash mask length: 30

# Display RP information on Switch B.

[SwitchB] display pim rp-info

BSR RP information:

Scope: non-scoped

Group/MaskLen: 224.0.0.0/4

RP address Priority HoldTime Uptime Expires

10.110.9.1 192 150 00:03:39 00:01:51

Scope: 239.0.0.0/8

Group/MaskLen: 239.0.0.0/8

RP address Priority HoldTime Uptime Expires

10.110.1.2 (local) 192 150 00:07:44 00:01:51

# Display RP information on Switch D.

[SwitchD] display pim rp-info

BSR RP information:

Scope: non-scoped

Group/MaskLen: 224.0.0.0/4

RP address Priority HoldTime Uptime Expires

10.110.9.1 192 150 00:03:42 00:01:48

Scope: 239.0.0.0/8

Group/MaskLen: 239.0.0.0/8

RP address Priority HoldTime Uptime Expires

10.110.5.2 (local) 192 150 00:06:54 00:02:41

# Display RP information on Switch F.

[SwitchF] display pim rp-info

BSR RP information:

Scope: non-scoped

Group/MaskLen: 224.0.0.0/4

RP address Priority HoldTime Uptime Expires

10.110.9.1 (local) 192 150 00:00:32 00:01:58

Troubleshooting PIM

A multicast distribution tree cannot be correctly built

Symptom

None of the routers in the network (including routers directly connected with multicast sources or receivers) have multicast forwarding entries. In other words, a multicast distribution tree cannot be correctly built and the receivers cannot receive multicast data.

Analysis

· On a PIM-DM enabled network, multicast data is flooded from the router that directly connects to the multicast source to the routers that directly connects to the receivers. When the multicast data is flooded to a router, the router creates an (S, G) entry only if it has a route to the multicast source. If the router does not have a route to the multicast source, or if PIM-DM is not enabled on the RPF interface toward the multicast source, the router cannot create an (S, G) entry.

· On a PIM-SM enabled network, when a router wants to join the SPT, the router creates an (S, G) entry only if it has a route to the multicast source. If the router does not have a route to the multicast source, or if PIM-SM is not enabled on the RPF interface toward the multicast source, the router cannot create an (S, G) entries.

· When a multicast router receives a multicast packet, it looks up the existing unicast routing table for the optimal route to the packet source. The outgoing interface of this route act as the RPF interface and the next hop acts the RPF neighbor. The RPF interface completely relies on the existing unicast route and is independent of PIM. The RPF interface must be enabled with PIM, and the RPF neighbor must be a PIM neighbor. If PIM is not enabled on the RPF interface or the RPF neighbor, the multicast distribution tree cannot be built correctly, causing abnormal multicast forwarding.

· Because a hello message does not carry PIM mode information, a PIM router cannot identify what PIM mode its PIM neighbor is running. If the RPF interface on a router and the connected interface of the router's RPF neighbor operate in different PIM modes, the multicast distribution tree cannot be built correctly, causing abnormal multicast forwarding.

· The same PIM mode must run on the entire network. Otherwise, the multicast distribution tree cannot be built correctly, causing abnormal multicast forwarding.

Solution

1. Use display ip routing-table to verify that a unicast route to the multicast source or the RP is available.

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

3. Use display pim neighbor to verify that the RPF neighbor is a PIM neighbor.

4. Verify that PIM and IGMP are enabled on the interfaces that directly connect to the multicast sources or the receivers.

5. Use display pim interface verbose to verify that the same PIM mode is enabled on the RPF interface on a router and the connected interface of the router's RPF neighbor.

6. Use display current-configuration to verify that the same PIM mode is enabled on all routers. For PIM-SM, verify that the BSR and C-RPs are correctly configured.

Multicast data is abnormally terminated on an intermediate router

Symptom

An intermediate router can receive multicast data successfully, but the data cannot reach the last-hop router. An interface on the intermediate router receives multicast data but does not create an (S, G) entry in the PIM routing table.

Analysis

· If a multicast forwarding boundary has been configured through the multicast boundary command, and the multicast packets are kept from crossing the boundary, PIM cannot create routing entries for the packets.

· If an ACL is defined by the source-policy command, and the multicast packets cannot match the ACL rule, PIM cannot create the routing entries for the packets.

Solution

1. Use display current-configuration to verify the multicast forwarding boundary settings. Use multicast boundary to change the multicast forwarding boundary settings to make the multicast packet able to cross the boundary.

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

An RP cannot join an SPT in PIM-SM

Symptom

An RPT cannot be correctly built, or an RP cannot join the SPT toward the multicast source.

Analysis

· RPs are the core of a PIM-SM domain. An RP serves a specific multicast group, and multiple RPs can coexist on a network. Make sure the RP information on all routers is exactly the same to map a specific multicast group to the same RP. Otherwise, multicast forwarding fails.

· If a static RP is configured, use the same static RP configuration on all routers on the entire network. Otherwise, multicast forwarding fails.

Solution

1. Use display ip routing-table to verify that a unicast route to the RP is available on each router.

2. Use display pim rp-info to verify that the dynamic RP information is consistent on all routers.

3. Use display pim rp-info to verify that the same static RPs are configured on all routers on the network.

An RPT cannot be built or multicast source registration fails in PIM-SM

Symptom

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

Analysis

· The C-RPs periodically send advertisement messages to the BSR by unicast. If a C-RP has no unicast route to the BSR, it cannot send advertisement messages to the BSR, and the BSR cannot advertise BSMs containing the information of the C-RP.

· If the BSR does not have a unicast route to a C-RP, it discards the advertisement messages from the C-RP. Therefore, the BSR cannot advertise BSMs containing the information of the C-RP.

· RPs are the core of a PIM-SM domain. Make sure the RP information on all routers is exactly the same to map a specific multicast group to the same RP, and a unicast route to the RP is available on the routers.

Solution

1. Use display ip routing-table to verify that unicast routes to the C-RPs and the BSR are available on each router and that a route is available between each C-RP and the BSR. Make sure each C-RP has a unicast route to the BSR, the BSR has a unicast route to each C-RP, and each router on the network has unicast routes to the C-RPs.

2. Use display pim bsr-info to verify that the BSR information exists on each router, and then use display pim rp-info to verify that the RP information is correct on each router.

3. Use display pim neighbor to verify that PIM neighboring relationship has been correctly established among the routers.

07-IP Multicast Configuration Guide

PIM-DM overview

PIM-SM overview

DR election

Administrative scoping mechanism

Relationship between admin-scope zones and the global scope zone

PIM-SSM overview

Configuring PIM-DM

Enabling PIM-DM

Enabling the state refresh feature

Configuring state refresh parameters

Configuring PIM-DM graft retry timer

Enabling PIM-SM

Configuring a C-BSR

Configuring multicast source registration

Configuring switchover to SPT

Configuration task list

Configuring a multicast data filter

Configuring a hello message filter

Configuring hello message options globally

Configuring hello message options on an interface

Configuring common PIM timers

Configuring common PIM timers globally

Configuring common PIM timers on an interface

Setting the maximum size of each join or prune message

PIM configuration examples

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

A multicast distribution tree cannot be correctly built

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Symptom

Analysis

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

News & Events

Contact Us