CloudEngine 6800&5800 V100R001C00 Configuration Guide - Multicast 04 PDF

CloudEngine 6800&5800 Series Switches
V100R001C00
Configuration Guide - IP Multicast
Issue 04
Date 2013-07-10
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://enterprise.huawei.com
Issue 04 (2013-07-10) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i
About This Document
Intended Audience
This document describes the concepts and configuration procedures of IP multicast on the CE
series switches, and provides the configuration examples.
This document is intended for:
l Data configuration engineers
l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
DANGER
Indicates a hazard with a high level or medium level of risk
which, if not avoided, could result in death or serious injury.
WARNING
Indicates a hazard with a low level of risk which, if not
avoided, could result in minor or moderate injury.
CAUTION
Indicates a potentially hazardous situation that, if not
avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
TIP
Provides a tip that may help you solve a problem or save time.
NOTE
Provides additional information to emphasize or supplement
important points in the main text.

Configuration Guide - IP Multicast About This Document
ii
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[ ] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by
vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by
vertical bars. One item is selected or no item is selected.
{ x | y | ... }
*
Optional items are grouped in braces and separated by
vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]
*
Optional items are grouped in brackets and separated by
vertical bars. You can select one or several items, or select
no item.
&<1-n> The parameter before the & sign can be repeated 1 to n times.
# A line starting with the # sign is comments.

Interface Numbering Conventions
Interface numbers used in this manual are examples. In device configuration, use the existing
interface numbers on devices.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 04 (2013-07-10)
This version has the following updates:
The following information is modified:
l 7.6.4 Configuring a Policy to Filter IGMP Report Messages
iii
l 3.6 Adjusting Multicast Source Control Parameters
l 7.6.7 Setting the Aging Time for Entries Triggered by Multicast Traffic
l 7.6.2 Filtering Multicast Data on an Interface
l 7.6.3 Discarding of Unknown Multicast Flows
l 7.6.4 Configuring a Policy to Filter IGMP Report Messages
The following information is added:
l 6.5 Disabling Soft Forwarding for Multicast Packets
Initial commercial release.
iv
Contents
About This Document.....................................................................................................................ii
1 Basics for IP Multicast Configuration.......................................................................................1
1.1 IP Multicast Overview....................................................................................................................................................2
1.2 Concepts of IPv4 Multicast............................................................................................................................................5
1.3 Multicast Deployment on an IPv4 Network...................................................................................................................9
2 IGMP Configuration...................................................................................................................16
2.1 IGMP Overview...........................................................................................................................................................18
2.2 IGMP Features Supported by the Switch.....................................................................................................................19
2.3 Default Configuration...................................................................................................................................................20
2.4 Configuring Basic IGMP Functions.............................................................................................................................20
2.4.1 Enabling IGMP..........................................................................................................................................................20
2.4.2 Configuring the IGMP Version.................................................................................................................................21
2.4.3 (Optional) Configuring a Static Multicast Group on an Interface.............................................................................22
2.4.4 (Optional) Configuring the Range of Multicast Groups That an Interface Can Join................................................23
2.4.5 Checking the Configuration.......................................................................................................................................23
2.5 Optimizing IGMP Performance....................................................................................................................................24
2.5.1 Configuring the Router-Alert Option........................................................................................................................24
2.5.2 Configuring IGMP Querier Parameters.....................................................................................................................26
2.5.3 Configuring IGMP Fast Leave..................................................................................................................................29
2.5.4 Configuring IGMP On-Demand................................................................................................................................30
2.5.5 Filtering IGMP Messages Based on Source IP Addresses........................................................................................31
2.6 Configuring IGMP SSM Mapping...............................................................................................................................32
2.7 Maintaining IGMP........................................................................................................................................................33
2.7.1 Clearing IGMP Group Memberships........................................................................................................................33
2.7.2 Monitoring IGMP Running Status............................................................................................................................34
2.8 Configuration Example.................................................................................................................................................34
2.8.1 Example for Configuring Basic IGMP Functions.....................................................................................................34
2.8.2 Example for Configuring a Static Multicast Group on an Interface..........................................................................39
2.8.3 Example for Configuring IGMP SSM Mapping.......................................................................................................43
2.9 Common Configuration Errors.....................................................................................................................................50
2.9.1 IGMP Entries Cannot Be Created.............................................................................................................................50
Configuration Guide - IP Multicast Contents
v
2.9.2 (S, G) Entries Are Not Generated After SSM Mapping Is Enabled..........................................................................50
3 PIM-SM (IPv4) Configuration..................................................................................................52
3.1 PIM-SM (IPv4) Overview............................................................................................................................................54
3.2 PIM-SM (IPv4) Features Supported by the Switch......................................................................................................56
3.3 Default Configuration...................................................................................................................................................58
3.4 Configuring PIM-SM in the ASM Model....................................................................................................................59
3.4.1 Enabling PIM-SM......................................................................................................................................................59
3.4.2 Configuring an RP.....................................................................................................................................................60
3.4.3 (Optional) Configuring a BSR Administrative Domain............................................................................................63
3.4.4 (Optional) Configuring SPT Switchover Conditions................................................................................................65
3.4.5 (Optional) Adjusting Control Parameters for Source Registering.............................................................................66
3.4.6 (Optional) Adjusting C-RP Control Parameters........................................................................................................68
3.4.7 (Optional) Adjusting C-BSR Control Parameters.....................................................................................................69
3.5 Configuring PIM-SM in the SSM Model.....................................................................................................................72
3.5.1 Enabling PIM-SM......................................................................................................................................................72
3.5.2 (Optional) Configuring an SSM Group Policy..........................................................................................................72
3.6 Adjusting Multicast Source Control Parameters..........................................................................................................74
3.7 Adjusting Control Parameters for Establishing Neighbor Relationships ....................................................................76
3.7.1 Adjusting Control Parameters for Hello Messages...................................................................................................76
3.7.2 Configuring PIM Neighbor Filtering ........................................................................................................................78
3.8 Adjusting Control Parameters for DR Election............................................................................................................79
3.8.1 Configuring the DR Priority......................................................................................................................................79
3.8.2 Configuring the DR Switchover Delay.....................................................................................................................80
3.9 Adjusting Control Parameters for Join/Prune Messages..............................................................................................81
3.9.1 Adjusting Time Related Parameters for Join/Prune Messages..................................................................................82
3.9.2 Disabling PIM Join/Prune Message Packaging.........................................................................................................83
3.9.3 Adjusting Control Parameters for Prune Delay.........................................................................................................84
3.9.4 Configuring a Join Information Filtering Policy.......................................................................................................86
3.10 Adjusting Assert Control Parameters.........................................................................................................................87
3.11 Configuring PIM Anycast RP.....................................................................................................................................89
3.11.1 Configuring Global Anycast RP..............................................................................................................................89
3.11.2 Configuring Local Addresses for Anycast RPs.......................................................................................................90
3.11.3 Configuring Anycast RP Peers................................................................................................................................91
3.11.4 Checking the Configuration.....................................................................................................................................91
3.12 Configuring PIM BFD................................................................................................................................................92
3.13 Configuring PIM Silent..............................................................................................................................................93
3.14 Maintaining PIM-SM.................................................................................................................................................95
vi
3.14.1 Clearing Statistics About PIM Control Packets......................................................................................................95
3.14.2 Clearing the PIM Status of the Specified Downstream Interfaces in PIM Entries..................................................95
3.14.3 Monitoring the Running Status of PIM-SM ...........................................................................................................96
3.15 Configuration Examples.............................................................................................................................................97
3.15.1 Example for Configuring PIM-SM in the ASM Model..........................................................................................97
3.15.2 Example for Configuring PIM-SM in the SSM Model.........................................................................................106
3.15.3 Example for Configuring PIM for Anycast RP.....................................................................................................115
3.16 Common Configuration Errors.................................................................................................................................121
3.16.1 RPT on a PIM-SM Network Fails to be Established.............................................................................................121
3.16.2 SPT on a PIM-SM Network Fails to be Established.............................................................................................124
3.16.3 Registration Interface Still Exists After the Source DR Registers with the RP....................................................126
4 MSDP Configuration................................................................................................................128
4.1 MSDP Overview.........................................................................................................................................................130
4.2 MSDP Features Supported by the Switch..................................................................................................................131
4.3 Default Configuration.................................................................................................................................................132
4.4 Configuring Basic MSDP Functions..........................................................................................................................132
4.4.1 Enabling MSDP.......................................................................................................................................................132
4.4.2 Configuring MSDP Peers........................................................................................................................................133
4.4.3 (Optional) Configuring Static RPF Peers................................................................................................................135
4.4.4 (Optional) Configuring the MSDP Mesh Group.....................................................................................................136
4.5 Controlling SA Messages and the SA Cache.............................................................................................................137
4.5.1 Configuring the SA Cache.......................................................................................................................................137
4.5.2 Setting Parameters of the SA Request Message......................................................................................................138
4.5.3 Configuring the Content of an SA Message............................................................................................................139
4.5.4 Configuring the Rule for Filtering SA Messages....................................................................................................140
4.6 Configuring MSDP Anycast RP.................................................................................................................................141
4.6.1 Configuring an RP...................................................................................................................................................142
4.6.2 Configuring MSDP Peer Connections.....................................................................................................................143
4.6.3 Configuring the Source RP Address of the SA Message........................................................................................143
4.7 Maintaining MSDP.....................................................................................................................................................144
4.7.1 Clearing Statistics on MSDP Peers.........................................................................................................................144
4.7.2 Clearing (S, G) Information in the SA Cache.........................................................................................................145
4.7.3 Monitoring the Running Status of MSDP...............................................................................................................145
4.8.1 Example for Configuring PIM-SM Inter-domain Multicast Using MSDP.............................................................146
4.8.2 Example for Configuring Inter-AS Multicast Using Static RPF Peers...................................................................155
4.8.3 Example for Configuring Anycast RP in a PIM-SM Domain.................................................................................163
4.8.4 Example for Configuring SA Message Filtering.....................................................................................................170
4.9 Common Configuration Errors...................................................................................................................................177
vii
4.9.1 An MSDP Peer Is Always in Down State...............................................................................................................177
4.9.2 There Is No (S, G) Entry in the SA Cache..............................................................................................................178
4.9.3 RPs Fail to Exchange Registration Information with Each Other...........................................................................178
5 MBGP Configuration................................................................................................................180
5.1 MBGP Overview........................................................................................................................................................181
5.2 MBGP Features Supported by the Switch..................................................................................................................181
5.3 MBGP Default Configuration....................................................................................................................................181
6 Multicast Route Management (IPv4) Configuration..........................................................182
6.1 Overview of Multicast Route Management (IPv4)....................................................................................................183
6.3 Configuring RPF Check Policies................................................................................................................................184
6.3.1 Configuring a Multicast Static Route......................................................................................................................184
6.3.2 Configuring the Longest Match Rule for Multicast Route Selection......................................................................185
6.3.3 Configuring Multicast Load Splitting......................................................................................................................186
6.4 Configuring the Multicast Boundary..........................................................................................................................187
6.5 Disabling Soft Forwarding for Multicast Packets......................................................................................................188
6.6 Maintaining Multicast Routes....................................................................................................................................189
6.6.1 Resetting Multicast Forwarding Entries..................................................................................................................189
6.6.2 Monitoring Multicast Routing and Forwarding.......................................................................................................189
6.7.1 Example for Configuring a Multicast Static Route to Change the RPF Route.......................................................190
6.7.2 Example for Configuring Multicast Static Routes to Connect RPF Routes............................................................195
6.7.3 Example for Configuring Multicast Load Splitting.................................................................................................201
6.8 Common Configuration Errors...................................................................................................................................207
6.8.1 A Multicast Static Route Fails to Take Effect.........................................................................................................207
7 IGMP Snooping Configuration..............................................................................................208
7.1 IGMP Snooping Overview.........................................................................................................................................210
7.2 IGMP Snooping Features Supported by the Switch...................................................................................................211
7.4 Configuring Basic IGMP Snooping Functions...........................................................................................................212
7.4.1 Enabling IGMP Snooping.......................................................................................................................................213
7.4.2 Configuring the IGMP Snooping Version...............................................................................................................214
7.4.3 (Optional) Configuring a Static Router Port............................................................................................................215
7.4.4 (Optional) Configuring a Static Member Port.........................................................................................................216
7.4.5 (Optional) Configuring an IGMP Snooping Querier...............................................................................................217
7.4.6 (Optional) Suppressing Report and Leave Messages..............................................................................................222
7.4.7 (Optional) Configuring the Router-Alert Option.....................................................................................................222
7.4.8 (Optional) Disabling Users from Dynamically Joining Multicast Groups..............................................................223
7.5 Configuring IGMP Snooping Proxy...........................................................................................................................224
viii
7.6 Configuring the IGMP Snooping Policy....................................................................................................................226
7.6.1 Configuring a Multicast Group Policy....................................................................................................................226
7.6.2 Filtering Multicast Data on an Interface..................................................................................................................227
7.6.3 Discarding of Unknown Multicast Flows................................................................................................................228
7.6.4 Configuring a Policy to Filter IGMP Report Messages..........................................................................................229
7.6.5 Configuring a Policy to Filter IGMP Query Messages...........................................................................................229
7.6.6 Configuring the Multicast Group Type for a VLAN...............................................................................................230
7.6.7 Setting the Aging Time for Entries Triggered by Multicast Traffic........................................................................231
7.7 Configuring Membership Fast-Update.......................................................................................................................232
7.7.1 Setting the Aging Time of Group Member Ports....................................................................................................233
7.7.2 Setting the Aging Time of Dynamic Router Ports..................................................................................................234
7.7.3 Configuring Fast Leave for Member Ports..............................................................................................................234
7.7.4 Sending IGMP Query Messages upon Topology Changes.....................................................................................235
7.8 Configuring IGMP Snooping SSM Mapping.............................................................................................................236
7.8.1 (Optional) Configuring an SSM Group Policy........................................................................................................237
7.8.2 Configuring IGMP Snooping SSM Mapping..........................................................................................................237
7.9 Maintaining IGMP Snooping.....................................................................................................................................239
7.9.1 Clearing IGMP Snooping Entries............................................................................................................................239
7.9.2 Clearing IGMP Snooping Statistics.........................................................................................................................240
7.9.3 Displaying the IGMP Snooping Running Status.....................................................................................................240
7.10 Configuration Examples...........................................................................................................................................241
7.10.1 Example for Configuring IGMP Snooping...........................................................................................................241
7.10.2 Example for Configuring Layer 2 Multicast Through Static Interfaces................................................................244
7.10.3 Example for Configuring an IGMP Snooping Querier.........................................................................................247
7.10.4 Example for Configuring IGMP Snooping Proxy.................................................................................................251
7.10.5 Example for Configuring Multicast SSM Mapping..............................................................................................254
7.11 Common Configuration Errors.................................................................................................................................257
7.11.1 Layer 2 Multicast Packets Cannot Be Forwarded.................................................................................................257
7.11.2 The Multicast Group Policy Does Not Take Effect...............................................................................................258
8 Static Multicast MAC Address Configuration.................................................................... 260
8.1 Multicast MAC Address.............................................................................................................................................261
8.2 Configuring a Static Multicast MAC Address...........................................................................................................262
8.3 Example for Configuring a Static Multicast MAC Address.......................................................................................263
9 Multicast Network Management............................................................................................266
9.1 Overview of Multicast Network Management...........................................................................................................267
9.2 Multicast Network Management Features Supported by the Switch.........................................................................267
9.3 Configuring Multicast Network Management............................................................................................................267
9.3.1 Enabling Multicast Network Management..............................................................................................................267
9.3.2 Enabling the Trap Function for a Specified Module...............................................................................................268
ix
9.3.3 Adjusting the Interval for PIM to Send Trap Messages..........................................................................................269
x
1 Basics for IP Multicast Configuration
About This Chapter
This chapter describes basic concepts, protocols, and features of IP multicast, and provides
multicast service deployment on IPv4 networks.
1.1 IP Multicast Overview
Multicast technology implements point-to-multipoint data transmission to save network
bandwidth and reduce network loads. It is widely used in IPTV, real-time data transmission, and
multimedia conference applications.
1.2 Concepts of IPv4 Multicast
Before using IPv4 multicast services, familiarize yourself with basic concepts of multicast,
multicast models, as well as multicast addresses and multicast protocols used on IPv4 networks.
A good understanding of these concepts and features helps you complete multicast service
configuration efficiently.
1.3 Multicast Deployment on an IPv4 Network
This section describes typical multicast service scenarios on an IPv4 network and applications
of multicast protocols and features in these scenarios, helping you configure multicast services
efficiently. Typical multicast service scenarios include multicast within a PIM domain, multicast
between PIM-SM domains, and multicast between ASs.
Configuration Guide - IP Multicast 1 Basics for IP Multicast Configuration
1
1.1 IP Multicast Overview
Multicast technology implements point-to-multipoint data transmission to save network
bandwidth and reduce network loads. It is widely used in IPTV, real-time data transmission, and
multimedia conference applications.
NOTE
Multicast routers mentioned in this document refer to routers or Layer 3 switches. The CE series
switches support IP multicast routing and can be used as a multicast router.
Why Multicast Is Needed
Traditional IP communication supports two transmission modes: unicast and broadcast. In
unicast transmission, a source sends an independent data packet to each host that requiring its
data. In broadcast transmission, a source sends data to all the hosts on the local network segment,
regardless whether the hosts require its data.
To transmit data to multiple destination hosts but not all hosts, a source host uses the broadcast
mode or sends multiple copies of data in unicast mode to the destination hosts one by one, as
shown in Figure 1-1.
2
Figure 1-1 Point-to-multipoint data transmission in unicast and broadcast modes
IP network
Packets for HostA
HostB
HostC
Source
SwitchB
SwitchA SwitchD
SwitchC
SwitchE
HostA
SwitchF
Receiver
Receiver
Packets for HostC
Unicast transmission
A network segment
Packets for all hosts
HostB
HostC
Source
SwitchB
SwitchA SwitchD
SwitchC
SwitchE
HostA
SwitchF
Receiver
Receiver
Broadcast transmission

l In unicast mode, the amount of data transmitted on the network is proportional to the number
of users that require the data. If a large number of users require the same data, the source
host must send many copies of data to these users, consuming high bandwidth on the source
host and network. Therefore, the unicast mode is not suitable for batch data transmission
and is applicable only to networks with a small number of users.
l In broadcast mode, data is sent to all hosts on a network segment regardless of whether
they need the data. This threatens information security and causes storms on the network
segment. Therefore, the broadcast mode is not suitable for data transmission from a source
to specified destinations and it also wastes network bandwidth.
3
In a summary, traditional unicast and broadcast modes cannot effectively implement point-to-
multipoint data transmission.
Multicast is a solution to point-to-multipoint data transmission. As shown in Figure 1-2, the
source sends only one copy of data, and all the hosts that require the data can receive the same
data copy. Other hosts on the network cannot receive the data.
Figure 1-2 Point-to-multipoint data transmission in multicast mode
IP network
Packets for the multicast group
HostB
HostC
Source
SwitchB
SwitchA SwitchD
SwitchC
SwitchE
HostA
SwitchF
Receiver
Receiver
Multicast transmission

Advantages of Multicast
Multicast has the following advantages over unicast and broadcast:
l Compared with the unicast mode, the multicast mode starts to copy data and distribute data
copies on the network node as far from the source as possible. Therefore, the amount of
data and network resource consumption will not increase greatly when the number of
receivers increases.
l Compared with the broadcast mode, the multicast mode transmits data only to receivers
that require the data. This saves network resources and enhances data transmission security.
Applications
IP multicast effectively addresses the problem of point-to-multipoint data transmission. This
technology efficiently transmits data from one point to multiple points over an IP network, saving
network bandwidth and reducing network loads. More importantly, multicast technology
facilitates deployment of new value-added services, including live broadcasting, IPTV, tele-
education, telemedicine, online radio, video conferencing, and other information services on the
Internet.
NOTE
Multicast technologies used on IPv4 and IPv6 networks are collectively called IP multicast. The CE series
switches support only IPv4 multicast.
4
1.2 Concepts of IPv4 Multicast
Before using IPv4 multicast services, familiarize yourself with basic concepts of multicast,
multicast models, as well as multicast addresses and multicast protocols used on IPv4 networks.
A good understanding of these concepts and features helps you complete multicast service
configuration efficiently.
Basic Concepts of Multicast
As shown in Figure 1-3, an information source sends data to interested users in multicast mode.
Figure 1-3 Multicast transmission
IP network
Multicast packets
HostB
HostC
Source
SwitchB
SwitchA SwitchD
SwitchC
SwitchE
HostA
SwitchF
Receiver
Receiver

l Multicast group: a group of receivers identified by an IP multicast address. After joining a
multicast group, hosts can receive multicast data sent to this multicast group.
l Multicast source: a sender of multicast data. Source in Figure 1-3 is a multicast source. A
multicast source can simultaneously send data to multiple multicast groups. Multiple
multicast sources can simultaneously send data to a multicast group. A multicast source
does not need to join any multicast groups.
l Multicast group member: a host that has joined a multicast group. HostA and HostC in
Figure 1-3 are multicast group members. Memberships in a multicast group change
dynamically. Hosts can join or leave a multicast group any time. Members of a multicast
group are located anywhere on a network.
l Multicast router: a router or Layer 3 switch that supports Layer 3 multicast. The switches
in Figure 1-3 are multicast routers. In addition to multicast routing functions, multicast
routers connected to user network segments provide multicast member management
functions.
Multicast Models
The following multicast models are used depending on the way receivers treat multicast sources:
5
l Any-Source Multicast (ASM) model: provides multicast distribution only based on
multicast group addresses. A multicast group address identifies a collection of network
services, and multicast packets sent from any source to this address obtain the same service.
Receiver hosts can receive data sent from any source to this group after joining the group.
l Source-Specific Multicast (SSM) model: provides service for the data flow from a specific
source to a specific group. Receiver hosts can specify the source from which they want to
receive data when they join a group. After joining the group, the hosts receive only the data
sent from the specified source.
The SSM and ASM models use different multicast address ranges so that receivers can easily
identify the two models.
IPv4 Multicast Addresses
On an IPv4 network, multicast sources and group members use IPv4 multicast addresses to
communicate. IPv4 multicast addresses are Class D IP addresses in the range of 224.0.0.0 to
239.255.255.255. Table 1-1 describes the meaning of each segment in this range.
Table 1-1 Range and description of IPv4 multicast addresses
Class D Address Range Description
224.0.0.0-224.0.0.255 Group addresses reserved for local links. These
addresses are reserved by the Internet Assigned Number
Authority (IANA) for routing protocols, and are called
permanent multicast addresses. The addresses identify
a group of network devices and are not used for multicast
forwarding.
224.0.1.0-231.255.255.255
233.0.0.0-238.255.255.255
ASM group addresses that are valid on the entire
network.
232.0.0.0-232.255.255.255 Default SSM group addresses that are valid on the entire
network.
239.0.0.0-239.255.255.255 Administrative multicast addresses. This is the default
group address range of BootStrap Router (BSR)
administrative domains. Addresses in this range are
private addresses and are valid only in a BSR
administrative domain. BSR administrative domains
can use the same multicast address.

IPv4 Multicast MAC Addresses
When unicast IP packets are transmitted on an Ethernet network, the packets use receiver MAC
addresses as destination MAC addresses. However, the destination of a multicast data packet is
a group with changeable members but not a specific receiver. Therefore, multicast data packets
must use IPv4 multicast MAC addresses on an Ethernet network. IPv4 multicast MAC addresses
are link-layer addresses mapped from IPv4 multicast addresses.
As defined by the IANA, leftmost 24 bits of an IPv4 multicast MAC address are 0x01005e, the
25th bit is 0, and the rightmost 23 bits are the same as the rightmost 23 bits of a multicast IP
6
address, as shown in Figure 1-4. For example, if the IPv4 multicast address of a group is
224.0.1.1, the IPv4 multicast MAC address of this group is 01-00-5e-00-01-01.
Figure 1-4 Mapping between an IPv4 multicast address and an IPv4 multicast MAC address
25 bits MAC address prefix
XXXX X
1110 XXXX X XXXXXXX XXXXXXXX XXXXXXXX
00000001 00000000 01011110 0 XXXXXXX XXXXXXXX XXXXXXXX
48-bit MAC address
5 bits information loss
23 bits
mapping
...... ......
32-bit IP address

The first 4 bits of an IPv4 multicast address are 1110 (multicast identifier), and only 23 bits of
the last 28 bits are mapped to a MAC address. That is, information about 5 bits of the IP address
is lost. As a result, 32 multicast IP addresses are mapped to the same MAC address, which may
cause address conflicts in MAC address-based multicast forwarding. When this occurs, change
the multicast forwarding mode to IP address-based forwarding. For example, IP multicast
addresses 224.0.1.1, 224.128.1.1, 225.0.1.1, and 239.128.1.1 are all mapped to multicast MAC
address 01-00-5e-00-01-01.
IPv4 Multicast Protocols
Table 1-2 IPv4 multicast protocols
Protocol Function Remarks
Internet Group Management
Protocol (IGMP)
IGMP manages IPv4
multicast group members and
runs on the end of a multicast
network (network segments
where Layer 3 multicast
devices connect to user
hosts). Hosts use the IGMP
protocol to join or leave
multicast groups, and Layer 3
multicast devices use the
IGMP protocol to manage
and maintain group
memberships. IGMP can
interact with upper-layer
multicast routing protocols.
IGMP has three versions:
IGMPv1, IGMPv2, and
IGMPv3.
All the three versions support
the ASM model. IGMPv3
can be independently used in
the SSM model, whereas
IGMPv1 and IGMPv2 must
be used with SSM mapping.
7
Protocol Independent
Multicast (PIM)
PIM runs on an IPv4 network
and sends multicast data
flows to multicast devices
connected to multicast group
members interested in the
data flows. The PIM protocol
has two modes, the sparse
mode (PIM-SM) applicable
to large-scale networks with
sparsely distributed group
members, and the dense
mode (PIM-DM) applicable
to small-scale networks with
concentrated group
members.
NOTE
The CE series switches support
only PIM-SM.
The PIM-DM model does not
need to differentiate the ASM
and SSM models.
The PIM-SM model
differentiates the ASM and
SSM models based on
multicast addresses in
multicast data and protocol
packets.
l If multicast addresses of
packets are in the range of
SSM group addresses,
PIM-SM uses the SSM
model to provide
multicast services. The
SSM model has a high
efficiency and simplifies
the multicast address
allocation process. It is
applicable to the scenario
where a group has only
one specific source.
l If multicast addresses of
packets are in the range of
ASM group addresses,
PIM-SM uses the ASM
model to provide
multicast services.
Multicast Source Discovery
Protocol (MSDP)
MSDP is an inter-domain
multicast protocol that
implements multicast
forwarding between PIM-
SM domains. Multicast
devices in a PIM-SM domain
use MSDP to discover
multicast sources in other
PIM-SM domains, and send
information about active
sources in other PIM-SM
domains to receivers in the
local PIM domain.
MSDP is not required when
PIM-SM uses the SSM
model.
MultiProtocol Border
Gateway Protocol (MBGP)
MBGP is also called
multicast BGP. It enables
multicast data to be
transmitted between
multicast sources and
receivers in different
autonomous systems (ASs).
-
8
IGMP snooping and IGMP
snooping proxy
IGMP snooping enables a
switch to create and maintain
a Layer 2 multicast
forwarding table by listening
to IGMP packets exchanged
between the upstream Layer
3 device and user hosts. The
switch controls forwarding of
multicast data packets based
on the Layer 2 multicast
forwarding table to reduce
multicast data flooding on the
Layer 2 network.
IGMP snooping proxy
enables a switch to substitute
for an upstream device to
send IGMP Query messages
and receive IGMP Report/
Leave messages from
downstream devices. This
function saves bandwidth
between the upstream device
and the switch.
IGMP snooping is an
extension of IGMP on Layer
2 network devices. You can
specify the IGMP snooping
version on a switch to enable
the switch to process IGMP
packets of specific versions.

1.3 Multicast Deployment on an IPv4 Network
This section describes typical multicast service scenarios on an IPv4 network and applications
of multicast protocols and features in these scenarios, helping you configure multicast services
efficiently. Typical multicast service scenarios include multicast within a PIM domain, multicast
between PIM-SM domains, and multicast between ASs.
CAUTION
Configure multicast services based on the actual situations and service requirements on your
network. This section provides only deployment of basic multicast services.
NOTE
Before deploying IPv4 multicast services on a network, ensure that IPv4 unicast routes on the network are
reachable.
Multicast Within a PIM Domain
On a small-scale network, all network devices and hosts belong to the same PIM domain. Figure
1-5 shows the multicast service deployment in this scenario.
9
Figure 1-5 Multicast service deployment within a PIM domain
Source
SwitchC
SwitchA
SwitchB
IGMP
PIM PIM
IP network
IGMP Snooping /
IGMP Snooping
Proxy
HostA
Receiver
LAN
SwitchD
HostB
Receiver
IGMP

Table 1-3 Multicast protocols used for multicast within a PIM domain
Protocol Application Position Purpose
PIM (mandatory) PIM must be configured on all
interfaces of multicast devices in
the PIM domain, including
SwitchA, SwitchB, and
SwitchC.
For the configuration procedure,
see 3 PIM-SM (IPv4)
Configuration.
PIM sends multicast data from
the multicast source to SwitchB
and SwitchC connected to
multicast receivers.
IGMP (mandatory) IGMP must be configured on
user-side interfaces of Layer 3
multicast devices SwitchB and
SwitchC.
see 2 IGMP Configuration.
IGMP allows receiver hosts to
join or leave multicast groups,
and allows SwitchB and
SwitchC to maintain and manage
multicast memberships.
10
IGMP snooping and
IGMP snooping
proxy (optional)
IGMP snooping and IGMP
snooping proxy must be
configured in VLANs on
SwitchD, a device between a
Layer 3 multicast device and
user hosts.
see 7 IGMP Snooping
Configuration.
IGMP snooping listens to IGMP
packets exchanged between
SwitchB and hosts to create and
maintain a Layer 2 multicast
forwarding table. In this manner,
SwitchD can control forwarding
of multicast data packets on the
Layer 2 network.
IGMP snooping proxy allows
SwitchD to substitute for
SwitchB to send IGMP Query
messages and substitute hosts to
send IGMP Report/Leave
messages.

Multicast Between PIM-SM Domains
A multicast domain can be divided into multiple isolated PIM-SM domains to facilitate
management of multicast resources, including multicast groups, multicast sources, and group
members. To enable the PIM-SM domains to exchange multicast data, MSDP needs to be
deployed between the PIM-SM domains, as shown in Figure 1-6.
NOTE
MSDP is not required when PIM-SM uses the SSM model.
11
Figure 1-6 Multicast service deployment between PIM-SM domains
PIM-SM 2
Source1
SwitchB
SwitchA
RP
IP network
Source2
Host
SwitchC
SwitchD
LAN
PIM-SM 1
RP
SwitchF
IP network
(Receiver)
IGMP
PIM
PIM
MSDP
IGMP Snooping /
SwitchE
PIM
IGMP Snooping
Proxy
SwitchG
PIM
PIM

Table 1-4 Multicast protocols used for multicast between PIM-SM domains
PIM-SM (mandatory) PIM-SM must be configured on
all interfaces of multicast
switches in the PIM-SM
domains, including Switches A
to G (except F).
see 3 PIM-SM (IPv4)
Configuration.
PIM-SM sends multicast data
from multicast sources Source 1
and Source 2 to SwitchD
connected to multicast receivers.
Receiver hosts proactively join a
multicast group, and multicast
data is forwarded to the receiver
hosts thought rendezvous points
(RPs) in the PIM-SM domains.
user-side interfaces of SwitchD.
and allows SwitchD to maintain
and manage multicast
memberships.
12
MSDP (mandatory) MSDP must be configured on
the RP in each PIM-SM domain,
that is, SwitchA and SwitchC.
see 4 MSDP Configuration.
MSDP transmits multicast data
between PIM-SM1 and PIM-
SM2. Host in PIM-SM2 can
receive data from Source 1.
IGMP snooping and
IGMP snooping
proxy (optional)
IGMP snooping must be
configured in VLANs on
SwitchF, a between user hosts
and multicast devices.
see 7 IGMP Snooping
Configuration.
IGMP snooping listens to IGMP
messages exchanged between
SwitchD and hosts to create and
maintain a Layer 2 multicast
forwarding table. In this manner,
SwitchF can control forwarding
of multicast data packets on the
Layer 2 network.
IGMP snooping proxy allows
SwitchF to substitute for
SwitchD to send IGMP Query
messages and substitute hosts to
send IGMP Report/Leave
messages.

Inter-AS Multicast
PIM forwards multicast data based on a unicast routing table; therefore, multicast forwarding
paths are the same as unicast forwarding paths. When a multicast source and receivers are located
in different ASs, a multicast distribution tree needs to be set up between the ASs. In this scenario,
MBGP can be used to create a multicast routing table independent of the unicast routing table.
Then multicast data is transmitted based on the multicast routing table. Figure 1-7 shows the
deployment of inter-AS multicast service deployment.
NOTE
Before configuring MBGP between ASs, configure BGP between the ASs.
13
Figure 1-7 Inter-AS multicast service deployment
SwitchE
SwitchD
RP
PIM-SM 2
Source2
PIM-SM 3
HostB
SwitchF
AS 200
RP
RP
PIM-SM 1
HostA
SwitchA
AS 100
Source1
SwitchB
SwitchG
SwitchC
SwitchH
(Receiver)
(Receiver)
PIM
PIM
PIM
PIM
PIM
MSDP
IGMP
IGMP
MSDP
MBGP

Table 1-5 Multicast protocols used for inter-AS multicast
PIM-SM (mandatory) PIM-SM must be configured on
all interfaces of multicast
switches in the PIM-SM
domains, including Switches A
to H.
see 3 PIM-SM (IPv4)
Configuration.
PIM-SM sends multicast data
and Source 2 to SwitchB and
SwitchH connected to multicast
receivers. Receiver hosts
proactively join a multicast
group, and multicast data is
forwarded to the receiver hosts
thought RPs in the PIM-SM
domains.
14
user-side interfaces of SwitchB
and SwitchH.
and allows SwitchB and
SwitchH to maintain and
manage multicast memberships.
MBGP (mandatory) MBGP must be configured on
SwitchA and SwitchF located at
the AS borders.
see 5 MBGP Configuration.
MBGP sends multicast data
and Source 2 to receivers in
another AS based on an
independent multicast routing
table.
MSDP (mandatory) MSDP must be configured on
the RP in each PIM-SM, that is,
SwitchA, SwitchD, and
SwitchF.
see 4 MSDP Configuration.
MSDP transmits multicast data
among PIM-SM1, PIM-SM2,
and PIM-SM3.
15
2 IGMP Configuration
About This Chapter
You can manage multicast group members by configuring IGMP on multicast device interfaces
connected to user networks.
2.1 IGMP Overview
The Internet Group Management Protocol (IGMP) is a protocol in the TCP/IP protocol suite
used by IPv4 hosts to report their group memberships to any immediately-neighboring multicast
routers.
2.2 IGMP Features Supported by the Switch
The IGMP features supported by the switch include basic IGMP settings, Router-Alert option,
IGMP querier, SSM mapping.
2.3 Default Configuration
This section provides the default IGMP configuration.
2.4 Configuring Basic IGMP Functions
After basic IGMP configurations are complete on interfaces connected to user networks, hosts
can connect to multicast networks and receive multicast packets.
2.5 Optimizing IGMP Performance
After being enabled, IGMP can work normally using the default configuration. You can also
adjust IGMP parameter settings to enhance network security and performance.
2.6 Configuring IGMP SSM Mapping
On a multicast network that provides the SSM service, interfaces of multicast devices run
IGMPv3, but some hosts can run only IGMPv1 or IGMPv2. To enable multicast devices to
provide the SSM service for hosts running IGMPv1 or IGMPv2, configure SSM mapping on
multicast devices.
2.7 Maintaining IGMP
You can clear IGMP group memberships and monitor IGMP running information.
2.8 Configuration Example
This section provides IGMP configuration examples to help you configure IGMP functions on
a multicast network.
2.9 Common Configuration Errors
Configuration Guide - IP Multicast 2 IGMP Configuration
16
This section describes common faults caused by incorrect IGMP configurations and provides
the troubleshooting procedure.
17
2.1 IGMP Overview
The Internet Group Management Protocol (IGMP) is a protocol in the TCP/IP protocol suite
used by IPv4 hosts to report their group memberships to any immediately-neighboring multicast
routers.
To receive multicast data, receivers must connect to an IP multicast network and joins
corresponding multicast groups. IGMP defines a signaling mechanism that IP hosts on user
networks use to communicate with multicast routers.
After IGMP is configured on receiver hosts and multicast routers on a shared network segment,
the receiver hosts can dynamically join multicast groups, and multicast routers can manage
multicast group members on the local network.
At present, IGMP has three versions: IGMPv1 (defined in RFC 1112), IGMPv2 (defined in RFC
2236), and IGMPv3 (defined in RFC 3376). All IGMP versions support the Any-Source
Multicast (ASM) model. IGMPv3 can be directly applied to the Source-Specific Multicast
(SSM) model, whereas IGMPv1 and IGMPv2 can be applied to the SSM model after SSM
mapping is configured.
Figure 2-1 IGMP networking
HostA HostB HostC
Ethernet
SwitchA
SwitchB
Multicast network
IGMP IGMP

As shown in Figure 2-1, IGMP is configured on the receiver hosts and switches on the shared
network segment.
l If a user network segment connects to multiple switches, one switch is elected as the querier
to periodically send Query messages to the network segment.
l The querier periodically sends Query messages to hosts and receives Report and Leave
messages from hosts. From these messages, the querier obtains information about receivers
(members) of multicast groups on network segments connected to its interfaces. If a
network segment has members of a multicast group, the switches forward multicast data
packets to this network segment. If a network segment has no multicast member, the
switches do not forward multicast data packets to this network segment.
18
l Hosts send Report messages to join multicast groups. If a host is running IGMPv2 or
IGMPv3, it can proactively leave a multicast group by sending a Leave message when it
does not need to receive multicast data of the multicast group.
2.2 IGMP Features Supported by the Switch
The IGMP features supported by the switch include basic IGMP settings, Router-Alert option,
IGMP querier, SSM mapping.
NOTE
On the CE series switches, IGMP can be configured only on VLANIF and loopback interfaces. In this document,
IGMP is configured on VLANIF interfaces unless otherwise specified. Before configuring IGMP on a VLANIF
interface, add physical interfaces to the corresponding VLAN.
Basic IGMP Functions
The switch supports the following basic IGMP settings:
l IGMP versions, including IGMPv1, IGMPv2, and IGMPv3. These IGMP versions define
different IGMP messages. To ensure normal communication between the switch and
receiver hosts, configure compatible IGMP versions on the switch and hosts. (A later IGMP
version running on the switch is compatible with an earlier IGMP version running on hosts.)
l Static multicast groups. When an interface connects to long-term members of a multicast
group, you can statically bind the interface to the multicast group so that the group members
can receive multicast data quickly and steadily.
l Range of multicast groups that an interface can join. You can apply an ACL to an interface
to limit the range of the multicast groups that the interface serves. This configuration
improves security of IGMP applications.
IGMP Performance Optimization
You can configure the following items on the switch to improve IGMP security or network
performance:
l Router-Alert option: To improve device security, configure the switch to accept only IGMP
packets with the Router-Alert option.
l Querier: Proper querier parameter settings ensure that memberships can be updated quickly
and prevent network congestion caused by excessive IGMP packets.
l Fast leave: This function allows fast response to Leave messages sent by hosts and saves
network bandwidth.
l IGMP on-demand: This function maintains memberships based on service requirements of
multicast members, reducing packets transmitted on the network.
l IGMP message filtering: This function filters IGMP messages received on an interface
based on source IP addresses, improving security.
SSM Mapping
Source-Specific Multicast (SSM) allows multicast group members to receive multicast data from
the specified multicast sources. Only IGMPv3 supports the SSM model. If some hosts can run
only IGMPv1 or IGMPv2, you can configure SSM mapping on the switch so that the switch can
provide the SSM service for these hosts.
19
This section provides the default IGMP configuration.
Table 2-1 lists the default IGMP configuration.
Table 2-1 Default IGMP configuration
Parameter Default Setting
IP multicast routing Disabled
IGMP Disabled
IGMP version IGMPv2
IGMP SSM mapping Disabled

After basic IGMP configurations are complete on interfaces connected to user networks, hosts
can connect to multicast networks and receive multicast packets.
Pre-configuration Tasks
Before configuring basic IGMP functions, complete the following task:
l Configuring a unicast routing protocol to ensure that IP routes between nodes are reachable
Configuration Process
IGMP needs to be configured on member hosts and switches connected to the hosts. This section
describes how to configure IGMP on a switch.
2.4.1 Enabling IGMP and 2.4.2 Configuring the IGMP Version are mandatory and other tasks
are optional.
2.4.1 Enabling IGMP
Context
You must enable IP multicast routing before configuring IGMP. Other multicast functions can
be configured only after IP multicast routing is enabled. All the multicast configurations become
invalid when IP multicast routing is disabled.
IGMP is configured on interfaces connected to user hosts.
Procedure
Step 1 Run:
20
system-view
The system view is displayed.
Step 2 Run:
multicast routing-enable
IP multicast routing is enabled.
Step 3 Run:
interface interface-type interface-number
The interface view is displayed.
Step 4 Run:
pim sm
Protocol Independent Multicast-Sparse Mode (PIM-SM) is enabled on the interface.
Before enabling IGMP on an interface, enable PIM-SM on the interface to allow the interface
to forward multicast data packets.
Step 5 Run:
igmp enable
IGMP is enabled on the interface.
Step 6 Run:
commit
The configuration is committed.
----End
2.4.2 Configuring the IGMP Version
Context
A switch running a later IGMP version can identify Membership Report messages of an earlier
IGMP version. However, a switch running an earlier IGMP version cannot identify Membership
Report messages of a later IGMP version. To ensure normal IGMP operation, ensure that the
switch runs the same IGMP version as member hosts or a later IGMP version.
If multiple switches exist on a shared network segment, configure the same IGMP version on
all switch interfaces. Otherwise, errors may occur in IGMP operation because interfaces running
different IGMP versions send packets with different formats.
Procedure
Step 1 Run:
system-view
Step 2 Run:
21
Step 3 Run:
igmp version { 1 | 2 | 3 }
The IGMP version is specified for the interface.
By default, an interface runs IGMPv2 after IGMP is enabled on the interface.
Step 4 Run:
commit
----End
2.4.3 (Optional) Configuring a Static Multicast Group on an
Interface
Context
You can configure static multicast groups on user-side interfaces of the switch in some scenarios,
for example:
l There are long-term group members on a shared network segment, and the switch needs to
forward multicast data to these group members quickly and steadily.
l A network segment has no group member or hosts on the network segment cannot send
Report messages, but multicast data needs to be sent to this network segment.
After a static multicast group is configured on an interface, the switch considers that the multicast
group always has members on the network segment of the interface. Therefore, the switch always
forwards multicast data of the multicast group.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
igmp static-group group-address [ inc-step-mask { group-mask | group-mask-length }
number group-number ] [ source source-address ]
The interface is statically bound to a multicast group or a source-group.
If the interface is a loopback interface, the switch forwards the received data only when a user
requests the data. This saves bandwidth. If the interface is a VLANIF interface, the switch
forwards the received data immediately.
By default, no static multicast group is configured on an interface.
Step 4 Run:
commit
22
----End
2.4.4 (Optional) Configuring the Range of Multicast Groups That
an Interface Can Join
Context
To enable hosts on the same network segment as an interface to receive packets of specified
multicast groups, use an ACL to filter Membership Report messages received on the interface.
This ACL allows the switch to maintain only memberships of the interface in these multicast
groups. For details on how to configure an ACL, see "ACL Configuration" in the CloudEngine
6800&5800 Series Switches Configuration Guide - Security.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
igmp group-policy { acl-number | acl-name acl-name } [ 1 | 2 | 3 ]
An ACL is applied to specify the range of multicast groups that the interface can join.
By default, an interface can join any multicast group.
Step 4 Run:
commit
----End
2.4.5 Checking the Configuration
Context
After completing basic IGMP configuration on an interface, you can run the following
commands in any view to check the IGMP configuration, IGMP running information, and
membership information on the interface.
Procedure
l Run the display igmp interface [ interface-type interface-number | up | down ]
[ verbose ] command to check the IGMP configuration and running information on an
interface.
23
l Run the display igmp group [ group-address | interface interface-type interface-
number ]
*
static [ verbose ] command to check information about members of a static
multicast group.
number ]
*
[ verbose ] command to check information about the members that have
dynamically joined a multicast group.
----End
2.5 Optimizing IGMP Performance
After being enabled, IGMP can work normally using the default configuration. You can also
adjust IGMP parameter settings to enhance network security and performance.
You can perform the following configuration tasks in any sequence as required.
2.5.1 Configuring the Router-Alert Option
Context
Generally, a network device sends a packet to the corresponding protocol module for processing
only when the destination address of the packet is the address of a local interface. According to
this rule, IGMP packets cannot be sent to the IGMP module because their destination addresses
are multicast addresses but not a local interface address. As a result, the network device cannot
maintain group memberships. The Router-Alert option is introduced to solve this problem. If a
packet contains the Router-Alert option in the IP header, devices that receive the packet send
the packet to the corresponding protocol module without checking the destination IP address of
the packet.
By default, the switch sends received IGMP packets to the IGMP module for processing no
matter whether the packets have the Router-Alert option in their IP headers. This ensures
compatibility between the switch and other devices. To improve device performance, reduce
transmission cost, and enhance protocol security, configure the switch to discard IGMP packets
without the Router-Alert option.
You can also configure the switch to send IGMP packets with or without the Router-Alert option.
By default, the switch sends IGMP packets with the Router-Alert option.
24
NOTE
The Router-Alert option can be configured in the IGMP view or interface view.
l The configuration in the IGMP view is valid globally, whereas the configuration in the interface view
is valid only for the specific interface.
l If the Router-Alert option is configured in the interface view and the IGMP view, the configuration in
the interface view takes precedence over the configuration in the IGMP view. If the Router-Alert option
is not configured on an interface, the interface uses the configuration in the IGMP view.
l If non-default configuration is performed in the IGMP view, the default configuration in the interface
view does not take effect.
Procedure
l Configuring the Router-Alert option globally
1. Run:
system-view
2. Run:
igmp
The IGMP view is displayed.
3. Run:
require-router-alert
The switch is configured to check for the Router-Alert option in IGMP packets and
discard IGMP packets without the Router-Alert option.
4. Run:
undo send-router-alert disable
The switch is configured to send IGMP packets with the Router-Alert option.
5. Run:
commit
l Configuring the Router-Alert option on an interface
1. Run:
system-view
2. Run:
3. Run:
igmp require-router-alert
The switch is configured to discard IGMP packets without the Router-Alert option.
4. Run:
undo igmp send-router-alert disable
The switch is configured to send IGMP packets with the Router-Alert option.
5. Run:
commit
25
----End
2.5.2 Configuring IGMP Querier Parameters
Context
IGMP maintains group memberships using Query and Report messages. When multiple
multicast devices exist on a network segment, an IGMP querier is elected among them to send
IGMP Query packets. The IGMP querier can work properly using default parameter settings.
You can modify these parameters as required.
Querier Parameter Description Default Setting Version
Query interval
(interval for sending
IGMP General
Query messages)
The querier sends
IGMP General
Query messages at
the specified interval
to maintain group
memberships of
interfaces.
60 seconds IGMPv1, IGMPv2,
IGMPv3
IGMP robustness
variable
The robustness
variable defines the
following values:
l Number of times
the querier sends
General Query
messages after
startup. The
message sending
interval is 1/4 of
query interval.
l Number of times
the querier sends
Group-Specific
Query messages
after receiving a
Leave message.
The message
sending interval
is the same as the
configured last
member query
interval.
2 IGMPv1, IGMPv2,
IGMPv3
26
Querier Parameter Description Default Setting Version
Maximum response
time for IGMP Query
messages
After a group
member receives an
IGMP Query
message, it must send
a Report message
within the maximum
response time.
10 seconds IGMPv2, IGMPv3
Other querier present
interval
If non-queriers do
not receive any
Query message
within the other
querier present
interval, they
consider the querier
invalid and trigger
election of a new
querier.
The other querier
present interval is
calculated using the
following formula:
Other querier present
interval = Interval for
sending General
Query messages x
Robustness variable
+ Maximum
response time x 1/2
When all the
parameters to the
right of the equal
mark use the default
values, the other
querier present
interval is 125
seconds.
IGMPv2, IGMPv3
Last member query
interval (interval for
sending IGMP
Group-Specific
Query messages)
When the querier
receives a Leave
message that a host
sends to leave a
multicast group, the
querier sends Group-
Specific Query
messages at intervals
to check for other
members in the
multicast group. This
parameter specifies
the interval at which
Group-Specific
Query messages are
sent.
1 second IGMPv2, IGMPv3

During IGMP querier configuration, ensure that the interval for sending General Query messages
is larger than the maximum response time for IGMP Query messages and is smaller than the
other querier present interval.
27
NOTE
If IGMP is enabled on user-side interfaces of multiple devices on a shared network segment, the devices
must have the same querier configuration. Otherwise, IGMP may not function normally.
The IGMP querier parameters can be configured in the IGMP view or interface view.
l The configuration in the IGMP view is valid globally, whereas the configuration in the interface view
is valid only for the specific interface.
l If a querier parameter is configured in the interface view and the IGMP view, the configuration in the
interface view takes precedence over the configuration in the IGMP view. If a querier parameter is not
configured on an interface, the interface uses the configuration in the IGMP view.
l If non-default configuration is performed in the IGMP view, the default configuration in the interface
view does not take effect.
Procedure
l Configuring global IGMP querier parameters
1. Run:
system-view
2. Run:
igmp
3. Run:
timer query interval
The interval for sending IGMP General Query messages is configured.
4. Run:
robust-count robust-value
The IGMP robustness variable is configured.
5. Run:
max-response-time interval
The maximum response time for IGMP Query messages is configured.
6. Run:
timer other-querier-present interval
The other querier present interval is configured.
7. Run:
lastmember-queryinterval interval
The interval for sending IGMP Group-Specific Query messages is configured.
8. Run:
commit
l Configuring IGMP querier parameters on an interface
1. Run:
system-view
28
2. Run:
3. Run:
igmp timer query interval
The interval for sending IGMP General Query messages is configured.
4. Run:
igmp robust-count robust-value
The IGMP robustness variable is configured.
5. Run:
igmp max-response-time interval
The maximum response time for IGMP Query messages is configured.
6. Run:
igmp timer other-querier-present interval
The other querier present interval is configured.
7. Run:
igmp lastmember-queryinterval interval
The interval for sending IGMP Group-Specific Query messages is configured.
8. Run:
commit
----End
2.5.3 Configuring IGMP Fast Leave
Context
In some scenarios, a querier interface connects to only one receiver host. If the host frequently
switches between multiple multicast groups, you can configure the fast leave function on the
interface so that the interface can quickly respond to Leave messages sent from the host.
After the fast leave function is configured, the querier does not send a Group-Specific Query
message after receiving a Leave message from the host. Instead, the querier directly notifies the
upstream multicast device that the host has left the multicast group. The fast leave function
reduces delay in response to Leave messages and saves network bandwidth.
IGMP fast leave applies only to IGMPv2 and IGMPv3.
Procedure
Step 1 Run:
system-view
Step 2 Run:
29
Step 3 Run:
igmp prompt-leave [ group-policy { acl-number | acl-name acl-name } ]
Fast leave is configured on the interface.
By default, the switch sends a Group-Specific Query message after receiving a Leave message.
Step 4 Run:
commit
----End
2.5.4 Configuring IGMP On-Demand
Context
The IGMP on-demand function enables a querier to maintain group memberships based on
requirements of members. In a standard IGMP working process, the querier sends Query
messages periodically and collects group membership information based on received Report and
Leave messages. Multicast members respond to every Query message they receive. After IGMP
on-demand is configured on the querier, the querier does not send Query messages, reducing
IGMP packets exchanged between the querier and member hosts.
After IGMP on-demand is configured on an interface, the switch:
l Does not send IGMP Query messages from this interface.
l Creates IGMP group entries only after receiving IGMP Report messages. The entries are
never aged.
l Deletes the matching IGMP group entry immediately after receiving a Leave message.
IGMP on-demand applies only to IGMPv2 and IGMPv3.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
igmp on-demand
IGMP on-demand is enabled on the interface. The interface then does not send IGMP Query
messages, and IGMP group entries on the interface are never aged.
By default, an interface sends Query messages and participates in querier election.
Step 4 Run:
30
commit
----End
2.5.5 Filtering IGMP Messages Based on Source IP Addresses
Context
IGMP runs between member hosts and the Layer 3 multicast device that is directly connected
to the host network segment. A multicast device processes all received Report messages. To
improve security, you can configure the switch to filter IGMP messages received on an interface.
Messages that can be filtered include IGMP Report and Leave messages.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
igmp ip-source-policy
A policy is configured on the interface to filer Report/Leave messages based on source IP
addresses.
By default, the switch does not filter Report/Leave messages and processes all the received
Report/Leave messages.
After Report/Leave message filtering is configured, the switch processes Report messages based
on source IP addresses as follows:
l If the source IP address of a Report message is 0.0.0.0 or on the same network segment as
the IP address of the inbound interface, the switch processes the Report message.
l If the source IP address of a Report message is on a different network segment than the IP
address of the inbound interface, the switch discards the Report message.
Step 4 Run:
commit
----End
31
Context
After completing the preceding configuration, you can run the following commands in any view
to check the adjusted membership information, IGMP configuration, and IGMP running
information.
Procedure
number ]
*
[ static ] [ verbose ] command to check information about members of an IGMP
multicast group.
interface.
----End
2.6 Configuring IGMP SSM Mapping
On a multicast network that provides the SSM service, interfaces of multicast devices run
IGMPv3, but some hosts can run only IGMPv1 or IGMPv2. To enable multicast devices to
provide the SSM service for hosts running IGMPv1 or IGMPv2, configure SSM mapping on
multicast devices.
2.4.1 Enabling IGMP
Context
You can map an SSM group address to one or more source addresses so that a (*, G) entry in
an IGMPv1 or IGMPv2 Report message can be converted into a group of (S, G) entries. By
default, SSM group addresses range from 232.0.0.0 to 232.255.255.255. You can expand the
range of SSM group addresses. For details, see 3.5.2 (Optional) Configuring an SSM Group
Policy.
Procedure
Step 1 Run:
system-view
Step 2 Run:
igmp
Step 3 Run:
ssm-mapping group-address { group-mask | group-mask-length } source-address
A group address is mapped to a multicast source address.
Step 4 Run:
quit
32
Return to the system view.
Step 5 Run:
Step 6 Run:
igmp ssm-mapping enable
SSM mapping is enabled on the interface.
To ensure that hosts running any IGMP version on a network segment can obtain SSM services,
enable IGMPv3 on switch interfaces.
Step 7 Run:
commit
----End
Checking the Configuration
After configuring SSM mapping on an interface, run the following commands in any view to
check the configured mapping entries and whether SSM mapping is enabled on the interface.
number ]
*
ssm-mapping [ verbose ] command to check information about group
memberships established with SSM mapping.
l Run the display igmp ssm-mapping { group [ group-address ] | interface [ interface-
type interface-number ] } command to check SSM mapping entries configured and whether
SSM mapping is enabled on an interface.
Related Concepts
Multicast Service Models
IGMP SSM Mapping
2.7 Maintaining IGMP
You can clear IGMP group memberships and monitor IGMP running information.
2.7.1 Clearing IGMP Group Memberships
Context
CAUTION
After IGMP group memberships are cleared, group members may fail to receive multicast data.
Therefore, confirm your operation before clearing IGMP group information.
33
Procedure
l Run the reset igmp group { all | interface interface-type interface-number { all | group-
address [ mask { group-mask | group-mask-length } ] [ source-address [ mask { source-
mask | source-mask-length } ] ] } } command in the user view to clear information about
IGMP-attached group memberships.
l Run the undo igmp static-group { all | group-address [ inc-step-mask { group-mask |
group-mask-length } number group-number ] [ source source-address ] } command in
the interface view to clear static group memberships.
----End
2.7.2 Monitoring IGMP Running Status
Context
To check the IGMP running status during routine maintenance, run the following display
commands in any view.
Procedure
number ]
*
[ static ] [ verbose ] command to check information about IGMP group
memberships.
interface.
number ]
*
ssm-mapping [ verbose ] command to check information about group
memberships established with SSM mapping.
l Run the display igmp ssm-mapping { group [ group-address ] | interface [ interface-
type interface-number ] } command to check SSM mapping entries configured and whether
SSM mapping is enabled on an interface.
l Run the display igmp control-message counters [ interface interface-type interface-
number ] [ message-type { query | report } ] command check statistics about IGMP
messages.
----End
2.8 Configuration Example
This section provides IGMP configuration examples to help you configure IGMP functions on
a multicast network.
2.8.1 Example for Configuring Basic IGMP Functions
Networking Requirements
As shown in Figure 2-2, video on demand (VoD) users receive video streams in multicast mode.
User hosts are located on two network segments: N1 and N2. Receivers HostA and HostC are
34
located on the two network segments respectively. The source sends video streams to group
addresses 225.1.1.1 to 225.1.1.5. HostA orders only the program of group 225.1.1.1, and HostC
can receive all the programs.
Figure 2-2 Networking diagram for basic IGMP configuration
SwitchA
PIM network
HostA
Receiver
HostB
HostC
HostD
SwitchB
SwitchC
1
0
G
E
1
/
0
/
2
10G
E
1/0/2
1
0
G
E
1
/
0
/
2
10GE1/0/1
10GE1/0/1
10GE1/0/1
Receiver
N1
N2
SwitchD
1
0
G
E
1
/0
/4
1
0
G
E
1
/
0
/
3
10G
E
1/0/2
VLANIF10
10.110.1.1/24
V
L
A
N
I
F
1
1
1
9
2
.
1
6
8
.
1
.
1
/
2
4
1
9
2
.
1
6
8
.
1
.
2
/
2
4
V
L
A
N
I
F
1
1
1
0
G
E
1
/
0
/
1
V
LA
N
IF21
192.168.2.2/24
V
L
A
N
I
F
3
1
1
9
2
.
1
6
8
.
3
.
2
/
2
4
V
L
A
N
IF
4
0
1
9
2
.1
6
8
.4
.1
/2
4
V
LA
N
IF21 192.168.2.1/24
VLANIF20
10.110.2.1/24
VLANIF20
10.110.2.2/24
V
L
A
N
I
F
3
1
1
9
2
.
1
6
8
.
3
.
1
/
2
4

Configuration Roadmap
To meet the preceding requirements, configure basic IGMP functions and limit the range of
multicast groups on the interface connected to the network segment of HostA. The configuration
roadmap is as follows:
1. Configure a unicast routing protocol to implement IP interworking.
Configure IP addresses for interfaces and configure a unicast routing protocol on each
switch. Multicast routing protocols depend on unicast routing protocols.
2. Configure basic multicast functions to enable multicast data to be forwarded on the network.
Enable PIM-SM and configure a rendezvous point (RP) on each switch. Enable IGMP on
the interfaces connected to the receiver network segments.
3. Control the multicast data that HostA can receive.
Configure an ACL on the interface of SwitchA connected to the network segment of HostA
to filter multicast data sent to HostA.
Procedure
Step 1 Configure IP addresses for interfaces and configure a unicast routing protocol on each switch.
Configure an IP address and mask for each interface according to Figure 2-2. Configure OSPF
on each switch to ensure IP connectivity between them, and enable them to dynamically update
routing information. The configuration details are not mentioned here.
35
Step 2 Enable IP multicast routing on each switch and enable PIM-SM on all interfaces.
# On SwitchA, enable multicast routing in the system view, enable PIM-SM on all interfaces,
and configure VLANIF40 of SwitchD as a static RP. The configurations of SwitchB, SwitchC
and SwitchD are similar to the configuration of SwitchA, and are not mentioned here.
[~SwitchA] multicast routing-enable
[~SwitchA] interface vlanif 10
[~SwitchA-Vlanif10] pim sm
[~SwitchA-Vlanif10] commit
[~SwitchA-Vlanif10] quit
[~SwitchA] pim
[~SwitchA-pim] static-rp 192.168.4.1
[~SwitchA-pim] commit
[~SwitchA-pim] quit
Step 3 On SwitchA, SwitchB, and SwitchC, enable IGMP on the interfaces connected to the receiver
network segments.
# Enable IGMP on VLANIF10 of SwitchA. The configurations of SwitchB and SwitchC are
similar to the configuration of SwitchA, and are not mentioned here.
[~SwitchA-Vlanif10] igmp enable
Step 4 Allow VLANIF10 of SwitchA to join only multicast group 225.1.1.1.
# On SwitchA, create an ACL, configure a rule that permits only packets of multicast group
225.1.1.1, and then apply the ACL to VLANIF10.
[~SwitchA] acl number 2001
[~SwitchA-acl4-basic-2001] rule permit source 225.1.1.1 0
[~SwitchA-acl4-basic-2001] commit
[~SwitchA-acl4-basic-2001] quit
[~SwitchA-Vlanif10] igmp group-policy 2001
Step 5 Verify the configuration.
# Run the display igmp interface command to check the IGMP configuration and running status
on each interface. The following is the IGMP information on VLANIF10 of SwitchA:
<SwitchA> display igmp interface vlanif 10
Interface information of VPN-Instance: public net
Vlanif 10(10.110.1.1):
IGMP is enabled
Current IGMP version is 2
IGMP state: up
IGMP group policy: 2001
IGMP limit: -
Value of query interval for IGMP (negotiated): -
Value of query interval for IGMP (configured): 60 s
Value of other querier timeout for IGMP: 0 s
Value of maximum query response time for IGMP: 10 s
Querier for IGMP: 10.110.1.1 (this router)
----End
36
Configuration Files
l Configuration file of SwitchA
#
sysname SwitchA
#
vlan batch 10 11
#
#
acl number 2001
rule 5 permit source 225.1.1.1 0
#
interface Vlanif10
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp group-policy 2001
#
interface Vlanif11
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
port default vlan 10
#
interface 10GE1/0/2
port link-type trunk
port trunk allow-pass vlan 11
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
l Configuration file of SwitchB
#
sysname SwitchB
#
vlan batch 20 21
#
#
interface Vlanif20
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif21
ip address 192.168.2.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
37
pim
static-rp 192.168.4.1
#
return
l Configuration file of SwitchC
#
sysname SwitchC
#
vlan batch 20 31
#
#
interface Vlanif20
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
#
interface Vlanif31
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
l Configuration file of SwitchD
#
sysname SwitchD
#
vlan batch 11 21 31 40
#
#
interface Vlanif11
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif21
ip address 192.168.2.2 255.255.255.0
pim sm
#
interface Vlanif31
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Vlanif40
ip address 192.168.4.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
38
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
2.8.2 Example for Configuring a Static Multicast Group on an
Interface
As shown in Figure 2-3, video on demand (VoD) users receive video streams in multicast mode.
User hosts are located on two network segments: N1 and N2. Receiver HostA is located on N1,
and receivers HostC and HostD are located on N2. HostA wants to receive data of multicast
group 225.1.1.3 for a long time, while HostC and HostD do not have such requirements.
Figure 2-3 Networking diagram for static multicast group configuration
SwitchA
PIM network
HostA
Receiver
HostB
HostC
HostD
SwitchB
SwitchC
1
0
G
E
1
/
0
/
2
10G
E
1/0/2
1
0
G
E
1
/
0
/
2
10GE1/0/1
10GE1/0/1
10GE1/0/1
Receiver
N1
N2
SwitchD
1
0
G
E
1
/0
/4
1
0
G
E
1
/
0
/
3
10G
E
1/0/2
VLANIF10
10.110.1.1/24
V
L
A
N
I
F
1
1
1
9
2
.
1
6
8
.
1
.
1
/
2
4
1
9
2
.
1
6
8
.
1
.
2
/
2
4
V
L
A
N
I
F
1
1
1
0
G
E
1
/
0
/
1
V
LA
N
IF21
192.168.2.2/24
V
L
A
N
I
F
3
1
1
9
2
.
1
6
8
.
3
.
2
/
2
4
V
L
A
N
IF
4
0
1
9
2
.1
6
8
.4
.1
/2
4
V
LA
N
IF21 192.168.2.1/24
VLANIF20
10.110.2.1/24
VLANIF20
10.110.2.2/24
V
L
A
N
I
F
3
1
1
9
2
.
1
6
8
.
3
.
1
/
2
4

39
To meet the preceding requirements, configure static multicast group 225.1.1.3 on the interface
connected to the network segment of HostA. The configuration roadmap is as follows:
Enable PIM-SM and configure a rendezvous point (RP) on each switch. Enable IGMP on
the interfaces connected to the receiver network segments.
3. Enable HostA to receive data of multicast group 225.1.1.3 for a long time.
On SwitchA, configure a static multicast group 225.1.1.3 on the interface connected to the
network segment of HostA.
Procedure
Step 2 Enable IP multicast routing on each switch and enable PIM-SM on all interfaces.
# On SwitchA, enable multicast routing in the system view, enable PIM-SM on all interfaces,
and configure VLANIF40 of SwitchD as a static RP. The configurations of SwitchB, SwitchC
and SwitchD are similar to the configuration of SwitchA, and are not mentioned here.
[~SwitchA] pim
[~SwitchA-pim] quit
Step 3 On SwitchA, SwitchB, and SwitchC, enable IGMP on the interfaces connected to the receiver
network segments.
# Enable IGMP on VLANIF10 of SwitchA. The configurations of SwitchB and SwitchC are
similar to the configuration of SwitchA, and are not mentioned here.
Step 4 Configure static multicast group 225.1.1.3 on VLANIF10 of SwitchA.
[~SwitchA-Vlanif10] igmp static-group 225.1.1.3
40
# Run the display igmp group static command to check the static multicast group configuration.
The command output shows that static multicast group 225.1.1.3 has been configured on
VLANIF10.
<SwitchA> display igmp group static
Static join group information of VPN-Instance: public net
Vlanif10:
Total 1 entry
Group Address Source Address Expires
225.1.1.3 0.0.0.0 never
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 11
#
#
interface Vlanif10
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp static-group 225.1.1.3
#
interface Vlanif11
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
#
sysname SwitchB
#
vlan batch 20 21
#
#
interface Vlanif20
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
41
#
interface Vlanif21
ip address 192.168.2.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
#
sysname SwitchC
#
vlan batch 20 31
#
#
interface Vlanif20
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
#
interface Vlanif31
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
#
sysname SwitchD
#
#
#
interface Vlanif11
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif21
ip address 192.168.2.2 255.255.255.0
42
pim sm
#
interface Vlanif31
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Vlanif40
ip address 192.168.4.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
2.8.3 Example for Configuring IGMP SSM Mapping
As shown in Figure 2-4, the multicast network runs PIM-SM, and uses ASM and SSM models
to provide multicast services. The Switch interface connected to the receiver network segment
runs IGMPv3, whereas the receiver runs IGMPv2 and does not support IGMPv3. Therefore, the
receiver cannot specify a multicast source from which it wants to receive multicast data when
joining a multicast group.
The range of SSM group addresses on the network is 232.1.1.0/24. Source 1, Source 2, and
Source 3 all send multicast data to the multicast groups in this range. However, the receiver only
wants to receive multicast data from Source 1 and Source 3.
43
Figure 2-4 Networking diagram for the SSM mapping configuration
10GE1/0/1
Source2
10.10.2.1/24
Source1
10.10.1.1/24
Receiver
10.10.4.1/24
PIM-SM
SwitchB
Source3
10.10.3.1/24
SwitchA
SwitchC
SwitchD
10GE1/0/1
10GE1/0/1
10GE1/0/1
10GE1/0/3 10GE1/0/3
10GE1/0/3 10GE1/0/3
10GE1/0/2
10GE1/0/2
10GE1/0/2
10GE1/0/2
VLANIF10
VLANIF20
VLANIF30
10.10.1.2/24
192.168.1.1/24
192.168.4.2/24
VLANIF30
192.168.4.1/24
VLANIF20
192.168.1.2/24
VLANIF11
VLANIF31
192.168.2.1/24
VLANIF31
192.168.2.2/24
10.10.2.2/24
VLANIF12
VLANIF21
192.168.3.1/24
10.10.3.2/24
VLANIF21
192.168.3.2/24
VLANIF13
10.10.4.2/24

To meet the preceding requirements, configure basic multicast functions on the switches, and
then configure SSM mapping on SwitchD. The configuration roadmap is as follows:
Enable PIM-SM on each switch and configure a rendezvous point (RP). Enable IGMP on
the interface connected to the receiver network segment.
3. Configure SSM mapping to enable the receiver to select multicast sources.
Enable SSM mapping on the interface of SwitchD connected to the receiver network
segment, and configure SSM mapping rules on SwitchD.
Procedure
Step 2 Enable IP multicast routing on each switch, and enable PIM-SM and IGMP on interfaces.
# On SwitchD, enable IP multicast routing in the system view and enable PIM-SM on all
interfaces. Enable IGMP on VLANIF13 and set the IGMP version to v3.
[~SwitchD] multicast routing-enable
44
[~SwitchD] interface vlanif 13
[~SwitchD-Vlanif13] pim sm
[~SwitchD-Vlanif13] igmp enable
[~SwitchD-Vlanif13] igmp version 3
[~SwitchD-Vlanif13] commit
[~SwitchD-Vlanif13] quit
# Enable IP multicast routing on SwitchA and enable PIM-SM on all interfaces. The
configurations of SwitchB and SwitchC are similar to the configuration of SwitchA, and are not
mentioned here.
# Configure VLANIF30 as a C-BSR and C-RP on SwitchD.
[~SwitchD] pim
[~SwitchD-pim] c-bsr vlanif 30
[~SwitchD-pim] c-rp vlanif 30
[~SwitchD-pim] commit
[~SwitchD-pim] quit
Step 3 Enable SSM mapping on the interface connected to the receiver network segment.
# Enable SSM mapping on VLANIF13 of SwitchD.
[~SwitchD-Vlanif13] igmp ssm-mapping enable
Step 4 Configure the range of SSM group addresses on all switches.
# Set the range of SSM group addresses to 232.1.1.0/24 on SwitchA. The configurations of
SwitchB, SwitchC, and SwitchD are similar to the configuration of SwitchA, and are not
mentioned here.
[~SwitchA-acl4-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[~SwitchA] pim
[~SwitchA-pim] ssm-policy 2000
[~SwitchA-pim] quit
45
Step 5 Configure SSM mapping rules on SwitchD.
# Map the multicast groups in the range of 232.1.1.0/24 to Source 1 and Source 3.
[~SwitchD] igmp
[~SwitchD-igmp] ssm-mapping 232.1.1.0 24 10.10.1.1
[~SwitchD-igmp] ssm-mapping 232.1.1.0 24 10.10.3.1
[~SwitchD-igmp] commit
[~SwitchD-igmp] quit
# Check the mappings between multicast sources and groups on SwitchD.
<SwitchD> display igmp ssm-mapping group
IGMP SSM-Mapping conversion table of VPN-Instance: public net
Total 2 entries 2 entries matched
00001. (10.10.1.1, 232.1.1.0)
00002. (10.10.3.1, 232.1.1.0)
Total 2 entries matched
# The receiver joins group 232.1.1.1.
# Run the display igmp group ssm-mapping command on SwitchD to view information about
the group memberships established with SSM mapping. The command output is as follows:
<SwitchD> display igmp group ssm-mapping
IGMP SSM mapping interface group report information of VPN-Instance: public net
Vlanif13 (10.10.4.2):
Total 1 IGMP SSM-Mapping Group reported
Group Address Last Reporter Uptime Expires
232.1.1.1 10.10.4.1 00:01:44 00:00:26
<SwitchD> display igmp group ssm-mapping verbose
Interface group report information of VPN-Instance: public net
Limited entry of this VPN-Instance: -
Vlanif13 (10.10.4.2):
Total entry on this interface: 1
Limited entry on this interface: -
Total 1 IGMP SSM-Mapping Group reported
Group: 232.1.1.1
Uptime: 00:04:25
Expires: 00:02:07
Last reporter: 10.10.4.1
Last-member-query-counter: 0
Last-member-query-timer-expiry: off
Group mode: exclude
Version1-host-present-timer-expiry: off
Version2-host-present-timer-expiry: 00:02:07
# Run the display pim routing-table command on SwitchD to view the PIM-SM multicast
routing table. The command output is as follows:
<SwitchD> display pim routing-table
VPN-Instance: public net
Total 2 (S, G) entries

(10.10.1.1, 232.1.1.1)
Protocol: pim-ssm, Flag: SG_RCVR
UpTime: 00:19:40
Upstream interface: Vlanif30
Upstream neighbor: 192.168.4.2
RPF prime neighbor: 192.168.4.2
Downstream interface(s) information:
Total number of downstreams: 1
1: Vlanif13
46
Protocol: ssm-map, UpTime: 00:19:40, Expires: -
(10.10.3.1, 232.1.1.1)
Protocol: pim-ssm, Flag: SG_RCVR
UpTime: 00:19:40
1: Vlanif13
Protocol: ssm-map, UpTime: 00:19:40, Expires: -
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20 30
#
#
acl number 2000
rule 5 permit source 232.1.1.0 0.0.0.255
#
interface Vlanif10
ip address 10.10.1.2 255.255.255.0
pim sm
#
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Vlanif30
ip address 192.168.4.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 10.10.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname SwitchB
#
vlan batch 11 20 31
#
47
#
acl number 2000
#
interface Vlanif11
ip address 10.10.2.2 255.255.255.0
pim sm
#
interface Vlanif20
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif31
ip address 192.168.2.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 10.10.2.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname SwitchC
#
vlan batch 12 21 31
#
#
acl number 2000
#
interface Vlanif12
ip address 10.10.3.2 255.255.255.0
pim sm
#
interface Vlanif21
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface Vlanif31
ip address 192.168.2.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
48
#
ospf 1
area 0.0.0.0
network 10.10.3 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname SwitchD
#
vlan batch 13 21 30
#
#
acl number 2000
#
interface Vlanif13
ip address 10.10.4.2 255.255.255.0
pim sm
igmp enable
igmp version 3
igmp ssm-mapping enable
#
interface Vlaniaf21
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Vlanif30
ip address 192.168.4.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 10.10.4 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
igmp
ssm-mapping 232.1.1.0 255.255.255.0 10.10.1.1
ssm-mapping 232.1.1.0 255.255.255.0 10.10.3.1
#
pim
c-bsr vlanif 30
c-rp vlanif 30
ssm-policy 2000
#
return
49
This section describes common faults caused by incorrect IGMP configurations and provides
2.9.1 IGMP Entries Cannot Be Created
Fault Description
Hosts request data of multicast group G after IGMP configuration is complete. However, the
last-hop multicast device does not create any IGMP entry.
Procedure
Step 1 Check whether the ordered group address is in the range of reserved group addresses (224.0.0.1
to 224.0.0.255). When receiving IGMP Report messages with destination addresses in this range,
the device does not generate IGMP entries.
Step 2 Run the display interface interface-type interface-number command to check whether the
interface directly connected to the host network segment is in Up state.
If the interface is in Down state, check whether the interface is correctly connected, whether the
interface has been shut down using the shutdown command, and whether the interface has a
correct IP address configured.
Step 3 Run the display current-configuration command to check whether multicast routing is enabled.
If the command output does not contain "multicast routing-enable", run the multicast routing-
enable command in the system view to enable multicast routing.
Step 4 Run the display current-configuration interface interface-type interface-number command to
check whether IGMP is enabled on the interface directly connected to the host network segment.
If the command output does not contain "igmp enable", IGMP is not enabled on the interface.
Run the igmp enable command in the interface view to enable IGMP.
Step 5 Run the display igmp interface interface-type interface-number command to check whether
the IGMP configuration on the interface is correct.
l The IGMP version (identified by Current IGMP version in the command output) running on
the interface must be later than or the same as the IGMP version running on the hosts.
l If the IGMP group policy field displays an ACL rule, check whether the multicast group
address is rejected by the ACL rule. If so, modify the ACL rule to allow the multicast device
to receive Report messages of this multicast group.
----End
2.9.2 (S, G) Entries Are Not Generated After SSM Mapping Is
Enabled
50
Fault Description
The interface is enabled with SSM mapping and IGMP, and is configured with a static SSM
mapping policy. After the interface receives IGMPv1 or IGMPv2 Report messages, (S, G) entry
doesn't exist in the MFIB table.
Procedure
Step 1 Check whether G in the (*, G) Report message is in the SSM group address range.
Run the display this command in the PIM view to check the current configuration. If the
command output displays the ssm-policy { basic-acl-number | acl-name acl-name } command,
the SSM group address range is redefined on the device.
Run the display acl { acl-number | name acl-name | all } command to check the ACL
configuration. Ensure that G is in the SSM group address range. By default, the SSM group
address range is 232.0.0.0/8.
----End
51
3 PIM-SM (IPv4) Configuration
About This Chapter
The PIM protocol implements multicast routing and data forwarding in a domain. The PIM-SM
protocol is a multicast routing protocol in sparse mode. It applies to a large-scale network with
sparsely-distributed group members.
3.1 PIM-SM (IPv4) Overview
This section describes PIM-SM application scenario and implementation.
3.2 PIM-SM (IPv4) Features Supported by the Switch
PIM-SM features supported by the switch include PIM-SM for ASM, PIM-SM for SSM, PIM
for Anycast RP, PIM BFD, and PIM silent.
This section describes the default PIM-SM configuration.
3.4 Configuring PIM-SM in the ASM Model
A PIM-SM network uses the ASM model to provide multicast services for user hosts. User hosts
in a multicast group can receive multicast data sent from any multicast source to this group.
3.5 Configuring PIM-SM in the SSM Model
A PIM-SM network uses the SSM model to provide specified multicast services for user hosts.
User hosts in a multicast group can receive multicast data sent from the specified multicast source
to this group.
3.6 Adjusting Multicast Source Control Parameters
You can configure the source address-based filtering rules and multicast source lifetime to
improve security of packets and control traffic on networks.
3.7 Adjusting Control Parameters for Establishing Neighbor Relationships
PIM devices establish PIM neighbor relationships by exchanging Hello messages.
3.8 Adjusting Control Parameters for DR Election
PIM devices exchange Hello messages to elect a DR, which is responsible for sending protocol
packets at the source side or the group member side.
3.9 Adjusting Control Parameters for Join/Prune Messages
A multicast device sends Join messages upstream to require forwarding of multicast data, and
Prune messages upstream for requiring to stop forwarding multicast data. You can configure
Configuration Guide - IP Multicast 3 PIM-SM (IPv4) Configuration
52
control parameters for Join/Prune messages as required. If there is no special requirement, the
default values are recommended.
3.10 Adjusting Assert Control Parameters
When a device receives multicast data through a downstream interface, the device knows that
other upstream devices exist on this network segment. The device then sends an Assert message
to participate in the election of the unique upstream device.
3.11 Configuring PIM Anycast RP
Anycast RP configures several RPs with the same address in a PIM-SM domain and establishes
peer relationships between RPs so that the multicast source can register with the closest RP and
the multicast receiver can join the closest RP. This releases burdens on a single RP, implements
RP backup, and optimizes multicast forwarding paths.
3.12 Configuring PIM BFD
After detecting a fault on the peer, BFD immediately instructs the PIM module to trigger a new
DR election rather than waits until the neighbor relationship times out. This shortens multicast
forwarding interruption time and improves reliability of multicast data transmission.
3.13 Configuring PIM Silent
A device interface directly connected to hosts must have PIM enabled. When a malicious host
sends a large number of forged PIM Hello messages to the interface, the device may break down.
To defend against such an attack, set the state of the interface to PIM silent.
3.14 Maintaining PIM-SM
This section describes how to maintain PIM-SM, including clearing statistics about PIM control
packets, clearing the PIM status of the specified downstream interfaces of PIM entries, and
monitoring the running status of PIM-SM.
3.15 Configuration Examples
This section provides configuration examples to describe how to construct a basic PIM-SM
network and configure basic PIM-SM functions.
This section describes common configuration errors and the corresponding troubleshooting
flowcharts.
53
3.1 PIM-SM (IPv4) Overview
This section describes PIM-SM application scenario and implementation.
PIM-SM is short for Protocol Independent Multicast - Sparse Mode. PIM-SM forwards multicast
data to networks that have multicast group members, but not all networks.
PIM-SM applies to the Any-Source Multicast (ASM) model and Source-Specific Multicast
(SSM) model.
PIM-SM for ASM
In the ASM model, an Rendezvous Point (RP) is the forwarding core of the PIM-SM network.
All PIM routers on the PIM-SM network know the position of the RP. When a new group member
appears on the network, the last-hop switch sends a Join message to the RP. A (*, G) entry is
created hop by hop, and an RPT with the RP as the root is generated. When an active multicast
source appears on the network, the first-hop router encapsulates the multicast data in a Register
message and sends the Register message to the RP. The RP then creates an (S, G) entry and
registers multicast source information. The RP then decapsulates the Register message and
forwards multicast data along the RPT to group members.
To reduce the burden on the RP and RPT, an SPT switchover is triggered.
l The RP sends a Join message to the multicast source to create an SPT between the source
and the RP.
l The DR at the group member side sends a Join message to the multicast source to create
an SPT between the source and the group member.
As shown in Figure 3-1, SwitchBand SwitchCinitiate SPT switchovers to the source.
54
Figure 3-1 SPT switchover in the ASM model
Source
HostA HostB
Multicast packets
Receiver
RP
SwitchA SwitchB
SwitchD
SwitchC
SwitchE
PIM-SM
DR
DR DR
Register
Receiver
RPT
Source
HostA HostB
Multicast packets
Receiver
RP
SwitchA SwitchB
SwitchD
SwitchC
SwitchE
PIM-SM
DR
DR
DR
Receiver
SPT
RPT
Before switchover After switchover

PIM-SM for SSM
In the SSM model, user hosts know the exact positions of the multicast sources in advance. When
user hosts join multicast groups, they can specify the sources from which they want to receive
multicast data. The DR at the group member side then sends Join messages directly to the
multicast sources. The Join message is transmitted upstream hop by hop to set up an SPT between
the source and group members. The SSM model uses only part of the PIM-SM technology and
IGMPv3. There is no need to maintain an RP, set up an RPT, or register a multicast source. As
shown in Figure 3-2, HostA and HostB join a multicast group G. HostA needs to receive
multicast data from S1, and HostB needs to receive multicast data from S2. The DRs at the group
member side send Join messages to the multicast sources to set up SPTs.
55
Figure 3-2 Setting up an SPT in the SSM model
Source
HostA HostB
Multicast packets
Receiver
SwitchA
SwitchB
SwitchD
SwitchC
SwitchE
PIM-SM
DR
DR
Receiver
(S1,G) SPT
DR
S1
S2
Source
DR
(S2,G) SPT

3.2 PIM-SM (IPv4) Features Supported by the Switch
PIM-SM features supported by the switch include PIM-SM for ASM, PIM-SM for SSM, PIM
for Anycast RP, PIM BFD, and PIM silent.
NOTE
On the CE series switches, PIM-SM can be configured only on VLANIF and loopback interfaces. In this
document, PIM-SM is configured on VLANIF interfaces unless otherwise specified. Before configuring PIM-
SM on a VLANIF interface, add physical interfaces to the corresponding VLAN.
PIM-SM for ASM
In the ASM model, PIM-SM supports the following functions:
l Static RP
l Dynamic RP
l Listening of Auto-RP messages
l BSR administrative domain
l Configuring SPT switchover conditions
l Adjusting source registration control parameters
56
l Adjusting C-RP parameters
l Adjusting C-BSR parameters
PIM-SM for SSM
In the SSM model, you can configure an SSM group policy to specify an SSM group range.
Adjusting PIM-SM Control Parameters
After basic PIM-SM functions for ASM or SSM are configured, PIM-SM domains can work
properly with default parameter settings. Multicast data is forwarded from multicast sources to
network segments with multicast group members. You can also adjust PIM-SM control
parameters on the device, as shown in Table 3-1.
Table 3-1 PIM-SM control parameters
Parameter Description
Control parameters for multicast sources A multicast device can control forwarding of
multicast data based on multicast sources.
This helps control data traffic and limits
information obtained by downstream
receivers. Therefore, security of the multicast
data is improved.
Control parameters for maintaining
neighbors
Multicast devices establish PIM neighbor
relationships and negotiate various control
parameters by exchanging Hello messages.
You can configure various neighbor control
policies to improve network security.
Control parameters for DR election Designated routers (DRs) need to be elected
on networks connected to multicast sources
and networks connected to multicast group
members. These DRs forward multicast data
between multicast sources and group
members. You can adjust the priority used for
DR election and the delay for DR
switchover.
Control parameters for Join/Prune messages A multicast device sends Join messages
upstream to require forwarding of multicast
data, and Prune messages upstream for
requiring to stop forwarding multicast data.
You can adjust parameters for controlling
Join/Prune messages to control the
forwarding of multicast data.
57
Parameter Description
Control parameters for assert When a device receives multicast data
through a downstream interface, the device
knows that other upstream devices exist on
this network segment. The device then sends
an Assert message to participate in the
election of the unique upstream device. You
can adjust the period for retaining the Assert
state of the device.

PIM for Anycast RP
In a traditional PIM-SM domain, all multicast groups map to one RP. When the network is
overloaded or traffic is concentrated on the RP, the RP may be overburdened. If the RP fails,
routes are converged slowly or multicast data are forwarded over non-optimal paths. Configuring
anycast RP in the PIM-SM domain can address this problem. IP routing will automatically select
the closest RP for each source and receiver. This releases burdens on a single RP, implements
PIM BFD
PIM Silent
This section describes the default PIM-SM configuration.
Table 3-2 lists the default PIM-SM (IPv4) configuration.
Table 3-2 Default PIM-SM (IPv4) configuration
Multicast routing Disabled
PIM-SM Disabled
Static RP address Unspecified
C-RP interface Unspecified
C-BSR interface Unspecified
58
Listening of Auto-RP
messages
Disabled
DR priority 1
SPT switchover conditions First multicast packet received by the RP or the DR at the
member side
Range of SSM group
addresses
232.0.0.0/8
PIM BFD Disabled
PIM silent Disabled

3.4 Configuring PIM-SM in the ASM Model
A PIM-SM network uses the ASM model to provide multicast services for user hosts. User hosts
in a multicast group can receive multicast data sent from any multicast source to this group.
Before configuring PIM-SM in the ASM model, configure a unicast routing protocol to ensure
that unicast routes on the network are reachable.
Mandatory procedures for configuring PIM-SM in the ASM model are as follows:
1. Enable PIM-SM.
2. Configure an RP.
Perform the optical configuration tasks as required.
3.4.1 Enabling PIM-SM
Context
It is recommended that you enable PIM-SM on all interfaces in a PIM-SM domain, so that the
interfaces can establish neighbor relationships with all connected PIM devices.
Procedure
Step 1 Run:
system-view
Step 2 Run:
59
The IP multicast routing function is enabled.
Step 3 Run:
Step 4 Run:
pim sm
PIM-SM is enabled.
Step 5 Run:
commit
----End
3.4.2 Configuring an RP
Context
An RP can be configured manually or elected through the BSR mechanism. Manually
configuring a static RP reduces bandwidth used for frequent information exchange between the
C-RPs and BSR. RP election through the BSR mechanism simplifies configuration and improves
reliability of multicast forwarding because multiple C-RPs are configured.
To allow the local device to receive Auto-RP Announcement or Discovery messages from other
devices, enable the listening of Auto-RP messages.
CAUTION
You can configure a static RP and multiple C-RPs for dynamic RP election. The static RP
functions as a backup RP because it has a lower priority. Ensure that all the devices on the
network have the same RP information. Inconsistent RP information may cause forwarding
failures on the network.
Default Configuration
Table 3-3 lists the default configuration of the C-BSR and C-RP.
Table 3-3 Default configuration of the C-BSR and C-RP
C-BSR priority 0
C-BSR hash mask length 30
BSR message
fragmentation
Disabled
60
Multicast group policy of a
static RP
No multicast group policy configured (receiving multicast data
with any group address)
Multicast group policy of a
C-RP
No multicast group policy configured (receiving multicast data
with any group address)
C-RP priority 0
Interval for sending C-RP
Announcement messages
60s
Hold time of C-RP
Announcement messages
150s

Procedure
l Configure a static RP.
1. Run:
system-view
2. Run:
pim
The PIM view is displayed.
3. Run:
static-rp rp-address [ basic-acl-number | acl-name acl-name ]
[ preferred ]
Address of a static RP is specified.
preferred indicates that the static RP takes precedence over a dynamic RP.
NOTE
All devices in the PIM-SM domain must be configured with the same static RP address.
4. Run:
commit
l Configure a dynamic RP.
1. Configure a C-BSR.
a. Run:
system-view
b. Run:
pim
c. Run:
c-bsr interface-type interface-number [ hash-length [ priority ] ]
61
A C-BSR is configured.
It is recommended that you configure the C-BSR on the device that aggregates
multicast data.
d. (Optional) Run:
bsm semantic fragmentation
The BSR message fragmentation function is enabled.
NOTE
BSR message fragmentation is recommended because it can solve the problem faced by
IP fragmentation that all fragments become unavailable due to loss of fragment
information. Enable BSR message fragmentation on all devices. Otherwise, devices that
do not fragment BSR messages may receive incomplete RPs.
e. Run:
commit
2. Configure a C-RP.
a. Run:
system-view
b. Run:
pim
c. Run:
c-rp interface-type interface-number [ group-policy { basic-acl-
number | acl-name acl-name } | priority priority | holdtime hold-
interval | advertisement-interval adv-interval ]
*
A C-RP is configured.
It is recommended that you configure the C-RP on the device that aggregates
multicast data.
d. Run:
commit
3. (Optional) Configure a BSR boundary.
a. Run:
system-view
b. Run:
c. Run:
pim bsr-boundary [ incoming ]
A BSR service boundary is configured.
NOTE
The BSR messages cannot pass through the BSR boundary. Therefore, it is recommended
that you configure the BSR service boundary on interfaces at the edge of a PIM-SM
domain.
62
d. Run:
commit
l Enable listening of Auto-RP messages.
1. Run:
system-view
2. Run:
pim
3. Run:
auto-rp listening enable
Listening of Auto-RP messages is enabled.
4. Run:
commit
----End
3.4.3 (Optional) Configuring a BSR Administrative Domain
Context
To facilitate PIM domain management, a PIM network is divided into multiple BSR
administrative domains and a global domain. Each BSR administrative domain maintains only
one BSR that serves specified multicast groups. Multicast groups that do not belong to any BSR
administrative domain are served by the global domain. A device can join only one
administrative domain, so devices in each administrative domain can forward multicast data
independently. Data of multicast groups in the global domain can be forwarded through devices
in any administrative domain.
NOTE
The maximum range of multicast groups that a BSR administrative domain can serve is 239.0.0.0 to
239.255.255.255. Multicast addresses in this range are used as private group addresses.
Procedure
Step 1 Enable BSR administrative domain on all devices in the PIM domain.
1. Run:
system-view
2. Run:
pim
3. Run:
c-bsr admin-scope
63
The BSR administrative domain is enabled.
4. Run:
commit
Step 2 Configure a BSR administrative domain boundary on an edge interface.
1. Run:
system-view
2. Run:
3. Run:
multicast boundary group-address { mask | mask-length }
The boundary of the BSR administrative domain is configured.
NOTE
Multicast packets that belong to the BSR administrative domain cannot traverse the boundary.
4. Run:
commit
Step 3 Configure a group address range for the C-BSR in each BSR administrative domain.
1. Run:
system-view
2. Run:
pim
3. Run:
c-bsr group group-address { mask | mask-length } [ hash-length hash-length |
priority priority ]
*
A group address range is configured for the C-BSR in each BSR administrative domain.
4. Run:
commit
Step 4 Configure a C-BSR in the global domain.
1. Run:
system-view
2. Run:
pim
64
3. Run:
c-bsr global [ hash-length hash-length | priority priority ]
*
A C-BSR is configured for the global administrative domain.
4. Run:
commit
----End
3.4.4 (Optional) Configuring SPT Switchover Conditions
Context
A high volume of multicast data traffic increases the load of an RP and may result in a fault.
The DR at the group member side triggers SPT switchover to reduce the burden of the RP.
NOTE
By default, a DR at the group member side immediately triggers SPT switchover after receiving the first
multicast data packet. You can configure a traffic rate threshold on a DR at the group member side to trigger
an SPT switchover or prevent the DR from triggering an SPT switchover.
Table 3-4 lists the default configuration of SPT switchover conditions.
Table 3-4 Default configuration of SPT switchover conditions
Group policy that specifies
the groups to which the SPT
switchover conditions
apply
No group policy configured (The SPT switchover conditions
apply to all multicast groups.)
Interval for checking the
forwarding rate of
multicast data
15s

Procedure
Step 1 Run:
system-view
Step 2 Run:
pim
Step 3 Run:
65
spt-switch-threshold { traffic-rate | infinity } [ group-policy { basic-acl-number
| acl-name acl-name } [ order order-value ] ]
The SPT switchover condition is configured.
traffic-rate specifies the rate threshold that triggers an SPT switchover. infinity indicates that
the SPT switchover is never triggered.
Step 4 Run:
timer spt-switch interval
The interval for checking the forwarding rate of multicast data is configured.
Step 5 Run:
commit
----End
3.4.5 (Optional) Adjusting Control Parameters for Source
Registering
Context
After receiving multicast data from a multicast source, the source DR encapsulates multicast
data in a Register message and forwards the message to the RP. Therefore, you can adjust control
parameters for source registering on the RP and source DR.
You can perform the following operations on the source DR.
l Configure the register message suppression time. After receiving a Register-Stop message,
the source DR stops sending Register messages to the RP during register suppression. The
source DR forwards packets again when the register suppression time expires and it receives
no more Register-Stop messages.
l Configure the interval at which null Register messages are sent. When the timeout period
for keeping the register suppression state is too long or too short, multicast data cannot be
forwarded normally. Sending null Register messages during register suppression can
relieve this problem.
l Configure the source address for Register messages. The RP cannot receive Register
messages from a source DR if the source address of the Register messages is not a unique
IP address on the network or if the source address is filtered out by a policy configured on
the RP. To enable the RP to receive Register messages from the source DR, configure a
new source address for the Register messages.
You can perform the following operations on the RP.
l Configure a policy to filter Register messages. You can specify the address range of
Register messages to improve network security.
Table 3-5 lists default configuration of control parameters for source registering.
66
Table 3-5 Default configuration of control parameters for source registering
Filter policy for Register
messages
No filter policy configured (receiving Register messages with
any group address)
Way to calculate the
checksum
Based on the entire message
Register message
suppression time
60s
Interval for sending null
Register messages
5s

Procedure
l Configure control parameters for source registering on the source DR.
1. Run:
system-view
2. Run:
pim
3. Run:
register-suppression-timeout interval
Register message suppression time is configured.
4. Run:
probe-interval interval
The interval for sending null Register messages is configured.
NOTE
The value of probe-interval must be smaller than half of register-suppression-timeout.
5. Run:
register-packet-checksum
The checksum is calculated based on all the contents of a Register message.
6. Run:
register-source interface-type interface-number
The source address of Register messages sent from the source DR is configured.
It is recommended that you use the IP address of a loopback interface on the source
DR as the source address of Register messages.
7. Run:
commit
67
l Configure control parameters for source registering on the RP.
1. Run:
system-view
2. Run:
pim
3. Run:
register-policy { advanced-acl-number | acl-name acl-name }
A policy for filtering Register messages is configured.
4. Run:
commit
----End
3.4.6 (Optional) Adjusting C-RP Control Parameters
Context
When a C-RP is configured on an interface, the C-RP periodically sends Advertisement
messages to a BSR. The Advertisement messages carry the C-RP priority and the holdtime of
Advertisement messages. After receiving Advertisement messages, the BSR starts the C-RP
timeout timer. The timer value is set to the holdtime of Advertisement messages. Before the
timer expires, the BSR collects the C-RP information in Advertisement messages into an RP-
set, encapsulates the RP-set into a Bootstrap message, and advertises the Bootstrap message to
all PIM devices in the PIM domain. If the BSR does not receive any Advertisement message
from the C-RP after the timer expires, the BSR considers the C-RP invalid or unreachable on
the network. The interval for sending Advertisement messages must be smaller than the holdtime
of Advertisement messages.
You can manually configure the interval for sending Advertisement messages, C-RP priority
and holdtime of Advertisement messages. To prevent C-RP spoofing, set the range of valid C-
RP addresses on the BSR. Then the BSR accepts only the Advertisement messages with the
source addresses in the specified range.
Procedure
l Configure parameters on Advertisement messages on the C-RP.
1. Run:
system-view
2. Run:
pim
3. Run:
c-rp priority priority
68
The C-RP priority is configured.
4. Run:
c-rp advertisement-interval interval
The interval for sending Advertisement messages is configured.
5. Run:
c-rp holdtime interval
The time period to hold the Advertisement messages received from the C-RP is
configured.
6. Run:
commit
l Configure the valid C-RP address range on the BSR.
1. Run:
system-view
2. Run:
pim
3. Run:
crp-policy { advanced-acl-number | acl-name acl-name }
The range of valid C-RP addresses and the range of groups that C-RPs serve are
configured.
4. Run:
commit
----End
3.4.7 (Optional) Adjusting C-BSR Control Parameters
Context
C-BSRs automatically elect a BSR in a PIM domain. At first, each C-BSR considers itself as a
BSR and sends Bootstrap messages to all devices in the domain. When a C-BSR receives a
Bootstrap message from another C-BSR, it compares the priority in the received Bootstrap
message with its own priority. The C-BSR with a higher priority wins. If the two BSRs have the
same priority, the BSR with a larger IP address is preferred. After a C-BSR is elected as the
BSR, it encapsulates its own IP address and the RP-Set information into a Bootstrap message
and sends the Bootstrap message in the PIM domain. The Bootstrap message contains a hash
mask which is used for hash calculation in C-RP election.
The BSR periodically sends a Bootstrap message to the network. When the other C-BSRs receive
the Bootstrap message, they start the holdtime timer. If they do not receive any Bootstrap
message from the BSR when the holdtime timer expires, they consider that the BSR fails and
initiate the election of a new BSR. The interval for sending Bootstrap messages must be smaller
than the holdtime of a Bootstrap message.
69
You can configure the C-BSR priority, the BSR hash mask length, the interval for sending
Bootstrap messages, and the holdtime of Bootstrap messages. To prevent BSR spoofing, set a
range of valid BSR addresses on devices, so that the devices receive messages only from the
BSRs within the address range.
Table 3-6 lists the default configuration of the C-BSR.
Table 3-6 Default configuration of the C-BSR
Interval for sending
Bootstrap messages
60s
Holdtime of Bootstrap
messages
130s

Procedure
l Configure parameters contained in a Bootstrap message for a C-BSR.
1. Run:
system-view
2. Run:
pim
3. Run:
c-bsr priority priority
The priority of the C-BSR is configured.
4. Run:
c-bsr hash-length priority
The hash mask length of the C-BSR is configured.
5. Run:
c-bsr interval interval
The interval for the BSR to send Bootstrap messages is configured.
6. Run:
c-bsr holdtime interval
The holdtime of the Bootstrap message received from the BSR is configured.
7. Run:
commit
l Configure a valid BSR address range on a PIM device.
70
1. Run:
system-view
2. Run:
pim
3. Run:
bsr-policy { basic-acl-number | acl-name acl-name }
The range of valid BSR addresses is configured.
4. Run:
commit
----End
Prerequisites
After configuration of PIM-SM in ASM model is complete, you can check information about
the BSR, RP, PIM interface, PIM neighbor, and PIM routing table.
Procedure
l Run the display pim bsr-info command to check the BSR configuration.
l Run the display pim rp-info [ group-address ] command to check the RP configuration.
l Run the display pim interface [ interface-type interface-number | up | down ]
[ verbose ] command to check PIM information on an interface.
l Run the display pim neighbor [ neighbor-address | interface interface-type interface-
number | verbose ]
*
command to check information about PIM neighbors.
l Run the following commands to check the PIM routing table.
display pim routing-table [ group-address [ mask { group-mask-length | group-
mask } ] | source-address [ mask { source-mask-length | source-mask } ] | incoming-
interface { interface-type interface-number | register } | outgoing-interface
{ include | exclude | match } { interface-type interface-number | register | none } |
mode { sm | ssm } | flags flag-value | fsm ]
*
[ outgoing-interface-number
[ number ] ]
display pim routing-table brief [ group-address [ mask { group-mask-length | group-
interface { interface-type interface-number | register } ]
*
----End
71
3.5 Configuring PIM-SM in the SSM Model
A PIM-SM network uses the SSM model to provide specified multicast services for user hosts.
User hosts in a multicast group can receive multicast data sent from the specified multicast source
to this group.
Before configuring PIM-SM in the SSM model, configure a unicast routing protocol to ensure
that unicast routes on the network are reachable.
Enabling PIM-SM is a mandatory procedure. Configuring an SSM group policy can control the
address range of SSM groups. This operation is optional.
3.5.1 Enabling PIM-SM
Context
It is recommended that you enable PIM-SM on all interfaces in a PIM-SM domain, so that the
interfaces can establish neighbor relationships with all connected PIM devices.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The IP multicast routing function is enabled.
Step 3 Run:
Step 4 Run:
pim sm
PIM-SM is enabled.
Step 5 Run:
commit
----End
3.5.2 (Optional) Configuring an SSM Group Policy
72
Context
By default, the SSM group address range is 232.0.0.0/8. Sometimes, the address range of SSM
groups must be limited to ensure security of multicast networks. If the addresses in the default
range are insufficient, the SSM group address range needs to be expanded. You can configure
an SSM group policy to control the address range of SSM groups.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim
Step 3 Run:
ssm-policy { basic-acl-number | acl-name acl-name }
The SSM group address range is configured.
NOTE
Ensure that the SSM group address range of all devices in the network are the same.
Step 4 Run:
commit
----End
Prerequisites
After configuration of PIM-SM in SSM model is complete, you can check information about
the PIM interface, PIM neighbor, and PIM routing table.
Procedure
number | verbose ]
*
*
[ number ] ]
73
*
----End
3.6 Adjusting Multicast Source Control Parameters
You can configure the source address-based filtering rules and multicast source lifetime to
improve security of packets and control traffic on networks.
Before setting the parameters for controlling a multicast source, complete the following tasks:
l Configuring a unicast routing protocol to ensure normal unicast routing on the network
l Enabling PIM-SM
Context
After a PIM device receives a multicast packet from a multicast source, it starts a timer for the
(S, G) entry and sets the timer to the multicast source lifetime. If the device receives a packet
from the source before the timer expires, it resets the timer. If the device does not receive any
multicast packet from the source within the lifetime, it considers the corresponding (S, G) entry
invalid and deletes this entry. You can configure the multicast source lifetime.
To control multicast traffic or ensure data security, configure source address-based filtering
policies on the device so that the device accepts only multicast data allowed by the policies.
Table 3-7 lists default configuration of multicast source control parameters.
Table 3-7 Default configuration of multicast source control parameters
Keepalive period of a
multicast source
210s
Source address filtering
policy
No policy configured (Multicast data from all sources is
accepted.)

Procedure
Step 1 Run:
system-view
Step 2 Run:
pim
74
Step 3 Run:
source-lifetime interval
The multicast source lifetime is configured.
Configure the source lifetime according to the number of the multicast forwarding entries used.
If a large number of multicast entries are used on your network, a too short lifetime will make
the multicast forwarding table incomplete. However, if the lifetime is too long, invalid entries
will be retained for a long time, wasting system resources. The following table lists the
recommended lifetime values for different quantities of multicast forwarding entries.
Number of Entries Recommended Lifetime Value
Within 1000 Default value
1000 to 2000 1000 seconds
2000 to 8000 2000 seconds
More than 8000 4000 seconds

Step 4 Run:
source-policy { acl-number | acl-name acl-name }
A multicast source address-based filtering policy is configured.
l If a basic ACL is specified in the command, the allowed multicast packets are specified by
the source parameter in the rule configured under the basic ACL. The device forwards only
the multicast packets with the source addresses allowed by the filtering policy.
l If an advanced ACL is specified in the command, the allowed multicast packets are specified
by source and destination parameters in the rule configured under the advanced ACL. The
device forwards only the multicast packets with both source addresses and group addresses
allowed by the filtering policy.
NOTE
l If the specified ACL contains no rule, the device does not forward multicast packets from any sources.
l This command does not filter multicast packets that match the PIM entries generated from statically
configured IGMP (S, G) entries.
Step 5 Run:
commit
----End
After the control parameters of a multicast source are adjusted, you can check entries in the PIM
routing table.
Run the following commands to check the PIM routing table.
l display pim routing-table [ group-address [ mask { group-mask-length | group-mask } ]
| source-address [ mask { source-mask-length | source-mask } ] | incoming-interface
75
{ interface-type interface-number | register } | outgoing-interface { include | exclude |
match } { interface-type interface-number | register | none } | mode { sm | ssm } | flags
flag-value | fsm ]
*
[ outgoing-interface-number [ number ] ]
l display pim routing-table brief [ group-address [ mask { group-mask-length | group-
*
3.7 Adjusting Control Parameters for Establishing Neighbor
Relationships
PIM devices establish PIM neighbor relationships by exchanging Hello messages.
Before configuring control parameters for establishing neighbor relationships, complete the
following tasks:
l Enabling PIM-SM
You can configure the Hello message control parameters, neighbor tracking function, and
neighbor filtering function in any sequence as required.
3.7.1 Adjusting Control Parameters for Hello Messages
Context
PIM devices send Hello messages periodically to maintain PIM neighbor relationships. When
a PIM device receives a Hello message from a neighbor, the PIM device starts the timer and sets
the timer to the holdtime of Hello messages. If the PIM device does not receive a new Hello
message from the neighbor within the holdtime, it considers the neighbor invalid or unreachable.
Therefore, the interval for a PIM device to send Hello messages must be smaller than the
holdtime of Hello messages.
NOTE
The interval for sending Hello messages and the holdtime of Hello messages can be set either globally or
on an interface. If you configure the two parameters in the global PIM view and in the interface view
simultaneously, the configuration in the interface view takes effect.
Table 3-8 lists default configuration of control parameters for Hello messages.
76
Table 3-8 Default configuration of control parameters for Hello messages
Interval for sending Hello
messages
30s
Holdtime of Hello
messages
105s

Procedure
l Global configuration
1. Run:
system-view
2. Run:
pim
3. Run:
timer hello interval
The interval for sending Hello messages is configured.
4. Run:
hello-option holdtime interval
The holdtime of Hello messages is configured.
5. Run:
commit
l Configuration on an interface
1. Run:
system-view
2. Run:
3. Run:
pim timer hello interval
The interval for sending Hello messages is configured.
4. Run:
pim hello-option holdtime interval
The holdtime of Hello messages is configured.
5. Run:
commit
77
----End
3.7.2 Configuring PIM Neighbor Filtering
Context
The switch supports different neighbor filtering policies to ensure secure and effective multicast
transmission in a PIM-SM domain. You can perform the following operations to filter neighbors:
l Configure a valid neighbor address range to prevent unauthorized neighbors from
connecting to the network.
l Configure the switch to reject Hello messages without Generation IDs so that switch
connects to normally working PIM neighbors.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim neighbor-policy { basic-acl-number | acl-name acl-name }
The range of valid neighbor addresses is configured.
NOTE
l If the IP address of a PIM neighbor that has established a neighbor relationship with the switch is not
in the configured range of valid neighbor addresses, the switch will no longer receive Hello messages
from this PIM neighbor. When the holdtime of Hello messages expires, the neighbor relationship
between the PIM device and the switch is terminated.
Step 4 Run:
pim require-genid
The device is configured to receive only Hello messages that contain Generation IDs.
Step 5 Run:
commit
----End
78
Prerequisites
After the control parameters for establishing the neighbor relationship are adjusted, you can
check information about the PIM interface and the PIM neighbor.
Procedure
number | verbose ]
*
----End
3.8 Adjusting Control Parameters for DR Election
PIM devices exchange Hello messages to elect a DR, which is responsible for sending protocol
packets at the source side or the group member side.
Before configuring control parameters for DR election, complete the following tasks:
l Enabling PIM-SM
You can configure the priority for DR election and DR switchover delay in any sequence as
required.
3.8.1 Configuring the DR Priority
Context
The shared network segment where a multicast source or group member resides is usually
connected to multiple PIM devices. PIM devices exchange Hello messages to elect a DR on the
network segment, which is the unique sender of multicast packets. The DR priorities carried in
Hello messages are compared at first. The device with the highest DR priority wins (A greater
value indicates a higher priority). If PIM devices have the same DR priority or at least one PIM
device does not support Hello messages carrying the DR priority, the PIM device with the largest
IP address wins.
NOTE
The DR priority can be configured globally or on an interface. If you configure the DR priority in the global
PIM view and in the interface view simultaneously, the configuration in the interface view takes effect.
Table 3-9 lists the default configuration of the DR priority.
79
Table 3-9 Default configuration of the DR priority
DR priority 1

Procedure
1. Run:
system-view
2. Run:
pim
3. Run:
hello-option dr-priority priority
The priority for DR election is configured.
4. Run:
commit
1. Run:
system-view
2. Run:
3. Run:
pim hello-option dr-priority priority
The priority for DR election is configured.
4. Run:
commit
----End
3.8.2 Configuring the DR Switchover Delay
Context
When an interface on a shared network segment changes from a DR to a non-DR, PIM devices
on the network segment immediately delete the related multicast forwarding entries. This causes
loss of multicast data in a short period. To avoid such a situation, enable DR switching delay
80
function and set a delay time. When the DR changes, the original multicast forwarding entries
are retained within the delay time.
NOTE
By default, the DR switchover delay function is not configured.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim timer dr-switch-delay interval
The DR switchover delay function is enabled and a delay time is configured.
Step 4 Run:
commit
----End
Prerequisites
After the control parameters for electing a DR are adjusted, you can check information about
the PIM interface and the PIM neighbor.
Procedure
number | verbose ]
*
----End
3.9 Adjusting Control Parameters for Join/Prune Messages
Prune messages upstream for requiring to stop forwarding multicast data. You can configure
control parameters for Join/Prune messages as required. If there is no special requirement, the
default values are recommended.
81
Before configuring control parameters for Join/Prune messages, complete the following tasks:
l Enabling PIM-SM
You can configure time related parameters for Join/Prune messages, disable Join-Prune
packaging, Prune delay, and Join information filtering in any sequence as required.
3.9.1 Adjusting Time Related Parameters for Join/Prune Messages
Context
Prune messages upstream for requiring to stop forwarding multicast data. Join information and
prune information are encapsulated in Join/Prune messages. The PIM device periodically sends
Join/Prune messages to an upstream device to update the forwarding state. When the upstream
device receives a Join/Prune message, it starts a timer and sets the timer value to the holdtime
of the Join/Prune message. If the device does not receive any Join/Prune when the timer expires,
it acts as follows:
l If the previously received Join/Prune message is sent by a host to join a multicast group,
the device stops sending multicast data to the downstream interface of the multicast group.
l If the previously received Join/Prune message is sent to prune the downstream interface of
a multicast group, the device starts to send multicast data packets to the downstream
interface.
Therefore, the interval for sending Join/Prune messages must be smaller than the holdtime of a
Join/Prune message.
NOTE
The interval for sending Join/Prune messages and the holdtime of Join/Prune messages can be set globally
or on an interface. If you configure the two parameters in the global PIM view and in the interface view
simultaneously, the configuration in the interface view takes effect.
Table 3-10 lists the default configuration of time related parameters for Join/Prune messages.
Table 3-10 Default configuration of time related parameters for Join/Prune messages
Interval for sending Join/Prune messages 60s
Holdtime of Join/Prune messages 210s

82
Procedure
1. Run:
system-view
2. Run:
pim
3. Run:
timer join-prune interval
The interval for sending Join/Prune messages is configured.
4. Run:
holdtime join-prune interval
The holdtime of Join/Prune messages is configured.
5. Run:
commit
1. Run:
system-view
2. Run:
3. Run:
pim timer join-prune interval
The interval for sending Join/Prune messages is configured.
4. Run:
pim holdtime join-prune interval
The holdtime of Join/Prune messages is configured.
5. Run:
commit
----End
3.9.2 Disabling PIM Join/Prune Message Packaging
Context
The efficiency for sending PIM Join/Prune messages in a package is higher than that for
separately sending a large number of PIM Join/Prune messages. By default, a device sends PIM
83
Join/Prune messages in a package. Because the size of a PIM Join/Prune message package is
large, devices that have poor performance cannot receive the PIM Join/Prune message package.
To prevent packets from being discarded, disable the Join/Prune message packaging function.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim
Step 3 Run:
join-prune triggered-message-cache disable
The real-time Join/Prune message packaging function is disabled.
Step 4 Run:
commit
----End
3.9.3 Adjusting Control Parameters for Prune Delay
Context
LAN-delay specifies the delay from the time a device receives a Prune message from a
downstream interface to the time it sends the Prune message to an upstream interface. A PIM
device does not prune the corresponding downstream interface immediately after it sends the
Prune message. If another device still requests multicast data, it needs to send a Join message
to the upstream device within this period. The period for overriding the Prune message is called
override-interval. The delay from the time a PIM device receives a Prune message to the time
it performs the prune action is the sum of the lan-delay and override-interval.
NOTE
The lan-delay and override-interval can be configured globally or on an interface. If you configure the lan-
delay and override-interval in the global PIM view and in the interface view simultaneously, the
configuration in the interface view takes effect.
Table 3-11 lists the default configuration of control parameters for prune delay.
Table 3-11 Default configuration of control parameters for prune delay
LAN-delay 500 ms
84
Override-interval 2500 ms

Procedure
1. Run:
system-view
2. Run:
pim
3. Run:
hello-option lan-delay interval
The delay for transmitting messages in a shared network is configured.
4. Run:
hello-option override-interval interval
The interval for overriding the prune action is configured.
5. Run:
commit
1. Run:
system-view
2. Run:
3. Run:
pim hello-option lan-delay interval
The delay for transmitting messages in a shared network is configured.
4. Run:
pim hello-option override-interval interval
The interval for overriding the prune action is configured.
5. Run:
commit
----End
85
3.9.4 Configuring a Join Information Filtering Policy
Context
To prevent access of unauthorized users, configure a join information filtering policy to specify
a valid source address range for join information contained in Join/Prune messages.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim join-policy { asm { basic-acl-number | acl-name acl-name } | ssm { advanced-acl-
number | acl-name acl-name } | advanced-acl-number | acl-name acl-name }
A Join information filtering policy is configured and a valid source address range is specified.
Step 4 Run:
commit
----End
Prerequisites
After control parameters for Join/Prune messages are configured, you can check information
about the PIM interface, statistics about PIM control messages, and PIM routing table.
Procedure
l Run the following commands to check the number of sent or received PIM control
messages.
display pim control-message counters message-type { probe | register | register-
stop | crp }
display pim control-message counters [ message-type { assert | hello | join-prune |
bsr } | interface interface-type interface-number ]
*
86
*
[ number ] ]
*
----End
3.10 Adjusting Assert Control Parameters
When a device receives multicast data through a downstream interface, the device knows that
other upstream devices exist on this network segment. The device then sends an Assert message
to participate in the election of the unique upstream device.
Before configuring assert control parameters, complete the following tasks:
l Enabling PIM-SM
Context
When multiple PIM devices on a network segment pass the Reverse Path Forwarding (RPF)
check and forward multicast data to this network segment, assert election is required to ensure
that only one PIM device forwards multicast data to this network segment.
PIM devices that fail the assert election disable their downstream interfaces from forwarding
multicast data to this network segment. The assert loser state lasts for a period, which is called
the holdtime of Assert messages. After the assert state timer times out, the devices that lost the
Assert election restore pruned interfaces to the forwarding state to trigger a new round of Assert
election.
NOTE
The holdtime of Assert messages can be configured globally or on an interface. If you configure the
holdtime of Assert messages in the global PIM view and in the interface view simultaneously, the
configuration in the interface view takes effect.
Table 3-12 lists default configuration of assert control parameters.
Table 3-12 Default configuration of assert control parameters
Period for holding the
Assert state
180s

87
Procedure
1. Run:
system-view
2. Run:
pim
3. Run:
holdtime assert interval
The holdtime of Assert messages is configured.
By default, the holdtime of Assert messages is 180 seconds.
4. Run:
commit
1. Run:
system-view
2. Run:
3. Run:
pim holdtime assert interval
The period for holding the Assert state is configured.
4. Run:
commit
----End
After assert control parameters are configured, you can check information about the PIM
interface, PIM neighbor, and PIM routing table using the following commands:
number | verbose ]
*
88
*
[ number ] ]
*
3.11 Configuring PIM Anycast RP
Anycast RP configures several RPs with the same address in a PIM-SM domain and establishes
peer relationships between RPs so that the multicast source can register with the closest RP and
the multicast receiver can join the closest RP. This releases burdens on a single RP, implements
Context
Currently, there are two anycast implementations: MSDP for anycast RP and PIM for anycast
RP. In IPv4 network deployment, choose either of the two modes. It is recommended that the
two modes be not used together.
Before configuring PIM anycast RP, complete the following task:
l Configure a unicast routing protocol to ensure connectivity at the network layer.
l 3.4 Configuring PIM-SM in the ASM Model
Configure anycast RP in the following sequence.
3.11.1 Configuring Global Anycast RP
Context
Either a static or dynamic RP can be used on the network. It is recommended that an RP be
configured on loopback interfaces. The same RP address is configured on multiple switchs where
anycast RP will be deployed.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim
Step 3 Run:
89
anycast-rp rp-address
Anycast RP is configured.
NOTE
The anycast RP address must be the same as that of the RP address on the current network.
Step 4 Run:
commit
----End
3.11.2 Configuring Local Addresses for Anycast RPs
Context
The devices functioning as Anycast RPs are identified by the same logical address so that the
RP in the PIM-SM domain is unique. However, the devices need to distinguish one another
during communication, so the Anycast RP addresses cannot be used. In this situation, you need
to configure the Anycast RP local address and Anycast RP peers.
After the local address is configured, the RP uses the local addresses as the source addresses of
the packets when sending Register packets to Anycast RP peers.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim
Step 3 Run:
The Anycast RP view is displayed.
Step 4 Run:
local-address local-address
Local addresses are configured for Anycast RP.
NOTE
You are advised to use the address of the Loopback interface as the local address of the Anycast RP.
The local address of the Anycast RP must be different from the address of the Anycast RP.
Step 5 Run:
commit
----End
90
3.11.3 Configuring Anycast RP Peers
Context
The devices functioning as Anycast RPs are identified by the same logical address so that the
RP in the PIM-SM domain is unique. However, the devices need to distinguish one another
during communication, so the Anycast RP addresses cannot be used. In this situation, you need
to configure the Anycast RP local address and Anycast RP peers.
After Anycast RP peers are configured, the RP uses the peer addresses as the destination
addresses of the packets when sending Register packets to Anycast RP peers.
Procedure
Step 1 Run:
system-view
Step 2 Run:
pim
Step 3 Run:
The Anycast RP view is displayed.
Step 4 Run:
peer peer-address [ fwd-msdp-sa [ acl-number | acl-name acl-name ] ]
Anycast RP peers are configured.
NOTE
In a PIM-SM domain, devices functioning as Anycast RP must be fully connected. Anycast RP peer
relationships need to be configured between every two Anycast RPs.
Step 5 Run:
commit
----End
Context
After PIM for Anycast RP is configured, you can check the PIM for Anycast RP configurations.
Procedure
l Run the display pim rp-info command to check the RP.
91
*
[ number ] ]
*
----End
3.12 Configuring PIM BFD
Before configuring PIM BFD, complete the following tasks:
l Enabling BFD globally
l Enabling PIM-SM
Context
Normally, if the current DR is faulty on the shared network segment, other PIM neighbors
participate in DR election after the neighbor relationship times out. Consequently, multicast data
transmission is interrupted. The interruption period, usually in seconds, is longer than or equal
to the timeout interval of the neighbor relationship.
BFD can detect faults in milliseconds. BFD is used to detect the status of PIM neighbors on the
shared network segment. When detecting a fault on the peer device, BFD reports the fault to the
PIM module. The PIM module triggers a new DR election immediately instead of waiting the
timeout of the neighbor relationship. This shortens the interruption time of multicast data
transmission and improves reliability of the multicast network.
PIM BFD is applicable to the assert election on the shared network segment. In addition, it
quickly responds to faults on the assert winner interface.
Table 3-13 lists default configuration of control parameters for PIM BFD messages.
Table 3-13 Default configuration of control parameters for PIM BFD messages
Minimum sending interval 1000 ms
92
Minimum receiving
interval
1000 ms
Local detection multiplier 3

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim bfd enable
PIM BFD is enabled.
Step 4 (Optional)Run:
pim bfd { min-tx-interval tx-value | min-rx-interval rx-value | detect-multiplier
multiplier-value }
*
This operation is performed to set the minimum interval for sending the PIM BFD messages,
the minimum interval for receiving the PIM BFD messages, and the local detection multiplier.
When other protocols have configured the same BFD parameters, PIM BFD parameters may be
affected.
Step 5 Run:
commit
----End
After PIM BFD is configured, you can run the following commands to check information about
the PIM BFD session.
l display pim bfd session statistics
l display pim bfd session [ interface interface-type interface-number | neighbor neighbor-
address ]
*
3.13 Configuring PIM Silent
93
Before configuring PIM Silent, complete the following task:
l Enabling PIM-SM
Context
On the access layer, if the interface directly connected to a device is enabled with the PIM
protocol, a PIM neighbor relationship can be established on this interface to process various PIM
packets. The configuration, however, has the security vulnerability. To be specific, when a host
maliciously sends PIM Hello messages, the device may break down.
To prevent the preceding case, you can set the state of the device interface to PIM silent. When
the interface is in PIM silent state, the interface is disabled from receiving and forwarding any
PIM packet. All PIM neighbors and PIM state machines on the interface are deleted. The
interface functions as the static DR and immediately takes effect. The PIM silent function does
not affect the IGMP function on the interface.
PIM client takes effect on an interface only when the interface is directly connected to a user
network segment and when the network segment is connected only to this PIM device.
CAUTION
l After you configure PIM silent on an interface, the interface no longer receives or sends any
PIM packets and other PIM functions on the interface become invalid. Confirm your action
before configuring this function.
l If a user network segment is connected to multiple devices and PIM silent is enabled on
interfaces of multiple devices, the interfaces become static DRs. This results in multicast
faults.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
pim silent
The PIM silent function is enabled.
Step 4 Run:
commit
94
----End
After PIM silent is configured, you can check information about the PIM interface.
Run the display pim interface [ interface-type interface-number | up | down ] [ verbose ]
command to check PIM information on an interface.
3.14 Maintaining PIM-SM
This section describes how to maintain PIM-SM, including clearing statistics about PIM control
packets, clearing the PIM status of the specified downstream interfaces of PIM entries, and
monitoring the running status of PIM-SM.
3.14.1 Clearing Statistics About PIM Control Packets
Context
To recollect statistics about PIM control packets, clear the existing statistics. The statistics cannot
be restored after you clear them. This operation does not affect normal running of PIM.
CAUTION
Statistics about PIM control packets on an interface cannot be restored after you clear them.
Exercise caution when clearing the statistics.
Procedure
l To clear statistics about PIM control packets on an interface, run the reset pim control-
message counters [ interface interface-type interface-number ] command in the user view.
----End
3.14.2 Clearing the PIM Status of the Specified Downstream
Interfaces in PIM Entries
Context
You can clear the PIM status on the specified downstream interface in a PIM entry. IGMP status
and static groups on this interface are not affected.
95
CAUTION
Clearing the PIM status of downstream interfaces may trigger the sending of Join/Prune packets,
which affects multicast services.
Procedure
l To clear the PIM status of specified downstream interfaces in specified PIM entries, run
the reset pim routing-table group group-address mask { group-mask-length | group-
mask } source source-address interface interface-type interface-number command in the
user view.
----End
3.14.3 Monitoring the Running Status of PIM-SM
Context
During routine maintenance, you can run the following commands in any view to monitor the
running status of PIM-SM.
Procedure
l Run the display pim claimed-route [ source-address ] command to check unicast routes
used by PIM.
l Run the display pim bfd session [ interface interface-type interface-number | neighbor
neighbor-address ]
*
command to check the PIM BFD session.
l Run the display pim bsr-info command in any view to check information about the BSR
in the PIM-SM domain.
l Run the following commands to check the number of sent and received PIM control packets.
display pim control-message counters message-type { probe | register | register-
stop | crp }
display pim control-message counters [ message-type { assert | hello | join-prune |
bsr } | interface interface-type interface-number ]
*
[ verbose ] command in any view to check PIM information on an interface.
number | verbose ]
*
command to check information about the PIM neighbor.
*
[ number ] ]
96
*
l Run the display pim rp-info [ group-address ] command to check information about RPs
of the multicast group.
----End
This section provides configuration examples to describe how to construct a basic PIM-SM
network and configure basic PIM-SM functions.
3.15.1 Example for Configuring PIM-SM in the ASM Model
As shown in Figure 3-3, the network is connected to the Internet. After the PIM-SM protocol
is configured on the switch, the switch is required to provide ASM services for hosts on the
Internet so that hosts in a multicast group can receive VoD information sent from any sources.
Figure 3-3 Networking diagram for configuring PIM-SM in the ASM model
SwitchA
Source
SwitchB
SwitchC
PIM-SM
SwitchD
Receiver
HostA
Receiver
HostB
10GE1/0/2
10GE1/0/1
10GE1/0/2
10GE1/0/2
10GE1/0/2
10GE1/0/1
10GE1/0/1
10GE1/0/1
10GE1/0/3
10GE1/0/1
10GE1/0/4
10GE1/0/2
SwitchE
1
0
G
E
1
/
0
/
3
10GE1/0/4
Internet
VLANIF60
192.168.4.1/24
VLANIF60
192.168.4.2/24
VLANIF50
192.168.3.2/24
VLANIF90
192.168.2.2/24
VLANIF90
192.168.2.1/24
VLANIF10
192.168.5.1/24
VLANIF10
192.168.5.2/24
VLANIF20
10.110.1.1/24
V
L
A
N
I
F
3
0
1
9
2
.
1
6
8
.
1
.
1
/
2
4
1
0
G
E
1
/
0
/
3
V
L
A
N
I
F
3
0
1
9
2
.
1
6
8
.
1
.
2
/
2
4
VLANIF70
10.100.4.1/24
VLANIF80
10.110.3.1/24
VLANIF50
192.168.3.1/24
VLANIF40
10.110.2.2/24
VLANIF40
10.110.2.1/24

97
1. Configure an IP address for each interface and a unicast routing protocol. PIM is an intra-
domain multicast routing protocol that depends on unicast routing protocols.
2. Enable the multicast function on all switches providing multicast services. Before
configuring PIM-SM, you must enable the multicast function.
3. Enable PIM-SM on all interfaces. You can configure other PIM-SM functions only after
PIM-SM is enabled.
4. Enable IGMP on interfaces that connect the switch and hosts. A receiver can join and leave
a multicast group by sending IGMP messages. The leaf switches maintain the multicast
member relationship through IGMP.
5. Enable PIM silent on interfaces that connect the switch and hosts to prevent malicious hosts
from simulating sending PIM Hello packets. In this manner, security of PIM-SM domain
is ensured.
NOTE
If the user host network segment connects to multiple switches, do not enable PIM silent on interfaces
that connect these switches and user hosts. For example, PIM silent cannot be enabled on SwitchB
and SwitchC.
6. Configure the RP. In PIM-SM domain, RP is essential in providing ASM services and helps
forward multicast data. You are advised to configure RP on switches that have more
multicast flows. For example, you can configure RP on SwitchE in the figure.
7. Configure the BSR boundary on interfaces connected to the Internet. The Bootstrap
message cannot pass through the BSR boundary; therefore, the BSR serves only this PIM-
SM domain. In this manner, multicast services can be controlled effectively.
Procedure
Step 1 Configure an IP address for each interface and a unicast routing protocol.
# Configure the IP address and mask for each interface shown in Figure 3-3, and configure
OSPF on each switch to ensure that switches can communicate at the network layer and can
dynamically update routes through the unicast routing protocol. The configuration details are
not provided here. The configurations of SwitchB, SwitchC, SwitchD, and SwitchE are similar
to the configuration of Switch A, and are not provided here.
# Add interfaces of SwitchA to VLANs.
[~SwitchA] vlan batch 10 20 30
[~SwitchA] interface 10ge 1/0/1
[~SwitchA-10GE1/0/1] port link-type trunk
[~SwitchA-10GE1/0/1] port trunk allow-pass vlan 10
[~SwitchA-10GE1/0/1] quit
[~SwitchA-10GE1/0/2] port default vlan 20
[~SwitchA] commit
# Assign IP addresses to VLANIF interfaces on SwitchA.
[~SwitchA-Vlanif10] ip address 192.168.5.1 24
98
[~SwitchA] commit
# Configure a routing protocol on SwitchA. OSPF is used in this example.
[~SwitchA] ospf
[~SwitchA-ospf-1] area 0
[~SwitchA-ospf-1-area-0.0.0.0] network 10.110.1.0 0.0.0.255
[~SwitchA-ospf-1-area-0.0.0.0] commit
[~SwitchA-ospf-1-area-0.0.0.0] quit
[~SwitchA-ospf-1] quit
Step 2 Enable multicast, and enable PIM-SM on all interfaces.
# Enable multicast on all switches and PIM-SM on all interfaces. The configurations of
SwitchB, SwitchC, SwitchD, and SwitchE are similar to the configuration of Switch A, and are
not provided here.
Step 3 Enable IGMP on interfaces that connect the switch and hosts.
# Enable IGMP on interfaces that connect SwitchA and user hosts. The configuration of
SwitchB and SwitchC are similar to the configuration of SwitchA, and are not provided here.
Step 4 Enable PIM silent on interfaces on SwitchA.
[~SwitchA-Vlanif20] pim silent
Step 5 Configure the RP.
NOTE
RP can be configured in two modes: static RP and dynamic RP. The static RP can be configured together
with the dynamic RP. You can also configure only the static RP or the dynamic RP. When the static RP
and the dynamic RP are configured simultaneously, you can adjust parameters to specify the preferred RP.
This example shows how to configure both the static RP and the dynamic RP and to specify the
dynamic RP as the preferred RP and the static RP as the standby RP.
# Configure the dynamic RP. Configure C-RP and C-BSR on one or more switches in the PIM-
SM domain. In this example, specify SwitchE as both the C-RP and the C-BSR. Configure the
99
address range of the multicast group that the RP serves on SwitchE and configure the C-BSR
and C-RP on the interface.
[~SwitchE] acl number 2008
[~SwitchE-acl4-basic-2008] rule permit source 225.1.1.0 0.0.0.255
[~SwitchE-acl4-basic-2008] commit
[~SwitchE-acl4-basic-2008] quit
[~SwitchE] pim
[~SwitchE-pim] c-bsr vlanif 60
[~SwitchE-pim] c-rp vlanif 60 group-policy 2008
[~SwitchE-pim] commit
[~SwitchE-pim] quit
# Configure the static RP. Specify the address of static RP on all switches. Perform the following
configurations on SwitchA. The configuration of SwitchB, SwitchC, SwitchD, and SwitchE are
similar to the configurations of SwitchA, and are not provided here.
NOTE
If you enter preferred in the static-rp X.X.X.X command, the static RP is selected as the RP in the PIM-
SM domain.
[~SwitchA] pim
[~SwitchA-pim] quit
Step 6 Configure the BSR boundary on interfaces that connect SwitchD to the Internet.
[~SwitchD-Vlanif70] pim bsr-boundary
# Run the display pim interface command to check the PIM configuration and status. The PIM
information on SwitchC is displayed as follows
<SwitchC> display pim interface
Interface State NbrCnt HelloInt DR-Pri DR-Address
Vlanif40 up 0 30 1 10.110.2.2 (local)
Vlanif50 up 1 30 1 192.168.3.1 (local)
# Run the display pim bsr-info command to check information about the BSR selection on the
switch. For example, the BSR information on Switch A and Switch E is displayed as follows
(C-BSR information is also displayed on Switch E):
<SwitchA> display pim bsr-info
Elected AdminScoped BSR Count: 0
Elected BSR Address: 192.168.4.2
Priority: 0
Hash mask length: 30
State: Accept Preferred
Scope: Not scoped
Uptime: 01:40:40
Expires: 00:01:42
C-RP Count: 1
<SwitchE> display pim bsr-info
Elected AdminScoped BSR Count: 0
Elected BSR Address: 192.168.4.2
Priority: 0
Mask length: 30
State: Elected
Scope: Not scoped
100
Uptime: 00:00:18
Next BSR message scheduled at :00:01:42
C-RP Count: 1
Candidate AdminScoped BSR Count: 0
Candidate BSR Address is: 192.168.4.2
Priority: 0
Hash mask length: 30
State:Elected
Scope: Not scoped
Wait to be BSR: 0
# Run the display pim rp-info command to check the RP information on the Switch. In this
example, the RP information on SwitchA is displayed as follows:
<SwitchA> display pim rp-info
PIM-SM BSR RP Information:
Group/MaskLen: 225.1.1.0/24
RP: 192.168.4.2
Priority: 0
Uptime: 00:45:13
Expires: 00:02:17
PIM SM static RP Information:
Static RP: 192.168.2.2
# Run the display pim routing-table command to view the PIM routing table. The multicast
source 10.110.3.100/24 sends message to the multicast group 225.1.1.1/24. Host A and Host B
join the multicast group 225.1.1.1/24. Detailed information is displayed as follows:
NOTE
By default, after the receiver's DR receives the first multicast data, an SPT switchover is performed and
(S, G) routing entries are created. Therefore, (S, G) routing entries displayed on the switch are (S, G) entries
after the SPT switchover.
<SwitchA> display pim routing-table
Total 1 (*, G) entry; 1 (S, G) entry

(*, 225.1.1.1)
RP: 192.168.4.2
Protocol: pim-sm, Flag: WC
UpTime: 00:13:46
Upstream interface: Vlanif30,
1: Vlanif20
Protocol: igmp, UpTime: 00:13:46, Expires:-

(10.110.3.100, 225.1.1.1)
RP: 192.168.4.2
Protocol: pim-sm, Flag: SPT ACT
UpTime: 00:00:42
1: Vlanif20
Protocol: pim-sm, UpTime: 00:00:42, Expires:-
<SwitchB> display pim routing-table

(*, 225.1.1.1)
RP: 192.168.4.2
101
UpTime: 00:10:12
1: Vlanif40
Protocol: igmp, UpTime: 00:10:12, Expires:-

(10.110.3.100, 225.1.1.1)
RP: 192.168.4.2
UpTime: 00:00:42
1: Vlanif40
<SwitchC> display pim routing-table
Total 1 (S, G) entry
(10.110.3.100, 225.1.1.1)
Protocol: pim-sm, Flag:
UpTime: 00:01:25
1: Vlanif40

(10.110.3.100, 225.1.1.1)
RP: 192.168.4.2
UpTime: 00:00:42
1: Vlanif30
1: Vlanif60
<SwitchE> display pim routing-table

(*, 225.1.1.1)
RP: 192.168.4.2 (local)
UpTime: 00:13:16
Upstream interface: Register
1: Vlanif10
1: Vlanif90
102
Protocol: igmp, UpTime: 00:13:16, Expires: 00:03:22

(10.110.5.100, 225.1.1.1)
Protocol: pim-sm, Flag:
UpTime: 00:01:22
1: Vlanif90
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20 30
#
#
interface Vlanif10
ip address 192.168.5.1 255.255.255.0
pim sm
#
interface Vlanif20
ip address 10.110.1.1 255.255.255.0
pim silent
pim sm
igmp enable
#
interface vlanif30
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
pim
static-rp 192.168.2.2
#
return
#
sysname SwitchB
#
#
vlan batch 40 90
103
#
interface Vlanif40
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif90
ip address 192.168.2.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
static-rp 192.168.2.2
#
return
#
sysname SwitchC
#
vlan batch 40 50
#
#
interface Vlanif40
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
#
interface Vlanif50
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
static-rp 192.168.2.2
#
return
#
sysname SwitchD
#
#
#
interface Vlanif30
104
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif60
ip address 192.168.4.1 255.255.255.0
pim sm
#
interface Vlanif70
ip address 10.110.4.1 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif80
ip address 10.110.3.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
ospf 1
area 0.0.0.0
network 10.110.3.0 0.0.0.255
network 10.110.4.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
static-rp 192.168.2.2
#
return
l Configuration file of SwitchE
#
sysname SwitchE
#
#
#
acl number 2008
#
interface Vlanif10
ip address 192.168.5.2 255.255.255.0
pim sm
#
interface Vlanif50
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Vlanif60
ip address 192.168.4.2 255.255.255.0
pim sm
#
interface Vlanif90
ip address 192.168.2.2 255.255.255.0
pim sm
#
105
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
pim
c-bsr vlanif 60
c-rp vlanif 60 group-policy 2008
static-rp 192.168.2.2
#
return
3.15.2 Example for Configuring PIM-SM in the SSM Model
In Figure 3-4, the switch configured with PIM-SM is required to provide SSM services for hosts
on the network so that hosts in a multicast group can receive VoD information sent from specified
multicast sources.
106
Figure 3-4 Networking diagram for configuring PIM-SM in the SSM model
SwitchA
SwitchB
SwitchC
PIM-SM
SwitchD
HostA
HostB
10GE1/0/2
10GE1/0/1
10GE1/0/4
SwitchE
10GE1/0/3
S2
S1
SwitchF
10GE1/0/2
10GE1/0/2
10GE1/0/2
10GE1/0/2
10GE1/0/1
10GE1/0/1
10GE1/0/1
10GE1/0/1
10GE1/0/1
10GE1/0/3
10GE1/0/4
VLANIF10
192.168.5.1/24
VLANIF10
192.168.5.2/24
VLANIF20
10.110.1.1/24
VLANIF30
192.168.1.1/24
VLANIF30
192.168.1.2/24
VLANIF50
VLANIF90
VLANIF60
192.168.2.2/24
192.168.3.2/24
192.168.4.2/24
VLANIF90
192.168.2.1/24
VLANIF40
10.110.2.1/24
VLANIF60
192.168.4.1/24
VLANIF70
VLANIF80
10.110.4.1/24
10.110.3.1/24
VLANIF50
192.168.3.1/24
VLANIF40
10.110.2.2/24

The configuration roadmap is as follows:
1. Configure an IP address for each interface and a unicast routing protocol. PIM is an intra-
domain multicast routing protocol that depends on unicast routing protocols.
2. Enable the multicast function on switches providing multicast services. Before configuring
PIM-SM, you must enable the multicast function.
3. Enable PIM-SM on all interfaces. You can configure other PIM-SM functions only after
PIM-SM is enabled.
4. Enable IGMP on interfaces that connect the switch and hosts and set the IGMP version to
IGMPv3. A receiver can join and leave a multicast group of a specified source by sending
IGMP messages. The leaf switches maintain the multicast member relationship through
IGMP.
5. Enable PIM silent on interfaces that connect the switch and hosts to prevent malicious hosts
from simulating sending PIM Hello packets. In this manner, security of PIM-SM domain
is ensured.
NOTE
If the user host network segment connects to multiple switches, do not enable PIM silent on interfaces
that connect these switches and user hosts. For example, PIM silent cannot be enabled on SwitchB
and SwitchC.
107
6. Configure the same address range for SSM groups on each switch. Ensure that switches in
the PIM-SM domain provide services only for multicast groups in the range of SSM group
addresses. In this manner, multicast can be controlled effectively.
Procedure
Step 1 Configure an IP address for each interface and a unicast routing protocol.
# Configure the IP address and mask for each interface shown in Figure 3-4, and configure
OSPF on each switch to ensure that switches can communicate at the network layer and can
dynamically update routes through the unicast routing protocol. The configuration of SwitchB,
SwitchC, SwitchD, SwitchE, and SwitchF are similar to the configuration of SwitchA, and are
not mentioned.
[~SwitchA] vlan batch 10 20 30
[~SwitchA] commit
[~SwitchA] commit
[~SwitchA] ospf
[~SwitchA-ospf-1-area-0.0.0.0] network 10.110.1.0 24
Step 2 Enable multicast, and enable PIM-SM on all interfaces.
# Enable multicast on all switches and PIM-SM on all interfaces. The configuration of Switch
B, Switch C, Switch D, Switch E, and SwitchF are similar to the configuration of Switch A, and
are not mentioned.
108
Step 3 Enable IGMP on interfaces that connect the switch and hosts and set IGMP version to IGMPv3.
# Enable IGMP on interfaces that connect SwitchA and user hosts. The configuration of
SwitchB and SwitchC are similar to the configuration of SwitchA, and are not mentioned.
[~SwitchA-Vlanif20] igmp version 3
Step 4 Enable PIM silent on interfaces on SwitchA.
[~SwitchA-Vlanif20] pim silent
Step 5 Configure the address range for SSM groups.
# Set the address of SSM group to range from 232.1.1.0 to 232.1.1.24 on all switches. The
configuration of Switch B, Switch C, Switch D, Switch E, and SwitchF are similar to the
configuration of Switch A, and are not mentioned here.
[~SwitchA-acl4-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[~SwitchA] pim
[~SwitchA-pim] ssm-policy 2000
[~SwitchA-pim] quit
# Run the display pim interface command to check the PIM configuration and status. The PIM
information on SwitchC is displayed as follows:
<SwitchC> display pim interface
Interface State NbrCnt HelloInt DR-Pri DR-Address
Vlanif40 up 0 30 1 10.110.2.2 (local)
Vlanif50 up 1 30 1 192.168.3.1 (local)
# Run the display pim routing-table command to view the PIM routing table. HostA receives
information sent from multicast source 10.110.3.100/24 and 10.110.4.100/24 to the multicast
group 232.1.1.1/24. HostB receives information sent from multicast source 10.110.3.100/24 to
multicast group 232.1.1.1/24. The following information is displayed.
<SwitchA> display pim routing-table

(10.110.3.100, 232.1.1.1)
Protocol: pim-ssm, Flag: SPT ACT
UpTime: 00:13:46
109
1: Vlanif20
Protocol: pim-ssm, UpTime: 00:13:46, Expires:-

(10.110.4.100, 232.1.1.1)
UpTime: 00:00:42
1: Vlanif20

(10.110.3.100, 232.1.1.1)
UpTime: 00:10:12
1: Vlanif40
(10.110.3.100, 232.1.1.1)
Protocol: pim-ssm, Flag:
UpTime: 00:01:25
1: Vlanif40

(10.110.3.100, 232.1.1.1)
UpTime: 00:00:42
1: Vlanif60
<SwitchE> display pim routing-table

(10.110.3.100, 232.1.1.1)
UpTime: 00:13:16
Upstream interface: Vlanif 60
110
1: Vlanif10
1: Vlanif50
1: Vlanif90
Protocol: pim-ssm, UpTime: 00:13:16, Expires: 00:03:22
<SwitchF> display pim routing-table

(10.110.4.100, 232.1.1.1)
UpTime: 00:13:16
Upstream interface: Vlanif 70
1: Vlanif30
Protocol: pim-ssm, UpTime: 00:15:28, Expires: 00:05:21
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20 30
#
#
acl number 2000
#
interface Vlanif10
ip address 192.168.5.1 255.255.255.0
pim sm
#
interface Vlanif20
ip address 10.110.1.1 255.255.255.0
pim silent
pim sm
igmp enable
igmp version 3
#
interface vlanif30
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
111
network 192.168.5.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname SwitchB
#
#
vlan batch 40 90
#
acl number 2000
#
interface Vlanif40
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
igmp version 3
#
interface Vlanif90
ip address 192.168.2.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname SwitchC
#
vlan batch 40 50
#
#
acl number 2000
#
interface Vlanif40
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
igmp version 3
#
interface Vlanif50
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
112
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname SwitchD
#
vlan batch 60 80
#
#
acl number 2000
#
interface Vlanif60
ip address 192.168.4.1 255.255.255.0
pim sm
#
interface Vlanif80
ip address 10.110.3.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/4
#
ospf 1
area 0.0.0.0
network 10.110.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname SwitchE
#
#
#
acl number 2000
#
interface Vlanif10
ip address 192.168.5.2 255.255.255.0
pim sm
#
interface Vlanif50
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Vlanif60
ip address 192.168.4.2 255.255.255.0
113
pim sm
#
interface Vlanif90
ip address 192.168.2.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
l Configuration file of SwitchF
#
sysname SwitchD
#
vlan batch 30 70
#
#
acl number 2000
#
interface Vlanif30
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif70
ip address 10.110.4.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.4.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
114
3.15.3 Example for Configuring PIM for Anycast RP
HostA and HostB in Figure 3-5 receive VoD information in multicast mode. When the network
is overloaded or traffic is concentrated on an RP, the RP may be overburdened or fails and the
route convergence may be slow. HostB is required to join the closest RP to fast receive the
multicast data.
Figure 3-5 Networking diagram for configuring PIM for anycast RP
HostB
Loopback0
Loopback0
10GE1/0/2
10GE1/0/1
10GE1/0/1
SwitchC
SwitchD
PIM-SM
Source
Loopback1
Loopback1
10GE1/0/2
10GE1/0/3
1
0
G
E
1
/
0
/
1
SwitchA
SwitchB
10GE1/0/1
HostA
10GE1/0/3
V
L
A
N
I
F
1
1
1
0
.
1
1
0
.
1
.
1
/
2
4
10GE1/0/2
VLANIF10
192.168.1.1/24
VLANIF10
192.168.1.2/24
VLANIF30
192.168.3.1/24
VLANIF21
10.110.2.1/24
1.1.1.1/32
2.2.2.2/32
3.3.3.3/32
1.1.1.1/32
VLANIF20
192.168.2.2/24
VLANIF20
192.168.2.1/24
VLANIF31
10.110.3.1/24
VLANIF30
192.168.3.2/24

Configuring PIM for anycast RP reduces the burden on an RP and hosts can join the closest RP.
1. Configure IP addresses and unicast routes for interfaces on each switch to ensure
connectivity at the network layer.
2. Configure basic multicast functions so that multicast data can be forwarded. Enable
multicast, enable PIM-SM and configure C-BSR and C-RP on each interface, and enable
IGMP on interfaces that connect the switch and hosts.
115
3. Configure anycast RP to allow HostB to fast receive multicast data. Configure SwitchC
and SwitchD as the anycast RP peers. HostB joins the closest SwitchD. After receiving the
source multicast data, SwitchA encapsulates the data into Register messages and sends the
message to SwitchC. SwitchC forwards the Register message to SwitchD. Host B then
receives the multicast source data.
Procedure
Step 1 Configure an IP address for each interface on the switch and a unicast routing protocol.
# Configure the IP address and mask for each interface on the switch shown in Figure 3-5, and
configure OSPF on each switch to ensure that switches can communicate. The configuration of
SwitchB, SwitchC, and SwitchD are similar to the configuration of SwitchA, and are not
mentioned.
[~SwitchA] vlan batch 10 11
[~SwitchA] commit
[~SwitchA] commit
[~SwitchA] ospf
Step 2 Configure basic multicast functions on each switch.
# Enable multicast routing on SwitchA and PIM-SM on interfaces. The configuration of
SwitchB,SwitchC, and SwitchD are similar to the configuration of SwitchA, and are not
mentioned here.
[~SwitchA] interface vlanif10
[~SwitchA] interface vlanif11
# Configure the Loopback0 interface of SwitchC and SwitchD as C-RP and C-BSR. The
configuration of SwitchD is similar to the configuration of SwitchC, and is not mentioned here.
116
[~SwitchC] pim
[~SwitchC-pim] c-bsr loopback 0
[~SwitchC-pim] c-rp loopback 0
[~SwitchC-pim] commit
[~SwitchC-pim] quit
# Enable IGMP on interfaces that connect SwitchC, SwitchD and hosts. The configuration of
SwitchD is similar to the configuration of SwitchC, and is not mentioned.
[~SwitchC] interface vlanif21
[~SwitchC-Vlanif21] igmp enable
[~SwitchC-Vlanif21] commit
[~SwitchC-Vlanif21] quit
Step 3 Configure anycast RP.
# Configure the Loopback0 interface of SwitchC and SwitchD as anycast RPs. The configuration
of SwitchD is similar to the configuration of SwitchC, and is not mentioned.
[~SwitchC] pim
[~SwitchC-pim] anycast-rp 1.1.1.1
[~SwitchC-pim-anycast-rp-1.1.1.1] commit
[~SwitchC-pim-anycast-rp-1.1.1.1] quit
# Configure the address of Loopback1 on SwitchC and SwitchD as the local address of each
anycast RP. The configuration of SwitchD is similar to the configuration of SwitchC, and is not
mentioned.
[~SwitchC-pim-anycast-rp-1.1.1.1] local-address 2.2.2.2
# Configure SwitchC and SwitchD as anycast RP peers.
[~SwitchC-pim-anycast-rp-1.1.1.1] peer 3.3.3.3
[~SwitchC-pim] quit
[~SwitchD-pim] anycast-rp 1.1.1.1
[~SwitchD-pim-anycast-rp-1.1.1.1] peer 2.2.2.2
[~SwitchD-pim-anycast-rp-1.1.1.1] commit
[~SwitchD-pim-anycast-rp-1.1.1.1] quit
[~SwitchD-pim] quit
# Run the display pim rp-info command to check information about the RP on SwitchC and
SwitchD.
<SwitchC> display pim rp-info
RP: 1.1.1.1 (local)
Priority: 0
Uptime: 00:45:19
Expires: 00:02:11
<SwitchD> display pim rp-info
RP: 1.1.1.1 (local)
Priority: 0
117
Uptime: 02:27:56
Expires: 00:01:39
The preceding information shows that SwitchC and SwitchD serve as the RPs and can forward
the Register message from the multicast source to each other.
# Run the display pim routing-table command to check PIM entries on each switch. The
multicast source 10.110.1.2/24 in the PIM-SM domain sends multicast data to multicast group
G 226.1.1.1, and HostB joins G and receives the multicast data sent to G. The multicast source
sends a Register message to Switch C and Host B sends a Join message to Switch D.
(10.110.1.2, 226.1.1.1)
RP: 1.1.1.1 (local)
Protocol: pim-sm, Flag: 2MSDP ACT
UpTime: 00:00:38
Upstream neighbor: NULL
RPF prime neighbor: NULL
Downstream interface(s) information: None
(*, 226.1.1.1)
RP: 1.1.1.1 (local)
UpTime: 00:01:25
1: Vlanif31
Protocol: igmp, UpTime: 00:01:25, Expires: -
(10.110.1.2, 226.1.1.1)
RP: 1.1.1.1 (local)
Protocol: pim-sm, Flag: 2MSDP SWT ACT
UpTime: 00:00:02
1: Vlanif31
Protocol: pim-sm, UpTime: 00:00:02, Expires: -
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 11
#
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
pim sm
118
#
interface Vlanif11
ip address 10.110.1.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 20
#
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
#
return
#
sysname SwitchC
#
vlan batch 10 21 30
#
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif21
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
119
interface 10GE1/0/3
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 10.110.2.0 0.0.0.255
network 1.1.1.1 0.0.0.0
network 2.2.2.2 0.0.0.0
#
pim
c-bsr LoopBack0
c-rp LoopBack0
anycast-rp 1.1.1.1
local-address 2.2.2.2
peer 3.3.3.3
#
return
#
sysname SwitchD
#
vlan batch 20 30 31
#
#
interface Vlanif20
ip address 192.168.2.2 255.255.255.0
pim sm
#
interface Vlanif30
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface Vlanif31
ip address 10.110.3.1 255.255.255.0
pim sm
igmp enable
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
120
network 1.1.1.1 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.110.3.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
c-bsr LoopBack0
c-rp LoopBack0
anycast-rp 1.1.1.1
local-address 3.3.3.3
peer 2.2.2.2
#
return
This section describes common configuration errors and the corresponding troubleshooting
flowcharts.
3.16.1 RPT on a PIM-SM Network Fails to be Established
Fault Symptom
The RPT that provides services for ASM fails to be established. User hosts cannot receive
multicast data.
Fault Analysis
This fault is commonly caused by one of the following:
l The unicast route from multicast devices to the RP is unavailable.
l The RP addresses of multicast devices are inconsistent.
l The downstream interfaces of multicast devices do not receive any (*, G) Join message.
l PIM-SM is not enabled on interfaces.
l The RPF route to the RP is incorrect, for example, a unicast routing loop occurs.
l Configurations are incorrect, for example, the configurations of the MTU, or multicast
boundary are improper.
Procedure
Step 1 Check whether the PIM routing table contains correct (*, G) entries.
Run the display pim routing-table group-address command on the device to check whether
the PIM routing table contains (*, G) entries of multicast group G.
l If the PIM routing table contains correct (*, G) entries, you can run the display multicast
ip fib group-address command every 15 seconds to check whether the forwarding table
contains (S, G) entries that correspond to (*, G) entries and whether the value of the Matched
field in the command output keeps increasing.
If the forwarding table contains (S, G) entries and the value of the Matched field keeps
increasing, data forwarding on the upstream devices is correct but data cannot be
121
forwarded to downstream devices. In this case, check whether the TTL value is too
small or a forwarding failure occurs.
If the forwarding table does not contain (S, G) entries or the value of the Matched field
stops increasing:
If the local device is not an RP, it has not received any multicast data. Check whether
the PIM routing table on the upstream device contains correct (S, G) entries.
If the local device is the RP, the RPT has been established successfully. In this case,
check whether the source's DR is registered successfully.
l If the PIM routing table does not contain correct (*, G) entries, go to step 2.
Step 2 Check whether the downstream interfaces of upstream devices receive Join messages.
Run the display pim control-message counters interface interface-type interface-number
message-type join-prune command to check whether the number of Join/Prune messages
received by downstream interfaces increases.
l If the number of Join/Prune messages received by downstream interfaces of the device does
not increase, you can run the display pim control-message counters interface interface-
type interface-number message-type join-prune command on the downstream neighbors
to check whether the downstream devices send Join/Prune messages to upstream devices.
If the number of Join/Prune messages increases, the downstream devices send Join/
Prune messages. In this case, check whether PIM neighbors can communicate with each
other.
If the number does not increase, the downstream devices are not working properly. In
this case, locate and rectify the faults.
l If the number of Join/Prune messages received by downstream interfaces increases, go to
step 3.
Step 3 Check whether PIM-SM is enabled on the interface.
The fault occurs when PIM-SM is not enabled on the following interfaces:
l RPF neighboring interface to the RP
l RPF interface to RP
l Interface directly connected to network segment of user hosts (downstream interfaces of the
receiver's DR)
Run the display pim interface verbose command on the device to check PIM information on
interfaces. Check whether PIM-SM is enabled on the preceding interfaces.
l If "Error: Please enable multicast in the system view first." is displayed when you enable
PIM-SM on interfaces, run the multicast routing-enable command in the system view to
enable the multicast function. Then, enable PIM-SM on the interface.
l If PIM-SM is enabled on all interfaces, go to step 4.
Step 4 Check whether the RP information is correct.
Run the display pim rp-info command on the device to check whether the device learns the RP
information that provides services for a multicast group and has the same RP information as
other devices that provide services for the same group.
l If the device does not have RP information or has different RP information from other
devices and the static RP is used in the network,
122
run the static-rp command to configure the address of the RP that provides services for
a multicast group to be the same on all devices.
l If the RP information that provides services for a multicast group is the same on all devices,
go to step 5.
Step 5 Check whether the RPF route to the RP is available.
Run the display multicast rpf-info source-address command on the device to check whether
the RPF route to the RP is available.
l If the command output does not contain the RPF route to the RP, check the configuration
of the unicast route. Run the ping command on the device and on the RP to check whether
they can ping each other.
l If the command output contains the RPF route to the RP,
and the RPF route is a static multicast route, run the display current-configuration
command to check whether the static route configuration is correct.
If the command output indicates that the RPF route is a unicast route, run the display
ip routing-table command to check whether the unicast route is consistent with the
RPF route.
l If the command output contains the RPF route to the RP and the configuration of the route
is correct, go to step 6.
Step 6 Check whether the interface forwarding multicast data is the receiver's DR.
Run the display pim interface interface-type interface-number command to check whether the
interface forwarding multicast data is the receiver's DR.
l If there is no local flag in the command output, the device is not the receiver' DR. In such
a case, you can locate the receiver's DR based on the DR address that is displayed in the
command output and go to step 7.
l If there is local flag in the command output, go to step 7.
Step 7 Check whether the multicast boundary is configured on the interface.
Run the display current-configuration interface interface-type interface-number command to
check whether the multicast boundary is configured on the interface.
l If the command output contains multicast boundary, the multicast boundary is configured
on the interface. In this case, you can run the undo multicast boundary { group-address
{ mask | mask-length } | all } command to delete the multicast boundary configuration or
replan the networking to ensure that the multicast boundary is not configured on the RPF
interface or the RPF neighbor interface.
l If the multicast boundary is not configured on the interface, go to step 8.
Step 8 Check whether the source-policy is configured.
Run the display current-configuration configuration pim command to check current
configuration in the PIM view.
l If the command output contains the "source-policy acl-number" or the "source-policy acl-
name", source-based filtering rules are configured. If the received multicast data does not
match ACL rules, the multicast data is discarded. In this case, you can run the undo source-
policy command to delete the configuration or reconfigure the ACL rules to ensure that the
multicast data can be forwarded normally.
----End
123
3.16.2 SPT on a PIM-SM Network Fails to be Established
Fault Symptom
SPT is not established. User hosts cannot receive multicast data.
Fault Analysis
This fault is commonly caused by one of the following:
l The downstream interfaces of multicast devices do not receive any (S, G) Join message.
l PIM-SM is not enabled on the interface.
l The RPF route to the multicast source is incorrect (for example, a unicast routing loop
occurs).
l Configuration are incorrect (the configurations of MTU, switchover threshold, and
multicast boundary are incorrect.)
Procedure
Step 1 Check whether the PIM routing table contains correct (S, G) entries.
Run the display pim routing-table command on the device to check whether the PIM routing
table contains (S, G) entries.
l If the PIM routing table contains (S, G) entries, the entry has an RPT flag, and the multicast
group is in the ASM group address range, the upstream interface is the RPF interface to
RP but not the SPT interface to the multicast source, the SPT fails to be established.
Run the display current-configuration configuration pim command on the receiver's DR
to check the current configuration in the PIM view. If the command output contains "spt-
switch-threshold traffic-rate" or "spt-switch-threshold infinity", run the undo spt-switch-
threshold command to delete the configuration or run the spt-switch-threshold traffic-
rate command to reconfigure a proper traffic rate.
l If the PIM routing table contains (S, G) entries and the entry has an SPT flag, run the
display multicast ip fib command to check (S, G) entries and check whether the value of
Matched field keeps increasing. Wait a few minutes for the value of Matched field to update
after running the display multicast ip fib command.
If the value of Matched field keeps increasing, the data forwarding on the upstream
devices is normal but the data cannot be forwarded to downstream devices.
If the value of Matched field stops increasing and the current device is not the source's
DR, the current device fails to receive multicast data. In this case, check whether the
PIM routing table of the upstream devices have correct (S, G) entries.
l If the PIM routing table does not contain correct (S, G) entries, go to step 2.
Step 2 Check whether downstream interfaces receive Join messages.
NOTE
If the current device is the receiver's DR, skip this step.
Downstream interfaces fail to receive (S, G) Join packets if a fault occurs on these interfaces or
PIM-SM is not enabled.
124
Run the display pim control-message counters interface interface-type interface-number
message-type join-prune command to check whether the number of Join/Prune messages
received by downstream interfaces increases.
l If the number of Join/Prune messages received by downstream interfaces does not increase,
run the display pim control-message counters interface interface-type interface-
number message-type join-prune command to check whether the downstream devices
send Join/Prune messages to upstream devices.
If the number of Join/Prune messages increases, the downstream devices send Join/
Prune messages. In this case, check whether PIM neighbors can communicate with each
other.
If the number does not increase, the downstream devices are not working properly. In
this case, locate and rectify the faults.
l If the number of Join/Prune messages received by downstream interfaces increases, go to
step 3.
Step 3 Check whether PIM-SM is enabled on the interface.
The fault usually occurs when PIM-SM is not enabled on the RPF interface connecting to the
multicast source.
NOTE
When deploying a PIM-SM network, you are advised to enable multicast on all switches and the PIM-SM
protocol on all interfaces.
Run the display pim interface verbose command on the device to check PIM information on
interfaces. Check whether the PIM-SM function is enabled on the preceding interfaces.
l If the command output indicates that PIM-SM is not enabled on the interface or the PIM
mode on an interface is Dense, run the pim sm command on the interface.
If "Error: Please enable multicast in the system view first." is displayed when you enable
PIM-SM on interfaces. run the multicast routing-enable command in the system view to
enable the multicast function. Then, run the pim sm command in the interface view to
enable PIM-SM.
l If PIM-SM is enabled on all interfaces, go to step 4.
Step 4 Check whether the RPF route to the multicast source is available.
Run the display multicast rpf-info source-address command on the device to check whether
the RPF route to the multicast source is available.
l If the command output does not contain the RPF route to the multicast source, check the
configuration of the unicast route. Run the ping command on the device and on the multicast
source to check whether they can ping each other.
l If the command output contains the RPF route to the multicast source,
and the RPF route is a static multicast route, run the display current-configuration
command to check whether the static route configuration is correct.
If the command output indicates that the RPF route is a unicast route, run the display
ip routing-table command to check whether the unicast route is consistent with the
RPF route.
l If the command output contains the RPF route to the multicast source and the configuration
of the route is correct, go to step 5.
Step 5 Check whether the interface forwarding multicast data is the receiver's DR.
125
Run the display pim interface interface-type interface-number command to check whether the
interface forwarding multicast data is the receiver's DR.
l If there is no local flag in the command output, the device is not the receiver' DR. In such
a case, you can locate the receiver's DR based on the DR address that is displayed in the
command output and go to step 6.
l If there is local flag in the command output, go to step 6.
Step 6 Check whether the multicast boundary is configured on the interface.
Run the display current-configuration interface interface-type interface-number command to
check whether the multicast boundary is configured on the interface.
l If the command output contains multicast boundary, the multicast boundary is configured
on the interface. In this case, you can run the undo multicast boundary { group-address
{ mask | mask-length } | all } command to delete the multicast boundary configuration or
replan the networking to ensure that the multicast boundary is not configured on the RPF
interface or the RPF neighbor interface.
l If the multicast boundary is not configured on the interface, go to step 7.
Step 7 Check whether the source policy is configured.
Run the display current-configuration configuration pim command to check current
configuration in the PIM view.
l If the command output contains the "source-policy acl-number" or the "source-policy acl-
name", source-based filtering rules are configured. If the received multicast data does not
match ACL rules, the multicast data is discarded. In this case, you can run the undo source-
policy command to delete the configuration or reconfigure the ACL rules to ensure that the
multicast data can be forwarded normally.
----End
3.16.3 Registration Interface Still Exists After the Source DR
Registers with the RP
Fault Description
After multicast configuration is complete on a network, a multicast source sends multicast data.
However, after the source DR completes registration with the RP, the registration interface still
exists in the corresponding multicast forwarding entry.
Fault Analysis
The source DR does not delete the registration interface from the corresponding multicast
forwarding entry if the source DR does not receive any Register Stop message from the RP. A
common cause of this problem is that unicast routes between the source DR and PR are
unreachable.
Procedure
Step 1 Ensure that the source DR and RP have reachable unicast routes to each other and can ping each
other successfully.
126
l If the source DR has no reachable unicast route to the RP or has a route but cannot ping the
RP, the RP cannot receive the Register message from the source DR and therefore does not
send a Register Stop message to the source DR.
l If the PR has no reachable unicast route to the source DR or has a route but cannot ping the
source DR, the Register Stop message sent from the RP cannot reach the source DR.
Step 2 Run the display pim routing-table source-address command on the RP to check whether the
corresponding (S, G) entry exists.
If the source DR and RP can ping each other successfully, check whether the RP has completed
the SPT switchover to set up a multicast forwarding path toward the multicast source. If the SPT
switchover has not completed, the RP does not send a Register Stop message to the source DR.
To ensure a successful SPT switchover, configure the same PIM mode on all the interfaces
between the RP and source DR.
----End
127
4 MSDP Configuration
About This Chapter
The MSDP protocol is used to implement multicast routing and data forwarding between PIM-
SM domains and anycast RP in a PIM-SM domain.
4.1 MSDP Overview
MSDP sets up MSDP peer relationships between Rendezvous Points (RPs) in different PIM-
SM domains. MSDP peers exchange (S, G) information by sending SA messages. In this manner,
MSDP enables multicast data transmission among multiple PIM-SM domains.
4.2 MSDP Features Supported by the Switch
MSDP implements PIM-SM inter-domain multicast and anycast RP in a PIM-SM domain. You
can adjust SA message parameters and configure the maximum number of (S, G) entries in the
SA cache to improve forwarding efficiency.
This section provides the default MSDP configuration.
4.4 Configuring Basic MSDP Functions
MSDP allows you to set up MSDP peers between the PIM-SM domains, and the MSDP peers
exchange SA messages to share multicast source information.
4.5 Controlling SA Messages and the SA Cache
MSDP peers share (S, G) information by exchanging SA messages. To control SA message
transmission, you can configure the SA cache size, enable the local device to send SA request
messages, encapsulate multicast data in SA messages, and configure policies to filter SA
messages and SA request messages.
4.6 Configuring MSDP Anycast RP
Anycast RP supports the configuration of several RPs with the same address in a PIM-SM
domain. MSDP peer relationship is established between these RPs so that the multicast source
can register to the closest RP and the multicast receiver can join the closest RP.
4.7 Maintaining MSDP
Maintaining MSDP involves clearing MSDP peer statistics and (S, G) information in the SA
cache, and monitoring MSDP running status.
Configuration Guide - IP Multicast 4 MSDP Configuration
128
The configuration examples describe how to implement PIM-SM inter-domain multicast using
MSDP, inter-AS multicast, anycast RP within a PIM-SIM domain, and how to configure filtering
policies for SA messages.
This section describes common faults caused by incorrect MSDP configurations and provides
129
4.1 MSDP Overview
MSDP sets up MSDP peer relationships between Rendezvous Points (RPs) in different PIM-
SM domains. MSDP peers exchange (S, G) information by sending SA messages. In this manner,
MSDP enables multicast data transmission among multiple PIM-SM domains.
On the general PIM-SM networks, a multicast source registers only with the RP in the local
domain and hosts send Join messages to only the RP in the local domain. Information about
multicast sources of different domains is isolated. Therefore, the RP only knows information
about multicast sources in the local domain and can only distribute multicast packets sent by
multicast sources in this domain to local users. After a large PIM-SM network is divided into
multiple PIM-SM domains, a mechanism is required to enable user hosts in a PIM-SM domain
to receive multicast data from sources in another PIM-SM domain.
Multicast Source Discovery Protocol (MSDP) provides such a mechanism. It interconnects
multiple PIM-SM domains to implement inter-domain multicast. RPs in PIM-SM domains set
up MSDP peer relationships. By sending Source Active (SA) messages, the MSDP peers send
the (S, G) information from the RP to which the source registers to the RPs in another PIM-SM
domain.
As shown in Figure 4-1, an MSDP peer relationship is set up between RP1 in PIM-SM1 and
RP2 in PIM-SM2. Therefore, receivers in PIM-SM2 can receive multicast data sent from the
source in PIM-SM1.
Figure 4-1 Inter-domain multicast through MSDP
PIM-SM1
PIM-SM2
Source
DR1
RP1
DR2
Receiver
RP2
MSDP peers
Multicast packets
SA message

MSDP is developed to implement inter-domain multicast. When MSDP is enabled on devices
within a PIM-SM domain, it has another function: anycast RP. Anycast RP supports several RPs
with the same address in a PIM-SM domain. MSDP peer relationship is established between
these RPs so that the multicast source can register to the closest RP and the multicast receiver
can join the closest RP. In this manner, burdens on a single RP are released, and RP backup is
implemented.
130
4.2 MSDP Features Supported by the Switch
MSDP implements PIM-SM inter-domain multicast and anycast RP in a PIM-SM domain. You
can adjust SA message parameters and configure the maximum number of (S, G) entries in the
SA cache to improve forwarding efficiency.
NOTE
On the CE series switches, MSDP can be configured only on VLANIF and loopback interfaces. In this document,
MSDP is configured on VLANIF interfaces unless otherwise specified. Before configuring MSDP on a VLANIF
interface, add physical interfaces to the corresponding VLAN.
Basic MSDP Function
The basic MSDP function is to implement PIM-SM inter-domain multicast. When a multicast
network is divided into multiple PIM-SM domains, MSDP allows RPs in different domains to
communicate and share information about multicast sources with each other. Therefore, users
in a domain can receive multicast data from multicast sources in other domains.
MSDP peers perform the RPF check during SA message transmission to prevent loops. To
prevent RPF checks from occupying many system resources, you can configure static RPF peers.
In addition, you can configure an MSDP mesh group between MSDP peers to prevent them from
flooding SA messages.
The MSDP peer relationship is established by setting up a TCP connection between the peers.
MSDP supports MD5 authentication and keychain authentication to enhance the security of TCP
connections.
Controlling SA Messages and the SA Cache
SA messages are of great importance in MSDP implementation. The switch supports the
following configurations to control SA messages:
l Configuring the SA cache: The SA cache function is enabled on the device by default. The
device locally stores (S, G) information contained in SA messages. When the device needs
to receive messages, it can obtain valid (S, G) information from the SA cache.
l Configuring SA Request messages: When a receiver joins in the domain, the RP initiatively
sends an SA Request message to the MSDP peer to obtain valid (S, G) information. The
RP does not need to wait for the SA message sent by the MSDP peer during the next period.
This reduces the period during which the device obtains SA messages.
l Configuring the content of an SA message: An SA message can contain only (S, G)
information or contain both (S, G) information and encapsulated multicast data packets. If
an SA message contains only (S, G) information, remote users may not receive multicast
data because the (S, G) entry has already timed out when reaching the remote domain. If
multicast data packets are encapsulated in an SA message, remote users can still receive
multicast data when the (S, G) entry times out.
l Configuring rules for filtering SA messages: To control SA message transmission between
MSDP peers and prevent loops, you can configure rules for filtering SA messages. After
the rules are configured, the device receives and forwards only the SA messages that match
the rules.
131
Anycast RP in a PIM-SM Domain
When anycast RP is enabled in a PIM-SM domain, a multicast source registers to the closest RP
and a receiver joins the closest RP. This releases burdens on a single RP, implements RP backup,
and optimizes the forwarding path.
This section provides the default MSDP configuration.
Table 4-1 lists the default MSDP configuration.
Table 4-1 Default MSDP configuration
MSDP Disabled
MSDP peer Unspecified
MSDP authentication Unspecified
SA cache Enabled after an MSDP peer relationship is
established
Content of SA messages (S, G) information without encapsulated
multicast packets
Rule for filtering SA messages Unspecified. No SA message is filtered out.
Source RP address in the SA message Actual RP address used to create an SA
message

4.4 Configuring Basic MSDP Functions
MSDP allows you to set up MSDP peers between the PIM-SM domains, and the MSDP peers
exchange SA messages to share multicast source information.
Before configuring the basic MSDP functions, complete the following task:
l Configuring multicast in each PIM-SM domain
4.4.1 Enabling MSDP and 4.4.2 Configuring MSDP Peers are mandatory and other tasks are
optional.
4.4.1 Enabling MSDP
132
Context
To ensure that all RPs on a network share source information and the number of devices
configured with MSDP is minimized, it is recommended that you configure MSDP only on the
RPs on the network.
After MSDP is enabled, the MSDP view is displayed. You can perform other MSDP
configurations in the MSDP view. Enabling MSDP is the prerequisite for other MSDP
configurations.
Procedure
Step 1 Run:
system-view
Step 2 Run:
msdp
MSDP is enabled and the MSDP view is displayed.
Step 3 Run:
commit
----End
4.4.2 Configuring MSDP Peers
Context
An MSDP peer relationship is identified by the addresses of the local and remote MSDP peers.
You must create an MSDP peer relationship on both the local and remote ends.
Procedure
Step 1 Run:
system-view
Step 2 Run:
msdp
The MSDP view is displayed.
Step 3 Run:
peer peer-address connect-interface interface-type interface-number
MSDP peers are created.
l peer-address: specifies the address of the remote MSDP peer.
l interface-type interface-number: specifies the local interface connected to the remote MSDP
peer.
133
Step 4 (Optional) Run:
peer peer-address description text
The description of a remote MSDP peer is added.
This configuration helps to differentiate remote MSDP peers and manage the connections to the
remote MSDP peers.
timer retry interval
The interval at which MSDP peers retry to set up a connection with each other is set.
A TCP connection needs to be quickly established between MSDP peers in one of the following
situations:
l An MSDP peer is created.
l The disconnected MSDP peers need to be reconnected.
l A faulty MSDP peer attempts to restore works.
You can run this command to adjust the interval at which MSDP peers retry to set up a
connection.
Step 6 (Optional) Configure an MSDP authentication mode.
To improve the security of a TCP connection, MSDP supports two authentication modes: MD5
and keychain. MD5 authentication and keychain authentication are mutually exclusive on an
MSDP peer. You must configure the same password on both ends in MD5 authentication or
configure the same encryption algorithm and password on both ends in keychain authentication.
Otherwise, the TCP connection cannot be set up.
l Run:
peer peer-address password { cipher cipher-password | simple simple-password }
MSDP MD5 authentication is configured.
CAUTION
If simple is selected, the password is saved in the configuration file in plain text. This brings
security risks. It is recommended that you select cipher to save the password in cipher text.
l Run:
peer peer-address keychain keychain-name
MSDP keychain authentication is configured.
keychain-name in this command is defined in the keychain command. For details, see
"Keychain Configuration" in the CloudEngine 6800&5800 Series Switches Configuration
Guide-Security.
shutdown peer-address
The session with the remote MSDP peer is closed.
After the session with the remote MSDP peer is closed, SA messages are not exchanged between
the MSDP peers. The configuration, however, is saved. You can run the undo shutdown peer-
134
address command to set up a session with the remote MSDP peer and to reestablish a TCP
connection.
Step 8 Run:
commit
----End
4.4.3 (Optional) Configuring Static RPF Peers
Prerequisites
MSDP peers have been configured. For details, see 4.4.2 Configuring MSDP Peers.
Context
The device does not perform RPF checks on SA messages received from static RPF peers.
Therefore, SA messages are not discarded.
If a device has only one remote MSDP peer, the remote MSDP peer automatically becomes the
static RPF peer.
Procedure
Step 1 Run:
system-view
Step 2 Run:
msdp
Step 3 Run:
static-rpf-peer peer-address [ rp-policy ip-prefix-name ]
The remote MSDP peer is specified as the RPF peer.
l rp-policy ip-prefix-name: specifies a policy for filtering SA messages based on the source
RP address.
When you specify multiple static RPF peers for a switch, pay attention to the following points:
If rp-policy is set for all peers, after receiving SA messages from multiple active static
RPF peers, the local switch filters the SA messages based on the configured rp-policy
for each static RPF peer. Only the SA messages that match policy rules are accepted.
If no rp-policy is set for the peers, the switch accepts all SA messages from the active
static RPF peers.
Step 4 Run:
commit
135
----End
4.4.4 (Optional) Configuring the MSDP Mesh Group
Prerequisites
MSDP peers have been configured. For details, see 4.4.2 Configuring MSDP Peers.
Context
An AS may contain multiple MSDP peers. To prevent these MSDP peers from flooding SA
messages, configure an MSDP mesh group to optimize data traffic control.
MSDP peers in a mesh group forward SA messages that are sent by a peer not in the mesh group
and pass the RPF check to other members in the group. If SA messages are sent by a group
member, the messages are accepted without the RPF check and are not forwarded to other group
members. This prevents MSDP peers from flooding SA messages and simplifies the RPF
checking mechanism on MSDP peers.
You can set up an MSDP mesh group by configuring the same mesh group name for multiple
MSDP peers.
Procedure
Step 1 Run:
system-view
Step 2 Run:
msdp
Step 3 Run:
peer peer-address mesh-group name
The remote MSDP peer is added to the mesh group.
l name: specifies the name of the mesh group. Members of the same mesh group use the same
group name.
Configuration notes:
l Members of a mesh group set up an MSDP peer relationship with one another using the mesh
topology.
l The two members between which the connection is set up must recognize each other as the
member of the same mesh group.
l One MSDP peer can join only one mesh group. If an MSDP peer is configured to join different
mesh groups several times, the latest configuration takes effect.
Step 4 Run:
136
commit
----End
Context
After configuring basic MSDP functions, run the following commands in any view to check the
brief and detailed information about MSDP peers.
Procedure
l Run the display msdp brief command to check brief information about MSDP peers.
l Run the display msdp peer-status [ peer-address ] command to check the detailed
information about MSDP peers.
----End
4.5 Controlling SA Messages and the SA Cache
MSDP peers share (S, G) information by exchanging SA messages. To control SA message
transmission, you can configure the SA cache size, enable the local device to send SA request
messages, encapsulate multicast data in SA messages, and configure policies to filter SA
messages and SA request messages.
Basic MSDP functions have been configured. For details, see 4.4 Configuring Basic MSDP
Functions.
The following configuration tasks can be performed at any sequence as required.
4.5.1 Configuring the SA Cache
Context
To shorten the delay of obtaining multicast information, enable the SA caching function on the
device. The device can locally cache (S, G) entities contained in SA messages. When the device
receives a new Join message, it searches for the (S, G) entry in the local SA cache.
l If the matching (S, G) entry is found, the device adds the sender of the Join message to the
shortest path tree (SPT) with S as the root.
l If no matching (S, G) entry is found, the device must wait for the SA message sent by the
MSDP peer during the next period.
137
When there are more (S, G) entries in the cache, they occupy a larger memory space. You can
set the maximum number of (S, G) entries to be cached to efficiently protect the device against
Denial of Service (DoS) attacks.
Procedure
Step 1 Run:
system-view
Step 2 Run:
msdp
Step 3 Run:
undo cache-sa-disable
The SA caching function is enabled.
By default, the SA caching function is enabled on the switch that has a remote MSDP peer
specified.
peer peer-address sa-cache-maximum sa-limit
The maximum number of (S, G) entries is set.
The value takes effect only when it is smaller than the specification of the cache. If the value is
larger than the specification of the cache, the specification of the cache takes effect. By default,
a maximum of 8192 (S, G) entries can be saved to the SA cache.
Step 5 Run:
commit
----End
4.5.2 Setting Parameters of the SA Request Message
Context
By default, when a receiver joins in, the device does not initiatively send an SA Request message
to the MSDP peer. The device waits for the SA message sent by the MSDP peer during the next
period, which delays the time for the receiver to obtain information about multicast sources. To
enable the new receiver to learn information about active multicast sources immediately, the
device needs to initiatively send an SA Request message to the MSDP peer.
After receiving the SA Request message, the remote MSDP peer responds to the SA message
with a message containing the (S, G) information that meets the requirements. If the rule for
filtering SA Request messages is configured on the remote MSDP peer, the remote MSDP peer
responds only to the SA Request messages that match the rule.
138
NOTE
Before configuring a local RP to send SA Request messages, you must disable the SA caching function on
the local RP and enable the SA caching function on its remote MSDP peer.
Procedure
Step 1 Run:
system-view
Step 2 Run:
msdp
Step 3 Configure a local RP to send SA Request messages initiatively.
Run:
peer peer-address request-sa-enable
The local RP is configured to send SA Request messages initiatively.
Step 4 (Optional) Configure the rule for filtering received SA Request messages on the remote MSDP
peer.
Run:
peer peer-address sa-request-policy [ acl { basic-acl-number | acl-name } ]
A rule for filtering received SA Request messages is configured.
Step 5 Run:
commit
----End
4.5.3 Configuring the Content of an SA Message
Context
The interval for sending multicast data by some multicast sources is longer than the aging time
of (S, G) entries. In this case, the source DR can only encapsulate multicast data into Register
messages, and send the messages to the source RP. The source RP transmits (S, G) information
contained in SA messages to the remote RP. Then the remote RP sends an (S, G) Join message
to the source DR and creates an SPT. The remote RP cannot receive multicast data sent by this
source because the (S, G) entry is aged out.
After the function of encapsulating a multicast packet in an SA message is enabled on a source
RP, the source RP encapsulates a multicast packet in an SA message and sends the message out.
After receiving the SA message, the remote RP decapsulates it and transmits the multicast packet
along RPT to users in the local domain.
In addition, you can set the time to live (TTL) threshold to control what multicast data will be
encapsulated in the SA message and forwarded to the MSDP peer.
l When the RP creates an SA message for the first time, it checks the TTL value of the IP
header in the multicast packet. If the value is smaller than the threshold, the RP does not
139
create an SA message. If the value is equal to or larger than the threshold, the RP
encapsulates the multicast packet in an SA message and forwards the message to an MSDP
peer.
l When the RP receives an SA message that contains the multicast packet, it reduces the TTL
value in the IP header by 1 and checks the TTL value. If the value is smaller than the
threshold, the RP does not forward the SA message to any MSDP peer. If the value is equal
to or larger than the threshold, the RP forwards the SA message to an MSDP peer.
Procedure
Step 1 Run:
system-view
Step 2 Run:
msdp
Step 3 Run:
encap-data-enable
The function of encapsulating multicast data packets in SA messages is enabled.
peer peer-address minimum-ttl ttl
The TTL value of multicast data packets is set.
By default, the TTL value of multicast data packets is set to 0.
Step 5 Run:
commit
----End
4.5.4 Configuring the Rule for Filtering SA Messages
Context
By default, a device receives all SA messages that pass the RPF check, and forwards the SA
messages to all MSDP peers. By configuring the filtering rule for creating, receiving, and
forwarding SA messages, you can control what SA messages are transmitted between MSDP
peers.
l After you configure the rules for filtering the SA messages to be created, the device filters
the (S, G) entries advertised through SA messages based on the rules, and determines
whether to create the multicast source messages.
l After you configure the rules for filtering the SA messages to be forwarded and received,
the device filters the (S, G) entries advertised through SA messages based on the rules, and
determines whether to accept or forward the multicast source messages.
140
Procedure
Step 1 Run:
system-view
Step 2 Run:
msdp
Step 3 Run:
import-source [ acl { acl-number | acl-name } ]
The rules for filtering multicast sources in SA messages are set.
Step 4 Run:
peer peer-address sa-policy { import | export } [ acl { advanced-acl-number | acl-
name } ]
The rules for filtering the received SA messages or the SA messages to be forwarded are set.
Step 5 Run:
commit
----End
Context
After configuring parameters for SA messages and the SA caching function, run the following
commands in any view to check the SA cache information and detailed information about MSDP
peers.
Procedure
l Run the display msdp sa-cache [ group-address | source-address | as-number ]
*
command
to check (S, G) information in the SA cache.
l Run the display msdp sa-count [ as-number ] command to check the number of (S, G)
entries in the SA cache.
----End
4.6 Configuring MSDP Anycast RP
Anycast RP supports the configuration of several RPs with the same address in a PIM-SM
domain. MSDP peer relationship is established between these RPs so that the multicast source
can register to the closest RP and the multicast receiver can join the closest RP.
141
The PIM-SM function has been enabled on all switchs in the PIM-SM domain and RP are not
configured.
Perform configuration tasks in the sequence listed as follows.
4.6.1 Configuring an RP
Context
In the anycast RP application, configure RPs with the same address on multiple switches in a
PIM-SM domain. Before configuring anycast RP on the devices in the PIM-SM domain,
configure a loopback interface on each device and assign the same IP address to the loopback
interfaces. Then configure these interfaces as static RPs or C-RPs.
l If you configure a static RP, configure an RP on each switch in the PIM-SM domain.
l If you configure a C-RP, you only need to configure the C-RP on the switch as the anycast
RP.
NOTE
After an RP is configured, advertise the IP address of the RP interface through unicast routes to ensure that each
switch on the network has a reachable route to the RP interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface loopback interface-number
The loopback interface view is displayed.
Step 3 Run:
ip address ip-address { mask | mask-length }
An IP address is configured for the loopback interface.
Step 4 (For a C-RP) Run:
pim sm
PIM-SM is enabled on the RP interface.
Before configuring a C-RP, run this command. This command is not required if you configure
a static RP.
Step 5 Run:
quit
142
Step 6 Run:
pim
Step 7 Configure the loopback interface address as a static RP address or a C-RP address.
l Configure a static RP.
Run:
static-rp rp-address
The loopback interface address is configured as a static RP address.
l Configure a C-RP.
NOTE
When configuring dynamic RP, configure C-BSRs. When configuring MSDP-based anycast RP,
ensure that the addresses of the C-BSR and the C-RP are different. For details on how to configure the
C-BSR, see Configuring a C-BSR.
Run:
c-rp loopback interface-number
The loopback interface address is configured as a C-RP address.
Step 8 Run:
commit
----End
4.6.2 Configuring MSDP Peer Connections
Context
MSDP peer relationships need be set up between RPs. If more than three switches exist, establish
an MSDP peer relationship between each two switches and add them to the same mesh group.
The purpose of this task is to set up MSDP peer relationships among multiple RPs. For details,
see 4.4 Configuring Basic MSDP Functions.
4.6.3 Configuring the Source RP Address of the SA Message
Context
In the anycast RP application, you need to configure RPs on two or more devices in a PIM-SM
domain, assign the same IP address to these RPs, and set up MSDP peer relationships between
these devices. An MSDP peer performs the RPF check on a received SA message and then
discards the message if the addresses of the local RP and the remote RP are the same. Therefore,
you need to specify a logical RP address for the SA message on the device on which anycast RP
is to be configured.
Procedure
Step 1 Run:
system-view
143
Step 2 Run:
msdp
Step 3 Run:
originating-rp interface-type interface-number
The address of the logical RP interface is set as the source RP address for the SA message.
The interface functioning as a logical RP cannot be an actual RP interface. It is recommended
that you configure the address of the MSDP peer interface as the logical RP address.
Step 4 Run:
commit
----End
Context
After configuring anycast RP in a PIM-SM domain, run the following commands in any view
to check the brief and detailed information about MSDP peers and RP information about PIM
routing entries.
Procedure
l Run the display msdp brief command to check brief information about MSDP peers.
l Run the display pim routing-table command to check RP information about PIM routing
entries.
----End
4.7 Maintaining MSDP
Maintaining MSDP involves clearing MSDP peer statistics and (S, G) information in the SA
cache, and monitoring MSDP running status.
4.7.1 Clearing Statistics on MSDP Peers
Context
When you clear statistics on MSDP peers, you can determine whether to reset the TCP
connection between MSDP peers based on the actual networking environment. Resetting the
TCP connection will affect MSDP running.
144
CAUTION
Statistics on MSDP peers cannot be restored after you clear them. Therefore, exercise caution
when you run the command.
Procedure
l Run the reset msdp peer [ peer-address ] command in the user view to reset the TCP
connection with the specified MSDP peer and clear all statistics of the specified MSDP
peer.
l Run the reset msdp statistics [ peer-address ] command in the user view to clear the
statistics of one or multiple MSDP peers but not to reset the TCP connection.
l Run the reset msdp control-message counters [ peer peer-address ] command in the user
view to clear the statistics on the received, sent, and discarded MSDP messages.
----End
4.7.2 Clearing (S, G) Information in the SA Cache
Context
CAUTION
The (S, G) information in the SA cache cannot be restored after you clear it. Therefore, exercise
caution when you run the command.
Procedure
l Run the reset msdp sa-cache [ group-address ] command in the user view to clear the (S,
G) information in the SA cache.
----End
4.7.3 Monitoring the Running Status of MSDP
Context
During the routine maintenance, you can run the following commands in any view to learn the
running status of MSDP.
Procedure
l Run the display msdp brief [ state { connect | down | listen | shutdown | up } ] command
to check brief information about MSDP peers.
145
l Run the display msdp sa-cache [ group-address | source-address | as-number ]
*
command
to check (S, G) information in the SA cache.
l Run the display msdp sa-count [ as-number ] command to check the number of (S, G)
entries in the SA cache.
l Run the display msdp control-message counters [ peer peer-address | message-type
{ source-active | sa-request | sa-response | keepalive | notification | traceroute-
request | traceroute-reply | data-packets | unknown-type } ]
*
command to check the
statistics on the received, sent, and discarded MSDP packets.
----End
The configuration examples describe how to implement PIM-SM inter-domain multicast using
MSDP, inter-AS multicast, anycast RP within a PIM-SIM domain, and how to configure filtering
policies for SA messages.
4.8.1 Example for Configuring PIM-SM Inter-domain Multicast
Using MSDP
As shown in Figure 4-2, two ASs exist on the network. Each AS contains at least one PIM-SM
domain and each PIM-SM domain may contain no or one multicast source and receiver. The
receiver in PIM-SM2 domain wants to receive the multicast data sent by both S3 in PIM-SM3
and S1 in PIM-SM1.
146
Figure 4-2 Networking diagram of PIM-SM inter-domain multicast
AS100
AS200
PIM-SM1
S1
10GE1/0/2
1
0
G
E
1
/0
/1
Loopback0
SwitchB
SwitchC
SwitchE
Loopback0
1
0
G
E
1
/0
/1
PIM-SM2
MSDP peers
S3
Loopback0
10GE1/0/3
10GE1/0/2
PIM-SM3
Receiver
SwitchA
10GE1/0/2
1
0
G
E
1
/
0
/
1
10G
E
1/0/2
1
0
G
E
1
/
0
/
1
10GE1/0/2
10GE1/0/1
SwitchD
SwitchF
10GE1/0/3
10G
E
1/0/2
V
LA
N
IF300
192.168.3.1/24
V
LA
N
IF300
192.168.3.2/24
V
L
A
N
I
F
1
0
2
1
0
.
1
1
0
.
2
.
1
/
2
4
VLANIF100
192.168.1.1/24
VLANIF100
192.168.1.2/24
1.1.1.1/32
V
L
A
N
IF
2
0
0
1
9
2
.1
6
8
.2
.1
/2
4
V
L
A
N
IF
2
0
0
1
9
2
.1
6
8
.2
.2
/2
4
2.2.2.2/32
VLANIF400
192.168.4.1/24
VLANIF400
192.168.4.2/24
3.3.3.3/32
VLANIF500
192.168.5.1/24
VLANIF500
192.168.5.2/24
VLANIF103
10.110.3.1/24
V
L
A
N
I
F
1
0
1
1
0
.
1
1
0
.
1
.
1
/
2
4

Configure MSDP, and set up MSDP peer relationships between RPs in PIM-SM domains to
implement inter-domain multicast.
1. Configure IP addresses for the interfaces on each switch. Configure OSPF in the ASs to
ensure route reachability within each AS.
2. Configure EBGP peers between ASs and import BGP and OSPF routes into each other's
routing table to ensure route reachability between ASs.
3. Enable multicast routing and PIM-SM on each interface. Configure a BSR boundary to
divide the PIM-SM domain and enable IGMP on interfaces connected to network segments
of receiver hosts.
4. Configure C-BSRs and C-RPs. Configure the RPs in PIM-SM1 and PIM-SM2 on the
ASBRs.
147
5. Set up MSDP peer relationships between RPs in PIM-SM domains. According to the RPF
rule, switches receive SA messages from the next hop destined for the source RP.
Procedure
# According to Figure 4-2, configure IP addresses and masks for the interfaces on each
switch. Configure OSPF between switches. Ensure network connectivity in each AS and enable
each switch to update routes using the unicast routing protocol. The configuration details are
not mentioned here.
Step 2 Configure EBGP peers between ASs and import routes of BGP and OSPF into each other's
routing table.
# Configure EBGP on SwitchB and import OSPF routes to BGP.
[~SwitchB] bgp 100
[~SwitchB-bgp] router-id 1.1.1.1
[~SwitchB-bgp] peer 192.168.2.2 as-number 200
[~SwitchB-bgp] import-route ospf 1
[~SwitchB-bgp] commit
[~SwitchB-bgp] quit
# Configure EBGP on SwitchC and import OSPF routes to BGP.
[~SwitchC] bgp 200
[~SwitchC-bgp] router-id 2.2.2.2
[~SwitchC-bgp] peer 192.168.2.1 as-number 100
[~SwitchC-bgp] import-route ospf 1
[~SwitchC-bgp] commit
[~SwitchC-bgp] quit
# Import BGP routes to OSPF on SwitchB. The configuration on SwitchC is similar to the
configuration on SwitchB, and is not mentioned here.
[~SwitchB] ospf 1
[~SwitchB-ospf-1] import-route bgp
[~SwitchB-ospf-1] commit
[~SwitchB-ospf-1] quit
Step 3 Enable multicast routing, enable PIM-SM on all interfaces. Configure a BSR boundary to divide
the PIM-SM domain and enable IGMP on interfaces connected to network segments of receiver
hosts.
# Enable multicast routing on SwitchB and enable PIM-SM on each interface. The configurations
on other switches are similar to the configuration on SwitchB, and are not mentioned here.
[~SwitchB] multicast routing-enable
[~SwitchB] interface vlanif 100
[~SwitchB-Vlanif100] pim sm
[~SwitchB-Vlanif100] commit
[~SwitchB-Vlanif100] quit
# Configure a BSR boundary on VLANIF200 of SwitchB.
[~SwitchB-Vlanif200] pim bsr-boundary
148
# Configure BSR boundaries on VLANIF200 and VLANIF400 of SwitchC. Configure a BSR
boundary on VLANIF400 of SwitchE. The configurations on SwitchC and SwitchE are similar
to the configuration on SwitchB, and are not mentioned here.
# Enable IGMP on the interface connecting to SwitchD to the user network segment.
[~SwitchD-Vlanif102] igmp enable
Step 4 Configure C-BSRs and C-RPs.
# Create a Loopback0 interface, and then configure the C-BSR and C-RP on Loopback0 of
SwitchB. The configurations on SwitchC and SwitchE are similar to the configuration on
SwitchB, and are not mentioned here.
[~SwitchB] interface loopback 0
[~SwitchB-LoopBack0] ip address 1.1.1.1 255.255.255.255
[~SwitchB-LoopBack0] pim sm
[~SwitchB-LoopBack0] commit
[~SwitchB-LoopBack0] quit
[~SwitchB] pim
[~SwitchB-pim] c-bsr loopback 0
[~SwitchB-pim] c-rp loopback 0
[~SwitchB-pim] commit
[~SwitchB-pim] quit
Step 5 Configure MSDP peers.
# Configure an MSDP peer on SwitchB.
[~SwitchB] msdp
[~SwitchB-msdp] peer 192.168.2.2 connect-interface vlanif200
[~SwitchB-msdp] commit
[~SwitchB-msdp] quit
# Configure MSDP peers on SwitchC.
[~SwitchC] msdp
[~SwitchC-msdp] peer 192.168.2.1 connect-interface vlanif200
[~SwitchC-msdp] commit
[~SwitchC-msdp] quit
# Configure an MSDP peer on SwitchE.
[~SwitchE] msdp
[~SwitchE-msdp] peer 192.168.4.1 connect-interface vlanif400
[~SwitchE-msdp] commit
[~SwitchE-msdp] quit
# Run the display bgp peer command to view the BGP peer relationships among switches. The
following output shows the BGP peers of SwitchB and SwitchC:
<SwitchB> display bgp peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State
PrefRcv
192.168.2.2 4 200 24 21 0 00:13:09 Established 6
149
<SwitchC> display bgp peer
BGP local router ID : 2.2.2.2
Local AS number : 200
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State
PrefRcv
192.168.2.1 4 100 18 16 0 00:12:04 Established 1
# Run the display bgp routing-table command to view the BGP routing table on a switch. The
following output shows the BGP routing table on SwitchC:
<SwitchC> display bgp routing-table

BGP Local router ID is 2.2.2.2
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 5
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 1.1.1.1/32 192.168.2.1 0 0 100?
*> 2.2.2.2/32 0.0.0.0 0 0 ?
*> 192.168.2.0 0.0.0.0 0 0 ?
*> 192.168.2.1/32 0.0.0.0 0 0 ?
*> 192.168.2.2/32 0.0.0.0 0 0 ?
# Run the display msdp brief command to view the status of the MSDP peers on switches. The
following output shows summary information about MSDP peers on SwitchB, SwitchC and
SwitchE:
<SwitchB> display msdp brief
MSDP Peer Brief Information of VPN-Instance: public net
Configured Up Listen Connect Shutdown Down
1 1 0 0 0 0

Peer's Address State Up/Down time AS SA Count Reset Count
192.168.2.2 Up 00:12:27 200 13 0
<SwitchC> display msdp brief
2 2 0 0 0 0

192.168.2.1 Up 01:07:08 100 8 0
192.168.4.2 Up 00:06:39 ? 13 0
<SwitchE> display msdp brief
1 1 0 0 0 0
192.168.4.1 Up 00:15:32 ? 8 0
# Run the display msdp peer-status command to view the details about MSDP peers on
switches. The following output shows the details about the MSDP peer of SwitchB:
<SwitchB> display msdp peer-status
MSDP Peer Information of VPN-Instance: public net
MSDP Peer 192.168.2.2, AS 200
Description:
Information about connection status:
State: Up
150
Up/down time: 00:15:47
Resets: 0
Connection interface: vlanif200 (192.168.2.1)
Number of sent/received messages: 16/16
Number of discarded output messages: 0
Elapsed time since last connection or counters clear: 00:17:51
Information about (Source, Group)-based SA filtering policy:
Import policy: none
Export policy: none
Information about SA-Requests:
Policy to accept SA-Request messages: none
Sending SA-Requests status: disable
Minimum TTL to forward SA with encapsulated data: 0
SAs learned from this peer: 0, SA-cache maximum for the peer: none
Input queue size: 0, Output queue size: 0
Counters for MSDP message:
Count of RPF check failure: 0
Incoming/outgoing SA messages: 0/0
Incoming/outgoing SA requests: 0/0
Incoming/outgoing SA responses: 0/0
Incoming/outgoing data packets: 0/0
Peer authentication: unconfigured
Peer authentication type: none
# Run the display pim routing-table command to view the PIM routing table on a switch. When
S1 (10.110.1.2/24) in PIM-SM1 and S3 (10.110.3.2/24) in PIM-SM3 send multicast data to
multicast group G (225.1.1.1), Receiver (10.110.2.2/24) in PIM-SM2 receives the multicast data
sent to G. The following output shows the PIM routing tables on SwitchB and SwitchC:

(10.110.1.2, 225.1.1.1)
RP: 1.1.1.1 (local)
Protocol: pim-sm, Flag: SPT EXT ACT
UpTime: 00:00:42
Upstream interface: vlanif100
1: vlanif200
Total 1 (*, G) entry; 2 (S, G) entries

(*, 225.1.1.1)
RP: 2.2.2.2 (local)
Protocol: pim-sm, Flag: WC RPT
UpTime: 00:13:46
Upstream interface: NULL,
1: vlanif300,
(10.110.1.2, 225.1.1.1)
RP: 2.2.2.2
Protocol: pim-sm, Flag: SPT MSDP ACT
UpTime: 00:00:42
151
1: vlanif300
(10.110.3.2, 225.1.1.1)
RP: 2.2.2.2
Protocol: pim-sm, Flag: SPT MSDP ACT
UpTime: 00:00:42
1: vlanif300
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 101
#
#
interface Vlanif100
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Vlanif101
ip address 10.110.1.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 100 200
#
#
interface Vlanif100
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif200
ip address 192.168.2.1 255.255.255.0
pim bsr-boundary
pim sm
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
152
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
bgp 100
router-id 1.1.1.1
peer 192.168.2.2 as-number 200
#
ipv4-family unicast
undo synchronization
import-route ospf 1
peer 192.168.2.2 enable
#
ospf 1
import-route bgp
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 192.168.1.0 0.0.0.255
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
msdp
peer 192.168.2.2 connect-interface vlanif200
#
return
#
sysname SwitchC
#
vlan batch 200 300 400
#
#
interface Vlanif200
ip address 192.168.2.2 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif300
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface Vlanif400
ip address 192.168.4.1 255.255.255.0
pim bsr-boundary
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
153
#
bgp 200
router-id 2.2.2.2
#
ipv4-family unicast
import-route ospf 1
#
ospf 1
import-route bgp
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
msdp
#
return
#
sysname SwitchD
#
vlan batch 102 300
#
#
interface Vlanif102
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif300
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
#
sysname SwitchE
#
vlan batch 400 500
#
#
interface Vlanif400
ip address 192.168.4.2 255.255.255.0
pim bsr-boundary
pim sm
154
#
interface Vlanif500
ip address 192.168.5.1 255.255.255.0
pim sm
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 192.168.4.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
msdp
#
return
#
sysname SwitchF
#
vlan batch 103 500
#
#
interface Vlanif103
ip address 10.110.3.1 255.255.255.0
pim sm
#
interface Vlanif500
ip address 192.168.5.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.3.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
return
4.8.2 Example for Configuring Inter-AS Multicast Using Static RPF
Peers
155
As shown in Figure 4-3, two ASs exist on the network. Each AS contains at least one PIM-SM
domain and each PIM-SM domain may contain no or one multicast source and receiver. Source
information needs to be transmitted across PIM-SM domains without changing unicast topology.
Figure 4-3 Networking diagram of inter-AS multicast using static RPF peers
AS100
AS200
PIM-SM1
S1
Loopback0
SwitchA
SwitchC
SwitchB
SwitchD
SwitchE
Loopback0
PIM-SM2
PIM-SM3
SwitchG
S2
Loopback0
BGP peers
192.168.1.1/24
SwitchF
1
0
G
E
1
/
0
/
2
1
0
G
E
1
/
0
/
2
10G
E
1/0/1
10G
E
1/0/1
10GE1/0/1
Receiver
Receiver
10GE1/0/2
10GE1/0/3
10GE1/0/2
10GE1/0/2
10GE1/0/3
10GE1/0/1
10GE1/0/1
10GE1/0/3
10G
E
1/0/1
1
0
G
E
1
/
0
/
2
V
LA
N
IF100
10G
E
1/0/1
V
L
A
N
I
F
4
0
0
VLANIF400
192.168.4.2/24
VLANIF101
10.110.1.1/24
1.1.1.1/32
V
LA
N
IF500
192.168.5.2/24
1
9
2
.
1
6
8
.
4
.
1
/
2
4
V
LA
N
IF100 192.168.1.2/24
V
L
A
N
I
F
2
0
0
1
9
2
.
1
6
8
.
2
.
2
/
2
4
V
L
A
N
I
F
2
0
0
1
9
2
.
1
6
8
.
2
.
1
/
2
4
VLANIF300
VLANIF300
192.168.3.1/24
192.168.3.2/24
2.2.2.2/32
VLANIF102
10.110.2.1/24
3.3.3.3/32
V
LA
N
IF500 192.168.5.1/24
VLANIF600
192.168.6.1/24
VLANIF600
192.168.6.2/24
VLANIF103
VLANIF104
10.110.3.1/24
10.110.4.1/24

Configure an MSDP peer on the RP in each PIM-SM domain and specify static RPF peers for
the MSDP peers to transmit source information across PIM-SM domains without changing
unicast topology.
1. Configure IP addresses for the interfaces on each switch, configure OSPF in the ASs,
configure EBGP between ASs, and import BGP and OSPF routes into each other's routing
table.
2. Enable multicast on all switches and PIM-SM on all interfaces, and enable IGMP on
interfaces connected to network segments of receiver hosts. Configure Loopback0
interfaces, C-BSRs, and C-RPs on switches. Configure Loopback0 interfaces on SwitchC,
SwitchD, and SwitchF as the C-BSR and the C-RP of each PIM-SM domain.
156
3. Set up MSDP peer relationships between RPs in PIM-SIM domains. Set up the MSDP peer
relationship between SwitchC and SwitchD, and between SwitchC and SwitchF.
4. Specify static RPF peers for the MSDP peers. Specify SwitchD and SwitchF as the static
RPF peers of SwitchC. Specify SwitchC as the only static RPF peer of SwitchD and
SwitchF. According to RPF rules, switches accept SA messages from static RPF peers.
Procedure
# According to Figure 4-3, configure IP addresses and masks for the interfaces on each
switch. Configure OSPF in the ASs. Configure EBGP between SwitchA and SwitchF, and
between SwitchB and SwitchE. Import BGP and OSPF routes into each other's routing table.
Ensure network connectivity between switches and enable switches to update routes using the
unicast routing protocol. The configuration details are not mentioned here.
Step 2 Enable multicast routing on all switches and PIM-SM on all interfaces, and enable IGMP on
interfaces connected to network segments of receiver hosts. In addition, configure the BSR
boundary on the interfaces of switches on the AS boundary.
# Enable multicast routing on switches and enable PIM-SM on each interface. The configurations
on other switches are similar to the configuration on SwitchC, and are not mentioned here.
[~SwitchC] multicast routing-enable
[~SwitchC] interface vlanif 100
[~SwitchC-Vlanif100] pim sm
# Enable IGMP on VLANIF102 of SwitchE. The configuration on SwitchG is similar to the
configuration on SwitchE, and is not mentioned here.
[SwitchE] interface vlanif 102
[SwitchE-Vlanif102] igmp enable
[SwitchE-Vlanif102] commit
[SwitchE-Vlanif102] quit
# Configure a BSR boundary on VLANIF500 of SwitchA, VLANIF200 of SwitchB,
VLANIF200 of SwitchE, and VLANIF500 of SwitchF. The configurations on SwitchB,
SwitchE, and SwitchF are similar to the configuration on SwitchA, and are not mentioned here.
[~SwitchA-Vlanif500] pim bsr-boundary
Step 3 Configure Loopback0 interfaces, C-BSRs, and C-RPs on switches.
# Configure Loopback0 interfaces on SwitchC, SwitchD, and SwitchF. Configure Loopback0
interfaces as C-BSRs and C-RPs. The configurations on SwitchD and SwitchF are similar to the
configuration on SwitchC, and are not mentioned here.
[~SwitchC] interface loopback 0
[~SwitchC-LoopBack0] ip address 1.1.1.1 255.255.255.255
[~SwitchC-LoopBack0] pim sm
[~SwitchC-LoopBack0] commit
[~SwitchC-LoopBack0] quit
[~SwitchC] pim
157
[~SwitchC-pim] quit
Step 4 Configure static RPF peers.
# Configure SwitchD and SwitchF as the static RPF peers of SwitchC.
[~SwitchC] ip ip-prefix list-df permit 192.168.0.0 16 greater-equal 16 less-equal
32
[~SwitchC] msdp
[~SwitchC-msdp] static-rpf-peer 192.168.3.2 rp-policy list-df
[~SwitchC-msdp] static-rpf-peer 192.168.5.1 rp-policy list-df
# Configure SwitchC as the only static RPF peer of SwitchD and SwitchF. The configuration
on SwitchF is similar to the configuration on SwitchD, and is not mentioned here.
[~SwitchD] ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16 less-equal
32
[~SwitchD] msdp
[~SwitchD-msdp] peer 192.168.1.1 connect-interface vlanif300
[~SwitchD-msdp] static-rpf-peer 192.168.1.1 rp-policy list-c
[~SwitchD-msdp] commit
[~SwitchD-msdp] quit
# Run the display bgp peer command to view the BGP peer relationships among switches. No
command output is displayed on SwitchC, which indicates that no BGP peer relationship is set
up between SwitchC and SwitchD, or between SwitchC and SwitchF.
# Run the display msdp brief command to view the status of the MSDP peers on switches.
When S1 in the PIM-SM1 domain sends multicast data, the receivers in PIM-SM2 and PIM-
SM3 domains can receive the data. The following output shows summary information about
MSDP peers on SwitchC, SwitchD and SwitchF:
2 2 0 0 0 0

192.168.3.2 Up 01:07:08 ? 8 0
192.168.5.1 Up 00:16:39 ? 13 0
<SwitchD> display msdp brief
1 1 0 0 0 0

192.168.1.1 Up 01:07:09 ? 8 0
<SwitchF> display msdp brief
1 1 0 0 0 0

192.168.4.1 Up 00:16:40 ? 13 0
----End
158
Configuration Files
#
sysname SwitchA
#
#
#
interface Vlanif101
ip address 10.110.1.1 255.255.255.0
pim sm
#
interface Vlanif400
ip address 192.168.4.2 255.255.255.0
pim sm
#
interface Vlanif500
ip address 192.168.5.2 255.255.255.0
pim bsr-boundary
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
bgp 100
router-id 1.1.1.3
#
ipv4-family unicast
import-route ospf 1
#
ospf 1
import-route bgp
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 100 200
#
#
interface Vlanif100
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif200
ip address 192.168.2.2 255.255.255.0
pim bsr-boundary
pim sm
#
159
interface 10GE1/0/1
#
interface 10GE1/0/2
#
bgp 100
router-id 1.1.1.2
#
ipv4-family unicast
import-route ospf 1
#
ospf 1
import-route bgp
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
#
sysname SwitchC
#
vlan batch 100 400
#
#
interface Vlanif100
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Vlanif400
ip address 192.168.4.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
ip ip-prefix list-df index 10 permit 192.168.0.0 16 greater-equal 16 less-equal
32
#
msdp
static-rpf-peer 192.168.3.2 rp-policy list-df
160
static-rpf-peer 192.168.5.1 rp-policy list-df
#
return
#
sysname SwitchD
#
vlan batch 300
#
#
interface Vlanif300
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 192.168.3.0 0.0.0.255
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
ip ip-prefix list-c index 10 permit 192.168.0.0 16 greater-equal 16 less-equal
32
#
msdp
static-rpf-peer 192.168.1.1 rp-policy list-c
#
return
#
sysname SwitchE
#
#
#
interface Vlanif102
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif200
ip address 192.168.2.1 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif300
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
161
#
interface 10GE1/0/3
#
bgp 200
router-id 2.2.2.1
#
ipv4-family unicast
import-route ospf 1
#
ospf 1
import-route bgp
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
#
sysname SwitchF
#
vlan batch 500 600
#
#
interface Vlanif500
ip address 192.168.5.1 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif600
ip address 192.168.6.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
pim sm
#
bgp 200
router-id 3.3.3.3
#
ipv4-family unicast
import-route ospf 1
#
ospf 1
import-route bgp
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 192.168.5.0 0.0.0.255
network 192.168.6.0 0.0.0.255
#
pim
c-bsr LoopBack0
162
c-rp LoopBack0
#
ip ip-prefix list-c index 10 permit 192.168.0.0 16 greater-equal 16 less-equal
32
#
msdp
static-rpf-peer 192.168.4.1 rp-policy list-c
#
return
l Configuration file of SwitchG
#
sysname SwitchG
#
#
#
interface Vlanif103
ip address 10.110.3.1 255.255.255.0
pim sm
#
interface Vlanif104
ip address 10.110.4.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif600
ip address 192.168.6.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 10.110.3.0 0.0.0.255
network 10.110.4.0 0.0.0.255
network 192.168.6.0 0.0.0.255
#
return
4.8.3 Example for Configuring Anycast RP in a PIM-SM Domain
As shown in Figure 4-4, a PIM-SM domain contains multiple multicast sources and receivers.
RPs in a PIM-SM domain need to be configured as MSDP peers to perform load balancing.
163
Figure 4-4 Networking diagram of anycast RP
User2
Loopback10
Loopback0
Loopback0
Loopback10
10GE1/0/2
10GE1/0/3
SwitchC
SwitchD
SwitchE
PIM-SM
MSDP peers
Loopback1
Loopback1
10GE1/0/2
10GE1/0/3
10GE1/0/2
10GE1/0/1
SwitchA
SwitchB
1
0
G
E
1
/
0
/
1
10GE1/0/2
User1
S2
10GE1/0/1 10GE1/0/2
10GE1/0/1
10GE1/0/1
S1
VLANIF105
VLANIF101
10.110.5.1/24
10.110.1.2/24
VLANIF102
V
L
A
N
I
F
1
0
6
1
0
.
1
1
0
.
6
.
1
/
2
4
10.110.2.2/24
10.1.1.1/32
4.4.4.4/32
2.2.2.2/32
VLANIF103
10.110.3.1/24
1.1.1.1/32
3.3.3.3/32
10.1.1.1/32
VLANIF102
10.110.2.1/24
VLANIF101
10.110.1.1/24
VLANIF100
VLANIF104
192.168.1.1/24
10.110.4.1/24
VLANIF100
192.168.1.2/24
VLANIF300
192.168.3.2/24
VLANIF300
192.168.3.1/24

Configure anycast RPs using MSDP so that the receiver sends a Join message to the closest RP
and the multicast source sends a Register message to the nearest RP. RPs implement load
balancing.
1. Configure IP addresses for the interfaces on each switch and configure OSPF in the PIM-
SM domain.
2. Enable multicast on all switches and PIM-SM on all interfaces, and enable IGMP on
interfaces connected to network segments of receiver hosts.
3. Configure the same Loopback10 address on SwitchC and SwitchD. Configure C-RPs on
Loopback10 interfaces, and configure C-BSRs on Loopback1 interfaces.
4. Configure MSDP peers on Loopback0 interfaces of SwitchC and SwitchD. According to
RPF rules, the switches receive SA messages from the source RP.
Procedure
164
# According to Figure 4-4, configure IP addresses and masks for the interfaces in the PIM-SM
domain. Configure OSPF between switches. The configuration details are not mentioned here.
Step 2 Enable multicast routing and configure PIM-SM.
# Enable multicast routing on all switches and PIM-SM on all interfaces. Enable IGMP on
interfaces connected to network segments of receiver hosts. The configurations on other
switches are similar to the configuration on SwitchC, and are not mentioned here.
Step 3 Configure Loopback1 interfaces, Loopback10 interfaces, C-BSRs, and C-RPs.
# Configure Loopback1 addresses and the same Loopback10 address for SwitchC and
SwitchD. Configure C-BSRs on Loopback1 interfaces and C-RPs on Loopback10 interfaces.
The configuration on SwitchD is similar to the configuration on SwitchC, and is not mentioned
here.
[~SwitchC] pim
[~SwitchC-pim] quit
Step 4 Configure MSDP peers on Loopback0 interfaces.
# Configure an MSDP peer on Loopback0 of SwitchC.
[~SwitchC] msdp
[~SwitchC-msdp] originating-rp loopback0
[~SwitchC-msdp] peer 2.2.2.2 connect-interface loopback0
# Configure an MSDP peer on Loopback0 of SwitchD.
[~SwitchD] interface loopback 0
[~SwitchD-LoopBack0] ip address 2.2.2.2 255.255.255.255
[~SwitchD-LoopBack0] pim sm
165
[~SwitchD-LoopBack0] commit
[~SwitchD-LoopBack0] quit
[~SwitchD] msdp
[~SwitchD-msdp] originating-rp loopback0
[~SwitchD-msdp] peer 1.1.1.1 connect-interface loopback0
# Run the display msdp brief command to view the status of the MSDP peers on switches. The
following output shows summary information about MSDP peers on SwitchC and SwitchD:
1 1 0 0 0 0

2.2.2.2 Up 00:10:17 ? 0 0
<SwitchD> display msdp brief
1 1 0 0 0 0
1.1.1.1 Up 00:10:18 ? 0 0
# Run the display pim routing-table command to view the PIM routing table on a switch. When
S1 (10.110.5.100/24) in the PIM-SM domain sends multicast data to G (225.1.1.1), User1
(Receiver) joins G and receives the multicast data sent to G. Comparing information about the
PIM routing tables on SwitchC and SwitchD, you can find that SwitchC is the valid RP. S1
registers to SwitchC, and User1 sends a Join message to SwitchC.

(*, 225.1.1.1)
RP: 10.1.1.1 (local)
UpTime: 00:28:49
1: vlanif104
Protocol: static, UpTime: 00:28:49, Expires: -

(10.110.5.1, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: SPT 2MSDP ACT
UpTime: 00:02:26
1: vlanif104
Not output is displayed.
166
# User1 exits from G, and S1 stops sending multicast data to G. You can run the reset pim
routing-table command to clear PIM routing entries on SwitchC.
<SwitchC> reset pim routing-table group 225.1.1.1 mask 255.255.255.255 source
10.110.5.100 interface vlanif 104
# User2 joins G, and S2 (10.110.6.100/24) sends multicast dat to G. Comparing information
about the PIM routing tables on SwitchC and SwitchD, you can find that SwitchD is the valid
RP. S2 registers to SwitchD, and User2 sends a Join message to SwitchD.
Not output is displayed.
VPNInstance: public net

(*, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: WC RPT
UpTime: 00:07:23
Upstream interface: NULL,
1: vlanif103,
(10.110.6.100, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: SPT 2MSDP ACT
UpTime: 00:10:20
1: vlanif103
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 101 105
#
#
interface Vlanif101
ip address 10.110.1.2 255.255.255.0
pim sm
#
interface Vlanif105
ip address 10.110.5.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
167
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 10.110.5.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 102 106
#
#
interface Vlanif102
ip address 10.110.2.2 255.255.255.0
pim sm
#
interface Vlanif106
ip address 10.110.6.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 10.110.6.0 0.0.0.255
#
return
#
sysname SwitchC
#
#
#
interface Vlanif100
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Vlanif101
ip address 10.110.1.1 255.255.255.0
pim sm
#
interface Vlanif104
ip address 10.110.4.1 255.255.255.0
pim sm
igmp enable
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
168
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
pim sm
#
interface LoopBack10
ip address 10.1.1.1 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.1.1.1 0.0.0.0
network 10.110.1.0 0.0.0.255
network 10.110.4.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
pim
c-bsr LoopBack1
c-rp LoopBack10
#
msdp
originating-rp LoopBack0
peer 2.2.2.2 connect-interface LoopBack0
#
return
#
sysname SwitchD
#
#
#
interface Vlanif102
ip address 10.110.2.1 255.255.255.0
pim sm
#
interface Vlanif103
ip address 10.110.3.1 255.255.255.0
pim sm
#
interface Vlanif300
ip address 192.168.3.1 255.255.255.0
pim sm
igmp enable
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
pim sm
169
#
interface LoopBack10
ip address 10.1.1.1 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.1.1.1 0.0.0.0
network 10.110.2.0 0.0.0.255
network 10.110.3.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
c-bsr LoopBack1
c-rp LoopBack10
#
msdp
originating-rp LoopBack0
peer 1.1.1.1 connect-interface LoopBack0
#
return
#
sysname SwitchE
#
vlan batch 100 300
#
#
interface Vlanif100
ip address 192.168.1.2 255.255.255.0
pim sm
#
interface Vlanif300
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
4.8.4 Example for Configuring SA Message Filtering
As shown in Figure 4-5, service data is transmitted in multicast mode on the network that is
divided into three PIM-SM domains. The multicast source Source1 sends multicast data to
multicast groups 225.1.1.0/30 and 226.1.1.0/30, and Source2 sends multicast data to the
multicast group 227.1.1.0/30. According to service requirements, HostA and HostB need to
receive only multicast data that is sent to multicast groups 225.1.1.0/30 and 226.1.1.0/30, and
170
HostC needs to receive only multicast data that is sent to multicast groups 226.1.1.0/30 and
227.1.1.0/30.
Figure 4-5 Networking diagram for configuring SA message filtering
PIM-SM1 PIM-SM2
Source1
SwitchA
SwitchC
MSDP peers
HostA
SwitchB
PIM-SM3
Source2
HostC
HostB
SwitchD
Loopback0
Loopback0
Loopback0
10GE1/0/1
10GE1/0/2
10GE1/0/2
10GE1/0/1
10GE1/0/1
10GE1/0/2
10GE1/0/3
10GE1/0/1
10GE1/0/2
10G
E
1/0/3
1
0
G
E
1
/
0
/
3
Receiver
Receiver
Receiver
1
0
G
E
1
/
0
/
4
10G
E
1/0/3
1.1.1.1/32
VLANIF100
10.110.1.1/24
V
LA
N
IF101
192.168.1.1/24
VLANIF102
10.110.2.1/24
VLANIF102
10.110.2.2/24
VLANIF200
10.110.3.1/24
VLANIF300
10.110.4.1/24
2.2.2.2/32
VLANIF104
10.110.5.1/24
VLANIF104
10.110.5.2/24
3.3.3.3/32
V
LA
N
IF101
192.168.1.1/24
V
L
A
N
I
F
1
0
3
1
9
2
.
1
6
8
.
2
.
2
/
2
4
V
L
A
N
I
F
1
0
3
1
9
2
.
1
6
8
.
2
.
1
/
2
4
VLANIF500
VLANIF400
10.110.6.1/24
10.110.7.1/24

Configure MSDP to implement multicast source information sharing among domains. Configure
SA message filtering so that the receivers receive only required multicast data.
1. Configure IP addresses for the interfaces on each switch and configure OSPF in the PIM-
SM domain.
2. Enable multicast and PIM-SM on each interface. Configure a BSR boundary to divide the
PIM-SM domain and enable IGMP on interfaces connected to network segments of receiver
hosts.
3. Configure Loopback0 interfaces on SwitchA, SwitchC, and SwitchD as the C-BSR and the
C-RP of each PIM-SM domain.
4. Set up MSDP peer relationships between RPs in PIM-SIM domains. Set up the MSDP peer
relationship between SwitchA and SwitchC, and between SwitchC and SwitchD.
5. Configure rules for filtering SA messages. Prohibit SwitchC from forwarding SA messages
carrying (Source1, 225.1.1.0/30) entries to SwitchD. Prohibit SwitchD from creating SA
messages carrying Source2 information.
171
Procedure
# According to Figure 4-5, configure IP addresses and masks for the interfaces in the PIM-SM
domain. Configure OSPF between switches. The configuration details are not mentioned here.
Step 2 Enable multicast routing and configure PIM-SM.
# Enable multicast routing on all switches and PIM-SM on all interfaces. Enable IGMP on
interfaces connected to network segments of receiver hosts. The following information shows
the configuration on SwitchA. The configurations on other switches are similar to the
configuration on SwitchA, and are not mentioned here.
[~SwitchA] interface loopback 0
[~SwitchA-LoopBack0] pim sm
[~SwitchA-LoopBack0] commit
[~SwitchA-LoopBack0] quit
Step 3 Configure a BSR boundary to divide the PIM-SM domain.
# Configure a BSR boundary on SwitchC. The configurations on SwitchA, SwitchB, and
SwitchD are similar to the configuration on SwitchC, and are not mentioned here.
[~SwitchC-Vlanif101] pim bsr-boundary
[~SwitchC] commit
Step 4 Configure C-BSRs and C-RPs.
# Configure the C-BSR and C-RP on the Loopback0 interface of SwitchA. The configurations
on SwitchC and SwitchD are similar to the configuration on SwitchA, and are not mentioned
here.
[~SwitchA] pim
[~SwitchA-pim] c-bsr loopback0
[~SwitchA-pim] c-rp loopback0
[~SwitchC-pim] quit
Step 5 Configure MSDP peers.
# Configure an MSDP peer on SwitchA.
[~SwitchA] msdp
[~SwitchA-msdp] peer 192.168.1.2 connect-interface vlanif 101
172
[~SwitchA-msdp] commit
[~SwitchA-msdp] quit
# Configure MSDP peers on SwitchC.
[~SwitchC] msdp
[~SwitchC-msdp] peer 192.168.1.1 connect-interface vlanif 101
[~SwitchC-msdp] peer 10.110.5.2 connect-interface vlanif 104
# Configure an MSDP peer on SwitchD.
[~SwitchD] msdp
[~SwitchD-msdp] peer 10.110.5.1 connect-interface vlanif 104
Step 6 Configure rules for filtering SA messages.
# Prohibit SwitchC from forwarding SA messages carrying (Source1, 225.1.1.0/30) entries to
SwitchD.
[~SwitchC] acl number 3001
[~SwitchC-acl4-advance-3001] rule deny ip source 10.110.3.100 0 destination
225.1.1.0 0.0.0.3
[~SwitchC-acl4-advance-3001] rule permit ip source any destination any
[~SwitchC-acl4-advance-3001] commit
[~SwitchC-acl4-advance-3001] quit
[~SwitchC] msdp
[~SwitchC-msdp] peer 10.110.5.2 sa-policy export acl 3001
# Prohibit SwitchD from creating SA messages carrying Source2 information.
[~SwitchD] acl number 2001
[~SwitchD-acl4-basic-2001] rule deny source 10.110.6.100 0
[~SwitchD-acl4-basic-2001] quit
[~SwitchD] msdp
[~SwitchD-msdp] import-source acl 2001
[~SwitchD] commit
# Run the display msdp sa-cache command to view information about the (S, G) entries in the
SA cache on switches. The following output shows information about the (S, G) entries in the
SA cache on SwitchC and SwitchD.
<SwitchC> display msdp sa-cache
MSDP Source-Active Cache Information of VPN-Instance: public net
MSDP Total Source-Active Cache - 8 entries
MSDP matched 8 entries

(Source, Group) Origin RP Pro AS Uptime Expires
(10.110.3.100, 225.1.1.0) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 225.1.1.1) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 225.1.1.2) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 225.1.1.3) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.0) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.1) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.2) 1.1.1.1 ? ? 02:03:30 00:05:31
(10.110.3.100, 226.1.1.3) 1.1.1.1 ? ? 02:03:30 00:05:31
<SwitchD> display msdp sa-cache
MSDP Source-Active Cache Information of VPN-Instance: public net
MSDP Total Source-Active Cache - 4 entries
MSDP matched 4 entries
173

(Source, Group) Origin RP Pro AS Uptime Expires
(10.110.3.100, 226.1.1.0) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 226.1.1.1) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 226.1.1.2) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 226.1.1.3) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 227.1.1.0) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 227.1.1.1) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 227.1.1.2) 1.1.1.1 ? ? 00:32:53 00:05:07
(10.110.3.100, 227.1.1.3) 1.1.1.1 ? ? 00:32:53 00:05:07
The preceding output shows that only multicast data to multicast groups 225.1.1.0/30 and
226.1.1.0/30 exists in the SA cache on SwitchC, and only multicast data to the multicast groups
226.1.1.0/30 and 227.1.1.0/30 exists in the SA cache on SwitchD.
----End
Configuration Files
#
sysname SwitchA
#
#
#
interface Vlanif100
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif101
ip address 192.168.1.1 255.255.255.0
pim sm
#
interface Vlanif102
ip address 10.110.2.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.110.1.0 0.0.0.255
network 10.110.2.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
msdp
peer 192.168.1.2 connect-interface Vlanif101
174
#
return
#
sysname SwitchB
#
#
#
interface Vlanif102
ip address 10.110.2.2 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif103
ip address 192.168.2.1 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif200
ip address 10.110.3.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 10.110.3.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
#
sysname SwitchC
#
vlan batch 101 103 104 300
#
#
acl number 3001
rule 5 deny ip source 10.110.3.100 0 destination 225.1.1.0 0.0.0.3
rule 10 permit ip
#
interface Vlanif101
ip address 192.168.1.2 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif103
ip address 192.168.2.2 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif104
ip address 10.110.5.1 255.255.255.0
pim bsr-boundary
pim sm
175
#
interface Vlanif300
ip address 10.110.4.1 255.255.255.0
pim sm
igmp enable
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.110.4.0 0.0.0.255
network 10.110.5.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
msdp
peer 10.110.5.2 sa-policy export acl 3001
#
return
#
sysname SwitchD
#
#
#
acl number 2001
rule 5 deny source 10.110.6.100 0
#
interface Vlanif104
ip address 10.110.5.2 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif400
ip address 10.110.6.1 255.255.255.0
pim sm
#
interface Vlanif500
ip address 10.110.7.1 255.255.255.0
pim sm
igmp enable
#
interface 10GE1/0/1
176
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.110.5.0 0.0.0.255
network 10.110.6.0 0.0.0.255
network 10.110.7.0 0.0.0.255
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
msdp
import-source acl 2001
#
return
This section describes common faults caused by incorrect MSDP configurations and provides
4.9.1 An MSDP Peer Is Always in Down State
Fault Description
An MSDP peer is configured, but is always in Down state.
Fault Analysis
MSDP sets up a TCP connection between a local interface address and a remote MSDP peer.
l If the local interface address is different from the MSDP peer address configured on a
remote device, the TCP connection cannot be set up.
l If two MSDP peers have no route to each other, the TCP connection cannot be set up.
Procedure
Step 1 Check whether the two devices that will be configured as MSDP peers learn ARP entries from
each other.
Run the display arp command to check whether two devices learn ARP entries from each other.
Step 2 Check whether there is a reachable unicast route between two devices that will be configured
as MSDP peers.
177
Run the display ip routing-table command to check whether there is a unicast route between
the local MSDP peer and the remote MSDP peer.
Step 3 Check that the interface address of the MSDP peers is correct.
Run the display current-configuration command to check whether the local interface address
is the same as the address of the MSDP peer.
----End
4.9.2 There Is No (S, G) Entry in the SA Cache
Fault Description
MSDP fails to send (S, G) entries through SA messages.
Fault Analysis
l The import-source command forwards (S, G) entries in a local domain to the remote MSDP
peer through SA messages. If acl is not specified, the device filters all the (S, G) entries.
l If the import-source command is not configured, the device sends all the (S, G) entries in
the local domain. When MSDP fails to send (S, G) entries in the local domain through SA
messages, check whether the import-source command is configured and correct.
Procedure
each other.
as MSDP peers.
Step 4 Check whether the rule for filtering SA messages is configured.
Run the display this command in the MSDP view to check whether import-source is configured
with a specified acl, and the ACL rule is set to filter (S, G) information.
----End
4.9.3 RPs Fail to Exchange Registration Information with Each
Other
Fault Description
RPs in the anycast RP application fail to exchange (S, G) information registered to a local device
with each other.
178
Fault Analysis
Pay attention to the following configuration notes. If the requirements are not met, the anycast
RP works abnormally.
l The address of an MSDP peer must be different from the address of the anycast RP. The
C-BSR and C-RP must be configured on two devices or interfaces.
l An MSDP peer performs the RPF check on a received SA message and then discards the
message if the addresses of the local RP and the remote RP are the same. Run the
originating-rp command on the anycast RP to replace the RP address contained in the SA
message with the address of a specified interface.
Procedure
each other.
as MSDP peers.
Step 4 Check whether the RP configuration is correct.
In the anycast RP application, configure RPs with the same address on multiple switches in a
PIM-SM domain. Generally, configure a loopback interface on each device and assign the same
IP address to the loopback interfaces.
Step 5 Check whether the originating-rp command is configured.
The originating-rp command must be configured on an anycast RP and the interface address
specified by this command must be the same as the address of the local interface connected to
the MSDP peer.
Step 6 Check the C-BSR address and the anycast RP address, and ensure that the two addresses are
different.
----End
179
5 MBGP Configuration
About This Chapter
Multicast BGP (MBGP) is used to transmit routing information between Autonomous Systems
(ASs) for multicast network.
5.1 MBGP Overview
MBGP is a multiprotocol extension to the Border Gateway Protocol (BGP).
5.2 MBGP Features Supported by the Switch
The Switch supports the following MBGP features: basic BGP functions, BGP security,
simplifying IBGP network connections (route reflector and confederation), BGP route selection
and load balancing, controlling the receiving and advertisement of BGP routes, adjusting the
BGP network convergence speed, BGP reliability, BGP route summarization, and advertising
default routes to peers.
5.3 MBGP Default Configuration
This section describes default configurations.
Configuration Guide - IP Multicast 5 MBGP Configuration
180
5.1 MBGP Overview
MBGP is a multiprotocol extension to the Border Gateway Protocol (BGP).
If a multicast source and its receivers are located in different ASs, a multicast forwarding tree
must be built across the ASs. The Multiprotocol Border Gateway Protocol (MP-BGP) can be
used to transmit routing information between ASs for multicast services.
MP-BGP is an enhanced BGP. At present, BGP4 only applies to unicast routing. Adding
capabilities to BGP4, MP-BGP allows BGP to provide routing information for multiple routing
protocols, including multicast.
l MP-BGP maintains both unicast routes and multicast routes, stores them in different routing
tables, and keeps unicast routing information and multicast routing information separate
from each other.
l MP-BGP builds a unicast routing topology different from a multicast routing topology.
l Most of unicast routing policies and configuration methods supported by BGP4 can be
applied to multicast, and MP-BGP maintains unicast routes different from multicast routes
based on the routing policies.
5.2 MBGP Features Supported by the Switch
The Switch supports the following MBGP features: basic BGP functions, BGP security,
simplifying IBGP network connections (route reflector and confederation), BGP route selection
and load balancing, controlling the receiving and advertisement of BGP routes, adjusting the
BGP network convergence speed, BGP reliability, BGP route summarization, and advertising
default routes to peers.
Some MBGP functions can be configured in the BGP view, and some MBGP functions need to
be configured in the IPv4 multicast address family view. The following functions need to be
configured in the IPv4 multicast address family view: load balancing, route summarization, route
dampening, community, and route reflector.
For details, see "BGP Configuration" in the CloudEngine 6800&5800 Series Switches
Configuration Guide-IP Routing.
5.3 MBGP Default Configuration
This section describes default configurations.
MBGP Disabled
Keepalive message interval 60s
Hold time 180s
Configuration Guide - IP Multicast 5 MBGP Configuration
181
6 Multicast Route Management (IPv4)
Configuration
About This Chapter
The switch can run multiple multicast routing protocols to control multicast routing and
forwarding through message exchange between the control plane and forwarding plane.
6.1 Overview of Multicast Route Management (IPv4)
The multicast route management function helps control multicast packet forwarding by creating
or changing multicast routes, and to check and maintain multicast forwarding paths.
This section provides the default configuration of multicast route management.
6.3 Configuring RPF Check Policies
When the default RPF check policy cannot meet requirements in some multicast service
scenarios, change the RPF check policy.
6.4 Configuring the Multicast Boundary
The multicast boundary restricts the scope of multicast forwarding.
6.5 Disabling Soft Forwarding for Multicast Packets
Disabling soft forwarding for multicast packets on a multicast switch prevents packet loss and
disorder.
6.6 Maintaining Multicast Routes
You can reset multicast forwarding entries, and monitor multicast routing and forwarding.
This section provides examples to illustrate how to configure multicast static routes and multicast
load splitting on a multicast network.
This section describes the common configuration errors and troubleshooting methods.
Configuration Guide - IP Multicast 6 Multicast Route Management (IPv4) Configuration
182
6.1 Overview of Multicast Route Management (IPv4)
The multicast route management function helps control multicast packet forwarding by creating
or changing multicast routes, and to check and maintain multicast forwarding paths.
NOTE
On the CE series switches, multicast route management (IPv4) can be configured only on VLANIF and loopback
interfaces. In this document, multicast route management (IPv4) is configured on VLANIF interfaces unless
otherwise specified. Before configuring multicast route management (IPv4) on a VLANIF interface, add
physical interfaces to the corresponding VLAN.
Three types of tables are used for multicast routing and forwarding: multicast protocol routing
table, multicast routing table, and multicast forwarding table.
Multicast routing and forwarding is similar to unicast routing and forwarding. Each multicast
routing protocol creates and maintains a routing table. For example, Protocol Independent
Multicast (PIM) maintains a PIM routing table. Routing information of various multicast routing
protocols builds a multicast routing table. The switch selects optimal multicast routes from the
multicast routing table according to the multicast routing and forwarding policies, and then
delivers the optimal routes to the multicast forwarding table to control multicast data forwarding.
Multicast forwarding tables of network devices maintain a point-to-multipoint forwarding tree
on the entire network, with a multicast source as the root and group members as leaves. The
switch provides various multicast route management functions to create and maintain multicast
forwarding paths, as listed in Table 6-1.
Table 6-1 Multicast route management functions
Function Description
RPF check Ensures that multicast data is forwarded
through correct paths. The switch performs
RPF check automatically if received multicast
packets meet specified conditions. You do not
need to manually trigger RPF check.
RPF check policy configuration Applies different route selection policies to
adapt to different multicast service scenarios.
Multicast boundary Restricts the scope of multicast forwarding.
Multicast NSR Applies to a system with double main control
units. The multicast protocol control planes on
the main control units work in active/standby
mode to ensure highly reliable multicast data
forwarding. This function takes effect as soon
as the standby main control unit of the system
starts and does not need to be configured
manually.
Multicast traceroute Tracks the path to a multicast receiver along
a multicast forwarding tree.

183
This section provides the default configuration of multicast route management.
Table 6-2 lists the default configuration of multicast route management.
Table 6-2 Default configuration of multicast route management (IPv4)
Longest match rule for
multicast route selection
Not configured. The RPF route is selected based on router
preference during an RPF check.
Multicast load splitting Not configured. Only one route is selected according to a certain
rule in an RPF check to forward multicast packets.
Multicast boundary Not configured.

6.3 Configuring RPF Check Policies
When the default RPF check policy cannot meet requirements in some multicast service
scenarios, change the RPF check policy.
Before configuring an RPF check policy, complete the following tasks:
l Globally enabling Layer 3 multicast routing (using the multicast routing-enable command
in the system view)
The following configuration tasks can be performed at any sequence as required.
6.3.1 Configuring a Multicast Static Route
Context
A multicast static route specifies an RPF interface or RPF neighbor for multicast packets from
a specified multicast source. You can configure a multicast static route to:
l Change an RPF route.
If you want an interface to receive multicast data packets from a specified multicast source
but the interface is not the RPF interface for the multicast source, configure a multicast
static route to specify this interface as the RPF interface for the multicast source. When the
switch receives multicast data packets from the multicast source, it performs RPF check
using the configured RPF route. Packets sent from the source to the switch through other
interfaces fail the RPF check.
184
l Connect RPF routes.
If the unicast route on a network segment is incomplete, multicast packets cannot be
forwarded due to lack of an RPF route. For example, when two adjacent devices run
different routing protocols but the routing protocols do not import routes from each other,
packets cannot be forwarded between the two devices. In this case, you can configure RPF
static routes on the devices. The devices can perform RPF check using the specified RPF
interfaces so that multicast packets can be forwarded successfully.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip rpf-route-static source-address { mask | mask-length } { gateway-address |
interface-type interface-number } [ preference preference ]
A multicast static route is configured.
Step 3 Run:
commit
----End
6.3.2 Configuring the Longest Match Rule for Multicast Route
Selection
Context
By default, the switch selects RPF routes based on route preference. If you change the RPF check
policy to longest match, the switch first compares mask lengths of routes to select an RPF route,
and compares route preference when multiple routes have the same mask length.
Procedure
Step 1 Run:
system-view
Step 2 Run:
multicast longest-match
The longest match rule is applied for route selection.
Step 3 Run:
commit
----End
185
6.3.3 Configuring Multicast Load Splitting
Context
By default, if there are multiple equal-cost routes to a multicast source, the switch applies the
following route selection rules during RPF check:
l If the equal-cost routes are in the same routing table, for example, unicast routing table,
multicast static routing table, or MBGP routing table, the switch selects the route with the
largest next-hop address as the RPF route.
l If the equal-cost routes are in different routing tables, the switch selects the route with the
highest preference. If the routes have the same preference, the switch selects the route with
the longest mask length. If the routes have the same preference and mask length, the
switch uses an algorithm to select a route as the RPF route.
No matter in which condition, the switch selects only one route as the RPF route. After multicast
load splitting is configured, the switch uses the specified load splitting policy to distribute
multicast data among multiple equal-cost paths. This function improves quality of multicast
forwarding.
Procedure
Step 1 Run:
system-view
Step 2 Run:
multicast load-splitting { stable-preferred | source | group | source-group }
Multicast load splitting is configured.
The keywords in the command specify different multicast load splitting policies:
l stable-preferred: load splitting that ensures stable multicast forwarding. This policy applies
to networks with stable multicast services.
If the stable-preferred load splitting policy is used, the switch automatically adjusts traffic
on equal-cost routes when equal-cost routes are added or deleted. When multicast routing
entries are deleted or load splitting weights on interfaces are changed, the switch does not
automatically adjust the traffic on the equal-cost routes.
l group: load splitting based on group addresses. This policy applies to the scenarios where
one multicast source sends data to multiple groups.
l source: load splitting based on source addresses. This policy applies to the scenarios where
one group receives data from multiple sources.
l source-group: load splitting based on source addresses and group addresses. This policy
applies to the scenarios with multiple sources and multiple groups.
Step 3 Run:
commit
----End
186
Context
After changing the RPF check policy, check the multicast static routing table, multicast routing
table, and RPF routing table to verify that the multicast network can operate normally.
Procedure
l Run the display multicast routing-table static [ config ] [ source-address { mask | mask-
length } ] command to check the multicast static routing table.
l Run the display multicast routing-table [ group-address [ mask { group-mask | group-
mask-length } ] | source-address [ mask { source-mask | source-mask-length } ] | incoming-
interface { interface-type interface-number | register } | outgoing-interface { include |
exclude | match } { interface-type interface-number | register | none } ]
*
[ outgoing-
interface-number [ number ] ] command to check the multicast routing table.
l Run the display multicast rpf-info source-address [ group-address ] [ rpt | spt ]
[ verbose ] command to check the RPF route to a specified multicast source.
----End
6.4 Configuring the Multicast Boundary
The multicast boundary restricts the scope of multicast forwarding.
Before configuring the multicast boundary, complete the following tasks:
l Globally enabling Layer 3 multicast routing (using the multicast routing-enable command
in the system view)
Context
To restrict the forwarding of multicast packets sent to a multicast group within a range, configure
the multicast boundary on interfaces. Then multicast packets sent to the group cannot be
forwarded through the boundary interfaces.
NOTE
If the connects to a third-party device and needs to receive Auto-RP messages from the third-party device,
you must configure a rule to allow packets with destination addresses 224.0.1.39 and 224.0.1.40 to pass in
the ACL specified in the multicast boundary policy.
Procedure
Step 1 Run:
system-view
187
Step 2 Run:
Step 3 Run:
multicast boundary group-address { mask | mask-length }
The multicast boundary is configured on the interface.
Step 4 Run:
commit
----End
After configuring the multicast boundary on interfaces, check the multicast routing table and
information about the multicast boundary on the interfaces to verify that the multicast network
can operate normally.
*
[ outgoing-
l Run the display multicast boundary [ group-address [ mask | mask-length ] ]
[ interface interface-type interface-number ] command to check information about the
multicast boundary configured on an interface.
6.5 Disabling Soft Forwarding for Multicast Packets
Disabling soft forwarding for multicast packets on a multicast switch prevents packet loss and
disorder.
Applicable Environment
In most cases, the switch forwards packets based on software before the hardware forwarding
is completed. After that, the forwards packets based on hardware. An FCC-enabled device can
quickly forward packets based on hardware, not software.
When the switch works together with an FCC-based device, soft forwarding for multicast packets
must be disabled on the switch to prevent packet loss and disorder caused by the low forwarding
speed and first packet cache mechanism of soft forwarding.
Procedure
Step 1 Run:
system-view
Step 2 Run:
188
multicast cpu-forward disable
Soft forwarding is disabled for multicast packets.
By default, soft forwarding for multicast packets is enabled.
Step 3 Run:
commit
----End
6.6 Maintaining Multicast Routes
You can reset multicast forwarding entries, and monitor multicast routing and forwarding.
6.6.1 Resetting Multicast Forwarding Entries
Context
After confirming that multicast forwarding entries can be deleted, run the reset commands in
the user view to reset the entries.
CAUTION
Resetting multicast forwarding entries may cause interruption of multicast data transmission.
Procedure
l Run the command reset multicast ip fib to reset entries from the multicast forwarding
table.
----End
6.6.2 Monitoring Multicast Routing and Forwarding
Context
During routine maintenance, run the following commands in any view to check the running
status of the multicast forwarding and routing table.
Procedure
l Run the display multicast boundary [ group-address [ mask | mask-length ] ]
[ interface interface-type interface-number ] command to check information about the
multicast boundary configured on an interface.
l Run the display multicast ip fib [ group group-address | source source-address |
incoming-interface { interface-type interface-number | register } ]
*
command to check
the multicast forwarding table.
189
*
[ outgoing-
l Run the display multicast routing-table static [ config ] [ source-address { mask-
length | mask } ] command to check the multicast static routing table.
l Run the display multicast rpf-info source-address [ group-address ] [ rpt | spt ]
[ verbose ] command to check the Reverse Path Forwarding (RPF) route.
----End
This section provides examples to illustrate how to configure multicast static routes and multicast
load splitting on a multicast network.
6.7.1 Example for Configuring a Multicast Static Route to Change
the RPF Route
As shown in Figure 6-1, SwitchA, SwitchB, and SwitchC run OSPF to implement IP
interworking, and switch interfaces use PIM-SM to provide multicast services. Data sent from
the multicast source (Source) is forwarded to the receiver host (Receiver) through SwitchA and
SwitchB. The link between SwitchA and SwitchB transmits unicast and multicast services
simultaneously. To reduce the loads on this link, multicast data needs to be transmitted along
the path SwitchA->SwitchC->SwitchB.
190
Figure 6-1 Configuring a static route to change the RPF route
SwitchC
SwitchB
SwitchA
10GE1/0/3
10GE1/0/3
Source Receiver
7.1.1.2/24 8.1.1.2/24
PIM-SM
Multicast static route
10GE1/0/2
10GE1/0/2
10GE1/0/2
10GE1/0/3
10GE1/0/1
10GE1/0/1
VLANIF10
VLANIF20
VLANIF30
8.1.1.1/24
9.1.1.1/24
12.1.1.1/24
VLANIF30
12.1.1.2/24
VLANIF10
9.1.1.2/24
VLANIF50
7.1.1.1/24
VLANIF40
13.1.1.2/24
VLANIF40
13.1.1.2/24

The RPF interface used to receive multicast data can be changed by configuring a multicast static
route. After the RPF route is changed, multicast and unicast services are transmitted through
different links so that the load on a single link is reduced. The configuration roadmap is as
follows:
1. Configure IP addresses for interfaces and configure a unicast routing protocol (OSPF in
this example) on each switch. Multicast routing protocols depend on unicast routing
protocols.
2. Enable multicast routing on all switches and PIM-SM on all Layer 3 interfaces. Configure
an interface as a C-BSR and C-RP. Enable IGMP on the interface connected to the network
segment of the receiver host. After these basic multicast functions are configured, the
switches can establish a multicast distribution tree using default parameter settings. Then
multicast data can be forwarded to Receiver along the multicast distribution tree.
3. Configure a multicast RPF static route on SwitchB and specify SwitchC as the RPF
neighbor.
Procedure
Step 1 Configure IP addresses for interfaces and configure OSPF on each switch.
# Create VLANs and add Layer 2 physical interfaces to VLANs on the switches. (The
configurations of the other switches are similar to the configuration of SwitchB.)
[~SwitchB] vlan batch 10 40 50
[~SwitchB] interface 10ge 1/0/1
191
[~SwitchB-10GE1/0/1] port link-type trunk
[~SwitchB-10GE1/0/1] port trunk allow-pass vlan 10
[~SwitchB-10GE1/0/1] quit
[~SwitchB-10GE1/0/3] port default vlan 50
[~SwitchB] commit
# Configure IP addresses and masks for Layer 3 VLANIF interfaces on the switches. (The
[~SwitchB-Vlanif10] ip address 9.1.1.2 24
[~SwitchB] commit
# Configure OSPF on the switches. (The configurations of the other switches are similar to the
configuration of SwitchB.)
[~SwitchB] ospf
[~SwitchB-ospf-1] area 0
[~SwitchB-ospf-1-area-0.0.0.0] network 7.1.1.0 0.0.0.255
[~SwitchB-ospf-1-area-0.0.0.0] quit
[~SwitchB] commit
Step 2 Enable multicast routing on all switches, PIM-SM on all Layer 3 interfaces, and IGMP on the
interface connected to the network segment of the receiver host.
# Enable multicast routing on all the switches and enable PIM-SM on all Layer 3 interfaces.
Enable IGMP on the interface connected to the network segment of the receiver host. (The PIM-
SM configurations on the other switches are similar to the PIM-SM configuration on SwitchB.)
[~SwitchB] multicast routing-enable
[~SwitchB-Vlanif50] igmp enable
[~SwitchB] commit
# Configure VLANIF30 of SwitchC as a C-BSR and C-RP.
[~SwitchC] pim
[~SwitchC] c-bsr vlanif 30
[~SwitchC] c-rp vlanif 30
[~SwitchC] commit
[~SwitchC] quit
192
# Run the display multicast rpf-info command on SwitchB to check the RPF route to Source.
The following command output shows that the RPF route is originated from a unicast routing
protocol, and the RPF neighbor is SwitchA.
[~SwitchB] display multicast rpf-info 8.1.1.2
RPF information about source 8.1.1.2:
RPF interface: vlanif10, RPF neighbor: 9.1.1.1
Referenced route/mask: 8.1.1.0/24
Referenced route type: unicast
Route selection rule: preference-preferred
Load splitting rule: disable
Step 3 Configure a multicast static route.
# Configure a multicast RPF static route to Source on SwitchB, and configure SwitchC as the
RPF neighbor.
[~SwitchB] ip rpf-route-static 8.1.1.0 255.255.255.0 13.1.1.2
[~SwitchB] commit
# Run the display multicast rpf-info command on SwitchB to check the RPF route to Source.
The following information is displayed, indicating that the unicast RPF route has been replaced
by the multicast static route and the RPF neighbor has changed to SwitchC.
Referenced route type: mstatic
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20 30
#
#
interface Vlanif10
ip address 9.1.1.1 255.255.255.0
pim sm
#
interface Vlanif20
ip address 8.1.1.1 255.255.255.0
pim sm
#
interface Vlanif30
ip address 12.1.1.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
193
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 8.1.1.0 0.0.0.255
network 9.1.1.0 0.0.0.255
network 12.1.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 10 40 50
#
#
interface Vlanif10
ip address 9.1.1.2 255.255.255.0
pim sm
#
interface Vlanif40
ip address 13.1.1.1 255.255.255.0
pim sm
#
interface Vlanif50
ip address 7.1.1.1 255.255.255.0
pim sm
igmp enable
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 7.1.1.0 0.0.0.255
network 9.1.1.0 0.0.0.255
network 13.1.1.0 0.0.0.255
#
ip rpf-route-static 8.1.1.0 255.255.255.0 13.1.1.2
#
return
#
sysname SwitchC
#
vlan batch 30 40
#
#
interface Vlanif30
ip address 12.1.1.2 255.255.255.0
pim sm
#
interface Vlanif40
ip address 13.1.1.2 255.255.255.0
pim sm
194
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 12.1.1.0 0.0.0.255
network 13.1.1.0 0.0.0.255
#
pim
c-bsr Vlanif 30
c-rp Vlanif 30
#
return
6.7.2 Example for Configuring Multicast Static Routes to Connect
RPF Routes
As shown in Figure 6-2, SwitchB and SwitchC run OSPF to implement IP interworking, but
they have no unicast route to SwitchA. Switch interfaces need to run PIM-SM to provide
multicast services. The receiver host (Receiver) can receive data from Source1. Now Receiver
needs to receive data from Source2.
195
Figure 6-2 Configuring multicast static routes to connect RPF routes
Source1
SwitchC
SwitchB
10GE1/0/2
OSPF
Receiver
Multicast static route
PIM-SM
10.1.3.2/24
10GE1/0/1
10GE1/0/2
SwitchA
10GE1/0/1
Source2
10.1.5.2/24
10GE1/0/3
10GE1/0/3
10GE1/0/1
VLANIF13
VLANIF40
VLANIF20
10.1.4.1/24
10.1.2.2/24
10.1.3.1/24
VLANIF20
10.1.2.1/24
VLANIF12
10.1.1.1/24
VLANIF40
10.1.4.2/24
VLANIF11
10.1.5.1/24

An RPF route to Source2 can be established on the path SwitchC->SwitchB->SwitchA by
configuring multicast static routes on SwitchB and SwitchC. The configuration roadmap is as
follows:
1. Configure IP addresses for interfaces of the switches. Configure OSPF on SwitchB and
SwitchC but not on SwitchA, so that SwitchB and SwitchC have no unicast route to
SwitchA.
2. Enable multicast routing on all switches and PIM-SM on all Layer 3 interfaces. Configure
an interface as a C-BSR and C-RP. Enable IGMP on the interface connected to the network
segment of the receiver host. After these basic multicast functions are configured, the
switches can establish a multicast distribution tree using default parameter settings. Then
multicast data can be forwarded to Receiver along the multicast distribution tree.
3. Configure multicast static routes to Source2 on SwitchB and SwitchC.
196
Procedure
Step 1 Configure IP addresses for interfaces and configure OSPF on each switch.
# Create VLANs and add Layer 2 physical interfaces to VLANs on the switches. (The
[~SwitchB] vlan batch 13 20 40
[~SwitchB-10GE1/0/2] port default vlan 13
[~SwitchB] commit
# Configure IP addresses and masks for Layer 3 VLANIF interfaces on the switches. (The
[~SwitchB] commit
# Configure OSPF on SwitchB and SwitchC. (The configuration of SwitchC is similar to the
configuration of SwitchB.)
[~SwitchB] ospf
[~SwitchB-ospf-1] area 0
[~SwitchB-ospf-1-area-0.0.0.0] quit
[~SwitchB] commit
Step 2 Enable multicast routing on all switches, PIM-SM on all Layer 3 interfaces, and IGMP on the
interface connected to the network segment of the receiver host.
# On SwitchA, enable multicast routing globally and enable PIM-SM on the Layer 3 interfaces.
(The configuration of SwitchB is similar to the configuration of SwitchA.)
[~SwitchA] commit
# On SwitchC, enable multicast routing globally, enable PIM-SM on Layer 3 interfaces, and
enable IGMP on the interface connected to the network segment of the receiver host.
197
[~SwitchC] commit
# Configure VLANIF20 as a C-BSR and C-RP on SwitchB.
[~SwitchB] pim
[~SwitchB-pim] c-bsr vlanif 20
[~SwitchB-pim] c-rp vlanif 20
[~SwitchB-pim] commit
[~SwitchB-pim] quit
# Source1 (10.1.3.2/24) and Source2 (10.1.5.2/24) send multicast data to group G (225.1.1.1).
After Receiver joins group G, it receives the multicast data sent by Source1 but cannot receive
the multicast data sent by Source2.
# Run the display multicast rpf-info 10.1.5.2 command on SwitchB and SwitchC. No
information is displayed, indicating that SwitchB and SwitchC have no RPF route to Source2.
Step 3 Configure multicast static routes.
# Configure a multicast RPF static route to Source2 on SwitchB, and configure SwitchA as the
RPF neighbor.
[~SwitchB] ip rpf-route-static 10.1.5.0 255.255.255.0 10.1.4.2
[~SwitchB] commit
# Configure a multicast RPF static route to Source2 on SwitchC, and configure SwitchB as the
RPF neighbor.
[~SwitchC] ip rpf-route-static 10.1.5.0 255.255.255.0 10.1.2.2
[~SwitchC] commit
# Run the display multicast rpf-info 10.1.5.2 command on SwitchB and SwitchC to check the
RPF route to Source2. The following information is displayed:
RPF information about source: 10.1.5.2
Route selecting rule: preference-preferred
[~SwitchC] display multicast rpf-info 10.1.5.2
# Run the display pim routing-table command on SwitchC to check the PIM routing table.
SwitchC has multicast entries of Source2, indicating that Receiver can receive multicast data
from Source2.
[~SwitchC] display pim routing-table
Total 1 (*, G) entry; 2 (S, G) entries
198
(*, 225.1.1.1)
RP: 10.1.2.2
Protocol: PIM-SM, Flag: WC
UpTime: 03:54:19
Upstream interface: NULL
1: Vlanif12
Protocol: PIM-SM, UpTime: 01:38:19, Expires: never
(10.1.3.2, 225.1.1.1)
RP: 10.1.2.2
Protocol: PIM-SM, Flag: ACT
UpTime: 00:00:44
1: Vlanif12
(10.1.5.2, 225.1.1.1)
RP: 10.1.2.2
Protocol: PIM-SM, Flag: ACT
UpTime: 00:00:44
1: Vlanif12
----End
Configuration Files
#
sysname SwitchA
#
#
vlan batch 11 40
#
interface Vlanif11
ip address 10.1.5.1 255.255.255.0
pim sm
#
interface Vlanif40
ip address 10.1.4.2 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/3
#
return
#
sysname SwitchB
199
#
vlan batch 13 20 40
#
#
interface Vlanif13
ip address 10.1.3.1 255.255.255.0
pim sm
#
interface Vlanif20
ip address 10.1.2.2 255.255.255.0
pim sm
#
interface Vlanif40
ip address 10.1.4.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
#
ip rpf-route-static 10.1.5.0 24 10.1.4.2
#
pim
c-bsr vlanif 20
c-rp vlanif 20
#
return
#
sysname SwitchC
#
vlan batch 12 20
#
#
interface Vlanif12
ip address 10.1.1.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.0
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
#
200
ip rpf-route-static 10.1.5.0 24 10.1.2.2
#
return
6.7.3 Example for Configuring Multicast Load Splitting
As shown in Figure 6-3, SwitchE connects to HostA and has three equal-cost routes to the
multicast source (Source). According to the default RPF check policy, SwitchE will select one
of equal-cost routes to transmit multicast data. When the rate of multicast traffic is high, the
network may be congested, degrading the quality of multicast services. To ensure the quality of
multicast services, configure multicast load splitting so that multicast data can be transmitted
through multiple equal-cost routes.
Figure 6-3 Networking diagram of multicast load splitting
SwitchA
10GE1/0/4
10GE1/0/2
1
0
G
E
1
/
0
/
3
1
0
G
E
1
/
0
/
1
1
0
G
E
1
/
0
/
1
SwitchB
SwitchC
SwitchD
1
0
G
E
1
/
0
/
2
10GE1/0/4
Loopback0
HostA
Source
SwitchE
PIM-SM
1
0
G
E
1
/
0
/
1
10GE1/0/2
1
0
G
E
1
/
0
/
2
1
0
G
E
1
/
0
/
1
10GE1/0/2
1
0
G
E
1
/
0
/
3
VLANIF80
192.168.5.2/24
V
L
A
N
I
F
6
0
VLANIF140
10.110.2.2/24
V
L
A
N
I
F
1
0
0
1
9
2
.
1
6
8
.
6
.
2
/
2
4
V
L
A
N
I
F
4
0
1
9
2
.
1
6
8
.
3
.
1
/
2
4
VLANIF30
192.168.2.1/24
10GE1/0/1
V
L
A
N
I
F
2
0
1
9
2
.
1
6
8
.
1
.
2
/
2
4
V
L
A
N
I
F
6
0
1
9
2
.
1
6
8
.
4
.
1
/
2
4
V
L
A
N
I
F
2
0
1
9
2
.
1
6
8
.
1
.
1
/
2
4
VLANIF10
10.110.1.2/24
1.1.1.1/32
V
L
A
N
I
F
4
0
1
9
2
.
1
6
8
.
3
.
2
/
2
4
VLANIF30
192.168.2.2/24
1
9
2
.
1
6
8
.
4
.
2
/
2
4
VLANIF80
192.168.5.1/24
V
L
A
N
I
F
1
0
0
1
9
2
.
1
6
8
.
6
.
1
/
2
4

The configuration roadmap is as follows:
1. Configure IP addresses for interfaces on the switches.
201
2. Configure a unicast routing protocol (IS-IS in this example) to implement interworking
among all the switches and ensure that route costs are the same.
3. Enable multicast routing on all the switches and enable PIM-SM on all the Layer 3
interfaces. Configure the loopback interface on SwitchA as a C-BSR and C-RP.
4. On SwitchE, configure stable-preferred multicast load splitting to ensure stable
transmission of multicast services.
5. On SwitchE, configure static multicast groups on the interface connected to the network
segment of HostA, because HostA needs to receive data of these groups for a long time.
Procedure
Step 1 Configure IP addresses for interfaces on the switches.
# Create VLANs and add Layer 2 physical interfaces to VLANs on the switches. (Configurations
of the other switches are similar to the configuration of SwitchA.)
[~SwitchA] vlan batch 10 20 30 40
[~SwitchA] commit
# Configure IP addresses and masks for Layer 3 interfaces on the switches. (Configurations of
the other switches are similar to the configuration of SwitchA.)
[~SwitchA] interface loopback0
[~SwitchA-LoopBack0] ip address 1.1.1.1 32
[~SwitchA] commit
Step 2 Configure IS-IS to implement interworking among all the switches and ensure that route costs
are the same.
# Configure SwitchA. (Configurations of the other switches are similar to the configuration of
SwitchA.)
[~SwitchA] isis
[~SwitchA-isis-1] network-entity 10.0000.0000.0001.00
[~SwitchA-isis-1] quit
202
[~SwitchA-Vlanif10] isis enable
[~SwitchA] interface loopback0
[~SwitchA] commit
Step 3 Enable multicast routing on all the switches and enable PIM-SM on all the Layer 3 interfaces.
# Configure SwitchA. (Configurations of the other switches are similar to the configuration of
SwitchA.)
[~SwitchA] interface loopback 0
[~SwitchA-LoopBack0] pim sm
Step 4 Configure a C-BSR and C-RP on SwitchA.
# Configure Loopback0 on SwitchA as a C-BSR and C-RP.
[~SwitchA] pim
[~SwitchA-pim] c-bsr loopback 0
[~SwitchA-pim] c-rp loopback 0
[~SwitchA-pim] quit
Step 5 Configure stable-preferred multicast load splitting on SwitchE.
[~SwitchE] multicast load-splitting stable-preferred
[~SwitchE] commit
Step 6 Configure static multicast groups on the interface of SwitchE connected to the network segment
of HostA.
# Configure static multicast groups 225.1.1.1 to 225.1.1.3 on VLANIF140.
[~SwitchE] interface Vlanif140
[~SwitchE-Vlanif140] igmp static-group 225.1.1.1 inc-step-mask 32 number 3
[~SwitchE-Vlanif140] commit
[~SwitchE-Vlanif140] quit
Step 7 Verify the configuration of stable-preferred multicast load splitting.
# Source (10.110.1.1/24) sends multicast data to multicast groups 225.1.1.1 to 225.1.1.3. HostA
can receive multicast data from Source. Check brief information about the PIM routing table on
SwitchE.
203
<SwitchE> display pim routing-table brief
VPN-Instance: public net, Total 3 (*, G) entries, 3 (S, G) entry
Entries Upstream interface NDwnstrms
(*, 225.1.1.1) Register 1
(10.110.1.1, 225.1.1.1) Register 1
(*, 225.1.1.2) Register 1
(10.110.1.1, 225.1.1.2) Register 1
(*, 225.1.1.3) Register 1
(10.110.1.1, 225.1.1.3) Register 1
(*, G) and (S, G) entries are evenly distributed on the three equal-cost routes. The upstream
interfaces of the routes are VLANIF100, VLANIF80, and VLANIF60 respectively.
NOTE
The load splitting algorithm processes (*, G) and (S, G) entries separately using the same rule.
----End
Configuration Files
#
sysname SwitchA
#
#
#
isis 1
network-entity 10.0000.0000.0001.00
#
interface Vlanif10
ip address 10.110.1.2 255.255.255.0
isis enable 1
pim sm
#
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
isis enable 1
pim sm
#
interface Vlanif30
ip address 192.168.2.1 255.255.255.0
isis enable 1
pim sm
#
interface Vlanif40
ip address 192.168.3.1 255.255.255.0
isis enable 1
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
interface LoopBack0
204
ip address 1.1.1.1 255.255.255.255
isis enable 1
pim sm
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
return
#
sysname SwitchB
#
vlan batch 20 60
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface Vlanif20
ip address 192.168.1.2 255.255.255.0
isis enable 1
pim sm
#
interface Vlanif60
ip address 192.168.4.1 255.255.255.0
isis enable 1
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
#
sysname SwitchC
#
vlan batch 30 80
#
#
isis 1
network-entity 10.0000.0000.0003.00
#
interface Vlanif30
ip address 192.168.2.2 255.255.255.0
isis enable 1
pim sm
#
interface Vlanif80
ip address 192.168.5.1 255.255.255.0
isis enable 1
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
205
#
return
#
sysname SwitchD
#
vlan batch 40 100
#
#
isis 1
network-entity 10.0000.0000.0004.00
#
interface Vlanif40
ip address 192.168.3.2 255.255.255.0
isis enable 1
pim sm
#
interface Vlanif100
ip address 192.168.6.1 255.255.255.0
isis enable 1
pim sm
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
#
sysname SwitchE
#
vlan batch 60 80 100 140
#
multicast load-splitting stable-preferred
#
isis 1
network-entity 10.0000.0000.0005.00
#
interface Vlanif60
ip address 192.168.4.2 255.255.255.0
isis enable 1
pim sm
#
interface Vlanif80
ip address 192.168.5.2 255.255.255.0
isis enable 1
pim sm
#
interface Vlanif100
ip address 192.168.6.2 255.255.255.0
isis enable 1
pim sm
#
interface Vlanif140
ip address 10.110.2.2 255.255.255.0
isis enable 1
pim sm
igmp static-group 225.1.1.1 inc-step-mask 0.0.0.1 number 3
#
interface 10GE1/0/1
206
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
return
This section describes the common configuration errors and troubleshooting methods.
6.8.1 A Multicast Static Route Fails to Take Effect
Fault Description
A device does not run any dynamic routing protocols, and a multicast static route is configured
on the device. Multicast data cannot be forwarded to user hosts through this multicast static route
although the physical status and link-layer protocol status of the interface are both Up.
Procedure
Step 1 Check whether the multicast static route is configured correctly and has been added to the
multicast routing table.
Run the display multicast routing-table static command to check whether the multicast static
route is configured correctly.
If the multicast static route is not correctly configured or it does not match the network topology
because the topology has changed, the multicast routing table does not contain the routing entry
and configuration of the multicast static route. In this case, run the ip rpf-route-static command
to configure a multicast static route that matches the current network topology.
Step 2 Check whether the multicast static route has been added to the routing table of the specified
routing protocol.
If a routing protocol is specified for the multicast static route, run the display ip routing-
table command to check whether this route has been added to the routing table of the protocol.
If not, configure a matching unicast route for the routing protocol.
Step 3 Check whether the multicast static route matches the specified routing policy.
If a routing protocol is specified for the multicast static route, run the display route-policy
command to check whether the source address of the multicast static route matches the matching
rule of the routing policy. If not, run the route-policy command to change the matching rule of
the routing policy. Ensure that the multicast static route matches the routing policy and can be
added to the routing table.
----End
207
7 IGMP Snooping Configuration
About This Chapter
IGMP snooping enables a Layer 2 multicast device to create and maintain a Layer 2 multicast
forwarding table by analyzing IGMP messages exchanged between the upstream Layer 3 device
and user hosts. This technology implements on-demand multicast data transmission at the data
link layer.
7.1 IGMP Snooping Overview
Internet Group Management Protocol Snooping (IGMP snooping) is a Layer 2 IPv4 multicast
protocol. The IGMP snooping protocol maintains information about the outgoing interfaces of
multicast packets by snooping multicast protocol packets exchanged between the Layer 3
multicast device and user hosts. The IGMP snooping protocol manages and controls the
forwarding of multicast packets at the data link layer.
7.2 IGMP Snooping Features Supported by the Switch
This section describes the IGMP snooping features supported by the switch: basic IGMP
snooping functions, IGMP snooping proxy, IGMP snooping policy, membership fast-update and
IGMP snooping SSM mapping.
This section provides the default IGMP snooping configuration.
7.4 Configuring Basic IGMP Snooping Functions
Basic IGMP snooping functions enable a device to create and maintain a Layer 2 multicast
forwarding table and implement on-demand multicast data transmission at the data link layer.
7.5 Configuring IGMP Snooping Proxy
IGMP snooping proxy enables the switch to substitute for the Layer 3 device to send IGMP
Query messages to user hosts, and substitute for user hosts to send IGMP Report/Leave messages
to the Layer 3 device. This function saves bandwidth between the upstream device and local
switch.
7.6 Configuring the IGMP Snooping Policy
The IGMP snooping policy controls the multicast programs for users, making the multicast
network controllable and secure.
7.7 Configuring Membership Fast-Update
Configuration Guide - IP Multicast 7 IGMP Snooping Configuration
208
The switch is configured to rapidly update memberships when a multicast group member joins
or leaves the multicast group. This improves the efficiency and user experience of multicast
services.
7.8 Configuring IGMP Snooping SSM Mapping
If user hosts on a Layer 2 network run only IGMPv1 or IGMPv2, enable SSM mapping on the
switch to provide SSM services for these hosts.
7.9 Maintaining IGMP Snooping
You can maintain the IGMP snooping feature by clearing IGMP snooping entries, clearing IGMP
snooping statistics, and monitoring IGMP snooping running status.
This section provides IGMP snooping configuration examples to help you configure basic IGMP
snooping functions, static interfaces, an IGMP snooping querier, an IGMP snooping proxy, and
Layer 2 multicast SSM mapping on an IPv4 multicast network.
This section describes common faults caused by incorrect IGMP snooping configurations and
provides the troubleshooting procedure.
209
7.1 IGMP Snooping Overview
Internet Group Management Protocol Snooping (IGMP snooping) is a Layer 2 IPv4 multicast
protocol. The IGMP snooping protocol maintains information about the outgoing interfaces of
multicast packets by snooping multicast protocol packets exchanged between the Layer 3
multicast device and user hosts. The IGMP snooping protocol manages and controls the
forwarding of multicast packets at the data link layer.
IGMP Snooping
On an IPv4 multicast network, after receiving multicast packets from an upstream device, a
device at the edge of the access layer forwards the multicast packets to user hosts. Therefore,
the users can receive on-demand programs. As shown in Figure 7-1, by default, multicast packets
are broadcast at the data link layer, causing bandwidth waste.
After IGMP snooping is configured on a Layer 2 device (such as the Switch in Figure 7-1), the
Switch intercepts Internet Group Management Protocol (IGMP) messages exchanged between
an upstream device and downstream hosts and creates a Layer 2 multicast forwarding table. This
implements on-demand multicast data transmission at the data link layer.
Figure 7-1 Multicast packet transmission before and after IGMP snooping is configured on a
Layer 2 device
PIM
RecieverA
RecieverB
Source
Multicast packet
Switch
Router
Multicast packet transmission
without IGMP Snooping
PIM
RecieverA RecieverB
Source
Multicast packet transmission
when IGMP Snooping runs
Router
Switch
IGMP
Snooping

IGMP Snooping Benefits
The IGMP snooping protocol forwards multicast information only to the specified receivers
through Layer 2 multicast. It has the following advantages:
210
l Reducing broadcast packets on Layer 2 networks to conserve network bandwidth
l Forwarding multicast packets on Layer 2 networks to improve information security
7.2 IGMP Snooping Features Supported by the Switch
This section describes the IGMP snooping features supported by the switch: basic IGMP
snooping functions, IGMP snooping proxy, IGMP snooping policy, membership fast-update and
IGMP snooping SSM mapping.
NOTE
Because IGMP snooping is a Layer 2 multicast feature, all the IGMP snooping configurations on interfaces
mentioned in this chapter are performed on Layer 2 physical interfaces, including Eth-Trunk interfaces.
Basic IGMP Snooping Functions
The switch supports VLAN-based IGMP snooping. You can set the following parameters or
functions of IGMP snooping:
l IGMP Snooping versions, including IGMPv1, IGMPv2, and IGMPv3. The same IGMP
version needs to be configured on the switch and an upstream Layer 3 device because the
IGMP messages vary based on version.
l Statically configuring router ports and member ports. This implements fast and stable
forwarding of multicast data.
l IGMP snooping querier. When IGMP querier is not enabled on an upstream device, the
switch can substitute the upstream device to send IGMP Query messages.
l IGMP snooping message suppression. This function limits the number of IGMP Report
and Leave messages sent by member hosts to the upstream device and improves system
performance.
l Router-Alert. This function improves device performance and network security.
l Disabling users from dynamically joining multicast groups. The Report and Leave
messages received in a VLAN cannot be forwarded to the upstream device that has static
multicast groups configured.
IGMP Snooping Proxy
When IGMP snooping proxy is enabled on a Layer 2 device, this device is enabled with both
the message suppression and IGMP querier functions. The switch configured with IGMP
snooping proxy functions as a host for its upstream device and a querier for its downstream host.
IGMP Snooping Policy
The switch can be configured to filter multicast data according to networking requirements:
l Configures a multicast group policy to control the multicast groups that users can join.
l Configures a multicast group policy on an interface to filter multicast data sent from a
specified VLAN.
l Discards unknown multicast packets, preventing them from being broadcast in VLANs.
l Configures a multicast group policy to filter Report/Query messages, improving system
security.
211
l Configures the type of multicast groups in a VLAN, limiting the IGMP message types that
can be learned in the VLAN.
Membership Fast-Update
With this function, the switch can rapidly update memberships when a multicast group member
joins or leaves a multicast group. This improves the efficiency and user experience of multicast
services. You can set the following parameters or functions:
l Sets the aging time of dynamic member ports.
l Sets the aging time of dynamic router ports.
l Configures fast leave for member ports.
l Sends IGMP Query messages upon changes on a Layer 2 network topology.
IGMP Snooping SSM Mapping
Source-Specific Multicast (SSM) allows multicast members to receive multicast data from the
specified multicast sources. Only IGMPv3 supports the SSM model. Configure IGMP snooping
SSM mapping on the switch to set up one-to-one mappings between multicast groups and
multicast sources. The switch can then convert (*, G) entries in IGMPv1 or IGMPv2 messages
to (S, G) entries to provide the SSM service for the hosts that run IGMPv1 or IGMPv2.
This section provides the default IGMP snooping configuration.
Table 7-1 Default IGMP snooping configuration
IGMP snooping Disabled
IGMP snooping version IGMPv2 when IGMP snooping is enabled
IGMP snooping interface learning Enabled when IGMP snooping is enabled
IGMP snooping querier Disabled
IGMP snooping message suppression Disabled
IGMP snooping proxy Disabled
Layer 2 SSM mapping Disabled

Basic IGMP snooping functions enable a device to create and maintain a Layer 2 multicast
forwarding table and implement on-demand multicast data transmission at the data link layer.
Before configuring the IGMP snooping, complete the following tasks:
212
l Connecting interfaces and setting physical parameters for the interfaces to ensure that the
physical status of the interfaces is Up
l Creating VLANs
l Adding interfaces to VLANs
7.4.1 Enabling IGMP Snooping and 7.4.2 Configuring the IGMP Snooping Version are
mandatory and other tasks are optional.
7.4.1 Enabling IGMP Snooping
Context
Other IGMP snooping functions can be configured only after IGMP snooping is enabled
globally. Other IGMP snooping functions take effect in a VLAN only after IGMP snooping is
enabled in the VLAN.
By default, IGMP snooping is disabled globally on the switch.
Procedure
Step 1 Run:
system-view
Step 2 Run:
igmp snooping enable
IGMP snooping is enabled globally.
Step 3 Run:
vlan vlan-id
The VLAN view is displayed.
multicast layer-2 forwarding-mode { ip | mac }
The multicast flows in the VLAN are forwarded based on IP addresses or MAC addresses.
By default, multicast flows are forwarded based on IP addresses.
CAUTION
Configure the forwarding mode of multicast flows in the VLAN before IGMP snooping is
enabled in the VLAN. Enable IGMP snooping in the VLAN for the configuration to take effect.
Step 5 Run:
IGMP snooping is enabled in the VLAN.
213
NOTE
Run the igmp snooping enable [ vlan { vlan-id1 [ to vlan-id2 ] } &<1-10> ] command in the system view
to enable IGMP snooping in multiple VLANs.
Step 6 Run:
commit
----End
7.4.2 Configuring the IGMP Snooping Version
Context
IGMP manages multicast group members and runs on the network segments where Layer 3
multicast devices connect to user hosts. IGMP has three protocol versions V1, V2, and V3. You
can specify the IGMP snooping version on a Layer 2 device to enable the device to process
IGMP messages of the specified version. Generally, the version specified on the Layer 2 device
is the same as that configured on the Layer 3 multicast device. If IGMP is disabled on the Layer
3 multicast device, configure the same IGMP version as member hosts or a higher IGMP version.
Devices in the same VLAN must run IGMP of the same version. When hosts that run different
IGMP versions exist in a VLAN, configuring IGMP snooping version to enable the device to
process IGMP messages of different versions.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping version version
The version of IGMP messages that the device can process is set.
By default, the device can process IGMPv1 and IGMPv2 messages but cannot process IGMPv3
messages.
NOTE
When MAC address-based forwarding is enabled in the VLAN, IGMPv3 cannot be configured.
Step 4 Run:
commit
----End
214
7.4.3 (Optional) Configuring a Static Router Port
Context
A router port is located on a Layer 2 device and connects to an upstream Layer 3 device (a
multicast router or Layer 3 switch). When IGMP snooping is enabled in a VLAN, all interfaces
in this VLAN learn forwarding entries from multicast protocol packets. When an interface
receives IGMP Query messages or Protocol Independent Multicast (PIM) Hello messages, the
Layer 2 device sets this interface as a dynamic router port. A router port provides the following
functions:
l Receives multicast data from the upstream device.
l Forwards IGMP Report/Leave messages. IGMP Report/Leave messages received in a
VLAN are forwarded only to router ports in the VLAN.
A dynamic router port has an aging time. If a dynamic router port does not receive an IGMP
Query or a PIM Hello message before the aging time expires, the device deletes the port from
the router port list. To enable an interface to forward IGMP Report/Leave messages to the
upstream querier for a long time, configure the interface as a static router port.
Procedure
Step 1 Run:
system-view
vlan vlan-id
igmp snooping router-learning disable
Dynamic router port learning is disabled.
By default, dynamic router port learning is enabled in a VLAN.
quit
Exit from the VLAN view.
Step 5 Run:
Step 6 Run:
igmp snooping static-router-port vlan { vlan-id1 [ to vlan-id2 ] } &<1-10>
An interface is configured as a static router port.
Step 7 Run:
commit
215
----End
7.4.4 (Optional) Configuring a Static Member Port
Context
A member port is on a Layer 2 device and connects to receiver hosts which are multicast group
members. The member port can be configured manually or learned dynamically by multicast
protocols. When IGMP snooping is enabled in a VLAN, all interfaces in this VLAN learn
forwarding entries from multicast packets. When an interface receives IGMP Report messages,
the Layer 2 device sets this interface as a dynamic member port. A dynamic member port has
the aging time.
If the hosts connected to an interface need to receive the multicast data of a specific multicast
group or multicast source group for a long time, add the interface statically to the multicast group
or multicast source group. The manually added interface is a static member port. Static member
ports do not age.
Procedure
Step 1 Run:
system-view
Step 2 Run:
igmp snooping learning disable vlan { { vlan-id1 [ to vlan-id2 ] } &<1-10> | all }
Dynamic learning of member ports is disabled.
By default, dynamic learning of member ports is enabled. To forward multicast data, the
interfaces must be statically added to a multicast group after disabling dynamic learning of
member ports.
Step 4 Run:
igmp snooping static-group [ source-address source-ip-address ] group-address
group-ip-address vlan { vlan-id1 [ to vlan-id2 ] } &<1-10>
The interface is manually added to a multicast group and becomes a static member port.
Or run:
igmp snooping static-group [ source-address source-ip-address ] group-address
group-ip-address1 to group-ip-address2 vlan vlan-id
The interface is added to multiple multicast groups.
Step 5 Run:
commit
216
----End
7.4.5 (Optional) Configuring an IGMP Snooping Querier
Context
When IGMP snooping is enabled on a Layer 2 device, the Layer 2 device can listen on IGMP
protocol packets exchanged between an IGMP querier and user hosts to dynamically create Layer
2 multicast forwarding entries and provide Layer 2 multicast functions.
A Layer 2 device cannot create Layer 2 multicast forwarding entries by listening on IGMP
protocol packets in the following conditions, even when IGMP snooping is enabled on the
device:
l The interfaces on the upstream Layer 3 multicast device have static multicast groups
configured and do not run the IGMP protocol.
l The multicast source is located on the same Layer 2 network as user hosts, and therefore
no Layer 3 multicast device is required.
In either of the preceding conditions, you can configure the IGMP snooping querier on the Layer
2 multicast device. Then the Layer 2 multicast device substitutes for a Layer 3 multicast device
to send IGMP Query messages to user hosts.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping querier enable
The IGMP snooping querier function is enabled.
NOTE
l The IGMP snooping querier function cannot be enabled in a VLAN if the corresponding Layer 3
VLANIF interface has IGMP enabled.
l After an IGMP snooping querier is enabled, the switch periodically broadcasts IGMP Query messages
to all the interfaces in a VLAN, including the router ports in the VLAN. This may result in IGMP
querier reelection if an IGMP querier already exists on the multicast network. If an IGMP querier
already exists on the multicast network, configuring IGMP snooping querier is not recommended.
l IGMP snooping querier and IGMP snooping proxy cannot be enabled in the same VLAN.
igmp snooping querier-election
The querier election function is enabled.
217
If the querier function is enabled on multiple devices in the VLAN, one of these devices must
be elected as the querier to send Query messages to user hosts.
Step 5 (Optional) Set the querier parameters.
NOTE
When setting the querier parameters, ensure that the interval for sending IGMP General Query messages
is larger than the maximum response time for IGMP Query messages.
Querier
Parameter
Configuration
Command
Description Default
Setting
Version
Interval for
sending IGMP
General Query
messages
igmp snooping
query interval
query-interval
The querier
sends IGMP
General Query
messages at the
specified
interval to
maintain
memberships of
interfaces in a
VLAN.
60 seconds IGMPv1,
IGMPv2, and
IGMPv3
218
Querier
Parameter
Configuration
Command
Description Default
Setting
Version
IGMP
robustness
variable
igmp snooping
robust-count
robust-count
The robustness
variable defines
the following
values:
l Number of
times the
querier
sends
General
Query
messages
after startup.
The packet
sending
interval is
1/4 of the
configured
interval for
sending
General
Query
messages.
l Number of
times the
querier
sends
Group-
Specific
Query
messages
after
receiving a
Leave
message.
The packet
sending
interval is
the same as
the
configured
interval for
sending
Group-
Specific
Query
messages.
2 IGMPv1,
IGMPv2, and
IGMPv3
219
Querier
Parameter
Configuration
Command
Description Default
Setting
Version
Maximum
response time
for IGMP Query
messages
igmp snooping
query max-
response-time
max-response-
time
When receiving
IGMP Report
messages from
hosts, the
switch sets the
aging time of
member ports
by using the
following
formula: Aging
time = IGMP
robustness
variable x
Interval for
sending IGMP
General Query
messages +
Maximum
response time.
After a multicast
member
receives an
IGMP Query
message, it must
send a Report
message within
the maximum
response time.
10 seconds IGMPv2 and
IGMPv3
220
Querier
Parameter
Configuration
Command
Description Default
Setting
Version
Interval for
sending IGMP
Group-Specific
Query messages
igmp snooping
query last-
member-
interval last-
member-
interval
When receiving
IGMP Leave
messages from a
host, the switch
calculates the
aging time of the
member port by
using the
following
formula: Aging
time = Interval
for sending
Group-Specific
Query messages
x IGMP
robustness
variable. The
switch sends a
Group-Specific
Query message
certain times
(specified by the
IGMP
robustness
variable) to
check whether
this group has
any other
members.
1 second IGMPv2 and
IGMPv3

quit
igmp snooping send-query source-address ip-address
The source IP address of an IGMP General Query message is configured.
By default, the source IP address of an IGMP General Query message sent by the IGMP snooping
querier is 192.168.0.1. If this IP address is used by other devices on the network, you can use
this command to set another IP address.
Step 8 Run:
commit
----End
221
7.4.6 (Optional) Suppressing Report and Leave Messages
Context
IGMP periodically sends Query and Response messages to maintain memberships. When
multiple multicast members join the same multicast group, they send a large number of the same
Report message to the IGMP router. When IGMPv2 or IGMPv3 hosts leave a multicast group,
they send a large number of the same Leave message. To conserve bandwidth, configure
suppression for Report and Leave messages on the Layer 2 device.
After message suppression is configured, the switch forwards a Report message only when the
first member joins a multicast group or when it receives an IGMP Query message. and a Leave
message only when the last member leaves the multicast group.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping report-suppress
The Report and Leave messages are suppressed.
NOTE
When configuring message suppression, pay attention to the following points:
l After message suppression is configured in a VLAN, IGMP cannot be enabled on the corresponding
VLANIF interface.
l IGMP snooping proxy and message suppression cannot be configured in the same VLAN.
Step 4 Run:
commit
----End
7.4.7 (Optional) Configuring the Router-Alert Option
Context
By default, the switch does not check whether IGMP messages contain the Router-Alert option
and sends all the IGMP messages to the upper-layer routing protocol. To improve device
performance, reduce transmission cost, and enhance protocol security, configure the switch to
discard IGMP messages without the Router-Alert option.
By default, the switch sends IGMP messages with the Router-Alert option.
222
For details about the Router-Alert option, see RFC 2113.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping require-router-alert
The device is configured to check whether IGMP messages contain the Router-Alert option.
Step 4 Run:
undo igmp snooping send-router-alert disable
The device is configured to send only IGMP messages with the Router-Alert option.
Step 5 Run:
commit
----End
7.4.8 (Optional) Disabling Users from Dynamically Joining
Multicast Groups
Context
If an upstream multicast group is a non-Huawei device and has static multicast groups configured
on the interface connected to user hosts, multicast users are not allowed to dynamically join or
leave the multicast groups. In this case, disable the device from sending IGMP Report and Leave
messages that contain static group addresses to the upstream device.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping static-group suppress-dynamic-join
223
The switch is disabled from sending IGMP Report and Leave messages that contain static group
addresses to the upstream device.
By default, the device forwards IGMP Report and Leave messages that contain static group
addresses to the router port.
Step 4 Run:
commit
----End
Context
After the configurations are complete, run the following commands in any view to check IGMP
spooning configurations and the forwarding entries.
Procedure
l Run the display igmp snooping [ vlan [ vlan-id ] ] configuration command to check the
IGMP snooping configuration in a VLAN.
l Run the display igmp snooping [ vlan [ vlan-id ] ] command to check all the IGMP
snooping running parameters in a VLAN.
l Run the display igmp snooping port-info [ vlan vlan-id [ group-address group-
address ] ] [ verbose ] command to check member ports of the multicast group.
l Run the display igmp snooping router-port vlan vlan-id command to check router ports.
l Run the display multicast layer-2 ip fib [ vlan vlan-id [ [ source source-address ]
group group-address] ] command to check the multicast forwarding table in a VLAN.
l Run the display multicast layer-2 forwarding-mode vlan [ vlan-id ] command to check
multicast data forwarding mode in the VLAN.
l Run the display igmp snooping querier vlan [ vlan-id ] command to check the IGMP
snooping querier configuration.
----End
7.5 Configuring IGMP Snooping Proxy
IGMP snooping proxy enables the switch to substitute for the Layer 3 device to send IGMP
Query messages to user hosts, and substitute for user hosts to send IGMP Report/Leave messages
to the Layer 3 device. This function saves bandwidth between the upstream device and local
switch.
Context
When IGMP is disabled on the Layer 3 device (for example, only static multicast group is
configured), there is no IGMP querier on the network to maintain multicast memberships.
224
Configure the IGMP snooping proxy function on a Layer 2 device, then the Layer 2 device
functions as an IGMP querier to send IGMP Query messages.
When IGMP is enabled on the network, the IGMP snooping proxy function can be deployed on
a Layer 2 device to allow the device to substitute for the user host to send IGMP Report messages
to the upstream device. In this case, the Layer 3 device receives fewer IGMP Report and Leave
messages.
The device configured with IGMP snooping proxy functions as a host for its upstream device
and a querier for its downstream device.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping proxy
IGMP snooping proxy is enabled.
NOTE
l IGMP snooping proxy cannot be enabled in a VLAN if the corresponding VLANIF interface has IGMP
enabled.
l The IGMP snooping querier and IGMP message suppression functions can be enabled in the same
VLAN to implement the IGMP snooping proxy function. After you configure the IGMP snooping
proxy function in a VLAN, do not configure the IGMP snooping querier or IGMP message suppression
function in the VLAN. For detailed configurations of IGMP snooping querier and IGMP message
suppression, see 7.4.5 (Optional) Configuring an IGMP Snooping Querier and 7.4.6 (Optional)
Suppressing Report and Leave Messages.
quit
igmp snooping proxy-uplink-port vlan vlan-id
The switch is disabled from sending IGMP Query messages to the router port.
After IGMP snooping proxy is enabled in a VLAN, the switch broadcasts IGMP Query messages
to all interfaces in the VLAN periodically, including the router port in the VLAN. This may
result in reelection of the IGMP querier. To prevent IGMP querier reelection, run this command
to disable the switch from sending IGMP Query messages to the router port.
225
igmp snooping proxy router-protocol-pass
The switch is configured to transparently transmit IGMP messages in the VLAN.
By default, the switch having IGMP snooping proxy enabled terminates IGMP messages it
receives and learns multicast forwarding entries from the packets. When IGMP snooping proxy
is enabled on both the upstream device and downstream device on the network, you can run this
command to enable the device to transparently transmit IGMP messages from one router port
to other router ports without learning the forwarding entries. In this way, the aging of forwarding
entries is not affected.
Step 8 Run:
commit
----End
After completing IGMP snooping proxy configuration, you can run the display igmp
snooping [ vlan [ vlan-id ] ] configuration command in any view to check the IGMP snooping
proxy configuration in the VLAN.
7.6 Configuring the IGMP Snooping Policy
The IGMP snooping policy controls the multicast programs for users, making the multicast
network controllable and secure.
7.6.1 Configuring a Multicast Group Policy
Context
A multicast group policy determines which multicast groups the hosts in a VLAN can join. The
multicast group policy is applicable only to dynamic multicast groups. Before configuring the
multicast group policy, create an ACL and define rules. For details about ACL configuration,
see "ACL Configuration" in the CloudEngine 6800&5800 Series Switches Configuration Guide
- Security.
NOTE
The ACL referenced in a group policy permits all multicast groups by default. Therefore, to allow interfaces
in a VLAN to receive only multicast data sent to specific groups, use a rule deny source any rule with
permit rules in the ACL.
226
Procedure
Step 1 Run:
system-view
Step 2 Use either of the following methods to configure a multicast group policy.
l Configure a multicast group policy in a VLAN.
1. Run:
vlan vlan-id
2. Run:
igmp snooping group-policy { acl-number | acl-name acl-name } [ version
version-number ]
A multicast group policy is configured.
l Configure a multicast group policy on an interface.
1. Run:
2. Run:
igmp snooping group-policy { acl-number | acl-name acl-name } [ version
version-number ] vlan vlan-id1 [ to vlan-id2 ]
A multicast group policy is configured on an interface.
By default, the user hosts in a VLAN can join any multicast group. If the IGMP version is not
specified for a multicast group policy, the switch applies the policy to all the received IGMP
messages regardless of their versions.
If you configure multicast group policies for the same VLAN in the interface view and VLAN
view, the system first uses the policy configured in the interface view and then the policy
configured in the VLAN view to determine the groups that user hosts can join.
Step 3 Run:
commit
----End
7.6.2 Filtering Multicast Data on an Interface
Context
To reject certain types of multicast data, a network administrator can configure the switch to
filter multicast data packets from a certain VLAN on an interface.
Procedure
Step 1 Run:
system-view
227
Step 2 Run:
Step 3 Run:
multicast deny-vlan vlan { vlan-id1 [ to vlan-id2 ] } &<1-10>
The multicast data from a certain VLAN is filtered.
NOTE
You must specify a VLAN to which the interface has already been added. Otherwise, the configuration
does not take effect.
This command can discard only multicast data packets that meet both of the following conditions:
l The destination MAC address is an IP multicast MAC address (IPv4 MAC address starting with
0x01-00-5e ).
l The packet encapsulation protocol is UDP.
Step 4 Run:
commit
----End
7.6.3 Discarding of Unknown Multicast Flows
Context
Unknown multicast flows are multicast data flows that match no entry in the multicast
forwarding table. By default, the switch broadcasts unknown multicast flows in the
corresponding VLAN. Enabling the discarding of unknown multicast flows reduces instant
bandwidth usage compared with the broadcast mode.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
multicast drop-unknown
The switch is configured to discard unknown multicast flows.
228
NOTE
After the multicast drop-unknown command is configured:
l The switch discards the original unknown multicast data packets. Multicast data flows can be forwarded
after the matching multicast forwarding entries are generated.
l The switch discards protocol packets with reserved group addresses, such as PIM Hello packets, OSPF
packets, and BFD packets. If no multicast function is enabled, the switch discards IGMP packets. If
multicast functions are enabled, the switch processes IGMP packets normally.
Step 4 Run:
commit
----End
7.6.4 Configuring a Policy to Filter IGMP Report Messages
Context
An administrator can configure a policy to filter IGMP Report messages from specified hosts
to improve security of multicast services.
This function must be used together with an ACL. When a basic ACL is used, IGMP Report
messages with specified source addresses can be filtered. When an advanced ACL is used, IGMP
Report messages with destination addresses or source addresses can be filtered. For details on
how to configure an ACL, see "ACL Configuration" in the Configuration Guide - Security.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping ip-policy { acl-number | acl-name acl-name }
A policy is configured to filter IGMP Report messages so that hosts in a VLAN can only
dynamically join multicast groups that match the ACL rule.
By default, no policy is configured to filter IGMP Report messages in a VLAN.
Step 4 Run:
commit
----End
7.6.5 Configuring a Policy to Filter IGMP Query Messages
229
Context
If an attacker sends Query messages with a smaller IP address than the real IGMP querier on
the network, switches running IGMP snooping consider the attacker as a querier and forward
IGMP Membership Report messages to the attacker. In this case, multicast traffic cannot be
forwarded correctly. You can configure an IGMP Query message filtering policy to defend
against such attacks. An IGMP Query message filtering policy permits only IGMP Query
messages with specified source IP addresses and rejects other IGMP Query messages. This
improves security of a Layer 2 multicast network.
An IGMP Query message filtering policy must reference an ACL. IGMP Query messages are
accepted only when their source IP addresses are permitted by the referenced ACL (within the
address range following permit in the ACL rule). For details about ACL configuration, see
"ACL Configuration" in the CloudEngine 6800&5800 Series Switches Configuration Guide -
Security.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping query ip-policy { acl-number | acl-name acl-name }
An IGMP Query message filtering policy is configured.
By default, no IGMP Query message filtering policy is configured in a VLAN.
Step 4 Run:
commit
----End
7.6.6 Configuring the Multicast Group Type for a VLAN
Context
There are two multicast modes: Any-Source Multicast (ASM) mode and Source-Specific
Multicast (SSM). In the ASM mode, packets do not carry multicast source information; while
in the SSM mode, packets carry multicast source information. The ASM mode and SSM mode
use different multicast group addresses. This function enables the switch to learn only IGMP
messages within the ASM or SSM address scope.
NOTE
This function applies only to the switch that runs IGMPv3 snooping but not IGMPv1 or IGMPv2 snooping.
230
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping { asm-only | ssm-only | asm-ssm }
The type of multicast groups in a VLAN is configured.
By default, the type of multicast groups in a VLAN is asm-ssm.
Step 4 Run:
commit
----End
7.6.7 Setting the Aging Time for Entries Triggered by Multicast
Traffic
Context
If a multicast source does not send multicast data for some multicast groups, relevant (S, G)
entries need to be deleted. If a device does not receive any multicast data sent by a multicast
source to a multicast group within the aging time of the corresponding (S, G) entry triggered by
multicast traffic, the device deletes the multicast entry, improving device performance.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
multicast layer-2 source-lifetime lifetime
The aging time is set for entries triggered by multicast traffic in the VLAN.
By default, the aging time of an entry triggered by multicast traffic is 210s.
Configure aging time of (S, G) entries according to the number of the multicast forwarding
entries used. If a large number of multicast entries are used on your network, a too short aging
231
time will make the multicast forwarding table incomplete. However, if the aging time is too
long, invalid entries will be retained for a long time, wasting system resources. The following
table lists the recommended aging time values for different quantities of multicast forwarding
entries.
Number of Entries Recommended Aging Time
Within 1000 Default value
1000 to 2000 1000 seconds
2000 to 8000 2000 seconds
More than 8000 4000 seconds

Step 4 Run:
commit
----End
Prerequisites
After the configurations of IGMP snooping policy are complete, run the following commands
in any view to check the policy configurations and usage.
Procedure
IGMP snooping configuration.
The configurations of IGMP snooping include the configurations of IGMP snooping policy
in the VLAN.
group group-address ] ] command to check the multicast forwarding table in a VLAN.
You can check whether a Layer 2 multicast policy is used correctly by viewing Layer 2
multicast forwarding entries.
----End
7.7 Configuring Membership Fast-Update
The switch is configured to rapidly update memberships when a multicast group member joins
or leaves the multicast group. This improves the efficiency and user experience of multicast
services.
232
7.7.1 Setting the Aging Time of Group Member Ports
Context
A device sets the aging time of a group member port depending on the IGMP message received
on the member port:
l When the member port receives a Report message from a downstream host, the device sets
the aging time to: Robustness variable x General Query interval + Maximum response time
for General Query messages.
l When the member port receives a Leave message from a downstream host, the device sets
the aging time to: Last member query interval x Robustness variable.
When deploying a Layer 2 multicast network, ensure that all the Layer 2 multicast devices use
the same parameter values to calculate the aging time of dynamic group member ports, especially
the general query interval. Otherwise, errors may occur in Layer 2 multicast forwarding.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping query interval query-interval
The general query interval is configured. This parameter determines the interval at which the
querier sends General Query messages.
By default, the general query interval is 125 seconds.
Step 4 Run:
igmp snooping robust-count robust-count
The IGMP robustness variable is configured. This parameter determines the query count.
By default, the robustness variable is 2.
Step 5 Run:
igmp snooping query max-response-time max-response-time
The maximum response time for General Query messages is set.
By default, the maximum response time for an IGMP Query message is 10 seconds.
Step 6 Run:
igmp snooping query last-member-interval last-member-interval
233
The last member query interval is configured. This parameter specifies the interval at which the
querier sends Group-Specific Query messages.
By default, the last member query interval is 1 second.
Step 7 Run:
commit
----End
7.7.2 Setting the Aging Time of Dynamic Router Ports
Context
A router port sends IGMP Report messages to an upstream Layer 3 device and receives multicast
packets from the upstream device. When IGMP snooping is enabled on a device, the device can
learn entries of the dynamic router port to monitor the sending of multicast data. When network
congestion or flapping occurs, the dynamic router port does not receive General IGMP Query
or PIM Hello messages before it times out. The switch deletes the interface from the router port
list, which may cause service interruption. To avoid this problem, set a longer aging time.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping router-aging-time router-aging-time
The aging time is set for dynamic router ports.
By default, the aging time of router ports that the switch learns from General IGMP Query
messages is 180 seconds. By default, the aging time of router ports that the switch learns from
PIM Hello messages is the Holdtime value in PIM Hello messages.
Step 4 Run:
commit
----End
7.7.3 Configuring Fast Leave for Member Ports
234
Context
The fast leave function enables the switch to delete the multicast forwarding entry corresponding
to an interface immediately after the interface receives an IGMP Leave message, without waiting
for the aging of the forwarding entry.
NOTE
l Enable fast leave for member ports in the VLAN only when each interface in a VLAN is connected to
one receiver host.
l Prompt leave takes effect for member ports in a VLAN only when the switch can process IGMPv2 or
IGMPv3 messages.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping prompt-leave [ group-policy { acl-number | acl-name acl-name }]
Prompt leave is configured on the member port.
By default, no member port is allowed to fast leave a multicast group.
You can limit the number of member ports that fast leave a multicast group by using the group-
policy parameter. In this case, create an ACL and configure an ACL rule. The default ACL rule
permit is applicable to all multicast groups. Therefore, to enable the member ports to fast leave
a specified multicast group, run the rule deny source any command. For details on how to
configure an ACL, see "ACL Configuration" in the CloudEngine 6800&5800 Series Switches
Configuration Guide - Security.
Step 4 Run:
commit
----End
7.7.4 Sending IGMP Query Messages upon Topology Changes
Context
When a Layer 2 network topology changes, the forwarding path of multicast packets may change.
When a fault occurs on a link, the switch sends IGMP Query messages and the multicast members
reply with IGMP Report messages. The switch then updates information about multicast member
ports based on the IGMP Report messages. In this manner, multicast packets can be quickly
switched to new forwarding paths.
235
Procedure
Step 1 Run:
system-view
Step 2 Run:
igmp snooping send-query enable
IGMP Query messages are sent upon topology changes.
By default, the switch is disabled from sending IGMP Query messages upon topology changes.
This command enables the switch to send IGMP Query messages (the source IP address is
192.168.0.1 by default) upon topology changes, and quickly update information about multicast
member ports, so that multicast packets to the downstream members are interrupted only for a
short period.
igmp snooping send-query source-address ip-address
The source IP address of an IGMP General Query message is configured.
By default, the source IP address of an IGMP General Query message sent upon topology
changes is 192.168.0.1. If this IP address is used by other devices on the network, you can use
this command to set another IP address.
Step 4 Run:
commit
----End
Prerequisites
After the configuration of membership fast-update is complete, you can run the following
commands in any view to check the IGMP snooping configuration and forwarding entries.
Procedure
IGMP snooping configuration.
----End
7.8 Configuring IGMP Snooping SSM Mapping
If user hosts on a Layer 2 network run only IGMPv1 or IGMPv2, enable SSM mapping on the
switch to provide SSM services for these hosts.
236
7.8.2 Configuring IGMP Snooping SSM Mapping is mandatory and 7.8.1 (Optional)
Configuring an SSM Group Policy is optional.
7.8.1 (Optional) Configuring an SSM Group Policy
Context
By default, the address of an SSM group ranges from 232.0.0.0 to 232.255.255.255. If a user
joins a multicast group whose IP address is not in this range, configure an SSM group policy in
the VLAN to add the multicast group address to the range of SSM group addresses. The SSM
group policy must be used together with an ACL. For details on how to configure an ACL, see
"ACL Configuration" in the CloudEngine 6800&5800 Series Switches Configuration Guide -
Security.
NOTE
By default, the ACL applied to an SSM group policy denies all multicast groups. Therefore, to exclude
specific group addresses from the SSM group address range, use a rule permit source any rule with
deny rules in the ACL.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping ssm-policy { basic-acl-number | acl-name acl-name }
An SSM group policy is configured.
After you configure an SSM group policy, the multicast groups specified in the SSM policy are
considered as SSM groups.
Step 4 Run:
commit
----End
7.8.2 Configuring IGMP Snooping SSM Mapping
237
Context
l By configuring SSM mapping, you can set up one-to-one mappings between multicast
groups and multicast sources.
l SSM mapping applies only to the scenario where IGMP snooping in the VLAN can process
IGMPv3 messages.
l Although SSM mapping takes effect only for IGMPv3 messages in a VLAN, the switch
does not convert IGMPv2 messages into IGMPv3 messages before sending the messages
to router ports. You can configure IGMP snooping proxy or IGMP snooping Report
suppression on the switch to enable the switch to send IGMPv3 messages to the upstream
device.
Procedure
Step 1 Run:
system-view
Step 2 Run:
vlan vlan-id
Step 3 Run:
igmp snooping version 3
The version of IGMP snooping run in the VLAN is set to 3.
The default version number of IGMP snooping is 2, but IGMPv2 version does not support SSM
mapping.
Step 4 Run:
igmp snooping ssm-mapping enable [ policy policy-name ]
SSM mapping is enabled in the VLAN.
By default, SSM mapping is disabled in a VLAN.
Step 5 Configure the mapping between a group address and a source address.
Group addresses used in the following steps are included in the SSM group address range. For
details on how to configure an SSM group address range, see 7.8.1 (Optional) Configuring an
SSM Group Policy.
l If you do not specify policy policy-name in Step 4, run the igmp snooping ssm-mapping
group-address { group-mask | mask-length } source-address command to configure the
mapping between a group address and a source address.
l If you specify policy policy-name in Step 4, perform the following steps:
1. Run the quit command to return to the system view.
2. Run the ssm-mapping policy command to enter the SSM mapping policy view.
3. Run the group command to configure the mapping between a group address and a
source address.
The mapping configured in the SSM mapping policy view can be applied to multiple VLANs,
whereas the mapping configured in the VLAN view takes effect only in the current VLAN. To
238
apply the same mapping to multiple VLANs, you are advised to configure an SSM mapping
policy.
Step 6 Run:
commit
----End
Context
After configuring SSM mapping, run the following command in any view to check the
configured SSM mapping entries.
Procedure
address ] ] [ verbose ] command to check entries on the interface.
----End
7.9 Maintaining IGMP Snooping
You can maintain the IGMP snooping feature by clearing IGMP snooping entries, clearing IGMP
snooping statistics, and monitoring IGMP snooping running status.
7.9.1 Clearing IGMP Snooping Entries
Context
IGMP snooping entries are classified into static and dynamic entries, and they are cleared in
different ways.
CAUTION
Static entries cannot be restored after being cleared and can be created when you configure static
member ports.
When dynamic entries in a forwarding table are cleared, the hosts in the VLAN do not receive
the multicast packets temporarily. The hosts in the VLAN receive the multicast packets again
only after the hosts send IGMP Report messages and the forwarding entries are regenerated on
the switch.
239
Procedure
l Run the undo igmp snooping static-group [ source-address source-ip-address ] group-
address group-ip-address vlan { all | { vlan-id1 [ to vlan-id2 ] } &<1-10> } command in
the interface view to remove the interface from a multicast group.
You can run the following commands to batch remove the multicast group addresses that
the interface joins.
undo igmp snooping static-group [ source-address source-ip-address ] group-
address group-ip-address1 to group-ip-address2 vlan vlan-id
undo igmp snooping static-group [ source-address source-ip-address ] group-
address all vlan { all | { vlan-id1 [ to vlan-id2 ] } &<1-10> }
l Run the reset igmp snooping group { all | vlan { all | vlan-id } } command in the user
view to remove dynamic entries in a forwarding table.
----End
7.9.2 Clearing IGMP Snooping Statistics
Context
IGMP snooping statistics include the number of IGMP Report, Leave, and Query messages
received in a VLAN. To collect IGMP snooping statistics in a period of time, run the reset
command to set the IGMP snooping statistics to 0.
CAUTION
IGMP snooping statistics cannot be restored after being cleared. Exercise caution when you use
the command.
Procedure
l Run the reset igmp snooping statistics { all | vlan { vlan-id | all } } command in the user
view to clear IGMP snooping statistics.
----End
7.9.3 Displaying the IGMP Snooping Running Status
Context
To check the IGMP snooping running status during routine maintenance, run the following
display commands in any view. You can check the configuration information, information about
member ports and router ports, packet statistics and forwarding entries.
Procedure
l Run the display igmp snooping [ vlan [ vlan-id ] ] command to check all the IGMP
snooping running parameters in a VLAN.
240
IGMP snooping configuration in a VLAN.
address ] ] [ verbose ] command to check information about member ports.
l Run the display igmp snooping router-port vlan vlan-id command to check information
about router ports.
l Run the display igmp snooping querier vlan [ vlan-id ] command to check information
about the IGMP snooping querier.
l Run the display igmp snooping statistics vlan [ vlan-id ] command to check IGMP
snooping statistics.
l Run the display multicast layer-2 forwarding-mode vlan [ vlan-id ] command to check
the multicast forwarding mode.
l Run the display igmp snooping group interface interface-type interface-number vlan
vlan-id [ [ source-address source-address ] group-address group-address ] command to
check information about multicast groups that are learned dynamically.
----End
This section provides IGMP snooping configuration examples to help you configure basic IGMP
snooping functions, static interfaces, an IGMP snooping querier, an IGMP snooping proxy, and
Layer 2 multicast SSM mapping on an IPv4 multicast network.
7.10.1 Example for Configuring IGMP Snooping
As shown in Figure 7-2, Router connects to user hosts through a Layer 2 Switch and Router
runs IGMPv2. The multicast source sends data to multicast groups 225.1.1.1 to 225.1.1.5. On
the network, there are three receivers HostA, HostB, and HostC and the three hosts only want
to receive data of multicast groups 225.1.1.1 to 225.1.1.3.
241
Figure 7-2 Networking diagram for IGMP snooping configuration
VLAN10
10GE1/0/1
Switch
10GE1/0/3
Source
IP/MPLS core
Router
10GE1/0/2
HostA HostB
HostC

To meet the preceding requirements, configure basic IGMP snooping functions and a multicast
group policy on the Layer 2 Switch. The configuration roadmap is as follows:
1. On the Switch, create a VLAN and add interfaces to the VLAN.
2. Enable IGMP snooping globally and in the VLAN.
3. Configure a multicast group policy and apply this policy to the VLAN.
Procedure
Step 1 Create a VLAN and add interfaces to the VLAN.
<HUAWEI> system-view
[~HUAWEI] sysname Switch
[~HUAWEI] commit
[~Switch] vlan 10
[~Switch-vlan10] quit
[~Switch] interface 10ge 1/0/1
[~Switch-10GE1/0/1] port default vlan 10
[~Switch-10GE1/0/1] quit
[~Switch-10GE1/0/3] port link-type trunk
[~Switch-10GE1/0/3] port trunk allow-pass vlan 10
[~Switch-10GE1/0/3] commit
242
Step 2 Enable IGMP snooping.
# Enable IGMP snooping globally.
[~Switch] igmp snooping enable
# Enable IGMP snooping in VLAN 10.
[~Switch] vlan 10
[~Switch-vlan10] igmp snooping enable
[~Switch-vlan10] commit
Step 3 Configure a multicast group policy and apply this policy.
# Configure a multicast group policy.
[~Switch] acl 2000
[~Switch-acl4-basic-2000] rule deny source 225.1.1.4 0
[~Switch-acl4-basic-2000] rule deny source 225.1.1.5 0
[~Switch-acl4-basic-2000] commit
[~Switch-acl4-basic-2000] quit
# Apply the multicast group policy in VLAN 10.
[~Switch] vlan 10
[~Switch-vlan10] igmp snooping group-policy 2000
# Check the interface information on the Switch.
<Switch> display igmp snooping port-info vlan 10
-------------------------------------------------------------------------------
Flag: S:Static D:Dynamic M:Ssm-mapping
A:Active P:Protocol F:Fast-channel
(Source, Group) Port Flag
-------------------------------------------------------------------------------
VLAN 10, 3 Entry(s)
(*, 225.1.1.1) P--
10GE1/0/1 D--
10GE1/0/2 D--
2 port(s) include
(*, 225.1.1.2) P--
10GE1/0/1 D--
10GE1/0/2 D--
2 port(s) include
(*, 225.1.1.3) P--
10GE1/0/1 D--
10GE1/0/2 D--
2 port(s) include
-----------------------------------------------------------------------
The command output shows that multicast groups 225.1.1.1 to 225.1.1.3 have dynamically
generated member ports 10GE1/0/1 and 10GE1/0/2 on the Switch.
# Check the Layer 2 multicast forwarding table on the Switch.
<Switch> display multicast layer-2 ip fib vlan 10
------------------------------------------------------------------------------
Forwarding Mode: IP
VLAN Total (Source,Group) Interface
------------------------------------------------------------------------------
10 3
(*, 225.1.1.1) 10GE1/0/1
10GE1/0/2
(*, 225.1.1.2) 10GE1/0/1
243
10GE1/0/2
(*, 225.1.1.3) 10GE1/0/1
10GE1/0/2
------------------------------------------------------------------------------
The command output shows that the forwarding table contains only information about multicast
groups 225.1.1.1 to 225.1.1.3. The multicast groups 225.1.1.4 to 225.1.1.5 do not forward data
to the hosts.
----End
Configuration Files
l Configuration file of the Switch
#
sysname Switch
#
vlan batch 10
#
#
acl number 2000
#
vlan 10
igmp snooping group-policy 2000
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
return
7.10.2 Example for Configuring Layer 2 Multicast Through Static
Interfaces
As shown in Figure 7-3, Router connects to user hosts through a Layer 2 swtich. The user-side
VLANIF interface of Router has static groups 225.1.1.1 to 225.1.1.5 configured and does not
run IGMP. There are four receivers on the network: HostA, HostB, HostC, and HostD. HostA
and HostB expect to receive data of multicast groups 225.1.1.1 to 225.1.1.3 for long time. HostC
and HostD expect to receive data of multicast groups 225.1.1.4 to 225.1.1.5.
244
Figure 7-3 Networking diagram for Layer 2 multicast configuration through static interfaces
VLAN10
10GE1/0/1
Switch
10GE1/0/3
10GE1/0/2
Source
Router
HostA HostB HostC HostD
IP/MPLS core

To meet the preceding requirements, configure a static router port and static member ports of
IGMP snooping on the Layer 2 Switch. The configuration roadmap is as follows:
3. Configure a static router port.
4. Configure static member ports.
Procedure
HUAWEI> system-view
[~HUAWEI] commit
[~Switch] vlan 10
245
[~Switch] vlan 10
Step 3 Configure a static router port.
[~Switch] interface 10GE 1/0/3
[~Switch-10GE1/0/3] igmp snooping static-router-port vlan 10
Step 4 Configure static member ports.
[~Switch-10GE1/0/1] igmp snooping static-group group-address 225.1.1.1 to
225.1.1.3 vlan 10
[~Switch-10GE1/0/2] igmp snooping static-group group-address 225.1.1.4 to
225.1.1.5 vlan 10
# Check the router port information on the Switch.
<Switch> display igmp snooping router-port vlan 10
Port Name UpTime Expires Flags
---------------------------------------------------------------------
VLAN 10, 1 router-port(s)
10GE1/0/3 00h20m09s -- STATIC
The command output shows that 10GE1/0/3 has been configured as static router port.
# Check the member port information on the Switch.
<Switch> display igmp snooping port-info vlan 10
-------------------------------------------------------------------------------
Flag: S:Static D:Dynamic M:Ssm-mapping
A:Active P:Protocol F:Fast-channel
(Source, Group) Port Flag
-------------------------------------------------------------------------------
VLAN 10, 3 Entry(s)
(*, 225.1.1.1) P--
10GE1/0/1 S--
1 port(s) include
(*, 225.1.1.2) P--
10GE1/0/1 S--
1 port(s) include
(*, 225.1.1.3) P--
10GE1/0/1 S--
1 port(s) include
(*, 225.1.1.4) P--
10GE1/0/2 S--
1 port(s) include
(*, 225.1.1.5) P--
10GE1/0/2 S--
246
1 port(s) include
-----------------------------------------------------------------------
The command output shows that multicast groups 225.1.1.1 to 225.1.1.3 have a static member
port 10GE1/0/1 on the Switch and multicast groups 225.1.1.4 to 225.1.1.5 have a static member
port 10GE1/0/2 on the Switch.
# Check the Layer 2 multicast forwarding table on the Switch.
------------------------------------------------------------------------------
Forwarding Mode: IP
------------------------------------------------------------------------------
10 5
(*, 225.1.1.1) 10GE1/0/1
(*, 225.1.1.2) 10GE1/0/1
(*, 225.1.1.3) 10GE1/0/1
(*, 225.1.1.4) 10GE1/0/2
(*, 225.1.1.5) 10GE1/0/2
------------------------------------------------------------------------------
The command output shows that multicast groups 225.1.1.1 to 225.1.1.5 have a forwarding table
on the Switch.
----End
Configuration Files
#
sysname Switch
#
vlan batch 10
#
#
vlan 10
#
interface 10GE1/0/1
igmp snooping static-group group-address 225.1.1.1 to 225.1.1.3 vlan 10
#
interface 10GE1/0/2
igmp snooping static-group group-address 225.1.1.4 to 225.1.1.5 vlan 10
#
interface 10GE1/0/3
igmp snooping static-router-port vlan 10
#
return
7.10.3 Example for Configuring an IGMP Snooping Querier
As shown in Figure 7-4, on a pure Layer 2 network, multicast sources Source1 and Source2
send multicast data to multicast groups 224.1.1.1 and 225.1.1.1. HostA and HostC expect to
receive data of multicast group 224.1.1.1 for long time, while HostB and HostD expect to receive
data of multicast group 225.1.1.1 for long time. All the hosts run IGMPv2.
247
Figure 7-4 Networking diagram for IGMP snooping querier configuration
VLAN10
SwitchA
Source1
SwitchB
SwitchD
SwitchC
Source2
HostA
HostD
HostB
HostC
10GE1/0/1 10GE1/0/2
10GE1/0/2
10GE1/0/3
10GE1/0/3
10GE1/0/4
10GE1/0/1 10GE1/0/2
10GE1/0/2
10GE1/0/1
10GE1/0/1
10GE1/0/3

To meet the preceding requirements, enable IGMP snooping on the four Switches and configure
an IGMP snooping querier. Enable all the Switches to discard unknown multicast packets to
prevent the Switches from broadcasting multicast data in the VLAN when there are no Layer 2
multicast forwarding entries on the Switches. The configuration roadmap is as follows:
1. On all the Switches, create a VLAN and add interfaces to the VLAN according to Figure
7-4.
2. Enable IGMP snooping globally and in the VLAN on all the Switches.
3. Configure SwitchA as an IGMP snooping querier.
4. Enable all the Switches to discard unknown multicast packets.
Procedure
Step 1 On all the Switches, create a VLAN and add interfaces to the VLAN.
# Configure SwitchA.
[~HUAWEI] sysname SwitchA
[~HUAWEI] commit
[~SwitchA] vlan 10
[~SwitchA-vlan10] quit
248
[~SwitchA-10GE1/0/3] commit
# The configurations of SwitchB, SwitchC and SwitchD are similar to the configuration of
SwitchA, and are not mentioned here.
Step 2 Enable IGMP snooping globally and in the VLAN on all the Switches.
[~SwitchA] igmp snooping enable
[~SwitchA] vlan 10
[~SwitchA-vlan10] igmp snooping enable
[~SwitchA-vlan10] commit
Step 3 Configure SwitchA as an IGMP snooping querier.
[~SwitchA] vlan 10
[~SwitchA-vlan10] igmp snooping querier enable
Step 4 Enable all the Switches to discard unknown multicast packets.
[~SwitchA] vlan 10
[~SwitchA-vlan10] multicast drop-unknown
# When the IGMP snooping querier begins to work, all the Switches except the IGMP snooping
querier receive IGMP General Query messages. Run the display igmp snooping statistics vlan
10 command on SwitchB to view IGMP message statistics. The command output is as follows:
<SwitchB> display igmp snooping statistics vlan 10
IGMP Snooping Packets Counter:
Statistics for VLAN 10
Receive V1 Report:
0
Receive V2 Report:
32
Receive V3 Report:
0
Receive V1 Query:
0
Recv V2 Query: 30
Receive V3 Query:
0
Receive Leave:
0
Receive Pim Hello:
0
Send Query (S=0):
0
Send Query (S!=0):
-
Proxy Send General Query: 0
249
Proxy Send Group-Specific Query: 0
Proxy Send Group-Source-Specific Query: 0
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
#
vlan 10
igmp snooping querier enable
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
return
#
sysname SwitchB
#
vlan batch 10
#
#
vlan 10
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
return
#
sysname SwitchC
#
vlan batch 10
#
#
250
vlan 10
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
return
#
sysname SwitchD
#
vlan batch 10
#
#
vlan 10
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
7.10.4 Example for Configuring IGMP Snooping Proxy
As shown in Figure 7-5, Router connects to user hosts through a Layer 2 Switch and Router
runs IGMPv2. There are multiple receiver hosts on the network, and the administrator expects
that exchange of IGMP messages will not be a burden to Router.
251
Figure 7-5 Networking diagram for the IGMP snooping proxy configuration
VLAN10
10GE1/0/1
Switch
10GE1/0/3
10GE1/0/2
Source
Router
HostA HostG HostH HostN
IP/MPLS core
...
...

To meet the preceding requirements, configure IGMP snooping proxy on the Switch. The
configuration roadmap is as follows:
1. Create a VLAN and add interfaces to the VLAN.
3. Configure IGMP snooping proxy on the Switch to reduce packet exchange between the
Switch and Router.
4. Disable the Switch from sending IGMP Query messages to the upstream Router to prevent
election of the IGMP querier.
Procedure
[~HUAWEI] commit
[~Switch] vlan 10
252
[~Switch] vlan 10
# Configure IGMPv3 snooping to enable the Switch to process IGMP messages of all versions.
[~Switch-vlan10] igmp snooping version 3
Step 3 Enable IGMP snooping proxy.
[~Switch-vlan10] igmp snooping proxy
Step 4 Disable the Switch from sending IGMP Query messages to the upstream Router.
[~Switch-10GE1/0/3] igmp snooping proxy-uplink-port vlan 10
# Check IGMP message statistics on the Switch.
<SwitchB> display igmp snooping statistics vlan 10
IGMP Snooping Packets Counter:
Statistics for VLAN 10
Receive V1 Report:
0
Receive V2 Report:
121
Receive V3 Report:
0
Receive V1 Query:
0
Receive V2 Query: 0
Receive V3 Query:
0
Receive Leave:
82
Receive Pim Hello:
0
Send Query (S=0):
0
Send Query (S!=0):
-
Proxy Send General Query:
135
Proxy Send Group-Specific Query: 95
Proxy Send Group-Source-Specific Query: 0
The command output shows that the IGMP snooping proxy takes effect as the Switch functions
as a proxy to send IGMP General Query messages.
----End
253
Configuration Files
#
sysname Switch
#
vlan batch 10
#
#
vlan 10
igmp snooping proxy
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
igmp snooping proxy-uplink-port vlan 10
#
return
7.10.5 Example for Configuring Multicast SSM Mapping
As shown in Figure 7-6, Router connects to user hosts through a Layer 2 Switch. Router runs
IGMPv3 and uses the ASM mode and SSM mode to provide multicast services. User hosts
HostA, HostB, and HostC on the network run IGMPv2 and do not support IGMPv3. The
multicast sources Source1 and Source2 send multicast data to the multicast group 225.1.1.1, but
the user hosts want to receive only the multicast data sent from Source1.
254
Figure 7-6 Networking diagram for the SSM mapping configuration
VLAN10
10GE1/0/1
Switch
10GE1/0/3
Source1
Router
IP/MPLS core
Source2
10.10.1.1
10.10.2.1
HostA HostB HostC

To meet the preceding requirements, configure SSM mapping on the Switch. The configuration
roadmap is as follows:
3. Configure an IGMP snooping SSM policy to add the multicast address of the ASM mode
to the SSM group address range.
4. Configure SSM mapping to allow the users to receive only multicast data sent from the
specified source.
Procedure
[~HUAWEI] commit
[~Switch] vlan 10
255
[~Switch] vlan 10
Step 3 Configure an IGMP snooping SSM policy.
# Create an ACL, and configure a rule that allows hosts to receive data of multicast group
225.1.1.1.
[~SwitchA-acl4-basic-2008] rule 5 permit source 225.1.1.1 0
# Apply the SSM mapping policy in the VLAN and treat the multicast group 225.1.1.1 as a
member in the SSM groups.
[~SwitchA] vlan 10
[~SwitchA-vlan10] igmp snooping ssm-policy 2008
Step 4 Enable SSM mapping.
# Configure the Switch to run IGMPv3, enable SSM mapping, and configure a mapping between
the multicast group 225.1.1.1 and the source IP address 10.10.1.1.
[~SwitchA-vlan10] igmp snooping version 3
[~SwitchA-vlan10] igmp snooping ssm-mapping enable
[~SwitchA-vlan10] igmp snooping ssm-mapping 225.1.1.1 32 10.10.1.1
# Check the IGMP snooping configuration in the VLAN.
<Switch> display igmp snooping vlan configuration
IGMP Snooping Configuration for VLAN 10
igmp snooping ssm-mapping enable
igmp snooping ssm-policy 2008
igmp snooping ssm-mapping 225.1.1.1 255.255.255.255 10.10.1.1
An SSM mapping policy has been configured in VLAN 10.
# Check the Layer 2 multicast forwarding table.
------------------------------------------------------------------------------
Forwarding Mode: IP
------------------------------------------------------------------------------
10 1
(10.10.1.1, 225.1.1.1) 10GE1/0/1
------------------------------------------------------------------------------
256
The command output shows that a mapping entry (10.10.1.1, 225.1 .1.1) has been generated on
the Switch. The mapping entry indicates that the data is sent by Source1.
----End
Configuration Files
#
sysname Switch
#
vlan batch 10
#
#
acl number 2008
rule 5 permit source 225.1.1.1 0
#
vlan 10
igmp snooping ssm-mapping enable
igmp snooping ssm-policy 2008
igmp snooping ssm-mapping 225.1.1.1 255.255.255.255 10.10.1.1
#
interface 10GE1/0/1
#
interface 10GE1/0/3
#
return
This section describes common faults caused by incorrect IGMP snooping configurations and
provides the troubleshooting procedure.
7.11.1 Layer 2 Multicast Packets Cannot Be Forwarded
Fault Description
Multicast packets can be forwarded normally when IGMP snooping is not configured. However,
users cannot receive multicast packets after IGMP snooping is configured.
Procedure
Step 1 Check whether the IGMP snooping version configured on the device is earlier than that running
on user hosts.
If the IGMP snooping version configured on the device is earlier than that running on user hosts,
the device only forward IGMP Report messages to router ports and does not generate group
member ports and forwarding entries.
Run the display igmp snooping configuration command to check the IGMP snooping
configuration. If the IGMP snooping version configured on the device is earlier than that running
257
on user hosts, run the igmp snooping version version command to make the device run the same
IGMP version as user hosts.
Step 2 Check whether router port dynamic learning is disabled.
The switch does not listen to IGMP Query messages in a VLAN after router port dynamic
learning is disabled in the VLAN.
Run the display igmp snooping configuration command to check whether router port dynamic
learning is disabled. If the command output contains "igmp snooping router-learning disable",
run the undo igmp snooping router-learning disable command to enable dynamic learning of
router ports in the VLAN.
Step 3 Check whether fast leave for member ports is enabled.
Configure fast leave in a VLAN only when each interface in the VLAN connects to only one
host. If a member port is connected to multiple hosts and fast leave for member ports is enabled
in the VLAN, the switch immediately deletes the forwarding entry of the member port after
receiving an IGMP Leave message from the member port, and does not send a Group-Specific
Query message. Therefore, multicast packets cannot be forwarded.
Run the display igmp snooping configuration command to check whether fast leave for
member ports is enabled. If the command output contains "igmp snooping prompt-leave", run
the undo igmp snooping prompt-leave command in the VLAN view to disable the fast leave
function.
Step 4 Check whether the Router-Alert option is configured.
If the Router-Alert option is configured, the switch checks the Option field of IGMP messages
to discard messages without the Router-Alert option.
Run the display igmp snooping configuration command to check whether the Router-Alert
option is configured. If the command output contains "igmp snooping require-router-alert", run
the undo igmp snooping require-router-alert command in the VLAN view to delete the related
configuration.
Step 5 Check whether a multicast group policy is configured.
The multicast group policy limits the multicast groups that the hosts in a VLAN can join. Run
the display igmp snooping configuration command to verify the configuration of multicast
group policy. If an ACL rule is configured, run the display acl command to verify the
configuration of ACL rule.
Step 6 Check whether the Layer 2 multicast filtering function is configured.
If the Layer 2 multicast filtering function is configured on the interface, the interface discards
the UDP packets from the specified VLAN.
Run the undo multicast deny-vlan command in the physical interface view to disable the Layer
2 multicast filtering function.
----End
7.11.2 The Multicast Group Policy Does Not Take Effect
258
Fault Description
A multicast policy is configured on the switch to allow the hosts to join the specified multicast
groups. However, the hosts can still receive multicast data sent to other multicast groups.
Procedure
Step 1 Run the display acl command to check whether the ACL rules conflict with the multicast group
policy.
Step 2 Run the display igmp snooping configuration command to check whether a correct multicast
group policy is applied in the VLAN. If not, run the igmp snooping group-policy command to
apply a correct multicast group policy in the VLAN.
Step 3 Run the display current-configuration | include drop-unknown command to check whether
the switch is enabled to discard unknown multicast packets. If not, run the multicast drop-
unknown command to enable the switch to discard unknown multicast packets.
----End
259
8 Static Multicast MAC Address
Configuration
About This Chapter
You can manually configure mappings between multicast MAC addresses and interfaces on the
Layer 2 devices. Multicast packets destined for the specified multicast MAC address are
forwarded to these interfaces. This reduces broadcast packets on a Layer 2 network.
8.1 Multicast MAC Address
As defined by Ethernet frame, the 40th bit "1" in 48-bit MAC addresses indicates that it is a
multicast MAC address.
8.2 Configuring a Static Multicast MAC Address
After a static multicast MAC address is configured on interfaces, multicast packets destined for
the multicast MAC address are forwarded only to the interfaces.
8.3 Example for Configuring a Static Multicast MAC Address
This section provides an example for configuring a static multicast MAC address.
Configuration Guide - IP Multicast 8 Static Multicast MAC Address Configuration
260
8.1 Multicast MAC Address
As defined by Ethernet frame, the 40th bit "1" in 48-bit MAC addresses indicates that it is a
multicast MAC address.
NOTE
Because static multicast MAC address is a Layer 2 multicast feature, all the static multicast MAC address
configurations on interfaces mentioned in this chapter are performed on Layer 2 physical interfaces,
including Eth-Trunk interfaces.
When unicast IP packets are transmitted on an Ethernet network, destination MAC addresses
encapsulated in the packets at the link layer are the receiver MAC addresses. However, the
destination of a multicast data packet is a group with changeable members but not a specific
receiver. Therefore, multicast data packets must use multicast MAC addresses at the data link
layer. As defined in the IEEE 802.3 standard, the lowest bit in the high byte of the MAC address
is the multicast address flag. The bit is 1, representing the multicast MAC address. The broadcast
MAC address can be taken as a special type of multicast and is expressed in the format of
0xFFFF-FFFF-FFFF.
Figure 8-1 Multicast MAC address
XXXXXXX1
48-bit MAC address
7 0 7 0
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
7 0 7 0 7 0 7 0
Multicast Bit

As defined by the IANA, leftmost 24 bits of an IPv4 multicast MAC address are 0x01005E, the
25th bit is 0, and the rightmost 23 bits are the same as the rightmost 23 bits of a multicast IPv4
address, as shown in Figure 8-2. For example, if the IPv4 multicast address of a group is
224.0.1.1, the IPv4 multicast MAC address of this group is 01-00-5E-00-01-01.
Figure 8-2 Mapping between an IPv4 multicast address and an IPv4 multicast MAC address
25 bits MAC address prefix
XXXX X
1110 XXXX X XXXXXXX XXXXXXXX XXXXXXXX
00000001 00000000 01011110 0 XXXXXXX XXXXXXXX XXXXXXXX
48-bit MAC address
5 bits information loss
23 bits
mapping
...... ......
32-bit IP address
261

8.2 Configuring a Static Multicast MAC Address
After a static multicast MAC address is configured on interfaces, multicast packets destined for
the multicast MAC address are forwarded only to the interfaces.
Before configuring a static multicast MAC address, complete the following task:
l Creating a VLAN and adding the interface that needs to be configured with a static multicast
MAC address to the VLAN
Context
By default, Layer 2 devices broadcast all the received multicast data packets in VLANs. This
wastes network bandwidth and threatens network security. To suppress broadcast packets, you
can configure IGMP snooping on the switch to create Layer 2 multicast forwarding entries or
manually configure multicast MAC addresses on interfaces to create multicast MAC address
entries.
After static multicast MAC addresses are configured on interfaces, multicast packets destined
for a multicast MAC address are forwarded only to interfaces configured with this multicast
MAC address in a VLAN.
Pay attention to the following points when configuring a static multicast MAC address:
l The MAC address specified in the command must be a multicast MAC address with the
leftmost bit as 1 (xxxx xxx1). MAC addresses starting with 0x01 are recommended.
l The VLAN specified in the command cannot be a super-VLAN.
l If the switch uses MAC address based multicast forwarding mode, static groups configured
on an interface using the igmp snooping static-group command implement the same
function as static multicast MAC addresses configured on the interface.
l The following table lists the scenarios where IPv4 multicast MAC addresses (first 24 bits
are 0x0100-5e and bit 25 is 0) are valid.
Scenario No other
multicast
services
configured
Layer 3
multicast or
both Layer 2
and Layer 3
multicast
configured
IP address
based Layer 2
multicast
forwarding
MAC address
based Layer 2
multicast
forwarding
Valid or
invalid
Valid Valid Valid Valid, but may
cause conflicts

A conflict occurs in the following situation: If IGMP snooping is enabled and Layer 2
multicast forwarding mode is set to MAC address based mode, the switch generates IPv4
multicast MAC address entries. When a static multicast MAC address is configured, a
262
conflict may occur, causing data forwarding errors. Therefore, you are advised not to
configure static multicast MAC address in this situation.
Procedure
Step 1 Run:
system-view
Step 2 Configure a static multicast MAC address using the following two methods:
l Configure a static multicast MAC address on an interface:
1. Run:
2. Run:
mac-address multicast mac-address vlan vlan-id
A multicast MAC address is configured on an interface.
l Configure a static multicast MAC address on multiple interfaces:
Run:
mac-address multicast mac-address interface { interface-type interface-number1
[ to interface-type interface-number2 ] } &<1-10> vlan vlan-id
A static multicast MAC address is configured on multiple interfaces.
The interface numbers must be consecutive. interface-number2 must be greater than
interface-number1.
Step 3 Run:
commit
----End
After the configuration is complete, run the following commands in any view to check
configuration of static multicast MAC addresses.
l Run the display mac-address multicast [ [ mac-address ] vlan vlan-id ] command to check
the configured static multicast MAC address entries.
l Run the display mac-address multicast [ vlan vlan-id ] total-number command to check
the number of configured static multicast MAC address entries.
8.3 Example for Configuring a Static Multicast MAC
Address
This section provides an example for configuring a static multicast MAC address.
263
As shown in Figure 8-3, the Router connects to a user network through the Switch. There are
three receivers on the network: HostA, HostB, and HostC. As service requires, HostA and HostC
receive packets with destination address 0x0100-5A0A-0A0A but HostB cannot.
Figure 8-3 Networking diagram for configuring a static multicast MAC address
VLAN10
10GE1/0/1
Switch
10GE1/0/4
10GE1/0/2
Source
Router
HostA HostC
IP/MPLS core
10GE1/0/3
HostB

To meet the preceding requirement, configure static multicast MAC addresses on the Layer 2
Switch. The configuration roadmap is as follows:
1. Create a VLAN on the Switch and add interfaces to the VLAN.
2. Configure the static multicast MAC address: 0x0100-5A0A-0A0A on 10GE1/0/1 and
10GE1/0/2.
Procedure
Step 1 Create a VLAN and add the interface to the VLAN.
[~HUAWEI] commit
[~Switch] vlan 10
264
[~Switch] commit
Step 2 Configure a static multicast MAC address.
[~Switch-10GE1/0/1] mac-address multicast 0100-5a0a-0a0a vlan 10
[~Switch-10GE1/0/2] mac-address multicast 0100-5a0a-0a0a vlan 10
[~Switch] commit
# Display configured MAC address entries.
<Switch> display mac-address multicast
--------------------------------------------------------------------
MAC Address VLANID Out-Interface
--------------------------------------------------------------------
0100-5a0a-0a0a 10 10GE1/0/1
0100-5a0a-0a0a 10 10GE1/0/2
2 port(s)
--------------------------------------------------------------------
Total Group(s) : 2
The command output shows that static multicast MAC address entries are configured on
10GE1/0/1 and 10GE1/0/2.
----End
Configuration Files
#
sysname Switch
#
vlan batch 10
#
interface 10GE1/0/1
mac-address multicast 0100-5a0a-0a0a vlan 10
#
interface 10GE1/0/2
mac-address multicast 0100-5a0a-0a0a vlan 10
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
return
265
9 Multicast Network Management
About This Chapter
A network management workstation is used to manage multicast devices.
9.1 Overview of Multicast Network Management
A multicast MIB manages multicast information exchanged between the NMS and managed
devices.
9.2 Multicast Network Management Features Supported by the Switch
The system supports multicast network management includes configuring basic functions of
multicast network management and adjusting the frequency for each multicast protocol to send
trap messages.
9.3 Configuring Multicast Network Management
You can enable the alarm function for a specified module to monitor events of the specified
protocol.
Configuration Guide - IP Multicast 9 Multicast Network Management
266
9.1 Overview of Multicast Network Management
A multicast MIB manages multicast information exchanged between the NMS and managed
devices.
At present, with the increasingly wide application of IP multicast, the requirement for managing
multicast networks becomes more exigent. After multicast network management is enabled, you
can manage multicast switchs through the Network Management Station (NMS).
By means of the Simple Network Management Protocol (SNMP), Multicast Management
Information Base (MIB) manages multicast information exchanged between the NMS and
agents. Multicast MIB supports the basic SNMP operations, such as Get-Request, GetNext-
Request, Set-Request, and Trap.
9.2 Multicast Network Management Features Supported by
the Switch
The system supports multicast network management includes configuring basic functions of
multicast network management and adjusting the frequency for each multicast protocol to send
trap messages.
Basic Functions of Multicast Network Management
After multicast network management is enabled, you can bind multicast MIB to the public
network instance, or enable the trap function of a specified module as required so that you can
monitor the current status of the protocol event. At present, the MIBs of the following objects
are supported. Configure these MIBs as required:
l PIM
l MSDP
Adjusting the Frequency for Multicast Protocols to Send Trap Messages
By adjusting the frequency for each multicast protocol to send trap messages, you can know the
current statuses of various multicast events on the switches in real time. At present, the switch
supports adjusting the frequency for PIM protocol to send trap messages.
9.3 Configuring Multicast Network Management
You can enable the alarm function for a specified module to monitor events of the specified
protocol.
Before configuring multicast network management, complete the following tasks:
Configuring basic multicast functions
9.3.1 Enabling Multicast Network Management
267
Context
Before configuring basic functions of multicast network management, enable multicast network
management. Do as follows on the switch managed by the NMS:
Procedure
Step 1 Run:
system-view
Step 2 Run:
multicast mib
The multicast MIB view is displayed and multicast network management is enabled.
After this function is enabled, multicast MIB is bound to the public network instance.
Step 3 Run:
commit
----End
9.3.2 Enabling the Trap Function for a Specified Module
Context
You can enable the trap function for a specified module to monitor events of the specified
protocol. Perform the following steps on the switch that needs to be managed by the NMS.
Procedure
Step 1 Run:
system-view
Step 2 You can choose one or multiple operations to perform:
l Run the snmp-agent trap enable feature-name msdp [ trap-name { msdpestablished |
msdpbackwardtransition } ] command to enable the MSDP trap function.
By default, the MSDP trap function is disabled.
l Run the snmp-agent trap enable feature-name pim [ trap-name
{ hwpiminterfaceelection | hwpiminvalidjoinprune | hwpiminvalidregister |
hwpimneighboradd | hwpimneighborloss | hwpimrpmappingchange } ] command to
enable the PIM trap function.
By default, the PIM trap function is disabled.
l Run the snmp-agent trap enable feature-name pim-std [ trap-name { pimneighborloss
| piminvalidregister | piminvalidjoinprune | pimrpmappingchange |
piminterfaceelection } ] command to enable the public PIM trap function.
By default, the public PIM trap function is disabled.
268
Step 3 Run:
commit
----End
9.3.3 Adjusting the Interval for PIM to Send Trap Messages
Context
After PIM is enabled on the switches, you can configure PIM-MIB notifications to set the interval
for sending PIM events. Therefore, you can know the current status of various PIM events on
the switches in real time. The PIM events include the neighbor loss event, neighbor addition,
the event of receiving invalid Join/Prune messages, RP-mapping change event, event of the
interface being elected as the DR and the event of receiving invalid Register messages.
Do as follows on the switch managed by the NMS:
Procedure
Step 1 Run:
system-view
Step 2 Run:
multicast mib
The multicast MIB view is displayed.
Step 3 Run:
pim mib-notification interval { interface-election-dr election-value | invalid-
join-prune jp-value | invalid-register register-value | neighbor-loss loss-value |
new-neighbor new-value | rp-mapping-change change-value }
The interval for PIM to send trap messages is set.
By default, the interval for sending trap messages for neighbor lost and neighbor addition is 0
seconds. That is, once the event occurs, PIM reports it immediately.
The default interval for sending the trap of event of receiving invalid Join/Prune messages, the
RP-mapping change event, the event of the interface being elected as the DR or the event of
receiving invalid Register messages is 65535 seconds. After the events of these types occur,
PIM does not report them.
NOTE
To configure PIM to report these events, you can run the pim mib-notification interval command to set
an interval smaller than 65535 seconds.
Step 4 Run:
commit
----End
269
Procedure
l Run the display snmp-agent trap feature-name msdp all command to check the status
of the MSDP trap function.
l Run the display snmp-agent trap feature-name pim all command to check the status of
the PIM trap function.
l Run the display snmp-agent trap feature-name pim-std all command to check the status
of the public PIM trap function.
----End
270

CloudEngine 6800&5800 V100R001C00 Configuration Guide - Multicast 04 PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CloudEngine 6800&5800 V100R001C00 Configuration Guide - Multicast 04 PDF

Загружено:

Авторское право:

Доступные форматы

CloudEngine 6800&5800 Series Switches

Вам также может понравиться